agent-std-workflow

Use when capturing an investigation, PoC, measurement, or finding as a durable report. Create one directory per purpose with an evidence-complete README stating the question, method, and result, authored in isolation. Trigger on "write up the findings", "document this PoC".

Use when fixing a bug, dependency mismatch, broken build, or any other defect in product code under a canonical-branch-protecting workflow. Treat the fix exactly like a feature PoC — open a purpose-named report with the diagnosis and acceptance criteria, do the change in an isolated worktree, prove the gate goes from red to green, then cherry-pick. Trigger on "fix this", "build is broken", "deps mismatch", "rename leaks". This is the bug-side companion to `isolate-and-integrate`; it inherits that operation and adds the report-first discipline so a fix is documented evidence, not a hidden patch.

Prove a change is interpretable AND actually works at the consumer side before landing. Extract the deliverable's surface deterministically from source (no editorializing), enumerate its state matrix, hand the raw extraction and — when a UI can render — real screenshots to blind multi-persona agents, judge against pre-written ground truth, and block on FAIL. This is the procedure behind the iron rule "green only once consumed." Use AFTER a UI- or contract-facing change and BEFORE landing. Trigger on "zero-knowledge verification", "blind test", "verify before land", "consumer-side verification", "UI verify".

Use when implementing or changing product code in a repository that protects a canonical branch. Do the work in a throwaway git worktree off the canonical branch, verify it against the full quality gate, and cherry-pick only the finished, verified commits back — never commit to the canonical branch directly. Trigger on requests to add, fix, or refactor code.

Use BEFORE a non-trivial or unfamiliar change, when unsure which module owns the behavior — and BEFORE diving into a fix when prior reports may already describe the area. Build a pre-edit structure brief over both the source tree and the reports directory so candidate owners and prior investigations surface together; CONFIRM the owner by searching and reading before committing to it. Then deliver the change in isolation. Trigger on "where should this go", "did anyone already look at this", "what's the context".

Use when surveying or updating the implementation status of `requirements/RNN-*.md` against the current `source/` and `reports/`. The status model is multi-axis (not binary done/not-done) because parts can exist as building blocks for a larger exploration even when no single requirement is "done", and shipped features may differ from the requirement on purpose. Trigger on "update requirement status", "requirement status", "show the status table", "what's the status of R0N", "update the tracker".