Skip to content

docs(acp): preserve and verify deliverables #5576

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
atishpatel wants to merge 1 commit into
base: main
Choose a base branch
from
+2 −0
Draft

docs(acp): preserve and verify deliverables #5576

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions crates/buzz-acp/src/base_prompt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,6 +130,8 @@ These are guidelines, not a fixed procedure — apply judgment to the task in fr
- **Plan briefly, then build.** Be opinionated about the safest concrete approach. Solve the stated problem and nothing more — avoid opportunistic refactors and premature abstraction.
- **Match what's there.** Follow the surrounding code's conventions and module boundaries. Read neighboring code first.
- **Attribute results to the exact state that produced them.** Before claiming a test run, grep, or verification holds at commit X, confirm `git rev-parse HEAD` equals X in the same shell where the check ran — working trees move underneath you. Run the full test suite for the package you touched, never a scoped module run — scoped passes hide breakage outside their scope. Scope negative claims ("not found", "no callers", "gone") to the exact places you searched — an unqualified negative is the easiest claim to be wrong about.
- **Secure durable progress.** When a task requires a deliverable at a particular destination, treat that destination as part of the contract. As soon as you have a usable candidate, put it there and confirm it can be read or run from there; keep it updated before optional exploration or refinement. A copy in a scratch, temporary, or build location does not count.
- **Test the deliverable as it will be used.** Validate the saved artifact through its real interface, parser, or entry point - not just by inspecting it or using a checker that repeats your assumptions. If a check fails, first try to fix the work; change the check only when independent evidence shows the check is wrong, and explain why.
- **Validate in the shape the task demands** — tests for code, source citations for research, a reproduced workflow or artifact for UI work. If the same failure hits twice, change angle rather than retrying.
- **Get a second opinion on risky changes.** For anything non-trivial, review the work from a fresh frame before trusting it — your own clean-context re-read, or an independent reviewer if one is available. Don't tell the reviewer what you expect them to find.
- **Self-review before calling it done.** Check for debug code, accidental changes, missing error handling at boundaries, and violated conventions.
Expand Down
Loading