Orchestrate Agentic Engineering

Run one steering interface while specialist agents execute bounded work. Persist decisions and evidence in repository so delivery survives parallelism and context compaction.

Terms used in this repository's agent notes:

• A harness is the code around a model that defines its tools, parses its tool calls, runs them and returns the results. Claude Code, the Codex CLI and Pi are harnesses, and an agent is a model plus a harness configuration (tools, instructions, MCP servers).
• An interface is what a person uses to talk to a harness, such as a terminal UI, a desktop app or T3 Code. Anthropic describes the Agent SDK as a library that runs the Claude Code binary, so write "the SDK wraps Claude Code", and never "Claude Code is built on the SDK".
• An MCP server is a separate program that exposes tools, resources and prompts to a harness, and it runs locally over stdio or remotely over Streamable HTTP. To the model an MCP tool is one more tool in its list.
• A harness in the sense of a test or evaluation harness is a different thing, and the sentence must say which one is meant.

Role Model

Captain

• Provide raw intent, users, constraints, success criteria, and non-goals.
• Decide product tradeoffs, cost, security posture, scope, and production access.
• Review artifacts and proof instead of every tool call.
• Approve irreversible actions and actions only human can perform.

Orchestrator

• Convert narrative into decisions, unknowns, workstreams, dependencies, and gates.
• Delegate execution and remain responsive to steering.
• Persist task state, artifact paths, branches, commits, blockers, and evidence.
• Integrate results and surface only material choices or real blockers.
• Never claim completion from plans, mocks, or workflow status alone.

Specialists

• Own one bounded outcome per session.
• Work in isolated branches or worktrees when code changes can overlap.
• Return artifact, evidence, assumptions, risks, and next dependency.
• Diagnose failures before escalating.
• Ask captain only for authority, credentials, consent, or decisions agents cannot make.

Delegate only when host supports subagents and work can run independently. Otherwise execute same work graph sequentially.

