10. A worked undertaking

This constructed example concerns an editor that lets a person inspect proposed changes before applying them. It illustrates the method. It is not a claim about the current status or requirements of any named product.

10.1 Establish the intended use

The person wants help revising a document while retaining control over what becomes accepted text. The initial request is “add an agent review panel.” The agent asks what must be visible and what the person must be able to reject.

The discussion establishes that proposed changes must remain distinct from saved text until accepted. Rejection must leave the document unchanged. Accepted changes must be recoverable through the editor's undo and persistence behavior.

The implementation owner identifies an existing proposal representation, document store and history mechanism. The investigation finds that the display can show several proposals, but the apply function assumes only one current proposal. This is a consequential interface question, not a reason to repeat the whole project definition.

10.2 Define the contribution and its needs

The undertaking is bounded to one complete proposal-and-apply path. Its contract identifies display, acceptance, rejection, undo and save/reopen behavior. It excludes automatic acceptance and unrelated editor redesign.

The consumer needs the document store to reject a stale base revision. It also needs a history operation that can reverse the accepted change without altering unrelated edits. Those conditions are stated as needs rather than as a claim that the store is simply “ready.”

The owner of the implementation queries relevant consumers and inspects the interfaces. One session can perform the initial slice. A separate reviewer is arranged for persistence and permission behavior. An independent interface illustration can proceed concurrently because it does not write the shared store.

No work graph is authored merely to record these assignments. The current contract, need declarations, candidate and conversation provide sufficient continuity. If the work later spans sessions, a short recovery note can identify the current candidate and pending check.

10.3 Prove the difficult path

The implementation creates a proposal against a known document revision. The user accepts it. The resulting text is saved, reopened and undone under controlled conditions.

The first connected test reveals that reopening the document loses the proposal identity needed by undo. Unit tests for display and storage both pass, but the assembled path does not fulfill the undertaking's contract.

The owner preserves the failure and repairs the history representation. It does not weaken the undo requirement to fit the implementation. The independent illustration work continues because the failure does not invalidate its inputs.

This early path prevents broader implementation from multiplying the same assumption. It establishes a useful premise before adding many proposal types or interface variations.

10.4 Distinguish refinement from a reserved change

During repair, the owner changes an internal record layout. The behavior and accepted interface remain the same. This is an implementation refinement within the assignment.

A different proposal would remove undo after save because the new layout makes it difficult. That would change an accepted criterion. The owner must present the consequence and obtain the applicable decision rather than silently adopting it.

The distinction depends on meaning, not the number of edited files. A small text change can alter a commitment. A substantial refactor can preserve it.

10.5 Examine the result

The reviewer receives the current candidate, relevant requirements and actual test results. The review examines stale-base rejection, unauthorized application, rejection without mutation, persistence and undo.

A schema check confirms that records have valid structure. Behavioral checks establish that the actions preserve the required state. Neither alone establishes that the display makes the user's choice understandable; that question needs an appropriate interface exercise.

The reviewer finds that a second proposal can still refer to the old document revision after the first is accepted. The implementation owner repairs the refusal path and reruns the affected cases. The same reviewer confirms that repair. Unchanged rendering evidence remains usable.

10.6 Update meaning where it changed

The Design now explains the accepted proposal's identity and the stale-base behavior. The dependency condition names the consumer's required refusal. The change record explains the repair and checked scope.

The owner does not add a lifecycle file, local memory row, receipt and copied test log. Existing candidate identity and check results already let the reviewer and next session recover the claim.

If a required result were available only in a temporary environment, the owner would preserve it at a stable location or record how to reproduce it. The absence of routine records is not permission to lose necessary evidence.

10.7 Complete the undertaking

The integrated candidate supports the required complete path. The implementation owner establishes scope, relationship and examination coverage. No applicable requirement remains missing within the selected undertaking.

There is no additional governance closeout solely because the final change is ready. A final source comparison can still be necessary if integration introduced a new relationship. Its purpose must be the unresolved claim, not the name of the stage.

The return identifies the usable result, candidate, checks and any remaining limitations. Product acceptance and release remain separate owner acts. An opportunity for broader proposal types becomes future work only when selected; it does not make the completed bounded undertaking incomplete.