Work from deliverable contracts

Locate a deliverable through its stable ID and accepted decomposition, then read the current production format and control records. At INITIALIZED or later, PROJECT/SOFTWARE production has exactly one valid canonical format: a valid ScopeOfWork.md, or the complete retained four-document kit under the authorized legacy transition. Both complete formats are a temporary isolated migration state only with exact migration authority; they are not a normal accepted baseline. Partial or invalid production is a concrete defect to report. SPEC §2 · Scope-of-Work standard

The Scope-of-Work standard's activation is conditional on D-GOV-16. Its recorded owner ruling approves the exact successor standard and transition, while retaining implementation and migration boundaries. This illustrates how to read a conditional header: follow the named act, then determine the applicable project adoption and source state. Do not infer a blanket conversion mandate from the schema's availability. D-GOV-16 · Scope-of-Work standard

Read ScopeOfWork.md as a production contract. It connects the deliverable's contribution to project scope and Package objectives; defines outputs and behavior; states requirements and completion criteria; names production and verification methods; records governing decisions; and binds these through the Output and Evaluation Matrix. Its philosophical labels help distinguish the questions each section answers. They do not substitute for concrete requirements and evidence. Scope-of-Work standard §§3–5

The SOW_V1 frontmatter declares schema: chirality-deliverable-sow/v1, deliverable_id, package_id, decomposition_basis, and non-empty project_scope_refs and package_objective_refs. Use the active decomposition's identity widths. The six required level-two headings, in order, are Purpose and Objective Traceability; Deliverable Definition — Ontology; Completion and Reliance Basis — Epistemology; Production and Verification Method — Praxeology; Governing Values and Decisions — Axiology; and Output and Evaluation Matrix. Copy the exact form from the standard and validate it with the adopted consumer. MODE=INIT authors the production contract directly; it does not create a conversion evidence candidate or run conversion parity. The default NO_STATUS_TOUCH preserves _STATUS.md; recording a lifecycle transition requires its own authorized act. Scope-of-Work standard §3 · Scope-of-work brief · Scope-of-work tools

Local statement IDs use exactly three decimal digits, as in - **REQ-017** — The output shall …, and are unique within one contract. The prefix catalog is maintained in tools/scope_of_work/id_catalog.json. For a cross-deliverable reference, use a qualified citation such as DEL-01-02/REQ-003; the slash spelling is canonical in the current workflow. The standard also retains the hyphen-qualified form. A bare REQ-003 means the local contract's requirement and can silently misdirect a reader or parser when used for an upstream obligation. Preserve accepted IDs through edits. Scope-of-work workflow · Scope-of-Work standard §4

The matrix has six columns: Output; Objective refs; Requirement/claim refs; Acceptance refs; Verification refs; Evidence expectation. Every declared OUT-*, AC-*, and VER-* appears in at least one row. Every output cites project scope and Package objectives; every criterion is linked to a method or explicit HUMAN_REVIEW: <method>. Follow each row through the required conditions, methods, and evidence expectation. Check the pairing, not only that every ID appears somewhere. The workflow permits grouped acceptance criteria only when each inherits the same verification-method set; a row that combines unrelated criteria and methods can falsely imply coverage. A boundary exclusion also needs an owner for the excluded acts and a cited claim carrying that ownership. “This deliverable does not do X” is incomplete if X remains necessary and nobody owns it. Scope-of-work workflow

Compile review criteria with the registered deterministic checklist tool when the method calls for it. It retains source order, exact text, qualified identity, source location, contract hash, and the linked method or explicit human review. Do not create a second paraphrased acceptance namespace. The compiler establishes fidelity of the checklist; review establishes what the candidate supports, and the applicable human act establishes acceptance. Scope-of-Work standard §§4, 10

These are command templates from the repository root; supply the actual production contract and an authorized evidence destination:

python3 tools/scope_of_work/validate_scope_of_work.py <ScopeOfWork.md> --json
python3 tools/scope_of_work/derive_review_checklist.py <ScopeOfWork.md> \
  --output <review-checklist.json>

The validator reads the contract; the second command writes the derivative to the named destination. Regenerate the checklist after contract changes and reassess earlier findings against the new candidate. Boundary exclusions also require the selected workflow's owner-resolution check and semantic treatment of cases its tool cannot check. A checklist or structural pass does not replace that examination. Scope-of-work tools · Scope-of-work checks

For adopted graph-led work, identify the unsatisfied condition, affected contract reference, needed contribution, prerequisites and completion evidence in the graph. Distinguish missing production, missing verification, an unresolved decision and a documentation discrepancy. A completed repair with an outstanding required backcheck leaves the obligation open at that extent. Ordinary future requirements stay in governing scope until selected; they need no invented graph node or register row. Remaining retains its current-delta role only in still-adopted earlier programs. Preserve those entries and their identities until an authorized transition accounts for their meanings and destinations. Scope-of-Work standard §5 · Concordance §§2, 4, 6 · Task Management retirement contract

Keep control files separate. _CONTEXT.md preserves identity and decomposition traceability; _REFERENCES.md locates sources; dependency records state relationships; MEMORY.md indexes actual runs and their central evidence/decisions. Use MEMORY.md for new authorized writes under the revised arrangement. Preserve existing _MEMORY.md content; consolidation, dual-file conflicts and inbound links require explicit scope. Create no new aliases that split maintained memory. None of these records independently changes scope or lifecycle. Do not recreate retired legacy production files while reconciling a converted deliverable. SPEC §§2, 8 · Bounded reconciliation

Format conversion is a special bounded operation. It preserves content and lifecycle, isolates the temporary dual format, maps source ranges, verifies parity, creates a clean finalized contract, and integrates an atomic replacement. Semantic changes are conflicts for their owning decision process. An ISSUED deliverable needs the separately specified human representation-replacement approval. The on-demand ScopeOfWork.html derivative is non-authoritative and is not tracked per deliverable. These rules do not prohibit a separately authorized documentation manual having its own HTML edition. Scope-of-Work standard §§6–10