From daily user to Claude power user

What happened

• Repo initialized, uv installed for Python tooling
• backend/ — FastAPI scaffold managed with uv
• frontend/ — Vite + React + TypeScript scaffold
• /health wired end-to-end, verified live in the browser

Why it matters

Claude Code reasons about the repo it's sitting in. A clean, committed baseline means every later diff is legible — to you and to Claude.

What happened

• Wrote a real CLAUDE.md — conventions, commands, gotchas specific to this repo
• Used plan mode to design the Task data model and CRUD API before writing any code — plan approved, then implemented
• Backend: models, in-memory TaskStore, /tasks CRUD routes, 6 passing tests

Concepts exercised

• Plan mode vs. auto-accept
• Scoping asks: small diffs vs. "build the whole feature"
• Reading and steering the diff, not just approving it

What happened

• Wrote /new-endpoint, a project skill that scaffolds a route + model + test + optional frontend wrapper together
• Used it to build the AI-triage endpoint — Claude tool-use call suggests a priority without mutating the task
• A PostToolUse hook auto-runs ruff/oxlint on every edit — verified live by watching it silently fix an injected bug
• Permission allowlist narrowed to the dev loop; destructive actions still prompt
• An Explore subagent traced a field end-to-end across the stack, citing file:line locations independently

Concepts exercised

• Custom slash-command skills
• Hooks: enforcing lint/format automatically
• Permission modes and narrow allowlists
• Delegating to a subagent vs. doing it inline

What happened

• Vitest + React Testing Library added to the frontend; API mocked at the boundary, mirroring the backend's mocking pattern
• A real TDD loop: wrote a failing test for "confirm before delete," watched it fail against the real code, implemented the guard, watched it pass
• Ran /verify end-to-end in a live browser — found that headless automation auto-accepts native dialogs, a real gap worth knowing

Concepts exercised

• TDD: failing test first, then made to pass
• Testing LLM-backed endpoints by mocking the client
• The verify skill — driving the real flow, not just green tests

What happened

• .github/workflows/ci.yml — backend and frontend jobs on every push/PR
• A real feature, PR #1, exercised it — CI caught a genuine bug (a missing env var) on first run
• /code-review at medium effort found two confirmed bugs the new feature made more visible; kept out of scope and spawned as a follow-up instead of scope-creeping
• Branch protection required GitHub Pro on a private repo — made the repo public to unlock it for real, after confirming no secrets were ever committed
• Enforcement verified for real: a direct push bypassing the PR was rejected by GitHub itself (GH006), routed through PR #2 instead

Concepts exercised

• GitHub Actions: lint, test, build on every PR
• /code-review at medium effort
• Branch protection + required checks so the pipeline isn't advisory

What happened

• Two Fly.io apps — taskflow-nh-api (FastAPI/uv) and taskflow-nh-web (Vite build + nginx) — live at taskflow-nh-web.fly.dev
• nginx reverse-proxies /api/* to the backend server-to-server over Fly's private network — no CORS, and /api/* behaves identically in dev and prod
• docker-compose.yml for local parity; CD triggers automatically on merge to main
• /code-review caught two real deploy-breaking bugs before they shipped (a config path bug, an unnecessary job dependency serializing two independent deploys)
• The guided live deploy then surfaced three more real bugs only visible once actually running — an IPv4-only bind on an IPv6-only private network, nginx's own template auto-substitution colliding with a build-time one, and a static DNS resolution that crashed nginx if the backend was mid-restart — each found by reading the actual error and fixed in turn, verified live afterward

Concepts exercised

• Dockerizing a FastAPI service and a static frontend build
• Secrets via Fly (never in the repo or the image) and two least-privilege deploy tokens instead of one broad one
• Claude proposing risky infra changes and narrating them before acting — a proposed org-wide token and a direct machine scale were both paused for explicit approval

What happened

• Structured JSON logging on every request (request id, latency, status) via a FastAPI middleware
• The triage call traced specifically — tokens, latency, estimated cost, logged on both success and failure
• A log-based "dashboard" and a simulated alerting script, both reading flyctl logs directly — deliberately no hosted service, no webhook
• /code-review found six real bugs before any of it shipped, including a log line that could record status="ok" before the model's output was actually validated

What broke, and what happened instead

• Fly's free trial ended mid-phase, taking down the already-running apps — a billing action left for the human to take, not routed around
• docker compose up was tried as a cloud-free alternative and genuinely failed too (Docker Desktop's VM wouldn't boot in this sandboxed environment) — abandoned after a real observed failure, not more retries
• The live incident simulation still happened, just against local dev servers: a real invalid API key was swapped in, three genuine 502s generated, and the dashboard + alerting scripts run cold against the resulting logs — the alert correctly fired at a 100% error rate
• Root-causing past the alert surfaced a real, previously-unknown gap: the triage log recorded that a call failed but never why — no exception type or message

What happened

• A small mcp.server.fastmcp.FastMCP server, stdio transport, exposing TaskFlow's own REST API as six tools — a thin wrapper around the running backend, not a second store
• Verified through the real MCP protocol via the Inspector, not just imports: tool listing, a full taskflow_create_task call round-tripped and confirmed against the backend directly, and every error path (404, connection-refused, upstream-502) exercised on its own
• A recurring chore — a weekly triage-usage digest — retired to an actual scheduled Claude agent (not a script run by CI), run once manually first to prove it produces a correct entry before trusting the schedule unattended

The plan said "Agent SDK" — that was wrong

The lesson goal says rebuild triage on the Claude Agent SDK. But that SDK is Claude Code itself, packaged as a library — a full coding-agent harness (file tools, bash, subagents, permissions) for open-ended work. TaskFlow's triage call is one forced-tool classification request, not an agent. That mismatch got caught and confirmed with a human before any code was written, and the rebuild happened on the Anthropic SDK's Tool Runner instead — the right next tier up, honestly assessed as a small real win, not oversold as a rewrite.