STEERING AND LOCAL WORK GRAPHS THROUGH THE 60% PHASE

The development loop carries a project forward through successive undertakings. Each undertaking has an intended result, a body of work, and conditions by which its completion can be assessed. The human directs the effort. HELP_HUMAN relates that direction to the present project, and WORKING_ITEMS organises contributions that can fulfil it. Their work continues through investigation, implementation, verification, review, integration, and the reconciliation of project records with the results.

During the work toward 30%, the loop gives sustained attention to closely coupled questions. Strongly connected components (SCCs) identify relationships whose ordering remains unresolved. Direct steering selects the questions to pursue, and the Agent 0/1/2 arrangement carries the necessary design, investigation, and implementation. Construction and examination of the resulting DAG complete the execution-definition work before the 30% gate.

In the 60% phase, the established DAG supplies a broader route through the Deliverables. Local work graphs develop selected parts of that route into executable undertakings. They state what is to be achieved, why it matters now, which inputs are required, and what evidence will establish the result. They also preserve the separation between independent areas of work. This permits several contributions to proceed concurrently with disjoint writes and an agreed means of integration.

Detailed development can reveal relationships that require a successor project DAG. Such revisions are common during this phase as the path to the delivered product becomes clearer. The project approaches the end of 60% when it expects to complete the remaining development without further changes to that broader structure. This is a judgment about the work still ahead. The same local-graph method then supports the longer task and time horizons of the 90% phase.

Steering remains a substantial human contribution throughout. Objectives and constraints have acquired a project structure, but choosing a useful course through that structure still requires attention to purpose, progress, difficulty, and consequences. The human may concentrate work on a capability, redirect a diagnosis, prescribe an exemplar, change the deployment of agents, or call for a decision before further implementation. The graph preserves those directions and the consequences of acting upon them.

The agents reckon through technical choices within their assignments and return work for examination. The human judges consequential choices and the reliance to place on these contributions from others. This chapter develops that relationship through steering, local graphs, execution, and reconciliation, then considers the transition to longer-horizon completion.

4.1Steer the development undertaking

Begin with what the human wants to accomplish in the present work. The accepted project scope may contain many useful contributions, and the DAG may show several available routes. Steering selects the outcome to pursue and the extent of the undertaking. HELP_HUMAN develops a concrete reading of that direction against the current state, then works with the managers to establish the contributions it requires.

A steer can be brief when the objective and relevant basis are already understood. It can also carry a substantial explanation of a difficulty, a preferred approach, or the consequences to be avoided. Use the opening brief, subsequent conversation, and applicable recorded decisions together. Preserve the human's words and identify the agent's interpretation separately where that interpretation affects the proposed work.

Give direction a practical expression

Steering commonly addresses five subjects. Their extent depends on what the present undertaking needs. They can be expressed in ordinary conversation; the human need not prepare a graph or supply node identifiers before the agent can help.

These subjects often interact. A direction to establish control behaviour before visual refinement changes the selected route, the types of evidence needed first, and the useful allocation of agents. A request to examine an unfamiliar interface before implementing it introduces an investigation with a defined return. A pause pending the human's inspection limits continuation even when the graph contains ready work.

STEER FOR THE PRESENT UNDERTAKING: ILLUSTRATIVE

Outcome and scope
Establish the control behaviour needed for the selected capability.
Leave visual refinement for later.

Priority and approach
Resolve the shared operation and its failure handling first.
Use the accepted interface and the identified working exemplar.
Explain any difference in meaning before copying its arrangement.

Execution
Use WORKING_ITEMS to coordinate the connected implementation.
Run independent contributions with separate write targets.
Include review, connected checks, and bounded reconciliation.

Continuation
Continue through the selected result. Bring back choices that
change the accepted behaviour or require a different project route.

Figure 4.1. An illustrative steer. It expresses the purpose and conduct of one undertaking. Actual directions may be shorter or distributed across the conversation.

Select a useful route

Follow the intended result into the relevant Deliverables and their dependencies. A priority identifies what the human values; its implementation may first require enabling work elsewhere. Explain that relationship and include the enabling contribution in the proposed route. Work that is ready but unrelated to the intended result can remain outside the undertaking.

State the reading of the steer briefly enough for the human to examine. Ask a focused question when different answers would materially change the scope, order, effort, or completion conditions. Where the conversation already provides adequate direction, continue within it. Requested planning checkpoints and existing holds remain in force. An applicable execution strategy can be reused, with material changes brought back under its governing terms.

The human may revise the steer as results arrive. Preserve useful completed work and identify the obligations displaced by the new priority. Some may return to a later node, some may need a changed owner, and some may require an explicit scope decision. Recording this treatment lets another session understand why an unfinished contribution has ceased to be the immediate next action.

During 60% and 90%, much of the enduring project structure already exists. The main work of steering is therefore to navigate that structure and solve the problems encountered along it. Keep the selected outcome, the reasons for the route, and the extent of delegated discretion visible while the agents carry the work forward.

4.2Construct and traverse a local work graph

The project DAG records production relationships among Deliverables for a stated objective. A local work graph develops the part needed for a selected undertaking into executable contributions. It can include design, investigation, implementation, checking, integration, and reconciliation. Its useful extent follows the result being pursued and can span many sessions. One undertaking retains one graph through those sessions.

In the adopted App/Piping arrangement, the current local graph is Git-tracked at exactly execution/_Coordination/WorkGraphs/<undertaking>/WORK_GRAPH.md, relative to the project. Include it early in the undertaking's PR sequence, keep it current, and point LOOP_INIT to its actual location. Historical graphs remain at their original paths. A still-pinned undertaking changes to this arrangement through its owning adoption; the new current graph then uses the required location. Detailed AgentRuns evidence links the graph instead of carrying another current copy.

The graph must support both action and explanation. A participant should be able to establish what is available to work on, what has been done, why it was done, what ought to follow, and what would complete the undertaking. These questions require the intended outcome and its source as well as the current node states. A task list without their relationships leaves the next participant to reconstruct the reasons for its order.

Recover the current undertaking

Begin by locating the undertaking selected for continuation. Its graph should identify the intended result, work performed, outstanding inputs, and the state from which the next contribution can proceed. The fresh session checks this account against the actual project before arranging further work.

The session's opening instructions identify the project, active role, and current direction. They also give a route to the accepted basis and the selected undertaking. Figure 4.2 shows the entry information and six steps for advancing the work.

SESSION ENTRY AND LOOP ORDER

Opening instructions
  Project and active role; steering for the undertaking.

Current records
  Selected work graph, if one exists.
  Purpose, accepted basis, Deliverables, decisions,
  constraints, and verification requirements.

1. Orient and recover
2. Construct or revise the local graph
3. Organise and advance ready work
4. Execute, verify, and record the result
5. Close documentation and governance; record the run
6. Complete the graph and merge the final PR

Figure 4.2. Entry information and six steps of the development loop. The implementation steps can span sessions; the bounded closeout and final PR end the selected undertaking.

Begin by reading the selected graph and the owner's current direction. Examine their material claims against the actual branch, working tree, referenced evidence, and named unmerged worktrees. A repair may exist outside the main line. Edits may follow the last graph update. Check these conditions before commissioning replacement work or describing a result as complete. Preserve unrelated changes and deliberately parked work.

Also determine whether previous workers or checks are still active. A new session does not by itself release their files or test resources. Verify that the prior operation has stopped, or explicitly transfer ownership, before assigning another participant to the same work. The graph's recovery information should identify active operations whose continuation matters.

Recover the method as well as the current task. An undertaking can have an internal sequence, an identified basis, and earlier human decisions that still govern its continuation. Establish the last completed step and recover any facts needed for the next one. A change of session preserves these obligations until they are deliberately amended.

