Issues live in this repo's GitHub Issues (yellowryan/dev-agent); use the gh CLI for all operations. See docs/agents/issue-tracker.md.
Uses the five default canonical labels: needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix. See docs/agents/triage-labels.md.
Single-context layout — CONTEXT.md + docs/adr/ at the repo root. See docs/agents/domain.md.
The MVP build-out for this project (the local coding agent itself) is tracked
as local tickets under .scratch/local-coding-agent-mvp/issues/NN-*.md
(published locally rather than to GitHub Issues for this ticket set — see
each file's numbering/blocking edges for the dependency order).
MVP mainline is tickets 01–11, driven by docs/specs/local-coding-agent-mvp.md
(deva run + runTask state machine: understand → generate → test → fix).
Tickets 08–11 (RAG, memory, domain docs) may still be open on that path.
Post-MVP parallel track — CLI Chat: ticket 12+ in the same
.scratch/local-coding-agent-mvp/issues/ folder (e.g. 12-cli-chat-repl.md).
Chat is not part of the MVP coding loop: it adds deva chat (REPL +
tool calling) and must not be folded into runTask. Spec:
docs/specs/cli-chat-v1.md. Decision record:
docs/adr/0001-chat-vs-task-runtime.md. Chat tickets do not block
08–11 and are not blocked by them (unless a ticket explicitly says so).
Whenever you finish the work for a ticket, update that ticket file in the same change:
- Check off every acceptance-criteria checkbox (
- [ ]→- [x]) that is actually done. Leave a box unchecked if the work wasn't fully completed. - Add a
**Status:**line (placed right after**Blocked by:**) with one of:blocked(a blocker hasn't shipped yet),ready-for-agent(unblocked, not started),in-progress, ordone(include the commit SHA that completed it, e.g.done — completed in commit \abc1234``). - When a ticket flips to
done, re-check any tickets it was blocking — if all of their blockers are now done, update their**Status:**toready-for-agenttoo, so the frontier is always visible without needing chat history.
This is how any agent (this session, a fresh Claude Code/Codex session, or a human) can tell project progress at a glance just by reading the ticket files — don't rely on conversation history to convey it.
Note: this is distinct from the product's own "project memory" concept
(docs/specs/local-coding-agent-mvp.md, ticket 10) — that's the target
agent's runtime memory about the repos it operates on, not meta-tracking
of building this repo.