Use the guide at the right scale

Begin with the result the human wants and the undertaking already in progress. Determine whether the assignment is project formation, an existing project's development, a bounded maintenance change, an inquiry, or separately authorized Root governance work. These can share tools and records without sharing every stage or checkpoint. A small authorized documentation correction does not require a new PRD, a new decomposition, a project-wide dependency audit, or a replacement work graph. A new product with unsettled scope needs more basis work before production can be meaningfully bounded. Root entry · WORKING_ITEMS

Use the human-facing manual for the management argument: establish intent, make the basis usable, organize contributions, examine them, preserve their consequences, and deliver an identified result. Use this guide to find the repository instruments that implement those ideas. Use the owning project's live entry to decide what applies now. The human manual explains general practice and illustrative cases; a method described there does not become operational merely by being described. Human manual

Three questions keep the work proportional:

What decision or operation is next? Read enough to support it, including consequential inputs and downstream effects.
What could make its result unusable? Select the checks, review, and evidence that detect those failures.
What must another participant recover? Preserve the basis, actual outcome, remaining obligations, and next safe action without duplicating the entire history.

This is a working aid, not another mandatory form. Root explicitly permits ad hoc plans and ordinary conversational briefs. A workflow is optional unless the assignment or an accepted instrument requires it; creating or revising a reusable workflow is the important exception, discussed in section 19. An agent may act and make routine choices within clear authorization. It should prepare consequential human decisions, rather than multiply prompts for each tool result or harmless implementation detail. Root entry · Create a workflow

Keep four distinctions visible throughout the work:

Distinction	Operational consequence
Description and authority	A report of what code does cannot replace an accepted requirement.
Preparation and execution	A launch brief proves that instructions were prepared; an actual child record establishes that work ran.
Evidence and acceptance	A passing check supports a bounded claim; the applicable human act governs acceptance.
Source integration and release	Commit, push, PR, and merge concern Git state; none independently issues a deliverable or publishes a product.

These distinctions are grounded in the invariant catalog, delegation decision D-GOV-35, and Chirality change conventions. They allow extensive autonomous preparation and execution while preserving the decisions the human has retained.

The common route in this guide applies across project types. The exact product, source boundaries, domain constraints, checks, and adoption state remain local. In particular, the revised App and Piping route uses a local work graph; Runtime and PEC retain different continuation rules. Do not export one project's newest loop into its siblings without their adoption. App loop · Piping loop · Runtime loop · PEC loop

Read the published route with its adoption boundary

Version 7 develops an undertaking around substantive implementation and evidence integration, one planned documentation/governance closeout before its final PR, terse deliverable run entries, and final review and merge. Documentation and reconciliation needed for a substantive slice travel with that slice. A completed node or PR does not itself require another formal reconciliation pass or Task Management intake. The published development-loop amendment now aligns the shared methods and revised App/Piping instruction sources with that arrangement. Human manual §§4.2, 4.11, 5.6, 5.8 · Accepted instruction amendment

The amendment records owner acceptance of the identified third-draft instruction package and takes effect for the shared instructions on publication. It supersedes only the named earlier provisions. Its publication is distinct from a receiving loop's authority-corpus adoption or repinning. Establish that loop's actual accepted basis before relying on changed project instructions. Accepted instruction amendment · App notice · Piping notice

Context	How to enter
App/Piping undertaking adopting the revision	Use the revised loop and bundled graph/closeout methods. Keep the current graph at the required WorkGraphs path, selected execution in that graph, and terse `MEMORY.md` Runs rows. Both checked loop headers currently say “none selected for a successor undertaking”; this selects no new work and proves no prior program complete.
Continuing or frozen program	Recover its actual graph, activation, pins, pauses and owner directions. Transition only through its owning adoption; preserve historical graphs and source populations. Existing Remaining entries need separately authorized, individually accounted retirement before removal.
Runtime or PEC	Retain the project's accepted selection, recording and closeout arrangements. The source notices neither adopt the revision there nor authorize product work.

The source comparison records how the merged amendment superseded this guide's earlier draft assessment. The guide itself changes no instructions, project basis, pointer, lifecycle or individual obligation. Construct a local work graph §§3–4 · SPEC §§3, 8, 9.8 · Runtime notice · PEC notice