If no undertaking is selected, examine the current direction and relevant existing work before constructing one. If the selected record is missing or contradicts the observed state, recover the pertinent records and history before replacing it. Recent results or a handoff may help locate the work. A doubtful recovery record requires examination; other work can continue from a separately verified basis.

Leave a completed graph selected until another undertaking is chosen. Its completion remains visible at entry and gives the human a definite account of the result. Completion does not authorise an agent to begin another phase or invent a new objective. When the intended continuation cannot be inferred from the current direction and project state, establish it with the human.

Develop the graph from intent and the DAG

The graph-construction method described here takes an established phase DAG as input. SCC-directed work before the first DAG follows the cycle-resolution methods and the owner's specific steer.

Construct the local graph in five steps: understand the intended course; select a route through the project DAG; develop enough scope for executable work; build and check the graph; then save it and return to execution. HELP_HUMAN coordinates that preparation with the human. WORKING_ITEMS can develop a selected portion, and TASK can perform a bounded inspection or drafting contribution. Assign responsibility for maintaining the resulting record.

First recover the intended outcome, priorities, approach, limits, and completion conditions from steering and the relevant decisions. Relate those directions to the work already performed. An existing useful graph should be revised where the undertaking continues, preserving its identity and completed results.

Next locate the Deliverables that serve the outcome. Follow the project DAG upstream to the inputs and unresolved prerequisites they need. Follow it downstream far enough to understand affected interfaces and consumers. Examine the actual state of each material input. A pending dependency can be included as enabling work; a result already produced may be usable after its revision and evidence are checked. Select the smallest coherent body of work that reaches the intended outcome.

Read the controlling parts of the selected scopes of work, current-state and dependency records, and decisions. Inspect the associated implementation, tests, specifications, and relevant unmerged changes. Establish what exists, what is missing or incorrect, what is planned, and what remains uncertain. This comparison supplies the detail from which meaningful work nodes can be defined.

An unresolved diagnosis or design question becomes a node with a question and an expected return. Its answer can establish the basis for a subsequent implementation node. The desired behaviour alone may leave too much unknown to assign the implementation responsibly.

Where a capability lacks a sound Deliverable mapping, retain the mismatch and arrange the investigation or decision needed to settle it. Keep that work in the current graph when the undertaking can carry it. A concern without an immediate home receives the unallocated-work treatment described in §5.6. Its source, affected commitment, and missing allocation remain explicit.

Give each node a result and its prerequisites

A work node identifies a contribution that can be examined on return. State the affected Deliverables, relevant files, required inputs, write boundary, and completion evidence. An implementation node may include source, tests, and configuration needed for one coherent result. A reconciliation node identifies the document sections that must be brought up to date after that result. A review node identifies its candidate and the independent examination required.

Use stable node identifiers and express each executable dependency as a required result or condition. A node may need an agreed interface, an available candidate, a completed review, or an updated Deliverable record. These are different prerequisites and become satisfied through different work. Keep references used for information and assignments of ownership distinguishable from prerequisites.

Check the executable graph for cycles. A newly exposed cycle requires treatment before its affected nodes can be traversed as an ordered sequence. Identify the unresolved relationship and return it for the appropriate design refinement or human decision. Independent work with a verified basis can remain available while that question is resolved.

A Deliverable may contribute to several local nodes, and one integration node may involve several Deliverables. Preserve the links to the accepted project basis throughout. Node completion applies to the contribution it describes. Deliverable production, review, and acceptance retain their own requirements.

Include examination and reconciliation in the route

The graph includes the implementation, verification, validation where applicable, independent review, repair and integration needed to establish the intended result. Plan substantive PRs that include the documentation, reconciliation and conditional Task Management consequences needed for their slices. Neither a PR boundary nor a completed node requires a formal reconciliation pass or an intake by itself. After that integration, normally the penultimate merge, place one documentation/governance closeout stage before the final PR. Divide its affected deliverables into bounded comparisons as needed, with explicit statements, evidence and permitted changes. Follow with terse MEMORY run entries and final PR review and merge. This stage does not recur after each ordinary graph node.

This arrangement gives document upkeep a definite subject. An implementation may resolve a design detail or expose a limitation, and the affected Scope of Work should explain the resulting position. The reconciliation node performs that comparison and its authorised edits at the claim level. It updates supporting evidence and present state without turning every implementation detail into a new production commitment. Implementation completion and reconciliation completion remain separately visible until both have met their conditions.

Walk the graph from its starting nodes to the proposed outcome. Establish how every dependent will receive its inputs and how the result will be checked. Examine concurrent areas for common assumptions, shared writes, and test resources. Name the integration owners. State any material exclusion and its consequence for completion. This examination tests whether the selected route can actually produce what steering asks for.

LOCAL WORK GRAPH: CONTENT

Intent and selected route
  Intended result and completion conditions; steering source;
  priorities and approach; selected and unallocated scope;
  route through the project DAG; material open questions.

Deliverable scope
  Deliverable and basis; what exists; what this undertaking
  changes or resolves; corresponding work nodes.

Work
  Stable node identity and outcome; scope and write bounds;
  required inputs and reasons; completion check;
  state, result, evidence, or blocker.

Current state and recovery
  Checked revision; ready work and holds; local or unmerged work;
  active operations and ownership; graph maintainer;
  completed contributions and remaining consequences.

Figure 4.3. The information needed to explain and continue a local work graph. A small undertaking can keep this account in a short document; a larger one may use linked records.

Maintain the graph through traversal

Describe each node's current condition in terms useful for action. Identify the input or decision preventing progress, the operation underway, or the result and evidence supporting completion. A state label makes that account easier to find; the explanation establishes what the label means here.

Preserve the undertaking's identity, completed work and supporting evidence. Keep historical graph files at their original locations. A still-pinned undertaking retains its accepted recording basis until its owning authority explicitly adopts the App/Piping local development arrangement. On adoption, its current Git-tracked graph must reside at execution/_Coordination/WorkGraphs/<undertaking>/WORK_GRAPH.md, relative to the project, and LOOP_INIT must point there. Carry the current scope and state into that graph without maintaining a second current copy.

One maintainer integrates graph updates against the latest revision. Children return findings and proposed state changes to that maintainer, with the evidence needed to examine them. Preserve revisions and useful completed work. Retain necessary evidence before temporary worktrees are removed. The local graph then supports continuation from current state, including after a change of agent or session.

Keep LOOP_INIT's pointer aligned with the actual selected graph at the required WorkGraphs path. When the human selects a successor undertaking under the adopted arrangement, create its graph at that same path pattern and preserve the predecessor as history. Updating navigation changes neither authorised scope nor the required graph location.

Continue through ready authorised nodes while the intended undertaking remains applicable. Return consequential choices to the human and preserve the resulting directions. The graph can be restructured as discoveries require, with updated dependencies, verification, and reconciliation. Changes to the accepted project basis follow their owning decision process. Sections 4.7 and 4.11 develop those two kinds of revision.

4.3Organise the agents and their execution resources

The local work graph identifies contributions and the relationships among them. The agent arrangement assigns responsibility for carrying those contributions through. HELP_HUMAN maintains alignment with the human and coordinates the selected undertakings. WORKING_ITEMS manages an undertaking's implementation, its internal dependencies, and the integrated return. TASK or a bounded ephemeral Type 2 instance performs an assigned contribution.

Two structures therefore operate together. The work graph expresses what depends on what. The delegation hierarchy expresses who assigns, supervises, and integrates the work. In this arrangement, children return consequential findings and coordination needs through their parents. A dependency between contributions can run across managers; the managers preserve it through their exchanges. There is no need to add an agent for every graph node or every arrow.

Keep HELP_HUMAN and WORKING_ITEMS in contact

HELP_HUMAN interprets steering against the project basis and brings the relevant Deliverables and managers into the undertaking. It retains the reasons for the chosen route, coordinates matters affecting several managers, and prepares consequential choices for the human. Assign responsibility for maintaining graph and decision records explicitly; it need not be carried by the same instance that coordinates the undertaking.

