10. A worked undertaking

This constructed example concerns an editor that lets a person inspect proposed changes before applying them. Follow the decisions as an agent who might investigate, implement, coordinate or review this work. The case illustrates the method; it does not claim to describe 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 agent responsible for implementation 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 implementation owner 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.

The current contract, need declarations, candidate and conversation provide sufficient continuity without a separate work graph for these assignments. 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 implementation 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 implementation 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 implementation owner must present the consequence to the person authorized to change the criterion and obtain that 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 material 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 implementation owner keeps the candidate identity and check results where the reviewer and next session can recover the claim. Those existing records meet the need; additional copies would introduce maintenance without improving examination or recovery.

If a required result were available only in a temporary environment, the implementation 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 acts of the people authorized to make those decisions. An opportunity for broader proposal types becomes future work only when selected; it does not make the completed bounded undertaking incomplete.