The following examples are constructed teaching cases. They report no real authorization, execution, test, acceptance, or current project status. Their purpose is to show how to make the next contribution concrete without requiring the human to fill a form. Apply the actual sources cited in the preceding sections.

A small documentation correction

The human asks to fix a broken guide link. Recover the relevant instruction and link target, inspect the existing diff, and make the authorized bounded edit. Check the resulting link and any affected document rendering. Obtain the independent candidate review and applicable repository closeout checks required for the slice. Do not open a new product PRD or rebuild its DAG. If inspection reveals that the proposed target is obsolete, repair the link to the supported current entry or return that concrete ambiguity with evidence. Root entry · Chirality change conventions

An appropriate return might read:

Updated the guide's entry link to the live project launcher and preserved the historical reference in its source note. The link and rendered heading resolve. Independent review found no blocking issue on the submitted revision. This documentation change does not alter the project's selected undertaking or instructions.

The actual return should link the changed artifact and identify actual verification. Do not copy this sample's claimed results into a real run without performing them.

A bounded implementation brief

Suppose the human has authorized repair of a save operation that overwrites intervening edits. The parent first reads the adopted save contract, current implementation, failing observation, consumer interface, and applicable holds. It prepares this kind of assignment, with actual IDs, paths, and checks substituted:

Objective: Preserve intervening edits when applying a prepared proposal.
Basis: The adopted revision-comparison contract and identified failing case.
Scope: The save/apply boundary and its focused regression coverage.
Writes: Exact implementation and test files; one evidence result location.
Exclusions: No storage-format change, lifecycle edit, or unrelated UI cleanup.
Checks: Registered focused checks plus the required connected journey.
Return: Diff, tested candidate, observed outcomes, evidence, and residuals.
Parent: The implementation manager; return interface changes before applying.

This concise human-readable explanation complements any required structured fields. If the diagnosis shows the interface itself cannot express the needed condition, the child returns that design question. It does not silently change every caller or weaken the expected preservation behavior. Bounded implementation · Implementation brief

A decision package the human can act on

Suppose two deliverables cannot be ordered because each needs an unresolved contract from the other. Prepare the source-linked SCC and a remedy before asking for a decision:

The export writer needs an accepted schema; the schema task currently waits for the writer's implementation evidence. I propose separating the schema definition from its implementation validation. The definition would supply the writer, and a later validation task would check their combined result. The attached draft shows the affected claims, edges, and checks. This preserves both obligations and leaves the existing implementation usable. The decision requested is acceptance of this exact scope/dependency amendment under the project's process; implementation would then continue from the revised basis.

The real packet identifies exact candidate bytes, alternatives, consequences, and the reserved act. If the remedy is a cut or merge, obtain the doctrine's human decision. A graph visualization alone is insufficient. Cycle-driven resolution · Scope change

A repair that is useful but incomplete

The implementation passes its focused tests, but native interruption recovery remains unobserved. Report the code result and keep the evidence node open. Reconcile any stale “not implemented” wording only to the extent supported, while retaining the required native observation in the graph (and in Remaining only where a still-pinned method requires it). A good return names the next action instead of declaring the whole feature passed. App evidence rules · Bounded reconciliation

The repair and focused regression checks are complete on the identified candidate. Independent review and the affected backcheck found no blocking issue. The required native interruption scenario could not run in this host and remains recorded with its exact command and starting conditions. The implementation is ready for that examination; no checking promotion or release is claimed.

One closeout across substantive PRs

Suppose an undertaking uses the adopted revised development arrangement. Its first substantive PR implements revision comparison with its tests and required user guidance. A second integrates the connected recovery path and its evidence. Each carries any documentary consequences needed by its slice. A concern already allocated to a later owned graph remains there; a newly discovered external responsibility with no home is preserved as a conditional intake linked from its originating PR and node. Neither PR triggers a routine Task Management sweep.

After intended implementation/evidence integration, the planned closeout compares affected deliverable claims and governing records against the combined candidate. A missing required interruption witness returns to its evidence node and the affected comparison is rechecked once that work is complete. Terse memory entries index the work and central records. Final review, checks, applicable decisions, and final PR merge finish the undertaking at that scope. A still-pinned App/Piping concordance run follows its own method until explicit transition. Human manual §§4.2, 4.11, 5.6, 5.8 · Adoption boundary

A stale continuation summary

The graph says “review next,” while its linked event log records a review and subsequent correction. Read the governing resume method, inspect the actual patch and review return, and determine whether the correction was backchecked. Preserve the review as evidence of its original candidate. Update continuation through the authorized maintainer only after recovering the actual result. Do not repeat review blindly or conclude that the later correction inherited the earlier pass. Use the selected run's recovery procedure to resolve that discrepancy. Piping loop · Bounded reconciliation