WORKING_ITEMS translates its assigned portion into concrete contributions. It inspects current work, arranges the inputs, delegates bounded execution, follows findings, and examines the combined result. The undertaking may be a Package, selected Deliverables, a workflow run, or another coherent body of work. A connected problem may cross Package boundaries; several independent problems may occur within one Package. The assignment follows the coordination required and retains its actual authorisation.

The manager reports more than individual task completions. HELP_HUMAN needs to know what the combined result establishes, which dependencies have become usable, which questions remain, and how those matters affect other undertakings. In return, the manager receives relevant changes in steering and cross-undertaking decisions. This exchange lets the human direct the project through HELP_HUMAN while WORKING_ITEMS carries substantial execution forward.

A small independently assessable contribution can be dispatched by HELP_HUMAN directly to Type 2. Use WORKING_ITEMS where implementation, feedback, repair, and integration need sustained coordination. The human can also work directly with a manager. These arrangements retain the same responsibilities while varying the number and placement of instances.

Parent-mediated coordination adds an exchange, but gives assignment changes and combined results an accountable point of examination. Its value rises when a finding can alter several active contributions. For small work, the parent can record the finding and its disposition together without adding another management layer.

HELPS_HUMANS remains available for conception and design. WORKING_ITEMS brings design-changing questions through the human or HELP_HUMAN, with the relevant requirement, finding, and consequences. The resulting design work returns a sufficiently understood basis for implementation. This is a continuing relationship through development.

Define typed instances for the particular work

Agent Type identifies a position in the delegation arrangement. Type 0 coordinates with the human across undertakings; Type 1 manages a bounded undertaking and may delegate; Type 2 executes a bounded contribution and returns to its caller without delegating. The four standing roles give those responsibilities a reusable expression.

Within that repertoire, an instance can be defined for a particular assignment. A Type 2 may inspect an interface, implement a service operation, devise a verification case, or reconcile named Deliverable sections. Its specialisation is supplied through the brief, relevant context, selected methods, and tools. Additional subject matter can therefore be assigned without expanding the permanent role inventory.

The arrangement can change as the graph develops. A manager may first use one investigator, then dispatch several independent implementations once their shared input has been established. Another manager can oversee verification of their combined behaviour. HELP_HUMAN maintains the relationship between these undertakings and the human's objective. All active instances retain identifiable parents, boundaries, and return paths.

WORK AND DELEGATION: ILLUSTRATIVE ARRANGEMENT

Work relationships
  Shared definition -> implementation A -> combined verification
                    -> implementation B -> combined verification
  Checked results   -> bounded Deliverable reconciliation

Agent responsibilities
  HELP_HUMAN, Type 0
    WORKING_ITEMS, Type 1: connected implementation and integration
      Type 2: implementation A
      Type 2: implementation B
      Type 2: independent checks or review
    Type 2: bounded reconciliation, where directly assessable

The parent relays relevant findings. Every assignment retains
its own basis, writes, completion conditions, and return.

Figure 4.4. The work relationships and the delegation arrangement describe the same undertaking from different viewpoints. The example neither requires one instance per node nor requires a manager for every Package.

Select resources by expected task performance

Model selection is a separate decision from Type and role. Consider the particular task or domain: the information to compare, uncertainty to resolve, complexity of the implementation, consequences of error, and means available for checking the result. A bounded technical review may warrant a more capable model or greater reasoning effort than a routine management assignment. A Type number supplies no ranking of the intelligence needed.

The harness is the environment through which the model receives context, uses tools, and performs operations. Its capabilities are part of the execution choice. An assignment may need source editing and test execution, another a graphical application, and another only read access to a limited set of records. Establish actual tool availability, permissions, and the supported delegation mechanism before launching the work. A model's capability cannot make an unavailable operation executable.

Choose reasoning effort and context for the question being examined. A substantial comparison may need more sustained reasoning and a wider body of sources. A narrow reproducible check may be carried mainly by deterministic tools. The assignment still needs a clear result, adequate inputs, and a method of examination. More reasoning effort by itself establishes neither correctness nor independence.

Consider performance in both money and time. An inexpensive attempt can become costly if it produces repeated repair, consumes another participant's time, or delays integration. A more expensive execution can be appropriate when experience suggests it will resolve a difficult question with less total effort. These are expectations to examine against returned work. Record the actual model, reasoning settings, relevant harness capabilities, substitutions, and observed limitations where the host makes them available.

The useful comparison concerns the cost of obtaining a contribution fit for its next use. Include preparation, checking, correction, and integration in that assessment. Preserve measured costs and durations where available and distinguish them from estimates. A handful of unlike assignments supports limited conclusions about comparative performance. Use experience to improve selection without treating a role title or a model name as a performance guarantee.

Keep the strategy proportionate

State how the undertaking will be organised: HELP_HUMAN's contribution, manager responsibilities, selected execution resources, concurrency, write scopes, review, and integration. Obtain agreement where steering or an adopted procedure requires it. Reuse a clear, applicable strategy and bring material changes back under its terms. A new session alone need not reopen an agreed strategy.

For independent work, a parent can commission bounded contributions and integrate their completed returns. Where findings from active work affect other contributions, the parent selects and relays the relevant information while execution continues. A mixed arrangement uses both forms of coordination. Choose according to the work, preserving the parent's responsibility for amendments and the combined result.

Review and integration capacity constrain useful concurrency. When returns accumulate faster than they can be examined and combined, allocate effort to that work. When shared decisions dominate the exchanges, draw the affected development together. When established interfaces support independent progress, release it. The purpose of the arrangement is to advance the selected outcome with an intelligible account of quality, cost, and remaining work.

4.4Develop the technical details

Detailed development establishes how each contribution will meet its requirements and interact with the rest of the product. It gives technical form to the means of execution established by 30%. The required detail depends on the contribution. It can include interfaces, states, data structures, calculation methods, limits, operating sequences, failure treatment, and verification.

Read the local Scope of Work and its governing sources before selecting a solution. Establish which outcomes and choices are fixed, which methods have been prescribed, and where the assignment permits discretion. Relate each proposed detail to that basis. This keeps implementation choices within the intended contribution while exposing decisions that require the human's attention.

Describe the relationship at each interface

An interface defines an exchange between participants in the product. Its details should tell a supplier what to provide and a consumer what may be expected. Depending on the work, the exchange can concern a value, a document, an operation, a message, or an observable state. State its identity, meaning, required conditions, and treatment when the expected exchange cannot occur.

Names and data formats provide only part of this account. A software operation also has conditions under which it may run and effects that its caller must understand. Establish what remains unchanged, what becomes current, and what happens after a rejected or interrupted operation. Where two routes are intended to perform the same operation, specify the behaviour they must share and the differences allowed in their presentation or transport.

A brief example is a request to apply a proposed change to an identified revision. The producer must identify the revision used to prepare the proposal. Under the illustrative decision used in this manual, a difference between that revision and the live revision requires refusal of the stale proposal. The live document is retained, the reason is explained, and the user can request a fresh proposal. These details allow each side to be developed and tested against the same meaning of the exchange.

In a traditional engineering contribution, the corresponding examination follows the information being transferred and the conditions of its use. The supplying party establishes the defined input; the receiving party applies it within its stated scope and limitations. Software changes the form and frequency of many exchanges. The need to establish their meaning and responsibility continues through both domains.

Carry detail into the appropriate record

Place each design detail where the project expects it to be maintained. Product code, schemas, drawings, specifications, and configuration each have an appropriate technical role. The Scope of Work carries the Deliverable's production obligation, governing decisions, and evaluation relationships. The work graph records the present assignments and discoveries. The local status record identifies production standing; the graph carries execution and MEMORY.md indexes what each run did in the Deliverable.

