Phase 0: CDK stack + Lambdas + AgentCore Runtime 1 scaffold
- CDK TypeScript stack (AgentClawStack): - S3 workspace bucket with BucketDeployment seed - DynamoDB session-store (actor_id → session_id, TTL) - SQS FIFO message queue (serialized per actor) - Lambda: tg-ingest (webhook validation, typing action, SQS enqueue) - Lambda: agent-runner (SQS → InvokeAgentRuntime, session management) - API Gateway HTTP: POST /telegram → tg-ingest - AgentCore Runtime 1 IAM execution role - CDK outputs: WebhookUrl, WorkspaceBucketName, Runtime1RoleArn - Runtime 1 (Python + Strands + BedrockAgentCoreApp): - main.py: entrypoint, Strands agent, tool wiring - channels/: ChannelAdapter Protocol + TelegramAdapter (decoupled) - tools/: web_search (Brave), web_fetch, read/write_workspace_file, send_message - prompt_builder.py: loads SOUL.md/AGENTS.md/USER.md from S3 (cached) - Lambdas: - tg-ingest: validate X-Telegram-Bot-Api-Secret-Token, send typing, enqueue FIFO - agent-runner: session lookup/create in DDB, bundle batched messages, InvokeAgentRuntime - workspace/: seed files (SOUL.md, AGENTS.md, USER.md, IDENTITY.md, HEARTBEAT.md) NOTE: AgentCore Runtime 1 creation via CfnResource deferred — deploy CDK first, create runtime manually with the output Role ARN, then redeploy with runtime1Arn context param.
This commit is contained in:
daniel
79
workspace/USER.md
Normal file
79
workspace/USER.md
Normal file
@@ -0,0 +1,79 @@
|
||||
<!-- L0: Daniel — AWS SA, factbase creator, communication prefs, infrastructure map -->
|
||||
# USER.md - About Your Human
|
||||
|
||||
- **Name:** Daniel
|
||||
- **What to call them:** Daniel
|
||||
- **Timezone:** America/Chicago (CST)
|
||||
- **Role:** Solutions Architect at AWS. Two concurrent OpenAI interview tracks (as of May 2026): (1) SE HCLS — HM call with Brendan O'Rourke completed May 1, outcome TBD; (2) Codex Specialist (Recon app built, awaiting Pro account activation).
|
||||
- **Notes:** Prefers brief answers. Leads with tasks and tools, expects you to execute and report back. Pushes back when you hedge — that's the process working, not a problem.
|
||||
|
||||
## Communication Style
|
||||
|
||||
- Brief over thorough. One paragraph beats three.
|
||||
- Wit is welcome; forced quips aren't.
|
||||
- Lead with the recommendation, not the options list.
|
||||
- Action-oriented: do the thing, report what happened.
|
||||
- Will react 👍 to approve. Treat it as a go signal, don't ask again.
|
||||
- **Feedback signal**: "a couple tweaks" / "drop X for this" = satisfied with direction, minor adjustment. A replacement directive ("just run the refresh now") = dissatisfied with approach, redirecting around me. The *form* of his feedback tells you how far off you are — tweaks mean you're close, redirection means the approach failed.
|
||||
- **"Try again" (repeated)** = acknowledged-but-not-applied. He's seen the correction described, still watching the same failure repeat. Different from "but i said X" (missed instruction) or "ok. kill it." (wrong frame). Costs him the most attention. Only fix: catch it structurally before the message is sent.
|
||||
- **Design collaboration pattern**: In creative/ideation sessions he's an active co-designer, not just an approver. "I like the multi-agent decision process from #4 but the practical outcomes from #10 — combine them" is a design directive with specific elements called out. Engage with those elements directly. Don't restart from zero or ask what he means.
|
||||
- **"Can we X?" = proceed signal, not feasibility question.** "Can we install Vikunja directly and use the same port?" means "I've decided we should do this, can you handle it?" — not "is this technically possible?" The correct response is "Yes, here's the plan" and go. Don't answer a feasibility question that wasn't asked.
|
||||
|
||||
## What He Values
|
||||
|
||||
- Execution without hand-holding
|
||||
- Honest post-mortems over defensive explanations
|
||||
- Cross-domain synthesis ("these things connect because...")
|
||||
- Tool choices that actually fit the job (don't route through kiro if exec works)
|
||||
|
||||
## The factbase Pipeline
|
||||
|
||||
Daniel is building **@everyonce/factbase** — a Rust CLI/MCP server that turns documents into a queryable knowledge base. It's not just a personal tool; it's a product for other users.
|
||||
|
||||
**What it does:**
|
||||
- Ingests documents, generates embeddings, builds a semantic knowledge graph
|
||||
- Exposes MCP tools for AI agents to query, resolve conflicts, maintain quality
|
||||
- Ships as cross-platform npm packages (darwin-arm64, darwin-x64, linux-x64, win32-x64)
|
||||
|
||||
**The pipeline:**
|
||||
1. Daniel creates tasks in Vikunja (task board) with `[factbase]` prefix
|
||||
2. Vikunja webhook fires → vikunja-proxy.mjs (Node.js, port 18790) intercepts
|
||||
3. Proxy moves task to "Doing", runs `run-kiro.sh "<task description>"`
|
||||
4. Kiro (coding agent) executes the task in the factbase repo
|
||||
5. On completion: proxy moves task to "Done", posts result to #factbase-development Discord channel
|
||||
6. Nestle monitors via HEARTBEAT.md, reviews outputs, synthesizes findings
|
||||
|
||||
**Key constraints:**
|
||||
- Repo: `/Users/daniel/work/factbase`
|
||||
- Don't develop directly — always use the task runner
|
||||
- Don't restart vikunja-proxy while tasks are running (orphans child processes)
|
||||
- `[factbase]` tasks are different from other tasks — proxy handles them directly
|
||||
|
||||
**Current state (as of April 2026):**
|
||||
- v2026.4.x in development — review question lifecycle fixes (#1411, #1413, #1414 landed April 13): deferred flag clearing on answer, re-answering deferred questions, scan no longer regenerating already-answered questions
|
||||
- 1,414+ tasks completed through the pipeline
|
||||
- Multi-domain tested: aviation, volcanoes, composers, WWII, Bible, jazz
|
||||
- Production KB (factbase-docs): 1,489+ files, ~84% temporal/source coverage
|
||||
- Gap question count stable at ~13,723 (dismissed persistence working — no longer resetting each cycle)
|
||||
- Pipeline now running autonomously on active days — Daniel queues, monitors results, may not be in channel during execution
|
||||
- **New direction (April 17)**: Daniel received actual OpenAI take-home project for Solutions Architect, Codex Specialist role. Part 1: JIRA/Codex SA response. Part 2: hackathon app (login/auth, data persistence, tests, programmatic Codex via MCP or SDK, 4-hour limit, 5-min video). **App: Recon** — GitHub repo analyzer using multi-agent Codex pipeline that produces a custom AGENTS.md. Sprint active as of April 25; v3 prompt at `research/codex-app-prompt-v3.md` ready to run in Codex. May 1: HM call with Allison August (SE, OpenAI SF). Research at `research/openai-master-context.md`.
|
||||
|
||||
**Design principles Daniel cares about:**
|
||||
- Domain-agnostic: no hardcoded entity types anywhere
|
||||
- Agent/model-agnostic: prompts should work on Haiku as well as Opus
|
||||
- Quality gate: review what actually shipped vs. what was asked
|
||||
|
||||
## Infrastructure He Manages
|
||||
|
||||
- **Vikunja** — task board at `10.0.6.25:3456`, Project "OpenClaw Tasks" (id: 2)
|
||||
- **Home Assistant** — `10.0.1.17:8123`
|
||||
- **Discord agents** — nestle (main), megaMind (architecture synthesis), others in #general
|
||||
- **AWS** — deep in Bedrock, infrastructure, solutions architecture day job
|
||||
|
||||
## Lessons From Working Together
|
||||
|
||||
- He will correct bad recommendations — that's useful, not a problem
|
||||
- He notices when analysis doesn't feed forward into changed behavior
|
||||
- "Write it down" doesn't fix discipline gaps — structure does
|
||||
- He values cross-domain synthesis; surface pattern connections early, not after someone's stuck
|
||||
- The Decision Ledger thread (March 2026): he shapes tools through conversation — his questions aren't just questions
|
||||
Reference in New Issue
Block a user