This constructed example completes the editor case introduced in the earlier chapters. All people, entries, candidate identifiers, observations, and decisions below are invented to illustrate the method. They report no actual execution or product qualification.

The application lets a user inspect an agent's proposed revision while continuing to edit the live document. The accepted product basis covers one document and one proposal at a time. It requires rejection to preserve the live editing state. Where the proposal's source revision differs from the live revision, application must be refused, the reason explained, and a fresh proposal made available on request. Automatic reconciliation and changes across several documents are outside this undertaking.

A.1 Give the obligation a home

The product owner, Lee, accepted basis B1 after review removed an inconsistent promise of automatic reconciliation. The contract also retained verification of editing history and interruption. Those obligations must reach the work even though the normal preview demonstration appears satisfactory.

The history and recovery integration labelled C in Figure 1.1 has already been completed in this example; its results form part of the editor's inherited basis. The interface, application, and connected examination work labelled A, B, and D is carried here by D-1, D-2, and D-3 respectively.

The current undertaking uses these homes:

D-2 requires the agreed revision interface from D-1 before implementing the application guard. D-3 can prepare scenarios from the accepted requirements before D-2 is complete, but needs an integrated candidate before executing them. These production relationships are already represented in the project DAG. The present undertaking is to complete and examine stale-proposal handling within D-2 and its connected D-3 scenarios.

HELP_HUMAN keeps this undertaking connected to Lee's intended review experience. WORKING_ITEMS arranges the investigation, repair, checks, review, and return. TASK instances receive bounded assignments; they do not acquire responsibility for accepting the product. HELPS_HUMANS remains available if a finding requires renewed design, but no new role is needed to investigate this defect.

A.2 Establish the candidate and bounded brief

The starting candidate is E1. D-1's revision interface is available, and command-level tests report stale-proposal refusal. The native Apply route has not yet been examined. The local graph therefore includes node R-3a for D-2: “Establish stale refusal through the native Apply control, preserving content, selection, and history.”

The manager prepares this assignment:

Assignment T-1 — Examine stale application through the native editor

Purpose: Establish D-2/R-3 on candidate E1 using the installed
         application and the agreed document-revision interface.

Input:   Test document at revision r41: “Valve tag: V-12”.
         Proposal prepared from r41: “Valve tag: XV-12”.

Exercise: Keep the proposal open. Append the manual note
          “Check isolation before removal.” to the live document,
          producing r42. Select the native Apply control.

Expected: Refuse the stale proposal; preserve live content,
          selection, and history; explain the refusal and make
          a fresh proposal available on request.

Boundary: Use the isolated test copy and application instance.
          Write observations and test artifacts only. Return any
          failure before changing implementation or expected results.

Return:   Starting state, actions, observed state, candidate,
          evidence references, and a finding tied to D-2/R-3.

Figure A.1. A bounded examination brief. The assignment identifies the required behaviour, the observation route, and the point at which the executor returns a failure.

The manager retains the live document, selection, and history immediately before Apply so preservation can be compared with a definite state. No other operator uses that test instance during the scenario. These are prerequisites to a meaningful observation, not product achievements.

A.3 Follow the failure through repair

In the illustrative result, observation O-1 records that E1 replaces the live document with the proposal text and loses the manual note. The earlier command test still passes. The difference suggests a route problem, but the observation alone does not establish its cause.

A diagnosis assignment compares the two routes. Its return identifies the divergence: the command interface calls a checked application operation, while the native Apply control calls a lower-level replacement operation directly. The required revision check is absent from that path. This explains how the command evidence can be correct while the product claim remains unsupported.

Lee's accepted requirement already determines the needed behaviour. The manager can commission repair under the existing authority. Assignment T-2 is confined to the native application handler, the shared application operation, and their tests. It requires the revision comparison at the point of application and preserves the existing atomic-edit contract. It excludes automatic merging, new document formats, and unrelated interface changes.

Candidate E2 routes application through the common checked operation. The worker also adds a regression case for a manual edit made after the proposal opens. This adds a local test contribution to the work graph. It does not amend the requirement, move its accountable home, or change the project DAG: D-1 still supplies the same interface, D-2 still owns the behaviour, and D-3 still examines the combined result.