Keep the Scope of Work's maintained claims at the level of obligations, depended-on interfaces, and conditions examined through named verification. Technical documentation and evidence describe the current mechanism. A mechanism specifically adopted by the human retains its governing force. This division keeps the production contract useful through repeated implementation changes.

When a commitment changes, identify the affected statements, the decision authorising the change, and the consumers that must receive it. Preserve the preceding basis and the reason for its replacement. Further design detail can elaborate the contract within its existing terms; a changed commitment requires its own examination and decision.

Keep proposals and findings recognisable while the work is open. A proposed method can be evaluated through a bounded investigation. An observed failure can be reported against an identified candidate. A human decision can adopt a revised behaviour within a stated scope. Each is useful information, and each has a different effect on what other participants may do next.

Test details while they are still economical to change

Use bounded implementation and testing to examine a design as soon as the relevant behaviour is operable. A connected exercise can show whether the proposed interface carries enough information or whether an operation leaves a state its next consumer cannot use. The finding then returns to a specific design question while its dependent work is still identifiable.

The examination should be capable of revealing an unsatisfactory result. A demonstration chosen only to display the intended path can leave important conditions unexamined. Derive scenarios from the requirements, relevant operating conditions, and known uncertainty. Preserve what each exercise establishes and what it leaves open.

As details become dependable, additional work can proceed independently. Maintain the definition and revision of the input each consumer receives. When a design changes, examine the effect on consumers already working from it before commissioning further dependent implementation. The manager's task is to keep the developing detail usable across the actual team, including participants who were absent from the discussion that produced it.

4.5Commission a bounded contribution

The brief binds the method to the present assignment. It tells the receiving agent what to accomplish, what material governs the work, what it may change, and what the caller needs on return. Prepare it before launch and preserve the version actually supplied. The parent can then examine the contribution against the same assignment the executor received.

A brief needs sufficient explanation of purpose to support choices within its boundary. Identify the result and its use in the larger undertaking. Supply the relevant requirements, accepted decisions, interface definitions, and existing work. State exclusions that could otherwise be mistaken for unfinished parts of the assignment. Identify required checks and the evidence through which the caller will assess completion.

Select context deliberately

Supply the context that bears on the contribution. The active role instructions establish how the agent contributes; a selected workflow supplies the method; the brief establishes its particular objective and limits. Load the resources needed for the selected stage. Preserve their origins and revisions so the resulting record can establish which instructions and inputs were actually used.

A reference to another Deliverable may require more than its title. The executor needs the particular output, condition, or decision on which its work depends. Follow the relevant source reference far enough to establish that meaning. Where an input is unavailable, the brief must make the resulting limit explicit or assign the work needed to obtain it before dependent production begins.

Avoid copying the entire project history into each assignment. A focused body of context is easier to inspect and maintain. Retain the source pointers through which the executor can reach further relevant material within its authority. Wider reading is appropriate when a finding shows that the selected context is insufficient; the supplied history should record material additions where the host exposes them.

For a small read-only question, the retained launch message can itself serve as the brief. Preserve its purpose, context identity, parent and role, read-only boundary, expected return, and checks. More extensive work may need a separate structured brief. The same responsibilities apply at both scales.

Establish effective permissions

The brief identifies exact writable targets and the operations permitted for the assignment. The effective boundary also depends on the host, the role ceiling, and any selected method restrictions. A directory supplied as a context anchor does not by itself grant permission to write there. The parent must know the available operations before promising an executable assignment.

For software implementation, the brief must make the change permission explicit. Name the writable targets, relevant Package and Deliverables, accepted basis, exclusions, criteria, checks, and expected return. Supply the project's defined verification methods and the operations permitted to carry them out. Figure 4.5 gives an outline for this information.

BOUNDED SOFTWARE BRIEF: OUTLINE

Purpose
  The result this contribution must establish and its use.

Scope and basis
  Relevant Package and Deliverables.
  Requirements, decisions, interfaces, and input revisions.

Permitted work
  Writable files or other exact targets.
  Operations allowed and work excluded.

Examination
  Applicable acceptance criteria.
  Defined checks and evidence required.

Return
  Changes, results, unresolved matters, and remaining work.
  Parent responsible for examining and integrating the result.

Figure 4.5. An outline for a bounded implementation brief. The actual assignment supplies concrete targets, requirements, permissions, and return conditions.

Check that the assignment can be performed within both its declared scope and the actual host permissions. A method can restrict operations more narrowly than the host. When a required operation lies outside that boundary, return the specific need, the useful work already completed, and the verification still outstanding.

Preserve the assignment and its changes

Retain the assignment as it stood at launch, including its supplied context, selected method, revisions, and content hashes where available. Record actual parentage and the mechanism used to create the child. An authored brief is a prepared instruction; the execution record must establish whether a child actually ran and what it received.

A separate process or inherited conversation is insufficient evidence that the intended role and boundary were supplied. Record the instructions actually given. Where the host remains broadly writable, describe the brief's narrower scope as an instruction restriction. Claim sandbox enforcement only for a boundary the host actually enforces.

During execution, a new input or decision may require an amendment. Name what changed, which part of the assignment it affects, and which earlier work needs reconsideration. Preserve the previous brief and supply the revised version through the applicable coordination mechanism. The new version must remain within the authority available to the parent. A change requiring human judgment returns to the human before dependent action proceeds.

TASK checks its result against the brief and returns it to the caller. The parent examines the artifacts, checks, containment, conflicts, dependencies, and the contribution's fit with the undertaking. Record whether it can be used, requires repair, remains held, or needs a decision. A partial return should preserve its completed work and define the obstacle that prevented further progress. Update the associated graph node and retain a separate follow-on contribution where repair or reconciliation remains.

4.6Coordinate parallel work

Parallel work is useful when contributions can develop independently enough to produce results that can be combined. Establish that independence through their requirements, inputs, write ownership, and integration conditions. The local graph identifies independent scopes and the conditions under which they can proceed together. Confirm those conditions against the selected basis before dispatch.

Three relationships deserve attention. Technical dependence concerns the information and behaviour one contribution needs from another. Write ownership concerns who may change a shared artifact. Resource use concerns the environments and tools through which work is exercised. A plan for concurrency must account for all three.

Separate writes and preserve shared meaning

Assign disjoint write targets to concurrent executors. Give a shared file one integration owner or arrange explicit serial access. Keep the boundary clear for generated files, common configuration, and evidence locations as well as product source. A contribution that requires a change outside its assigned targets returns that need to the parent.

Disjoint files can still embody a common assumption. A producer and consumer may implement the same field differently, or several components may use different definitions of a valid state. Supply the shared contract and revision to each affected brief. Identify who owns its interpretation and how a proposed change reaches every consumer.

When a shared definition is still being developed, concentrate that work under one coordinated undertaking. A bounded experiment may help resolve it. Once the definition supplies a dependable basis, the manager can release the dependent contributions under their respective briefs. The amount of concurrency can therefore change within a phase as particular relationships become clearer.

Keep integration in the original assignment arrangement. Name the owner, target, required inputs, and examination of the combined result. Contributors should know what their return must supply for integration and which other work is expected to meet it there. This avoids receiving several locally finished outputs whose compatibility has never been assigned for examination.

Relay findings through the parent

A finding matters to coordination when it changes the basis, validity, or useful next action of another contribution. The child reports the finding to its parent with the supporting observation, affected work, and proposed response. The parent determines which participants need the information and whether it requires a notice, brief amendment, hold, graph revision, or human decision.

Preserve the standing of the information during this relay. An observation remains an observation; an inferred cause remains an inference until examined. A recommendation remains a recommendation until acted upon under the appropriate authority. A summary sent to another child must not turn a proposed interface change into an accepted requirement.

ILLUSTRATIVE COORDINATION NOTICE

