Governed workflow

Governed is the advanced Day Shift workflow for work that needs explicit phase and milestone ownership, ordered delegation, reconciliation, persisted project review, and terminal closeout. It is not the default first-use path. Start with Basic or Structured planning unless the work genuinely needs the complete hierarchy and its review boundaries.

Treat Governed as available only when all of these gates can be honored: a numbered slice root, the full slice → phase → milestone → task hierarchy, task implementation evidence, milestone reconciliation, read-only project review, explicit project-review persistence, and separate closeout. If any gate would be skipped or replaced by prose, choose a simpler level or stop for a contract decision.

Use the Governed hierarchy reference beside this journey for the exact paths and artifact owners. The command examples assume the current compiled day-shift CLI; inspect any command first with day-shift commands describe "<command path>" --format json when its arguments or effects matter.

1. Qualify the work before creating a root

Governed begins with a registered, reviewed specification whose planning disposition is ready. The specification supplies the stable semantic identity and implementation order. Review is read-only; disposition is the separate revision-bound write. Creating a planning root is later and does not happen implicitly during review.

Before creation, confirm that the work needs ordered phases, milestones with reconciliation, and a project-level acceptance boundary. Agent mode and evidence profile are independent choices; neither one selects Governed or grants write authority.

Preview the canonical root before applying it:

day-shift work create \
  --spec .day-shift/specs/35-governed-delivery/governed-delivery.md \
  --level governed \
  --slice-id 35-governed-delivery \
  --dry-run \
  --format json

slice new --spec-id <registered-spec-id> is the layer-specific alternative for the same registered-spec context. A new write produces one numbered root at .day-shift/planning/governed/<NN>-<slice-slug>/slice-overview.md. It does not create <root>/overview.md or a nested <root>/slices/ layer.

2. Author the parent contract, then scaffold declared children

The slice overview declares ordered phases and their evidence projections. Complete that contract and collect its authoring-readiness evidence before creating missing phases. Then repeat the same parent-first discipline at each layer:

day-shift phase new \
  --slice-overview .day-shift/planning/governed/35-governed-delivery/slice-overview.md \
  --full-set

day-shift milestone new \
  --phase-overview .day-shift/planning/governed/35-governed-delivery/phases/01-runtime/phase-overview.md \
  --full-set \
  --phase-review-result .day-shift/runs/run-<run-id>/evidence/<phase-readiness>.json

day-shift task new \
  --milestone-overview .day-shift/planning/governed/35-governed-delivery/phases/01-runtime/milestones/01-delivery/milestone-overview.md \
  --full-set

--full-set means declared-only expansion: it creates the children named by the current parent contract and does not invent decomposition. Scaffold one active milestone at a time and delegate its tasks in declared dependency order. After an artifact body changes, refresh link-materialization evidence; apply only safe candidates tied to the exact preview evidence.

The canonical tree is:

.day-shift/planning/governed/<NN>-<slice-slug>/
├── slice-overview.md
├── phases/<NN>-<phase-slug>/
│   └── phase-overview.md
│       └── milestones/<NN>-<milestone-slug>/
│           ├── milestone-overview.md
│           ├── reconciliation.md
│           └── tasks/<NN>-<task-slug>/
│               ├── task-definition.md
│               └── implementation-summary.md
└── project-review.md                 # created only by explicit persistence

Validation records, receipts, and metadata transitions are evidence bound to these owners; they are not extra hierarchy containers.

3. Open one attributed task attempt

For each task, materialize safe links first, then run task readiness-review with an explicit reviewer and timestamp. Review never authorizes implementation. Apply task readiness-authorize against the exact current review result, open a stable attempt identity, and capture the attempt-owned baseline before any implementation write:

day-shift task readiness-review --task-definition <task-definition.md> \
  --reviewed-by <reviewer> --reviewed-at <timestamp> --format json
day-shift task readiness-authorize --task-definition <task-definition.md> \
  --review-result <current-readiness.json> --dry-run
day-shift task attempt-open --task-definition <task-definition.md> \
  --attempt-id <task-attempt-001> --opened-at <timestamp> --dry-run
day-shift task baseline --task-definition <task-definition.md> \
  --task-cycle-id <task-attempt-001> --checkpoint-id <readiness-review-id> \
  --captured-by <actor> --captured-at <timestamp> --dry-run

Inspect every preview, then repeat the identical command without --dry-run only when its preconditions and intended paths are correct. A material contract correction after baseline is a stop condition: revise the contract explicitly and use the typed supersession recovery only when the open attempt is baseline-only and every declared target remains unchanged.

4. Implement, validate, and close the task

Implementation stays within the task’s declared targets and rollback boundary. Record every declared executable validation through task validation-record so evidence is attempt-owned and command-observed. Build the paired implementation summary, author concrete changed paths, decisions, exceptions, residual work, and validation results, then rebuild to synchronize derived evidence.

Completion, review, disposition, and close are distinct boundaries:

1. task implementation-complete freezes implementation evidence for the current task revision and attempt.
2. implementation-summary review reads that evidence and does not accept it.
3. task disposition --disposition accepted --review-result <review.json> records the explicit decision.
4. A fresh implementation-summary review proves the accepted disposition.
5. task close --review-result <accepted-review.json> closes the task pair.

Do not mark a task complete by editing status fields or by substituting milestone prose for its implementation summary. Deferred work, exceptions, blockers, and waivers remain explicit evidence and may prevent acceptance.

5. Reconcile each milestone before advancing

After every declared task in the active milestone has a completed, non-placeholder summary, run reconciliation build --milestone-overview <path>. Populate the canonical reconciliation.md with task-summary links, acceptance-criteria coverage, validation review, deviations, residual work, and a milestone verdict.

reconciliation review is read-only. Repair body evidence when it finds a blocker, rebuild if source summaries changed, and review again. Only the separate supported update may record completed reconciliation metadata. Do not begin the next declared milestone until the current reconciliation is concrete and clean.

6. Persist project review, then close the slice

When every milestone is reconciled, run work status and work review on slice-overview.md. Both are read-only rollups. A recommendation of accepted is evidence, not a write and not project-review persistence.

Persist the decision explicitly, then close through a separate receipt-bound action:

day-shift work project-review create \
  --overview .day-shift/planning/governed/35-governed-delivery/slice-overview.md \
  --disposition accepted \
  --reviewer <reviewer> \
  --summary "All declared Governed evidence is accepted." \
  --dry-run

day-shift work close \
  --overview .day-shift/planning/governed/35-governed-delivery/slice-overview.md \
  --project-review .day-shift/planning/governed/35-governed-delivery/project-review.md \
  --dry-run

Apply each command only after checking its exact preview. Project-review creation owns project-review.md; close updates only the selected slice overview after verifying the persisted accepted review. Neither action retroactively repairs phase, milestone, reconciliation, task, or implementation evidence.

Recovery boundaries

• Stale review or revision evidence: refresh the same read-only review; do not reuse an earlier receipt.
• Changed task scope after a baseline: stop implementation and follow the explicit contract-revision route; never discard the baseline or open a sibling run to hide history.
• Interrupted or conflicting scaffold/mutation: preserve transaction evidence and follow the typed recovery path; never move hierarchy files manually.
• Incomplete task or milestone evidence: keep the parent open and record the blocker or discovered work explicitly.
• Legacy Governed layouts: treat extra overview.md or nested slices/ paths as compatibility or migration inputs only. All new writes use the numbered root shown above.

For the exact command and artifact matrix, continue to Governed hierarchy. For deeper evidence semantics, use Lifecycle records and Evidence review and reconciliation.