Split work across agents by context and not by problem type. Give each subagent a piece of work that needs little from the rest of the system and returns a compact result, such as an independent research path or a black-box check. Splitting by problem type makes each handoff lose detail (Anthropic's "telephone game", article read 2026-10-26).

Workflow

1. Capture intent

Accept a long, imperfect narrative. Extract:

• Problem and target users.
• Must-haves and explicit exclusions.
• Constraints, budget, deadline, and environments.
• Core user journey and verifiable definition of done.
• Assumptions, unresolved decisions, and authority boundaries.

Ask only questions whose answers materially change direction.

2. Dispatch parallel discovery

Run independent tracks when useful:

• Market or user research.
• Technical feasibility and architecture options.
• Low-fidelity UX journey or prototype.
• Existing-system and operational-state audit.

Do not implement before research can still invalidate product, scope, or architecture.

3. Run judgment loop

• Present findings as diagrams, prototypes, comparisons, or short decision records. Local rule: draw a diagram only when the reader learns more from it than from a paragraph or a 3-column table.
• Let captain accept, reject, or edit assumptions.
• Verify cost, platform, and vendor claims against primary evidence.
• Remove hidden scope: premature environments, audit systems, exports, enterprise controls, and imagined scale.
• Mark unresolved decisions explicitly; do not bury them in prose.

Stop and re-plan when new evidence invalidates dependency graph.

4. Persist foundation

Write settled state into repository before major implementation:

• PRD or concise product brief.
• Executable acceptance scenario.
• Architecture decisions and design rules.
• Decision log with rejected options.
• Dependency-aware work ledger.

Treat repository artifacts as recovery source after compaction. Never rely on chat history alone.

5. Build dependency graph

For each work item record:

• Outcome and owner.
• Inputs and dependencies. For each dependency, mark it hard (the item cannot start or be judged without it) or soft (the item is better with it but can start without it), and give a one-line reason. A dependency with no reason is a guess, so write the reason or drop the edge.
• Allowed files or system boundary.
• Acceptance checks.
• Branch/worktree or execution context.
• Expected artifact and handoff proof.
• Authority required.
• Stop condition and the maximum attempts before the item is escalated.
• Timeout for the handoff, and whether repeating it is safe.

Parallelize only independent nodes. Define integration owner where contracts meet.

• A soft dependency does not block dispatch, so a soft-blocked item can start in parallel and be reconciled at the integration owner. Check the graph has no cycle before dispatch. Two alternative routes to the same input are not expressible as hard edges, so write them as one node with an "either of these" input and not as two hard edges (this OR rule is our own suggestion and is not in the source).

6. Dispatch bounded implementation

• Keep orchestrator free for monitoring, steering, and dependency resolution.
• Route follow-up work to existing owner when scope matches.
• Require specialists to commit coherent changes and run relevant checks.
• Give reviewers raw artifacts and task contract, not desired conclusion.
• Tighten review and merge policy as prototype becomes production code.

When one verification run takes hours, open one branch per candidate fix and let the builds run in parallel. Keep one Markdown file as source of truth for root cause, test cases, branches and build status. Have a human test the resulting artifacts. Evidence: Grab Engineering blog (single author, self-reported, read on 2026-10-21), where it replaced one-by-one 2-hour CI waits.

7. Integrate real system

Verify cross-stream contracts:

• Frontend uses real backend where completion requires integration.
• Authentication, schema, names, URLs, and environment identity agree.
• Secrets remain outside prompts, source, logs, and ordinary config files.
• Deployment and runtime configuration point to intended environment.
• Mocks are identified and removed from core acceptance path.

Reject mock-only completion.

8. Prove end to end

Execute real core journey. Example:

1. Authenticate.
2. Create or mutate state.
3. Observe state through second relevant view or actor.
4. Restart or sign out.
5. Sign in again.
6. Confirm persistence and authorization.

Collect exact commit, commands, checks, endpoint/config identity, concise logs or screenshots, and remaining risks. Workflow success without user-journey proof is insufficient.

Drive the real user path, never internal setters, test-only endpoints or handlers invoked through eval. Use eval only to read state after the user path ran. Run a health check first, because a recording against a stale build or the wrong instance is not evidence. Capture the trigger and the stable end state in the same recording or log, and check side effects in the store that holds them. Exercise every reachable entry point the change touches, plus its success, cancel, error, empty and persistence paths. Report an unreachable path with its concrete blocker and cover the closest real path that remains, never claiming it verified through a different path. For a bug fix, run the same proof against the base commit and the branch, and require it to fail on the base. A proof that passes on both is not evidence. For a repeatable recipe per project, use create-verification-skill and keep it honest with maintain-verification-skill.

9. Review architecture and release

• Review API surface, authorization, data model, core boundaries, cost, and operational burden.
• Remove needless complexity introduced during parallel work.
• Build release or test-distribution artifact only after acceptance scenario passes.
• Require explicit captain approval before production writes, external sends, publication, spending, or destructive actions.

Unattended agent charter

Before an agent runs without a human watching, record:

• A spend cap. In Claude Code print mode, --max-budget-usd stops the run at an estimated spend, counts subagent spend, and makes later spawns fail with Budget limit reached. The flag is print mode only, spend can pass the cap, and the estimate can differ from the bill, so leave headroom.
• A fan-out cap. Set CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH and CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, see claude-code-spend. That a fan-out cap suits unattended runs is an inference, since no page says so.
• A separate credential and login for each agent.
• An append-only action log that someone reviews on a schedule.
• An approval gate for anything sent in a person's name, including negotiation emails.
• A kill switch.
• A loop exit that does not depend on the loop's own score. A loop told to run until a judge gives at least a set grade needs a maximum iteration count, because the judge may never reach the grade (inference). The judge must be able to read the artifact type, because a text-only judge cannot grade a screenshot or a build.
• A trust gate before scale. Do not raise the number of parallel agents or remove the human review until a single agent's output has passed an executable check you trust, such as a verification skill that drives the real app. One engineer describes the order as verification first, then local runs you can watch, then cloud runs from bug reports, then auto-merge with review after landing, and warns that jumping to many agents wastes tokens (single report, a 2026-10 talk). They work at an AI lab with unlimited tokens, so their volume figures (about 1,000 PRs a month) do not transfer to a paid plan.

The list is standard least-privilege practice, except the trust gate, which is a single report. Only the two mechanism notes above come from Anthropic's CLI reference and sub-agents pages, read 2026-10-23.

Gates

Research Gate

• User and problem explicit.
• Market gap or differentiation stated.
• Technical options compared with evidence.
• Major assumptions and unresolved risks visible.

Planning Gate

• Minimal scope frozen.
• Core journey reviewable and executable.
• Current-scale architecture chosen.
• Human decisions persisted.
• Work graph respects dependencies and file ownership.

Implementation Gate

• Each specialist has bounded outcome and contract.
• Record an autonomy level for each step: propose only (a human approves every edit), edit inside a named scope (a human approves merges), or run end to end only where tests fully cover the step. Raise a step's level only after repeated passing runs, and record how many. The source card uses three passing runs in a row, which is its own design choice with no evidence behind the number.
• Code changes isolated where needed.
• Tests and checks pass.
• Security-sensitive changes receive proportional review.
• Production mutation remains human-authorized.

Verification Gate

• Real integration, not mocks.
• Core journey passes end to end.
• Persistence and restart behavior checked when relevant.
• Architecture reviewed for security and overengineering.
• Exact source and evidence captured.
• Keep one checks table with a row per requirement and the columns requirement, verdict (pass, fail or unresolved), and evidence (a file path, a link or the command output). Leave an unresolved row visible in the final report, and never delete or reword a row to make it pass. Run each check against the saved version of the output and not against a draft in the session.
• Write each runnable check before the work, as a command and the exact text it must print (design advice from the unlazy skill at commit 16671491, read 2026-10-24, not measured). Count it as passed only when the command exits zero and the output contains that text, because a failing run can print the expected word in its error. Use a success-only token as the expected text.
• Before trusting a check that proves something is absent, run it once against a case known to contain it and confirm it fails. A wrong path or a bad pattern otherwise looks like a clean result.
• Store the command and expected text with the evidence, and treat evidence recorded for an older version of the check as unmet. The parent re-runs every check itself on the final state, even those a worker marked passed.
• Give a gate that cannot be met a named abandonment with a reason, and report it as a handoff, never as a pass.
• Read every command in an inherited checks file before running any of them, because each one is code. An expected-text match does not show that the plain-language gate describes what the command measures, so a person reviews that match.
• A model-reported bug is a claim until a repro test fails on the assertion that encodes it. A repro failing for another reason means the test is wrong. A passing repro rejects the finding. Local rule: confirm the run report lists the repro as executed, because an excluded or unselected test proves nothing either way.
• A claim that cannot be executed needs an independent verdict, and a change the agent both proposed and judged on the same task is a hypothesis. The verifier is a fresh agent that did not produce the claim and defaults to "false positive". It rules a finding true only with a file and line for the source, the sink and the absence of a mitigation it read. Count votes in code, not in prose, and let a vote lower a severity but never raise it. Count a self-judged change as verified only after an independent check such as a held-out task, a human review or a test the agent did not write. Prefer a check the agent can run itself and get feedback from at once, such as a test, a benchmark or a reproduction, over asking a model whether the result is good. Anthropic's Felix Rieseberg says in October 2026 not to ask the model to judge itself and to insist on outside validation (article read 2026-10-26, opinion). Evidence: the verifier rules are restated from Claude Security's plugin files (commit e68e375) and Cloudflare's security-audit skill README (MIT). The self-judged rule is inference from the Harness2 design (Google, Apache-2.0, commit 1cfe254) and reply-level opinion, not a statement in that repository.
• Evidence survives cleanup and every later run, and is checked at its named location after teardown. Local rule: a harness that reuses one results directory overwrites the proof on the next run, so name a per-proof output directory or copy the artifacts out first.
• When an agent run is scored against a public benchmark, rubric or test, block the answer hosts at network level for the executor and record the restriction with the result. Harness2's docs/EXPERIMENTS.md (commit 1cfe254, read 2026-10-20) documents a Codex rollout that downloaded its own rubric without being told to, and states that its own release does not block it.

Context and Handoff Discipline

Keep orchestrator context limited to:

• Settled decisions.
• Dependency graph.
• Workstream state.
• Blockers and authority needs.
• Artifact paths and proof.

Close completed specialist sessions. After compaction or handoff, reload repository artifacts before acting. Prefer reviewable artifacts over long report walls.

When a worker session is replaced because its context is full, give the successor the predecessor's transcript path as well as the brief, and tell it to search that file for exact lines instead of trusting a paraphrase. Mainplane's harness does this with one fixed message, "You are continuing session X. Retrieve key context from it as you go.", and a per-session log file searched with rg (source read 2026-10-30, https://github.com/mainplane-ai/mainplane, pkg/connector/tui/commands.go and pkg/harness/tools.go). Reports from repliers say a summary drops rejected approaches and dead ends, and that retrieval only works if the agent knows to look, so keep decisions and rejected approaches in a repository artifact and list them in the brief (single reports, no eval). Treat retrieval against summary as an open question for each model and task, as one practitioner put it: "best discovered with evals".

Bound code search output, because raw search hits are a large share of an agent's input tokens. List matching files first (grep -l or rg -l), cap matches per file (-m), keep context to a few lines, and narrow by path or type before reading whole files. The flags above (rg -l, -m) were not tested by the benchmark below, which tested ranked top-20 output after -C 3 context, so treat them as untested. In Context.dev's vendor-run sgrep benchmark (October 2026, 100 SWE-bench Verified attempts per arm, tool output capped at 8,000 o200k tokens), plain ripgrep returned about 4,100 search tokens per attempt and hit the cap in 88 searches, against about 1,500 tokens and 4 capped searches for rg --json -C 3 piped into sgrep. Mean API cost was 21.3% lower, but total cost moved -0.4% with an interval spanning zero, median agent time was slower at 56.1 s against 52.5 s, and the solve rate of 0.70 against 0.68 has a paired interval of -3 to +8 points, which does not establish a gain. Adopt output bounds, not a new search tool. A code-graph MCP server (a code index the agent queries) is a different mechanism from bounded search output. One vendor benchmark (haplollc/Vesalius, October 2026, 20 questions on 6 codebases, one run per question, one Claude judge, 3 codebases private) reports 44% fewer tokens by plain means (its headline 51% is a geometric mean) at about equal answer quality, and more tokens on 4 of 20 questions. It reads Dart only lexically, so it says nothing about a Flutter app. Treat it as a lead, and test any such server on one of the user's own apps only after a code-gate SAFE verdict. When an agent searches notes, dossiers, skills or documentation, treat a hit as a lead and the file as the source. Retrieve the full text of every hit that a claim rests on, and answer from the retrieved text with the path and line numbers. Do not answer from a snippet when the answer needs a fact, a decision, a quote or nuance. This is the retrieval rule in the skill that ships with the local search tool tobi/qmd (MIT, read 2026-10-23). That skill also tells the agent to write its own query terms, one set of exact words and one paraphrase, because the agent knows the goal and the built-in query expander does not (the skill's own claim, untested here). Applying the rule to the catalog's own notes and dossiers is an inference.

Use this handoff shape:

Outcome:
Owner:
Status:
Artifact/branch/commit:
Checks run:
Evidence:
Assumptions:
Risks:
Dependencies unblocked:
Authority still needed:

Running Many Helpers at Once

• Give each helper disjoint files, directories, or design pages. Two helpers editing one file at once break the checks. Disjoint files are not enough for Xcode work, because two helpers building one checkout into the same DerivedData collide. Give each its own -derivedDataPath or its own worktree.
• Helpers never commit. The orchestrator reviews the diff, runs the checks against the final state, and commits.
• Brief each helper with the rulings verbatim, the files it owns, the files it must not touch, and the report shape, including "choices no ruling settled".
• Verify each helper's key claims before relaying them, especially figures from research: estimates, prices, latencies, and terms clauses.
• Every product choice or assumption a helper made goes to the user. None stands by default.
• A resumed helper first checks what already exists, so it does not duplicate frames, files, or rows.
• Expect helpers to die from usage limits or stall watchdogs. Keep each brief small enough to resume, resume through the platform's message mechanism with the original context, and re-verify the state it left.
• Give each dispatch an attempt id and require the helper's completion report to carry the task id and the attempt id. A report from an earlier attempt then cannot close the current one. Require the report exactly once, including on failure, with an explicit succeeded or failed outcome. Put this in every brief: the final line of the report is literally OUTCOME: succeeded or OUTCOME: failed. The orchestrator then checks the outcome by text, and a clean turn end without that line counts as failed. The pattern follows the orchestration docs of Orca, a third-party desktop app (experimental feature, read 2026-10-25), and its fit for our helpers is an inference.
• A systematic defect needs a sweep of every instance. When one helper finds a pattern, such as an off-centre component, a wrong token, or a stale string, launch a sweep rather than fixing the samples. Check that the sweep only touched what it should.
• Keep the user oriented while helpers run. On a status request, answer with what is running, what is done with evidence, what is left, and whether design and documents agree.

Briefs, limits, and proof

• Size each brief to finish in 20 to 30 minutes. Long helper runs are where hangs and dropped connections happen, and a short brief is cheap to rerun.
• Launch every helper with a hard wall-clock limit, and check for file activity once a run passes about 30 minutes. A process that is alive at 0% CPU with no file changes has stalled, and waiting for its exit notice can waste hours.
• For a T3 Code child thread, poll its updatedAt and itemCount from t3_thread_list, and treat 20 minutes with no change in either as stalled. This is one cheap call, so it runs more often than the 30 minute file-activity check, which stays as is. T3 Code has no heartbeat field, so this is a parent habit and not a platform signal.
• Give every fact in a brief its provenance: the file and line, the command output, or the design node. For a design measurement, name the node, say whether it is the placed instance or the component, and read overrides such as stroke, radius, and clipping from the design tool's object model, not from generated code.
• Attach the project's pre-report checklist to every implementation brief, so the helper checks the recurring slips before it reports.
• Treat a helper's report as a claim. Before committing, the orchestrator reruns the gate on the final state and checks the facts a mistake would hide, such as lockfiles, measured sizes, and resource leases.
• Route the review to a reviewer that did not write the change, with the raw diff and the task contract. Put every finding through a fix round with its own review. The orchestrator does not wave findings through.
• Ask the reviewer to state, for each passing check, what it proved and what it did not prove, whether a test repeats the same mistake as the code, and what would have to be true for the change to be wrong. End the review with "did we miss anything?", because a frontier model often returns more items on that second ask (one Claude Code team member's report, Addy Osmani, read 2026-11-05, unmeasured).
• Ask the implementer to list the decisions and assumptions it made, namely the defaults it picked, what it left out and which requirement it reinterpreted when two clashed, and read that list before the summary.
• Read the command and its output before the agent's summary. A green check proves one property, so ask what it checked.
• When a helper restarts after a crash or a limit, tell it to inspect the working tree first and continue from it.
• When the same slip returns in round after round, fix its source (a pinned tool, a check that fails) instead of adding another manual step to every brief.
• A dead-code sweep must check the data a removed path wrote, not only its callers. A writer whose callers were removed can still feed data that live code reads.
• Stop patching and re-plan when a third fix round on one change still finds a blocking gap. Present the simpler design to the user.
• A text-only end of turn from a worker is a report and not proof of completion. Keep the task parts in a checklist the worker updates, in a to-do tool or a file. If a turn ends with items open and no blocker stated, send one short message naming them. State the completion condition up front, and optionally have a smaller model check it at each end of turn. If a background command or subagent is still running, do not treat the task as done. Stop after two or three automatic continuations on the same task and review it. For a fully unattended agent, Anthropic offers a standing system-prompt paragraph that names four early-stop patterns: a long summary announcing the next step, offering to continue unless redirected, listing non-blocking decisions, and reporting at a milestone. Use it only in unattended harnesses, keep confirmation for risky or irreversible actions, and expect more tool calls and output tokens. Source: Anthropic "Prompting Claude Opus 5.5", section "Unattended agentic runs" (official docs, read 2026-10-20). The separate checker model and the running-subagent rule are our additions.
• Allow at most two attempts at the same failing operation. Save finished work before a retry, record the exact error, and continue any work that does not depend on the failed step. Where a script or tool runs the retries, set the limit there as well, because an instruction alone does not stop a loop. A retry of an action that creates something first checks whether the first attempt already succeeded.
• Do not treat a clean exit or an HTTP 200 as proof a helper's model call worked. One vendor reports that a transient API error can arrive as plain text inside a successful response stream, so a run is logged as finished with no work done (Cloudflare blog, single vendor report on its own harness, read 2026-11-04, not reproduced here). Where a script drives helpers, classify the response text for known error strings as well as the exception type, and treat a helper that finished far faster than its peers with an empty result as failed until proven otherwise (the speed rule is an inference).

Process hygiene for agent shells

Record every background process an agent starts with echo $! > name.pid at spawn time. Check liveness with kill -0 "$(cat name.pid)", and stop a process with kill "$(cat name.pid)" before deleting the file. Never use pkill -f or pgrep, because a command-line pattern can match the agent's own shell and some sandboxes lack pgrep. An agent's shell shows output only when a command ends, so start any command that blocks on a human approval in the background, poll its log for the approval URL for a bounded time, print the URL and exit. Give every CLI that can fall back to interactive login an explicit timeout, such as Tailscale's --timeout=90s. In a readiness poll, stop waiting as soon as the started process is no longer alive. Set umask 077 before writing state or logs that hold login URLs or node identities. Exit 1 only when a named human step is needed or the service failed, and exit 0 once the core service serves, saying what optional part is missing. When a one-time login URL is consumed, kill by PID file, delete the stored identity and start fresh, instead of re-printing the dead URL. Put the next action in the failure output, including what not to do. A setup script writes its target directory first and, on failure, prints the one variable that moves it, before it downloads anything. Pin the release version in the script and fetch the asset URL directly. One installer script claims a latest-release redirect is refused in some sandboxes, which was not tested here.

Bug bash fan-out

A bug bash is many exploration runs, one charter each, then a pass that proves every claimed bug. A charter is one area, one posture and one sentence naming the start route and the account. Plan 5 to 10 charters with postures such as first-time user, numbers and copy, edge input, state and error paths. An edge-input charter names its exact input matrix, or it spends its budget before judging a result. Run charters four at a time, each with its own output directory and its own seeded disposable account, because explorers sharing an account report each other's edits as bugs. Local rule: read each run's step log before triage, because an exit code does not prove the charter ran. A run that aborted, executed no step, or surveyed the app instead of its charter did not cover that charter, whatever its exit code, and goes under areas no charter reached. Against a deployed site that others use, charters are read-only: no signups, submissions, injection-shaped URLs or request loops. Before running code from a repository you did not write, or code an agent generated while hunting bugs, run it in an OS-enforced sandbox. The sandbox has no external network, an empty environment plus an explicit allowlist, a read-only target, writes limited to a scratch directory, and hard CPU, memory and time limits. If the sandbox cannot be enforced, do not run the code and record the lead as needing validation. Check that no .env or credential file in the tree points at a shared or live service. Sort every finding into explorer artifact, environment, design, fixture or candidate by reading the source, and write repro tests only for candidates. Report confirmed bugs with their failing repro first, then unverified risks, then rejected findings grouped by reason, then areas no charter reached. Adapted from tester-army/e2e bug-bash.md (Apache-2.0, read 2026-10-13). The sandbox rule is restated from the READMEs of Cloudflare's security-audit skill, Mantis and Claude Security (read 2026-10-20). Two open-source sandbox runtimes are candidates for this rule, and neither was run here. NVIDIA OpenShell (Apache-2.0) says it enforces file, system call and network access per sandbox with kernel controls and policy, injects credentials only for approved endpoints, and supports macOS on Apple Silicon with Docker, Podman or host virtualization (README, read 2026-10-23). OpenSandbox (Apache-2.0) offers Docker sandboxes locally, per-sandbox egress policies and a credential vault (README, read 2026-10-23). Their documented installs are curl ... | sh and uvx opensandbox-server, so the sandbox itself goes through the code-gate rule before it is trusted to contain other code. Neither README says the default is no network, so test the "no external network" line before relying on either.

Failure Modes

• Orchestrator performs specialist work and becomes unavailable.
• Parallel agents edit overlapping files or assume incompatible contracts.
• Decisions exist only in chat and disappear after compaction.
• Vendor recommendation becomes architecture decision without human judgment.
• Mock client is mistaken for completed integration.
• Agent introduces unnecessary environments or enterprise controls.
• Specialist exposes secret through prompt, source, command, or log.
• Captain approves “done” without executable evidence.
• Team keeps patching after dependency plan becomes invalid.
• Reviewer receives expected answer and merely confirms it.
• A stalled helper runs for hours because the orchestrator only watches for its exit.
• An orchestrator's wrong fact in a brief is implemented faithfully and costs a review round.
• Cleanup kills processes by name instead of the process it started, and takes down the user's own session.
• Cleanup deletes the proof artifacts along with the scratch state.
• A verification recipe is handed over without being executed once end to end.
• A verification map is edited to match a regression, which hides a product bug as documentation drift.
• Review layers fix single elements, such as pixel alignment, while the overall layout of a screen stays wrong, and only a person looking at the screen notices (single report).
• An invariant lives only in a prompt, a skill or a reviewer's habit, so an agent forgets it and each miss is caught by a person or not at all. Encode it twice, as a guide that gives the reason and as a check the agent cannot bypass, and when a failure repeats, change the guide, test, tool or permission and not only the current output. The "guide plus mechanical check" pattern and a failure-class to fix table come from an unmeasured essay (inference), and a 2026-10 talk makes the same point (single report).

Output Contract

Return:

1. Normalized brief and unresolved decision list.
2. Parallel discovery plan.
3. Persisted decision and architecture artifacts.
4. Dependency-aware task ledger.
5. Workstream handoffs with branches, commits, and checks.
6. Integration findings and fixes.
7. End-to-end evidence.
8. Release decision, remaining risks, and authority requests.

Sources

Distilled from Kun Chen's video L8 Principal Building a Full Stack App with Agentic Engineering: https://www.youtube.com/watch?v=kPN564Kol14.

Search output numbers: https://github.com/context-dot-dev/sgrep (7452784, benchmarks/README.md and benchmarks/swe-bench/results/analysis.json, plus benchmarks/swe-bench/harness/PROTOCOL.md for the 8,000-token cap). The benchmark files were unchanged at commit dec6122 (2026-10-15).

Verification and stop rules: Harness2 https://github.com/google-research/harness2 (commit 1cfe254), Anthropic's "Prompting Claude Opus 5.5" guide, and the security tools named in the bug bash section.

Read references/video-notes.md when provenance, observed examples, or tool-agnostic adaptation choices matter. Keep normal execution on this file's workflow.