A failing exercise shows a stale proposal replacing a manual
edit made after the proposal was prepared. The proposal's
source revision differs from the live revision.

The cause is not yet established. Inspect the revision
comparison and retain the candidate and failed observation.
Hold the affected application path during this investigation.

The parent assigns the diagnosis and supplies the accepted
requirement to refuse stale application to the affected executors.
Independent work can continue on an established basis with separate
writes and test resources.

Figure 4.6. A constructed finding and its coordination consequences. The accepted requirement is retained while the cause of the failure is investigated.

For coordinated work across managers, HELP_HUMAN maintains the relationship among undertakings and brings consequential choices to the human. A manager engaged directly by the human presents cross-Package decisions through that relationship. TASK returns coordination needs to its caller and creates no additional delegation layer.

Supply updates at a boundary the receiving execution can actually observe. Preserve the revised instructions and any acknowledgment exposed by the mechanism. Editing a source file alone does not establish that an active child has received the change. Where receipt is uncertain, hold the affected reliance and establish the child's actual basis before proceeding. Execution history and retained context can support this examination where the host makes them available.

Coordinate test resources

An application window, test database, working directory, or other shared resource can be altered by one test while another is using it. Identify those resources when planning concurrent checks. Separate them where the test arrangement supports isolation, or serialize access through one owner. A test result needs an environment whose relevant state can be accounted for.

Serialise shared writes and test resources where necessary, including native or browser state whose concurrent use would invalidate results. Record the candidate and environment used for the observed workflow. An unexpected result from a contaminated environment first requires an intelligible observation before the team can infer a product defect from it.

Intervene when coordination ceases to help

Observe the pattern of returns and repair attempts. Several repeated attempts with no new evidence suggest that the diagnosis or division of work needs reconsideration. Narrow the question, inspect the relevant boundary, change the means of observation, or divide the problem into contributions with assessable returns. The next attempt should have a reason to produce information the previous ones did not.

Use the same test when adjusting concurrency. More simultaneous assignments are helpful only while the project can examine, coordinate, and integrate their outputs. If shared decisions dominate the exchanges, draw that work together. If mature interfaces separate independent contributions, allow them to proceed. The working arrangement follows the condition of the work while preserving the agreed responsibility for its result.

4.7Carry findings into decisions and change

Detailed work exposes both defects and incomplete definitions. A test may fail an accepted criterion. A consumer may need a detail its supplier has not specified. An implementation may reveal an alternative that better serves the purpose. Each finding needs a treatment that preserves the relationship between the evidence, the commitment, and the action that follows.

First identify the subject. State the affected requirement or choice, the relevant candidate or source, the observed difference, and the work that depends on it. Establish whether the issue concerns the produced work, its recorded account, an open design choice, or a fixed part of the accepted basis. This examination determines the authority and method needed for the response.

Exercise discretion within the assignment

A bounded implementation ordinarily leaves room for choices about its internal construction. The agent can inspect alternatives and select an approach within the requirements, exclusions, and permitted writes. It must preserve specifically adopted choices and protected criteria. Read the source terms and human direction to establish the actual extent of that discretion.

The four philosophical perspectives help examine a proposed choice. Determine which objects and relationships it changes, what supports its expected behaviour, how it will be carried out and checked, and which purposes or consequences govern the preference. These questions belong in the reckoning that prepares the contribution. They do not add four forms or four human prompts.

Disclose a departure from specification with its rationale and the means of reversing it. Where the departure conflicts with a human ruling, specifically adopted choice, or protected criterion, obtain the necessary human decision before it takes effect. Other implementation departures may fall within delegated discretion within the assignment, but they still need an intelligible record. An executor cannot determine that a fixed requirement is optional merely because another implementation is easier.

Prepare a question the human can decide

A consequential decision package brings together the issue, its grounds, the alternatives, and their effects. Explain what the project currently requires, what has been learned, and why the proposed response needs judgment. Give a recommendation with its reasons and identify the work that will follow each relevant choice. State any uncertainty that affects the comparison.

Keep the proposed decision proportionate to the finding. A local design choice can be presented briefly when its consequences are clear. A change affecting several Deliverables requires enough examination to identify their altered inputs, work already performed, and outstanding obligations. The human should be able to understand the choice without reconstructing the entire implementation history.

Record the human's words and distinguish the agent's interpretation of them. Preserve the scope and basis of the resulting direction. Silence supplies no acceptance. If the response leaves a material part unresolved, identify the affected action and seek its resolution without reopening decisions that remain clear.

Return to design when the question changes

WORKING_ITEMS carries design-changing findings to HELPS_HUMANS through the human or HELP_HUMAN. The return should describe the actual difficulty and its consequences for the product. It should preserve the relevant requirement, candidate, observations, and work that can still be used. This gives the design partner a concrete question rather than an instruction to reconsider everything.

The design exchange may confirm the existing requirement, develop an unresolved choice, or propose an amendment. Carry the resulting decision back into the affected briefs, contracts, and verification. Preserve the findings that led to it. A participant joining later needs to understand why the revised course differs from the one described in an earlier source.

Propagate amendments through their owners

A change to accepted decomposition requires examination of the proposed change and impact, the exact amendment and propagation plan, and the independently examined resulting records. As with decomposition, these are decision subjects that can be considered together when the undertaking is sufficiently small. The manager prepares the evidence and carries the accepted amendment through its assigned write boundaries and downstream handoffs.

Propagation includes the consumers of the changed basis. Identify affected local context, production contracts, dependency records, derived views, and verification. Their owners perform the required work under the accepted plan. A completed edit to the decomposition can leave several downstream obligations open. The amendment record must state which records are current, which require regeneration, and who is responsible for the remaining work.

Use the project graph and source references to locate possible consequences, then examine their actual extent. A change in an upstream statement may require rework, further review, or a recorded conclusion that an earlier contribution remains applicable. Preserve the evidence for that treatment. The graph locates the relationship; the responsible participants establish what the particular change means for it.

Renew the project DAG during detailed development

During the 60% phase, detailed work commonly reveals a clearer route to delivering the product. A shared definition may need to be separated from its implementation. A consumer may need an input earlier than was apparent during setup. A proposed division may leave a responsibility without a suitable owner. These findings can warrant a new project DAG. Preserve the finding in the local graph and bring the affected project relationship into the appropriate design or amendment work.

First distinguish the level of change. Dividing one implementation node into two tasks may alter only the local graph. A change to the Deliverable's governing scope or a production relationship can affect the broader basis. Identify the particular statements, nodes, edges, and consumers involved. The required decision and revision then follow from what is changing and the project's adopted graph rules.

Graph revision during 60% follows a material finding or decision. It can occur several times within the phase. Carry the source changes, extraction, audit, and any necessary cycle resolution through to the successor graph. Its revision must have a stated basis and appropriate authority. A new session alone gives no reason to reconstruct the accepted graph.

Once a successor is adopted, examine its effect on active local graphs. Identify which nodes retain their basis, which need revised inputs or verification, and which must pause. Preserve useful completed results with the revision they support. Revise affected briefs and confirm that active workers have received material changes before relying on their continuation. The preceding accepted graph and its basis should remain recoverable after the successor is selected.

A local discovery may expose an unresolved SCC. Do not infer an executable order or readiness from it. Identify the actual missing inputs and hold the work that needs them, as described in §3.11. Their consequences can justify prioritising a bounded investigation or design contribution while independent authorised work continues. Carry the remedy, its rationale, and the applicable decisions into the renewed project basis.

The worked undertaking in Appendix A distinguishes a correction that changes only local tasks from a finding that requires revised scope and a successor project DAG.

As detailed development proceeds, these revisions should leave fewer structural decisions anticipated on the path to delivery. The approach to the 60% boundary is assessed from the remaining work and its dependencies. Section 4.12 develops that judgment and its consequences for the next phase.