A.4 Complete production verification before formal review

The agreed review plan places command tests, the native regression, and the affected connected scenarios within production preparation. The independent formal review and practitioner examination follow on a frozen candidate. Their future place is explicit; it cannot be used to treat an unfinished production test as completed.

The illustrative verification record for E2 contains these entries:

These entries are summaries; their supporting records retain the inputs, actual actions, comparisons, and build E2. D-2/R-3a can now close because its stated condition has been examined. Other production obligations in D-2 and the affected D-3 scope are accounted for in the same way. The manager compares the records with the contract before reporting no remaining production work within the proposed review scope.

Lee then declares E2 the frozen candidate for formal checking. The independent reviewer receives the unchanged criteria, the failure and repair evidence, and the exact candidate. A practitioner is asked to recognise the stale condition, preserve their work, and obtain a usable fresh proposal. This examines the suitability of the interaction as well as the technical refusal.

A.5 Reconcile the finding and present the final decision

The formal reviewer confirms that the refusal criterion is supported but records finding F-1: the user instructions still promise automatic reconciliation. The practitioner exercise also shows why that wording matters: it gives the user the wrong expectation after refusal. The finding identifies a documentary defect in the candidate under review. The code test cannot close it.

Lee authorises a return to production for that correction. Candidate E3 changes the instructions to describe refusal and a fresh request. The revision leaves the implementation and configuration identical to E2. After the corrected instructions have been checked, Lee freezes E3 as the replacement candidate. Formal review record F-2 backchecks the correction, and the practitioner repeats the affected interaction using E3 and those instructions. The completion account retains V-1 through V-6 against E2, records why their technical findings still apply to E3, and adds the new documentary and practitioner evidence against E3.

Bounded reconciliation now follows the result through D-2 and D-3. D-2/R-3 retains its accepted wording. Its evidence references reach the revised candidate and the applicability assessment. R-3a is closed with its grounds. The documentary finding is closed by the correction and backcheck. D-3 records the completed scenarios and their limits. The project DAG remains unchanged. The current work graph shows the complete return, including formal findings and the correction they required.

HELP_HUMAN presents Lee with the candidate, the examined one-document scope, the preserved limitations, and the proposed delivery. In the example, Lee's decision reads: “Accept E3 for the internal one-document pilot and authorise delivery through the pilot installation procedure. Automatic reconciliation and multiple-document proposals remain outside this accepted scope.” This records the actual acts requested and their extent.

The delivery record identifies the installed E3 artifact and a successful opening check in the pilot environment. Sam, the named pilot support owner, receives the artifact, instructions, requirements, evidence index, and defect-report route, and accepts the stated support responsibility. The undertaking closes with this receipt. A later pilot failure returns through Sam to an identified requirement and candidate; it need not begin by reconstructing what the team meant to preserve.

A.6 Change the scale without losing the distinctions

For this small undertaking, one issue tracker can hold the local tasks, findings, decisions, and links to D-2 and D-3. Lee can use HELP_HUMAN directly for an independently assessable investigation and add WORKING_ITEMS when several contributions need coordination. Separate records are useful where they carry distinct information; their number need not grow with every assignment.

A larger product may need several managers, isolated test environments, and staged integration across many Deliverables. The same obligation still needs one accountable home, identified prerequisites, adequate examination, and a return that the parent can assess. Increasing the number of executors does not supply those relationships.

A later request to apply one proposal across several linked documents would require a different decision. It changes the accepted one-document scope and introduces questions about partial application, atomicity, and recovery. A proposed amendment could add D-4 — Multi-document transaction, revise D-2's application interface, and add D-4 as a prerequisite to connected examination in D-3. The owner would examine that scope and its consequences before adopting the revised DAG and commissioning dependent production. This is a genuine scope and dependency revision. The added native regression in T-2 was a local task change within the existing commitments. Keeping that distinction clear permits ordinary repair to proceed while giving a changed product promise the decision it requires.