Mission Slice Sop

Mission/Slice SOP — Part A

Use this skill to actually do mission/slice work: track on the canonical files, record what you proved, hand off through them, and survive compaction on them. Do the work described here; do not merely explain the protocol.

Full convention SSOT: repo docs/reference/sdlc-conventions.md; installed $OPENRIG_HOME/reference/sdlc-conventions.md. This skill is the concise Part-A teaching surface and does not replace the full convention.

Resolve the work first

Run rig whoami --json, then resolve project.yaml -> mission.yaml -> active slice.yaml -> selected component or wave map -> addressed context. The complete lookup and precedence rule is docs/reference/product-journey-sdlc.md#resolve-the-selected-path (installed: $OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path). Read the selected addresses and source needed for this task; skills available in your profile are capabilities, not a mandatory reading list. No composition means light Part A. Role names and idle seats add no gates. Explicit rigor and authored wave boundaries retain their named checks.

The light inner loop is ground yourself → build → test with your own eyes → iterate → record and return the whole outcome. The builder may hold this check on a tiny change. Independent review runs only when selected, and once at an authored wave boundary rather than once per slice.

Part B is defined in the conventions SSOT and runs only when explicitly assigned to named work. If you believe it is needed, state the reason to the owner and continue on the selected path until that choice changes.

Proportionality — this SOP serves shipping; it is not the work itself

The working product is the deliverable. This bookkeeping exists so the work survives handoff, compaction, and review — nothing more. Match it to stakes. The rig scope audit backstop is advisory and fail-open: it never blocks a build and is not a gate you clear before proceeding. If you're spending more time on the convention files or the audit than on the running product, stop and go build. Running the full apparatus on a small change is the letter-worship failure, not diligence.

The three role contracts

• Planning agent: records what the slice is for and what "done" looks like, in the slice's own words; produces mockups for UI deliverables so the builder has something to look at (a UI slice with no mockup is an incomplete plan; non-UI slices have none — not a gate).
• Build agent: builds it, and looks at the mockups. Verifies by running the thing.
• QA agent (owns the compare): compares planned vs delivered per deliverable, records the verdict and the note. On mismatch: fix-and-re-review, or kick back with the reason — never escalate a raw mismatch to the human.

These three are a division of labour, not a chain of gates. One agent may hold all three on a small slice.

The current file contract

These files are the operating surface of the work — you track on them, record on them, hand off through them, and survive compaction on them. Keep them current because that is what lets the work survive. But they serve the product; they are not the product. If you're polishing files while the actual thing isn't shipping, you've inverted it: go build, then update them.

• Slice: SPEC.md, PROGRESS.md, PROOF.md, and proof/.
• Mission: SPEC.md and NOTES.md.

Per-file rules — WHO / WHEN / HOW

SPEC.md

• WHO: the planning owner authors it; builders and reviewers read it as the scope and intent source.
• WHEN: at creation and whenever scope changes.
• HOW: a slice carries intent: in frontmatter and opens with ## Intent, ## Mini-requirements, and ## Proof contract. A mission carries its intent and mission-level specification in the same authored node file. Keep depth proportional to the work.

PROGRESS.md

• WHO: the orchestrator owns the current state; every agent logs its own outcomes.
• WHEN: on material delivery-state changes and at acceptance.
• HOW: keep current delivery state in ## Current state; append material outcomes with links to proof under ## Outcomes. Retain historical entries and existing checkboxes without treating them as current acceptance authority. For a selected proof policy, use rig proof show <slice> for current readiness; keep frontmatter stage/verified honest.

PROOF.md + proof/

• WHO: the impl/QA pair that worked the slice.
• WHEN: before you call a slice done.
• HOW: say what you verified and how you verified it — by effect: you ran it and looked at the result. Put supporting media under proof/. State plainly what is proven and what is not; an honest "this half is untested" is worth more than a checkmark. If a drop verb is in play for this slice, prefer it over hand-placing files so the artifact carries its own provenance.