4.8Implement and exercise the result

Begin implementation with one defined change: its required result, accepted basis, permitted writes, and examination. Inspect the smallest relevant implementation and test surface before editing. The manager must have settled the assignment's scope sufficiently for the executor to recognise a coherent return.

Figure 4.7 gives a six-step procedure for carrying the assignment from definition through a checked return.

The method prescribes a minimum coherent change. Coherence is determined by the required behaviour and its relationships. A change may need source, tests, configuration, and documentation together to establish that behaviour. Keep unrelated cleanup outside the assignment. Preserve existing user work and report any wider change that the objective appears to require.

BOUNDED IMPLEMENTATION: METHOD ORDER

1  Confirm objective, basis, write targets, exclusions, and checks.
2  Inspect the relevant implementation and test surface.
3  Make the minimum coherent change; preserve unrelated work.
4  Add or update tests in proportion to behaviour and risk.
5  Run the required checks within the assignment's permissions.
6  Check the changed scope and return the changes, evidence,
   residual risks, and blockers.

Figure 4.7. Six steps for bounded implementation. The defined result determines what constitutes a coherent change and which examination is required.

Select checks from the project basis

Select checks from the changed behaviour and the governing verification requirements. A project can maintain a common set of defined checks so that the manager and executor know what each examines and how it is run. Automated selection may identify checks affected by changed files. Examine their coverage before treating the selection as sufficient, then retain the actual results with the candidate.

These functions separate selection, execution, and assessment. A proposed check still needs authority to run. An executed check has an observed result. Its relevance to the criterion depends on what it actually examines. Read the declared check and preserve its result with the candidate. Where a required check is unavailable, return the specific outstanding verification.

Where the change affects generated artifacts, compare them with their sources and expected generation results. Structured comparison can help expose a missing update or an unintended difference. Establish the actual availability and scope of the tools used before relying on their return.

Exercise what a user or consumer can accomplish

Build and testing should progress together. As soon as a changed user workflow is operable, exercise it through the route the product provides. For an interactive application, use actual pointer and keyboard interaction, native computer use, and suitable automation alongside focused code tests. The observation should include the resulting state and the next relevant action, as well as the visible feedback.

For software whose consumer is another program, the same management question concerns the operation exposed to that consumer. Examine the applicable request, response, state changes, and failure treatment through the intended route. Select the cases from the product's own requirements and verification method. A service or command-line program needs a domain-appropriate examination; the editor application's screen-based scenarios are particular to its use.

Connected checks examine relationships that can remain outside a component's local tests. A successful operation may leave state that saving, reopening, or a subsequent operation handles incorrectly. Exercise the connected sequence once the relevant behaviour is available. Record which part was observed and which dependent route remains unavailable.

Extend a reusable set of scenarios as the product develops. For an interactive product, relevant scenarios include ordinary use, invalid inputs, cancellation, interruption, recovery, keyboard operation, and applicable window conditions. Apply the scenarios appropriate to the slice and its consequences. Select each exercise for the behaviour changed and the consequences under examination. When presentation changes can affect interaction, repeat the affected connected journeys after that work.

Observe the relevant environment

A result concerning native-host behaviour requires examination in the native application. Browser execution may support other claims, but its observation must retain that environment and coverage. Identify required native scenarios in the verification brief and report any unavailable witness. The governing criterion determines whether another form of evidence is an acceptable substitute.

Likewise, state the limits of an agent-driven exercise. It can supply reproducible observations and expose defects. An assessment of practical usability needs appropriate users, tasks, and conditions of use. The person responsible for acceptance considers whether the available examination supports the intended use.

After a defect is repaired, add suitable regression coverage and repeat the affected scenarios. A passing rerun provides an observation to examine alongside the diagnosis and changes. Confirm that the result addresses the known failure rather than merely exercising a different path. Preserve both the failed observation and the subsequent evidence so the correction can be assessed.

4.9Preserve the evidence of development

An empirical claim needs an identifiable observation or examination that supports it. Retain the inputs, candidate, relevant environment and tool versions, commands or actions, expected result, observed result, and necessary raw outputs. Provide a bounded rerun method where reproduction is feasible. This record allows a later participant to check the claim and assess whether the method was adequate for its proposed use.

The required extent follows the claim. A correction to a source reference can be examined against the identified source and change. A claim about recovery of user data needs evidence for the state, conditions, operation, and resulting preservation. Choose the record needed to support that examination without duplicating unrelated material.

Bind evidence to its candidate

Record the version actually exercised. A branch name can move as development continues. A commit identifies a retained version, while uncommitted changes require their own exact identification. The result should establish which candidate, inputs, and relevant configuration were present when the check ran. Preserve the relationship when the candidate is later integrated.

A changed input can affect evidence even when the tested source file is unchanged. An interface definition, test fixture, generated artifact, or expected result may have changed the meaning of the earlier examination. Assess the affected relationship and repeat verification where needed. Keep older evidence attributable to its original basis; it remains useful history and may still support a narrower unchanged claim.

The test's expected result is also part of the basis. Determine where it came from and how it represents the criterion. A comparison against an expected value invented during implementation cannot establish conformity to an external requirement. The agent can prepare a proposed comparison or investigate a missing reference, but its standing must remain apparent until the applicable decision or verification establishes it.

Keep outcomes distinct

A check can complete and report failure. It can be blocked before execution, unavailable in the host, skipped within an authorised plan, or interrupted before obtaining a result. Preserve the actual condition and the work needed to resolve it. A summary should allow the next participant to distinguish an observed failure from an unperformed examination.

Use the same care with partial results. A local check may pass while a connected route remains unavailable. A defect correction may have a successful focused rerun while independent backchecking is still pending. Report both the useful result and its boundary. The remaining work then has a concrete basis for assignment.

When a required check cannot be performed, retain the candidate and state the limitation. The parent decides how to obtain the missing capability, revise the authorised assignment, or present the unresolved reliance to the human. The recorded absence supplies a management question; it cannot be converted into a successful outcome by changing the wording of the report.

Preserve useful evidence without exposing protected material

Keep non-secret evidence sufficient for the declared claim. Preserve the applicable restrictions on secrets and private user material when designing the evidence record. Plan the test and its record accordingly. An invented fixture can support a bounded examination when its relevant properties and limitations are stated. It must remain identifiable as a test fixture rather than an actual user's data.

If the required examination cannot be reproduced or its evidence retained safely, state that limit and withhold the unsupported claim. The human may need to arrange another form of examination. The method does not authorise disclosure, transfer, or retention outside the applicable boundary.

Keep evidence in the undertaking folder or another appropriate existing artifact location, and link to it from the graph and review records. Preserve material needed for continuation outside temporary worktrees before retiring them. Retain child returns verbatim alongside the parent's findings and dispositions. A summary can direct the reader to the relevant result without replacing the original report. This separation preserves the distinction between what the executor returned and what the parent concluded from it.

4.10Review and integrate each contribution

Apply the independent-review requirements of the owning project to the actual candidate. The frozen-diff practice developed here examines each proposed mergeable slice before integration. The reviewer is a fresh-context participant who did not write the candidate. Supply the applicable requirements, complete source change, evidence, and a brief directed toward defects and unsupported claims. The implementer's self-checks remain part of preparation.

A diff is the set of changes between identified versions. Freezing the diff defines the candidate being examined, including changes to tests, configuration, generated artifacts, and instructions within the slice. Review depth follows what those changes can affect. A small slice can receive a small independent examination while retaining complete coverage of its changed content.

Protect the criterion during repair

Preserve a protected test, tolerance, oracle, or limit when it disagrees with the implementation. An oracle is the reference used to determine the expected result of a check. The conflict may concern the implementation, the criterion, or the suitability of the examination. Retain the measured result and bring the conflict to the human with a recommendation. Block the affected acceptance or merge until it has an appropriate disposition.

A repair should address the identified defect. Examine changes to checks as carefully as changes to production code. The executor may add coverage or correct a test within the authorised basis, but cannot weaken a protected condition to obtain a pass. Where a criterion is legitimately amended, the human decision and the resulting verification must remain tied to the new basis.

This discipline preserves the meaning of a successful check. It also helps the reviewer detect a false repair: the observed failure disappears because the comparison was removed, its input was narrowed, or its expected outcome was changed. The resulting pass would concern a different examination. The original defect still requires its disposition.

Examine findings and backcheck corrections

The reviewer reports a finding with its location, evidence, and consequence. The parent and implementer examine the finding against the candidate and requirements. Correct actionable defects within scope, preserve any disagreement with its grounds, and bring consequential decisions to the human. The record should show what was reported and how each finding was treated.

Backchecking examines the correction and the relationships it can affect. It may be focused when the remedy is narrow. It must still cover the changed candidate and establish whether the reported defect has been addressed. Earlier review cannot cover later changes merely because they occurred on the same branch.

Fresh context supports a separate examination of the supplied basis. It does not guarantee that a reviewer will find every defect. A different instance using the same model must be described accurately; it supplies no model diversity. The responsible human judges whether the combined evidence supports the proposed reliance.

CANDIDATE-SPECIFIC EXAMINATION

1  Identify the basis and complete change.
2  Retain the implementer's checks and evidence.
3  Review the frozen candidate independently.
4  Correct findings and backcheck affected content.
5  Run required checks on the candidate for integration.
6  Integrate, examine the combined result, and record it.

Further candidate changes require affected review
and verification coverage.

Figure 4.8. The relationship between a candidate, its examination, and integration. Apply the adopted project checks and review requirements to the actual combined result.

Integrate against the actual receiving state

Integration is an assigned contribution with an owner, a target, and examination of the resulting whole. Before combining work, inspect the receiving state and the changes that have arrived since the contribution was prepared. Establish whether its inputs, interfaces, and review evidence still apply.

In a Git-based software project, a branch identifies a line of development and a worktree provides a working checkout. A pull request presents a proposed change for review and integration. The index contains the changes staged for a commit. These records let the integration owner identify what is being combined and preserve unrelated work. Inspect them before staging or merging.

An upstream change can alter the combined candidate. Review the resulting change and repeat the checks whose applicability has changed. Preserve other contributors' work and return substantive conflicts beyond the current authority. Do not replace another contributor's branch history without the applicable authority: that operation can remove the history on which the other participant is relying.

Use the standing integration authority actually granted to the project. A valid grant can permit ordinary repository operations without a new permission request at every merge, while retaining required review, checks, and holds. It applies only within its stated scope. Product acceptance and publication remain separate decisions.

Continuous integration, or CI, runs configured checks on source changes. Record required results against the candidate that merges and preserve any outstanding native or practitioner examination. The project's instructions and check definitions govern that selection.

Return the integrated result at its proper scope

The manager examines how the contribution works with the undertaking and records what can now be used. It also carries forward unfinished dependencies, unavailable checks, review findings, and explicit holds. The return gives the next participant an account of the combined result rather than a list of independently completed tasks.

Source integration, Deliverable acceptance, and publication concern different acts and should receive their own records. A successfully integrated slice can advance the project substantially while its Deliverable still needs further production or review. The human's authority for acceptance and release remains in the governing arrangement. Report the contribution achieved and the work still needed without extending the result beyond its evidence.

4.11Close the records and preserve continuation

Development changes both the product and the team's account of it. A completed contribution may settle a design question, satisfy a prerequisite, expose a limitation, or leave an obligation partly fulfilled. The affected Deliverable documents must carry an accurate description of that position. Subsequent work can then use them to understand what is intended, what has been implemented, what has been verified, and what remains.

Plan one bounded documentation and governance closeout after the local graph's intended implementation and evidence work. It identifies the affected statements, integrated candidate, evidence, and permitted changes. Its completion requires those warranted changes to be made and checked when writes are authorised. A supported conclusion that no change is needed can also complete the comparison. Figure 4.9 gives the sequence.

Close the records against the completed work

Give the node the completed capability, repair, investigation, or design decision; the affected Deliverables; the stable code revision or exact candidate; the relevant human direction; and explicit document write targets. Mark unmerged work and incomplete verification accurately. A code result can be suitable for describing the present position while still lacking the standing required for a broader completion claim.

One Deliverable or a small connected group is a useful scope. The assignment must be narrow enough to inspect the actual statements and their implementation. TASK can perform it without delegation. An oversized comparison returns to its parent for division. If the Deliverable mapping cannot be established, return that precise question rather than producing a generic review that leaves the document responsibility unresolved.

Use this node after the intended implementation/evidence integration (normally the penultimate merge) and before the final PR. Documents that are themselves implementation inputs or outputs are developed as ordinary production work when needed. The closeout then accounts for the combined result once: which statements changed, which governing decisions were applied, and where unresolved consequences belong. If required implementation or evidence is missing, complete that work and recheck the affected comparison before closing.

Read the controlling documents

Read the current production obligation, its evidence, present state, and controlling decisions. Establish which record governs before editing; an archived or superseded copy supplies history. The following table identifies the records and the question each contributes to the comparison.

Read other review or derived artifacts when the affected statements depend on them. Preserve accepted and historical records. Identify required downstream regeneration without presenting it as already performed. Reconciliation need only touch the files relevant to the bounded result.

Compare in both directions

First follow the document's affected statements into the implementation and checks. Establish whether the code provides the described behaviour, enforces the constraint, uses the stated interface, and has the evidence claimed. Distinguish missing implementation from unperformed verification. Refer to the actual source and check results rather than relying solely on a completion summary.

Then follow the bounded code result back into the Deliverable documents. Look for resolved design details, newly established behaviour, changed interfaces, limits discovered during testing, and consequences for dependencies. Check earlier decisions before treating a difference as a new design choice. This second reading can reveal that useful work has been completed while the document still describes its initial setup assumptions.

Classify each material difference by the action it requires. Where documentation has fallen behind, update the current description, resolved detail, verification account, or graph consequence from the evidence. Where implementation falls short, preserve the requirement and record the particular gap for repair. Apply an adopted design decision within the assignment, keeping its basis and residual work visible. Return unapproved departures and uncertain results as precise investigations, proposed edits, or human decisions.

When stale wording describes an incidental mechanism, first determine what obligation the statement was meant to preserve. Apply the decision, interface, and named-verification tests. The preferred repair retains that stable claim and moves useful mechanism detail to supporting evidence. A mechanism that is itself an adopted commitment needs a different treatment, with the reason preserved in its ruling. Borderline cases remain questions for the human; the general preference does not authorise weakening a requirement.

An intended future capability can remain in the Scope of Work after reconciliation. Its unimplemented state should be explicit, with the remaining obligation available for further work. Conversely, an obsolete description of an initial plan should be corrected once the relevant detail has been established. The comparison must preserve the meaning and standing of both the commitment and the observed result.

For example, an implementation may now report why an operation was rejected while the Scope of Work still carries an open question about failure reporting. Examine the adopted behaviour, implementation, and tests. Record the required failure response and its supporting evidence, retaining any untested required case as remaining work. A private helper's design need not become part of the contract. If the implementation omits a required rejection condition, retain that requirement and route the defect through the graph.

BOUNDED RECONCILIATION: METHOD ORDER

1. Name the Deliverables and the work being reconciled.
2. Read the affected contents and controlling changes.
3. Compare documents with code and evidence in both directions.
4. Make and verify the warranted document changes.
5. Return the changes and their remaining consequences.

Completion requires the permitted edits or a supported
no-change result, with material residuals accounted for.
Unauthorised edits remain proposals for later application.

Figure 4.9. Five steps for bounded reconciliation. The comparison and its permitted document edits form one bounded contribution.

Make the warranted changes

Edit the named sections within the assignment. Keep descriptions, evidence claims, remaining work, and dependency statements consistent about the result. Preserve the identifiers and citations that let later readers recover their relationships. A short entry can link the code revision, evidence, and graph node. Avoid copying the same narrative into several records.

Account for a graph obligation only when evidence supports its stated condition. Record dependency satisfaction within the assignment and the authority governing that relationship. Keep any structured register and human-readable summary consistent where both are changed. Revise the accepted project DAG only through the agreed decision process.

Changes in scope, formal production standing, acceptance, identity, or the accepted basis require their own authority. An assignment to correct a factual description does not extend to those decisions. Routine authorised updates can proceed without another human approval; an unresolved material departure returns to the parent with the particular question and proposed treatment. Code repair is a separate node unless the assignment explicitly includes it.

Before saving, compare the target documents with the versions originally inspected. Preserve concurrent edits. If the code basis changed during the comparison, re-examine the affected statements or return them as stale. Read the edited documents together, check links and applicable formats, and confirm that the revision neither overstates completion nor loses intended scope. Apply required independent checking to the document change.

The returned result names the changed files and sections, their code or evidence basis, the supported edit or no-change conclusion, and the remaining consequence. When writes were not authorised, return the exact proposed edits and leave their application outstanding. Missing inputs or blocked inspection keep the affected comparison incomplete. The graph maintainer incorporates the result and its follow-on nodes against the current graph revision.

Continue from a dependable state

During ordinary traversal, keep the graph current as meaningful results, decisions, and failures change the work. Record the checked source revision, local or unmerged changes, outstanding checks, evidence locations, active operations, holds, and next safe action. The intended outcome and steering source explain why that continuation belongs to the undertaking. Another session can use this account to recover the position and infer the appropriate next work within existing direction.

Keep the production target, current deficit, and execution route connected. The Scope of Work states the target and its evaluation. Actual work and evidence establish the current result. The local graph organizes execution; MEMORY.md tersely records what each run did in the Deliverable and links the central records. Each record can point to the others without repeating their complete account.

Keep a concern awaiting allocation distinguishable from an assignment already selected for execution. Record its source, the commitment it may affect, and the decision or investigation needed to give it a home. The task-management treatment in §5.6 preserves such concerns without implying that their scope has been accepted or their work completed.

Appendix A shows the corresponding record changes after a failed observation, correction, and examination of the revised result.

Keep useful recoverable checkpoints during long work. Identify partial implementation and unverified checks accurately. Before retiring a temporary worktree, preserve necessary results and evidence in their continuing locations. A successor may otherwise find the reference to a result after the result itself has been removed.

Recover an interruption

An outside interruption can sever the loop before its latest work has been fully recorded. Inspect actual branches, worktrees, staged and unstaged changes, output locations, and still-active operations. Establish which edits and checks followed the last recorded revision. Verify that earlier workers have stopped or transfer their ownership explicitly before resuming the same scope. Preserve completed work while its evidence is examined.

A separate handoff is useful when it supplies facts that the graph and linked results lack: an unfinished diagnosis, a deliberate stop, an active external operation, or a decision still awaiting the human. Keep its statements attributable and check them against the actual work. Preserve any handoff required by the chosen procedure. A human pause remains effective until the human resumes the work. Continue the existing undertaking with its useful results intact.

Complete the graph's promised work, bounded closeout and memory entries, then merge the final PR after required review, checks and decisions. Its merge ends the loop. An explicit agreed disposition may instead close a reduced or otherwise bounded undertaking; identify that changed extent and any surviving obligation. Deferring a concern or closing a local node does not satisfy an outstanding Deliverable requirement. Preserve the completed graph and its evidence references, and leave it selected until another undertaking is chosen. The final return explains the result, limits, and continuing obligations at that scope. Deliverable issuance, a new project phase, and product release remain with their respective decisions.

4.12Establish the route toward completion

The end of the 60% phase is judged from the remaining route to the product. At entry, formation of the DAG provided a distinct development result. By the end of detailed development, the team should expect to carry the remaining work through without another change to the project DAG. The human examines whether the established details, production relationships, and treatment of open questions support that expectation.

This position permits substantial unfinished production. A Deliverable may have a settled design and known inputs while much of its implementation remains ahead. Another may already be integrated and undergoing examination. What matters for the transition is whether the remaining development can be organised on the established basis, with sufficiently clear routes and completion conditions for larger undertakings.

Examine what could still change the route

Read the current project DAG together with its adopted amendments and the active local graphs. Follow the accepted scope into the developed details. Examine shared definitions, consumed revisions, boundary owners, and unresolved decisions. Identify questions whose answers could still alter Deliverables or their production relationships. A broad uncertainty hidden inside an apparently ready task can make the expected route unreliable.

Consider the cumulative effect of departures and provisional mappings. Some can be resolved through ordinary completion or bounded reconciliation. Others require a project amendment or a renewed dependency analysis. Bring those distinctions into the human's review while preserving the work and evidence that remain valid. Graph revisions made during 60% should leave a clear account of what changed and which contributions adopted the change.

A modest PRD may have supported this development successfully because its open questions were addressed as their consequences arose. A more detailed PRD may still have left an important interaction unresolved. Assess the actual design and the remaining work rather than assigning confidence from the length of the starting document. The relevant evidence concerns the course the team can now undertake.

The expectation of no further DAG change remains revisable. A later discovery can expose a necessary amendment. Preserve the finding and carry its grounds and consequences through the established decision process.

An organisation using other phase names can retain its established reviews. Map the 30% milestone to the point at which the execution structure is sufficiently defined to direct detailed development, and the 60% milestone to the point at which that structure is expected to support the remaining route to completion. Keep the decisions and their evidence explicit; changing the names need not change their purpose.

POSITION FOR CONTINUATION BEYOND 60%

Project basis
  Current adopted DAG and its supporting scope and decisions.
  No further structural change anticipated on the remaining route.

Developed detail
  Interfaces, behaviour, methods, and boundary ownership established.
  Open questions identified with their effect on subsequent work.

Local execution
  Coherent undertakings with inputs, completion conditions,
  independent scopes, review, integration, and reconciliation.

Direction
  The human's selected objectives and priorities for completion;
  continuing holds and choices to return for judgment.

Figure 4.10. Subjects for the assessment at the end of 60%. The percentage marks a development milestone; it does not measure the fraction of all work completed.

Use the same graphs over a longer horizon

In the 90% phase, local work graphs are constructed and traversed by the same method. The change lies in how far a useful undertaking can be defined. Larger tranches can have clear inputs, dependable design details, and a known path to the produced result. Their graphs may extend over long task and time horizons, with bounded nodes completed by successive agents and sessions.

A longer undertaking still requires current state, evidence, and the treatment of findings. Managers continue to integrate returns, revise the local arrangement where necessary, and complete planned reconciliation. The graph lets them carry extensive work without relying on the uninterrupted context of one agent. Larger scope is supported by clearer relationships and recoverable progress.

Steering continues to select objectives, order priorities, prescribe approaches, and adjust the execution strategy. It can concentrate effort on integration, verification, or a difficult remainder. Longer-horizon work gives the human a different pattern of involvement, with less need to establish the broad production structure and continuing need to judge consequential choices and the adequacy of results.

The end of the 90% phase marks the change from development into user testing and debugging of the product. Development-time tests and connected exercises have already provided evidence and exposed defects throughout the work. The later emphasis is on the produced product in use, the defects that must be corrected, and the examination needed for its acceptance. The 100% publication pipeline follows for the verified, validated, and approved version.

Record the human's direction for this change of emphasis. Subsequent loops carry the identified product through its remaining examination and correction before the authorised publication sequence.