workflow-supervisor 0.1.2 → 0.1.3

package/README.md

@@ -20,6 +20,8 @@ Workflow Supervisor gives you a repeatable workflow for serious agent tasks:
 
 - a complete intake before work starts
 - a source map, even when the only source is the user prompt
+- a source-requirement coverage ledger so roadmap items and exit criteria cannot disappear
+- a `SPEC.md` review gate where humans can ask questions, request revisions, block, defer, or approve before work units are finalized
 - bounded work units, including `WU-001` for tiny tasks
 - dossiers that tell each worker exactly what to do and what not to touch
 - separate implementer, verifier, repair, and documenter responsibilities
@@ -92,16 +94,19 @@ Strict mode means task size does not matter. Even if the request is "make a func
 
 1. Ask the complete intake packet.
 2. Build or record the source corpus.
-3. Create at least one work unit.
-4. Create acceptance rows.
-5. Create dossiers for the planned workers.
-6. Create a worker-agent plan.
-7. Ask for approval when the selected path is human-in-loop.
-8. Delegate scoped work to real workers when the environment supports it.
-9. Verify with evidence.
-10. Route repair work if verification fails.
-11. Refresh docs or outcome state.
-12. Report final status and next action.
+3. Create a source-requirement coverage ledger.
+4. Create a `SPEC.md` review packet or file.
+5. Pause for human Q&A, revisions, block, defer, or approval when the path is human-in-loop.
+6. Create at least one work unit.
+7. Create acceptance rows that preserve source-scope fidelity.
+8. Create dossiers for the planned workers.
+9. Create a worker-agent plan.
+10. Ask for approval when the selected path is human-in-loop.
+11. Delegate scoped work to real workers when the environment supports it.
+12. Verify with evidence.
+13. Route repair work if verification fails.
+14. Refresh docs or outcome state.
+15. Report final status and next action.
 
 This rule exists to prevent the agent from deciding that a task is "too simple" and quietly skipping the supervisor.
 
@@ -123,6 +128,8 @@ If any answer is missing or vague, the supervisor asks only for the missing piec
 
 Expected human pauses are normal. A workflow can move from `WAITING_FOR_HUMAN` back to `ACTIVE` after the user approves a plan or answers a blocker question.
 
+In `autonomous_goal`, a human clarification pause is not automatically a terminal failed goal. The supervisor records the blocker, asks the smallest needed question, updates SPEC/Q&A/coverage state when the answer arrives, refreshes only affected downstream artifacts, and resumes from the recorded next action. If an old Codex goal was already terminal-blocked, the resumed workflow references it as history and continues from workflow state or a newly authorized goal binding.
+
 ## The Workflow
 
 The full loop looks like this:
@@ -130,6 +137,8 @@ The full loop looks like this:
 ```text
 complete intake
 -> source corpus
+-> source-requirement coverage ledger
+-> SPEC review and Q&A gate
 -> work units
 -> loop policy
 -> acceptance matrix
@@ -152,6 +161,12 @@ planned -> handed_off -> acknowledged -> reported -> verified -> closed
 
 This makes it possible to see where the workflow is, which worker owns which piece, what evidence exists, and what should happen next.
 
+For source-of-truth builds, the coverage ledger is the guardrail against "green but incomplete" outcomes. Every material source requirement must be mapped to a work unit and acceptance row, explicitly deferred by the user, blocked as a scope decision, or marked non-material with a reason. Residual risks and future-work notes cannot contain unimplemented material source requirements in a PASS workflow.
+
+`SPEC.md` is the human review contract before final work units. In human-in-loop mode, the supervisor stops at the draft SPEC so the human can ask questions, request revisions, mark items deferred, block the workflow, or approve. The workflow continues only after explicit approval.
+
+When a workflow pauses for a human decision, the decision is recorded as state rather than treated as a restart. The next supervisor pass updates the affected coverage rows, SPEC fields, work units, acceptance rows, dossiers, or verification results, invalidates stale artifacts, and continues from the saved `Next Action`.
+
 ## Skills In The Pack
 
 The skill pack is made of small focused skills. The supervisor can use them as phase instructions.
@@ -181,6 +196,7 @@ Common workflow files:
 |---|---|---|
 | `.workflow/WORKFLOW.md` | `workflow-supervisor`, `loop-policy`, `workflow-docs` | Main state, objective, execution path, policy, stop gates, next action. |
 | `.workflow/SOURCE-CORPUS.md` | `source-corpus`, `workflow-docs` | Source ranking, missing sources, contradictions, assumptions. |
+| `.workflow/SPEC.md` | `workflow-supervisor`, `source-corpus`, `workflow-docs` | Human-reviewable interpretation, requirement coverage, Q&A, and approval decision before work units. |
 | `.workflow/WORK-UNITS.md` | `work-unit`, `workflow-docs` | Unit list, dependencies, sequencing, blocked units. |
 | `.workflow/DOSSIER.md` or `.workflow/dossiers/*.yaml` | `dossier-builder`, `workflow-docs` | Worker contracts for implementation, verification, repair, or documentation. |
 | `.workflow/WORKER-MAP.md` | `workflow-supervisor`, `worker-roles`, `workflow-docs` | Worker names, roles, transports, lifecycle, reports, blockers. |
@@ -190,7 +206,7 @@ Common workflow files:
 | `.workflow/DECISIONS.md` | supervisor, `workflow-docs` | User decisions, assumptions, reversals, unresolved questions. |
 | `.workflow/HANDOFF.md` | supervisor, `workflow-docs` | Resume pack for another agent or later session. |
 | `.workflow/OUTCOME.md` | supervisor, documenter worker, `workflow-docs` | Final status, checks, risks, disposition, next action. |
-| `.workflow/GOAL-STATE.md` | supervisor, `workflow-docs` | Codex goal mirror when goal state needs durable backup. |
+| `.workflow/GOAL-STATE.md` | supervisor, `workflow-docs` | Codex goal mirror, blocked-goal history, human-decision resume checkpoint, and durable backup. |
 
 For documentation-heavy workflows, `workflow-docs` can also create:
 
@@ -410,10 +426,12 @@ You should expect:
 1. The supervisor asks the complete intake packet.
 2. You answer every intake item.
 3. If the path is `human_in_loop`, the supervisor gives you an approval packet before implementation.
-4. The supervisor creates work units, acceptance rows, and dossiers.
-5. The supervisor delegates scoped work to workers when supported.
-6. Workers return structured reports.
-7. The supervisor verifies, routes repairs if needed, and gives you the final result.
+4. The supervisor creates the source-requirement coverage ledger and `SPEC.md`.
+5. You ask questions, request revisions, block, defer, or approve the SPEC.
+6. After approval, the supervisor creates work units, acceptance rows, and dossiers.
+7. The supervisor delegates scoped work to workers when supported.
+8. Workers return structured reports.
+9. The supervisor verifies, routes repairs if needed, and gives you the final result.
 
 If you only want a normal quick edit, do not invoke `$workflow-supervisor`.
 

package/bin/workflow-skills.mjs

@@ -8,8 +8,9 @@ import { fileURLToPath } from "node:url";
 
 const __dirname = path.dirname(fileURLToPath(import.meta.url));
 const packageRoot = path.resolve(__dirname, "..");
-const PACKAGE_NAME = "workflow-supervisor";
-const PACKAGE_VERSION = "0.1.1";
+const packageJson = JSON.parse(fs.readFileSync(path.join(packageRoot, "package.json"), "utf8"));
+const PACKAGE_NAME = packageJson.name || "workflow-supervisor";
+const PACKAGE_VERSION = packageJson.version;
 const WORKER_REPORT_SCHEMA_PATH = path.join(packageRoot, "schemas", "worker-report-v1.schema.json");
 const DOSSIER_SCHEMA_PATH = path.join(packageRoot, "schemas", "dossier-v1.schema.json");
 const ADAPTERS_ROOT = path.join(packageRoot, "adapters");

package/docs/skill-reference.md

@@ -2,7 +2,7 @@
 
 ## `workflow-supervisor`
 
-Coordinate explicit supervised or agent-loop workflows. It always starts with a complete intake gate before planning, implementation, goal binding, worker delegation, or final disposition. The user must answer every intake item; the supervisor must not infer or skip steps from keywords. After complete intake, it selects either autonomous goal execution or human-in-the-loop execution, then orchestrates named workers from dossiers through the portable delegate command or an approved native adapter. Loading the skill itself does not spawn workers. It binds Codex goals only after complete intake and when the user or environment authorizes goal-oriented work, checks active goal state first, and avoids unrelated active-goal collisions.
+Coordinate explicit supervised or agent-loop workflows. It always starts with a complete intake gate before planning, implementation, goal binding, worker delegation, or final disposition. The user must answer every intake item; the supervisor must not infer or skip steps from keywords. After complete intake, it creates a source-requirement coverage ledger and SPEC review gate before work units so controlling-source deliverables, roadmap phases, and exit criteria are either implemented, explicitly deferred, blocked, or marked non-material. In human-in-loop mode, the human can ask questions, request revisions, block, defer, or approve the SPEC before final work units. In autonomous goal mode, human clarification pauses resume from recorded workflow state after the answer updates Q&A, decisions, coverage, and affected downstream artifacts. It then selects either autonomous goal execution or human-in-the-loop execution, then orchestrates named workers from dossiers through the portable delegate command or an approved native adapter. Loading the skill itself does not spawn workers. It binds Codex goals only after complete intake and when the user or environment authorizes goal-oriented work, checks active goal state first, avoids unrelated active-goal collisions, and treats terminal blocked goals as history when resuming through workflow docs.
 
 ## `source-corpus`
 
@@ -10,7 +10,7 @@ Rank and reconcile sources when authority, freshness, contradictions, access rig
 
 ## `work-unit`
 
-Split broad work into bounded units with objective, scope, dependencies, readiness, done criteria, verification, sequencing, and parallel-safety notes.
+Split broad work into bounded units with objective, scope, dependencies, readiness, done criteria, verification, sequencing, and parallel-safety notes. It prevents broad roadmap or source-of-truth requests from collapsing into one giant unit unless all current-scope material requirements can be implemented and verified in that unit.
 
 ## `dossier-builder`
 
@@ -22,12 +22,12 @@ Define role contracts and solo-mode phase separation. It prevents role bleed: ve
 
 ## `acceptance-matrix`
 
-Create formal evidence-mapped acceptance rows for high-risk, supervised, ambiguous, resumable, or delegated workflows.
+Create formal evidence-mapped acceptance rows for high-risk, supervised, ambiguous, resumable, or delegated workflows. Rows must preserve source requirement strength, including named systems, quantities, live integration language, and exit criteria; weaker proxy checks require explicit user waiver or scope narrowing.
 
 ## `loop-policy`
 
-Define execution path, execution mode, worker delegation, approval gates, repair limits, parallel safety, no-progress rules, and Codex goal tool policy.
+Define execution path, execution mode, worker delegation, approval gates, repair limits, parallel safety, no-progress rules, human-decision resume rules, and Codex goal tool policy.
 
 ## `workflow-docs`
 
-Create durable workflow-state or documentation-production artifacts. Markdown artifacts default to `<workspace>/.workflow/` unless the user or project convention says otherwise. It also supports inline briefs, tickets, design annotations, runbooks, decision logs, and other usable state media.
+Create durable workflow-state or documentation-production artifacts. Markdown artifacts default to `<workspace>/.workflow/` unless the user or project convention says otherwise. It includes `SPEC.md` for human-readable interpretation, Q&A, and approval before work units, plus `GOAL-STATE.md` and resume fields for blocked-goal history and human-decision continuation. It also supports inline briefs, tickets, design annotations, runbooks, decision logs, and other usable state media.

package/docs/troubleshooting.md

@@ -27,6 +27,22 @@ Use `$workflow-docs` with a minimal artifact request. The skill must reject "cre
 
 Use `$acceptance-matrix` for formal evidence rows. A PASS requires row-by-row evidence or explicit waiver evidence.
 
+## A broad roadmap becomes one giant work unit
+
+Use the source-requirement coverage gate before work-unit finalization. Every material roadmap item, exit criterion, named integration, and numeric target should be mapped to a unit and acceptance row, explicitly deferred by the user, blocked for a decision, or marked non-material with a reason. Do not accept "future work" or residual risk notes as a substitute for work units.
+
+## Residual risks contain required work
+
+Treat this as FAIL or BLOCKED. Residual risks may describe remaining uncertainty after acceptance, but they must not contain unimplemented material source requirements, skipped mandatory checks, or source-of-truth deliverables that were quietly downgraded.
+
+## Humans need to review scope before work units
+
+Create or refresh `.workflow/SPEC.md` before final work units. The human can ask questions in the Q&A section, request revision, block the workflow, defer items, or approve. In `human_in_loop`, the supervisor must not continue to final work units, dossiers, or implementation until the SPEC decision is approved and Q&A is answered.
+
+## Autonomous workflow paused for a human decision
+
+Record the blocker before asking the human. When the answer arrives, update `.workflow/SPEC.md`, `.workflow/WORKFLOW.md`, `.workflow/GOAL-STATE.md`, and `DECISIONS.md` when present. Re-run only the affected coverage, SPEC, work-unit, acceptance, dossier, worker-plan, verification, or final-disposition steps. Do not restart complete intake unless the answer changes a required intake decision. If the old Codex goal is terminal blocked, reference it as history and continue from workflow state or a newly authorized goal binding.
+
 ## An existing skill folder blocks install
 
 Use:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "workflow-supervisor",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Portable workflow supervision skills for Codex, Claude Code, and generic agent workspaces.",
   "type": "module",
   "repository": {

package/skills/acceptance-matrix/SKILL.md

@@ -15,15 +15,39 @@ This skill owns evidence rows and supervisor verdict mapping. `$work-unit` may d
 
 - Every requirement needs evidence.
 - Evidence must name a source, command, artifact, UI state, test, inspection, or user decision.
+- Acceptance rows must preserve the source requirement's strength: named systems, quantities, live/integration wording, exit criteria, and "must" language.
+- A weaker proxy check is not equivalent evidence unless the user explicitly waives or narrows the original requirement.
 - PASS requires all material rows to be satisfied or explicitly waived by the user.
 - FAIL requires at least one material row with unmet evidence.
 - BLOCKED applies when evidence cannot be obtained or sources conflict.
 - Residual risks must not be hidden inside PASS.
+- If residual risks, skipped checks, future work, or next recommended actions contain an unimplemented material source requirement, the matrix status is FAIL or BLOCKED, not PASS.
+
+## Source Fidelity Rules
+
+When a source-requirement coverage ledger exists, every `in_current_scope` material requirement needs at least one matrix row. Preserve exact source details that affect scope or verification, including:
+
+- named integrations or providers
+- corpus sizes, question counts, coverage thresholds, or latency/cost budgets
+- "live" versus artifact-only behavior
+- required data sources, credentials, services, or indexes
+- roadmap phase exit criteria
+- mandatory checks, screenshots, reports, or review states
+
+Do not downgrade requirements while making them testable. Examples of invalid substitutions:
+
+- live service load/query verification -> generated export file only
+- required validation corpus size -> small starter fixture
+- named provider support -> generic extension hook
+- required analysis and report generation -> keyword metadata only
+- provider-backed extraction or indexing -> deterministic placeholder logic
+
+If a requirement cannot be verified in the current environment, mark it BLOCKED or require a user waiver. Do not convert it into an easier row.
 
 ## Row Shape
 
-| ID | Requirement | Evidence Required | Verification Method | Adversarial Check | Status | Evidence |
-|---|---|---|---|---|---|---|
+| ID | Source Ref | Requirement | Evidence Required | Verification Method | Adversarial Check | Status | Evidence |
+|---|---|---|---|---|---|---|---|
 
 Use statuses: Pending, PASS, FAIL, BLOCKED, Waived.
 
@@ -46,6 +70,9 @@ Consider:
 - missing citation or unsupported claim
 - document structure regression
 - stakeholder requirement omitted
+- source requirement weakened or omitted
+- roadmap exit criteria demoted to future work
+- material requirement hidden in residual risks
 - artifact cannot be reused by a fresh agent or human
 
 ## Verification Report Shape

package/skills/loop-policy/SKILL.md

@@ -21,7 +21,8 @@ For loop-oriented supervisor work, define how the workflow uses Codex goals afte
 - goal_state_mirror_cadence: each work unit, each verification result, each repair loop, and final outcome
 - goal_completion_rule: evidence required before completion
 - goal_blocked_rule: same material blocker across the required consecutive goal turns and no meaningful progress
-- goal_resume_rule: read active goal before workflow docs, then reconcile
+- goal_resume_rule: read active goal before workflow docs, reconcile state, and continue from the recorded next action after human decisions
+- human_decision_resume_rule: ask the smallest blocking decision, update state, invalidate only affected downstream artifacts, and resume without restarting intake unless intake changed
 
 Do not create goals for small direct tasks. A goal is the state container for open-ended loops, not a wrapper around every command.
 
@@ -36,7 +37,7 @@ Do not create goals for small direct tasks. A goal is the state container for op
 - Budget: time, token, command, cost, or file-change limits.
 - Escalation: when to ask the user, delegate to a specialist worker, or stop.
 - Completion: evidence required before marking done.
-- Resume: artifacts needed before pausing or compacting.
+- Resume: artifacts needed before pausing, compacting, or waiting for a human decision.
 - Mutation conflict: whether units touch the same mutable surfaces or decisions.
 
 ## Default Policy
@@ -63,6 +64,7 @@ workflow_unit_blocked_after: first material blocker may stop the unit while the
 codex_goal_blocked_after: same material blocker across 3 consecutive goal turns and no meaningful progress
 completion_requires: acceptance evidence plus residual risk report
 resume_requires: workflow state or outcome doc for long workflows
+human_decision_resume_rule: record blocker and next action before asking; after answer, update Q&A/decision/coverage state, re-run only affected downstream steps, invalidate stale artifacts, and continue from recorded next action
 missing_prerequisites: discovery-first, not failure
 goal_start: after complete intake only; create only when completed intake and environment authorize goal binding, otherwise mirror state in docs
 goal_state_mirror_cadence: after unit terminal states and final outcome
@@ -98,6 +100,7 @@ escalation_rules:
 stop_gates:
 completion_rule:
 resume_artifacts:
+human_decision_resume_rule:
 goal_policy:
 final_disposition_policy:
 ```

package/skills/work-unit/SKILL.md

@@ -43,6 +43,23 @@ Work-unit drafts coarse done criteria only. Use `$acceptance-matrix` when those
 
 For over-broad one-pass requests, produce a sequencing recommendation and invoke or mirror `$loop-policy` fields for mode, parallel safety, approval gates, and repair limits.
 
+## One-Pass Collapse Guard
+
+Do not collapse a multi-phase roadmap, spec, or "source of truth" corpus into one broad implementation unit unless every material requirement can be completed and verified inside that unit. If the source contains phases, exit criteria, named integrations, scale targets, or different risk classes, split them into independently verifiable units.
+
+Treat these as separate-unit signals:
+
+- roadmap phases or milestones
+- multiple external data sources, providers, services, or credentials
+- live system integration plus local artifact fallback
+- extraction/indexing/retrieval/evaluation/reporting layers with different evidence needs
+- numeric targets such as corpus size, eval question count, latency budget, or coverage threshold
+- implementation work that would otherwise be described as residual risk, future work, or next recommended action
+
+If a supervisor provides a source-requirement coverage ledger, every `in_current_scope` material requirement must appear in at least one work unit's done criteria. Every `explicit_user_deferred`, `blocked_needs_decision`, or `out_of_scope_by_user` item must remain visible in `blocked_units` or a separate deferral list; do not hide it inside a unit note.
+
+Create exactly one `WU-001` only when the task is genuinely tiny or the full current-scope ledger can be implemented, verified, and documented as one bounded unit without deferred material requirements.
+
 ## Output Shape
 
 ```yaml
@@ -60,10 +77,12 @@ units:
     forbidden_surfaces:
     readiness:
     done_criteria:
+    source_requirements_covered:
     verification:
     sequence:
 parallel_groups:
 blocked_units:
+deferred_or_out_of_scope_requirements:
 first_recommended_unit:
 ```
 

package/skills/workflow-docs/SKILL.md

@@ -62,6 +62,7 @@ For documentation work, start with `DOCUMENTATION-BRIEF.md` unless the user prov
 
 - `.workflow/WORKFLOW.md`: overall objective, policy, state, units, and next action.
 - `.workflow/SOURCE-CORPUS.md`: source map, authority ranking, contradictions, gaps.
+- `.workflow/SPEC.md`: human-reviewable interpretation contract, requirement coverage, Q&A, and approval decision before final work units.
 - `.workflow/WORK-UNITS.md`: decomposition and sequencing.
 - `.workflow/DOSSIER.md`: delegation contract for one unit.
 - `.workflow/WORKER-MAP.md`: worker names, roles, transports, dossiers, dependencies, start conditions, report status, and supervisor checkpoints.
@@ -71,7 +72,7 @@ For documentation work, start with `DOCUMENTATION-BRIEF.md` unless the user prov
 - `.workflow/DECISIONS.md`: durable decisions, assumptions, and reversals.
 - `.workflow/HANDOFF.md`: resume state for another agent or session.
 - `.workflow/OUTCOME.md`: final status, checks, risks, and next step.
-- `.workflow/GOAL-STATE.md`: optional fallback record when a Codex goal tool is unavailable or goal state must be mirrored for continuation.
+- `.workflow/GOAL-STATE.md`: optional fallback or mirror for Codex goal state, terminal blocked-goal history, and human-decision resume checkpoints.
 - `.workflow/DOCUMENTATION-BRIEF.md`: audience, purpose, document type, reader task, channel, owner, approvers, and success criteria.
 - `.workflow/CONTENT-INVENTORY.md`: existing materials, reusable sections, gaps, stale areas, and owners.
 - `.workflow/OUTLINE.md`: information architecture, section hierarchy, and required content.

package/skills/workflow-docs/references/goal-resume.md

@@ -12,19 +12,28 @@ In Git-backed codebases, ensure `<workspace>/.gitignore` contains `.workflow/` b
 ## Goal Binding
 
 - Goal Binding: created | reused | skipped | unavailable | conflict
-- Goal Status: active | complete | blocked | unknown
+- Goal Status: active | complete | blocked | blocked old | unknown
 - Last Goal Tool Action: get_goal | create_goal | update_goal | none
 - Next Allowed Goal Action:
 - Goal Objective:
+- Previous Blocked Goal Reference:
+- Human Decision Needed:
+- Human Decision Answer:
+- Resume From:
+- Artifacts To Refresh:
+- Stale Artifacts Invalidated:
 ```
 
 ## Goal-Aware OUTCOME.md Fields
 
 ```md
 Goal Binding: created | reused | skipped | unavailable | conflict
-Goal Status: active | complete | blocked | unknown
+Goal Status: active | complete | blocked | blocked old | unknown
 Last Goal Tool Action: get_goal | create_goal | update_goal | none
 Next Allowed Goal Action:
+Previous Blocked Goal Reference:
+Resume From:
+Human Decision Resume Status:
 ```
 
 ## GOAL-STATE.md
@@ -40,10 +49,18 @@ created | reused | skipped | unavailable | conflict
 
 ## Goal Status
 
-active | complete | blocked | unknown
+active | complete | blocked | blocked old | unknown
 
 ## Why A Goal Was Created Or Skipped
 
+## Previous Blocked Goal
+
+Goal Reference:
+
+Reason:
+
+Use As History Only: yes | no
+
 ## Active Goal Conflict
 
 ## Last Tool Action
@@ -56,9 +73,37 @@ get_goal | create_goal | update_goal | none
 
 ## Current Work Unit
 
+## Current Blocker
+
+## Human Decision Needed
+
+Question:
+
+Smallest Sufficient Answer:
+
+## Human Decision Answer
+
+Answer:
+
+Decision Type: clarification | scope change | requirement waiver | explicit deferral | blocker resolution | final disposition | intake change | workflow cancellation
+
+## Resume Checkpoint
+
+Last Completed Step:
+
+Next Action:
+
+Artifacts To Refresh:
+
+Stale Artifacts Invalidated:
+
 ## Completion Rule
 
 ## Blocked Rule
 
 ## Resume Instructions
 ```
+
+## Human Decision Resume Rule
+
+When a workflow pauses for a human answer, record the blocker before asking. After the answer arrives, update the decision log, SPEC Q&A, coverage dispositions, and goal mirror before continuing. Resume from the recorded next action and re-run only affected downstream steps. Do not restart complete intake unless the answer changes a required intake decision. If the previous Codex goal is terminal blocked and cannot be reopened, keep that goal reference as history and continue with workflow docs or a newly authorized goal binding.

package/skills/workflow-docs/references/templates.md

@@ -34,6 +34,7 @@ Includes:
 
 - `WORKFLOW.md`
 - `SOURCE-CORPUS.md`
+- `SPEC.md`
 - `WORK-UNITS.md`
 - `DOSSIER.md`
 - `WORKER-MAP.md`
@@ -42,6 +43,7 @@ Includes:
 - `REPAIR-TICKETS.md`
 - `DECISIONS.md`
 - `HANDOFF.md`
+- `GOAL-STATE.md`
 - `OUTCOME.md`
 
 ## Goal And Resume

package/skills/workflow-docs/references/workflow-control.md

@@ -38,6 +38,21 @@ Git rule: in a Git-backed codebase, ensure `<workspace>/.gitignore` contains `.w
 
 ## Stop Gates
 
+## Blocking Decision
+
+| ID | Blocked Artifact | Question | Affected Requirements | Affected Work Units | Status | Answer Source |
+|---|---|---|---|---|---|---|
+
+## Resume Checkpoint
+
+Last Completed Step:
+
+Next Action:
+
+Artifacts To Refresh:
+
+Stale Artifacts Invalidated:
+
 ## Next Action
 ```
 
@@ -65,6 +80,80 @@ Git rule: in a Git-backed codebase, ensure `<workspace>/.gitignore` contains `.w
 ## Allowed Next Action
 ```
 
+## SPEC.md
+
+```md
+# SPEC
+
+Status: Draft | Approved | Needs Revision | Blocked
+
+## Objective
+
+## Source Of Truth
+
+| Source | Role | Notes |
+|---|---|---|
+
+## Interpreted Scope
+
+## Non-Goals
+
+## Requirement Coverage
+
+| ID | Source Ref | Requirement | Proposed Disposition | Final Disposition | Decision Source | Work Unit | Acceptance Row |
+|---|---|---|---|---|---|---|---|
+
+## Deferred, Out-Of-Scope, Or Blocked Items
+
+| ID | Requirement | Status | Reason | Needed Decision |
+|---|---|---|---|---|
+
+## Proposed Work Units
+
+| Work Unit | Objective | Depends On | Verification |
+|---|---|---|---|
+
+## Acceptance Summary
+
+## Assumptions And Risks
+
+## Open Questions
+
+| ID | Question | Asked By | Answer | Status |
+|---|---|---|---|---|
+
+## Q&A Log
+
+| ID | Question | Answer | Spec Change Required | Status |
+|---|---|---|---|---|
+
+## Resume Checkpoint
+
+Blocked At:
+
+Required Human Decision:
+
+Affected Requirement IDs:
+
+Affected Work Units:
+
+Next Action After Answer:
+
+Artifacts To Refresh:
+
+Stale Artifacts Invalidated:
+
+## Human Verification
+
+Reviewer:
+
+Decision: Approved | Needs Revision | Blocked
+
+Decision Source:
+
+Notes:
+```
+
 ## WORK-UNITS.md
 
 ```md
@@ -249,6 +338,66 @@ Acceptance Criteria:
 ## Next Recommended Action
 ```
 
+## GOAL-STATE.md
+
+```md
+# Goal State
+
+## Objective
+
+## Goal Binding
+
+created | reused | skipped | unavailable | conflict
+
+## Goal Status
+
+active | complete | blocked | blocked old | unknown
+
+## Previous Blocked Goal
+
+Goal Reference:
+
+Reason:
+
+Use As History Only: yes | no
+
+## Last Tool Action
+
+get_goal | create_goal | update_goal | none
+
+## Next Allowed Goal Action
+
+## Last Completed Step
+
+## Current Work Unit
+
+## Current Blocker
+
+## Human Decision Needed
+
+Question:
+
+Smallest Sufficient Answer:
+
+## Human Decision Answer
+
+Answer:
+
+Decision Type: clarification | scope change | requirement waiver | explicit deferral | blocker resolution | final disposition | intake change | workflow cancellation
+
+## Resume Checkpoint
+
+Next Action:
+
+Artifacts To Refresh:
+
+Stale Artifacts Invalidated:
+
+## Completion Rule
+
+## Blocked Rule
+```
+
 ## OUTCOME.md
 
 ```md

package/skills/workflow-supervisor/SKILL.md

@@ -16,13 +16,15 @@ Strict mode always requires:
 1. Complete intake before planning, goal creation, worker delegation, implementation, publication, or irreversible action.
 2. A human approval question before implementation unless completed intake explicitly selects `autonomous_goal`.
 3. A source corpus map, even if the source corpus is only "user prompt plus current workspace".
-4. At least one bounded work unit, even for a tiny change. Use `WU-001` when there is only one unit.
-5. A dossier for each implementation work unit before implementation begins.
-6. An acceptance matrix or acceptance draft with evidence expectations before implementation begins.
-7. A worker-agent plan with implementer, verifier, repair-author, and documenter agents.
-8. A worker lifecycle record using `planned -> handed_off -> acknowledged -> reported -> verified -> closed`.
-9. Verification labeled as `self-check`, `focused-check`, or `independent-verifier`.
-10. A final disposition question or recorded completed-intake final disposition after verification.
+4. A source-requirement coverage ledger before work-unit finalization.
+5. A SPEC review packet or `.workflow/SPEC.md` before work-unit finalization.
+6. At least one bounded work unit, even for a tiny change. Use `WU-001` when there is only one unit.
+7. A dossier for each implementation work unit before implementation begins.
+8. An acceptance matrix or acceptance draft with evidence expectations before implementation begins.
+9. A worker-agent plan with implementer, verifier, repair-author, and documenter agents.
+10. A worker lifecycle record using `planned -> handed_off -> acknowledged -> reported -> verified -> closed`.
+11. Verification labeled as `self-check`, `focused-check`, or `independent-verifier`.
+12. A final disposition question or recorded completed-intake final disposition after verification.
 
 Worker agents are mandatory when the environment provides worker, subagent, thread, or portable delegation tools. The supervisor must hand off implementation, verification, repair-authoring when needed, and documentation to separate agents with scoped dossiers and the required report schema. Run worker agents sequentially by default unless completed intake explicitly authorizes parallelism.
 
@@ -36,6 +38,60 @@ This workflow must work without a repository, codebase, existing docs, or instal
 
 When no source corpus exists, make the first work unit a discovery/intake unit instead of inventing prerequisites. Do not require `AGENTS.md`, a repo, commands, or Markdown files unless the specific task provides them or needs them.
 
+## Source Requirement Coverage Gate
+
+After the source corpus map and before final work units, extract the material requirements from the controlling sources into a coverage ledger. Include explicit user constraints, source deliverables, roadmap phases, exit criteria, named integrations, scale targets, verification requirements, and forbidden surfaces.
+
+For every source requirement, record:
+
+- source reference: file, ticket, prompt, section, line, or artifact id when available
+- requirement statement using the source's own strength, including numbers, named systems, and "must"/"exit criteria" language
+- disposition: `in_current_scope`, `explicit_user_deferred`, `blocked_needs_decision`, `out_of_scope_by_user`, or `non_material_context`
+- planned work unit id or blocking question
+- planned acceptance row id or waiver evidence
+
+Do not weaken requirements while translating them into units or acceptance rows. Examples of forbidden downgrades:
+
+- "live service import and query verification" to "generated export or optional loader"
+- "required validation corpus size" to "small starter checks exist"
+- "named providers A and B" to "one provider plus an extension hook"
+- "required batch analysis and report generation" to "metadata says reports are possible"
+- "provider-backed extraction and indexing" to "deterministic placeholder logic"
+
+Treat roadmap phases, source "Build" lists, and exit criteria as material when the user says the source is the source of truth, asks to implement everything, or does not explicitly narrow the scope. If the user wants only a first slice, record every non-slice material item as `explicit_user_deferred`; otherwise create work units for it or stop as `blocked_needs_decision`.
+
+Create exactly one implementation work unit only when all current-scope material requirements can be implemented and verified inside that one unit without hiding source requirements in residual risks, skipped checks, future work, or next recommended actions. For multi-phase, dependency-heavy, or roadmap-driven work, create one work unit per independently verifiable phase, integration, data slice, or risk boundary.
+
+Before final closeout, audit the coverage ledger. The workflow may be PASS only when every material requirement is mapped to a PASS acceptance row, explicitly waived by the user, or blocked and reported as not complete.
+
+## SPEC Review And Q&A Gate
+
+Before final work units, create a concise reviewable spec as `.workflow/SPEC.md` when workflow docs are enabled, or as an inline SPEC review packet when state is inline. The SPEC is the human-readable contract for interpretation, not the execution plan.
+
+The SPEC must include:
+
+- status: `Draft`, `Approved`, `Needs Revision`, or `Blocked`
+- objective and non-goals
+- source of truth summary
+- interpreted scope
+- requirement coverage ledger or summary
+- deferred, out-of-scope, and blocked items
+- proposed work units summary
+- acceptance summary
+- assumptions, risks, and open questions
+- Q&A log
+- human verification decision with reviewer, decision, notes, and date when known
+
+In `human_in_loop`, stop after presenting the draft SPEC and ask for review. The human may ask questions, request revisions, block, defer requirements, change dispositions, or approve. Continue to final work units, dossiers, or implementation only after the SPEC has `Decision: Approved` or an equivalent explicit approval in the conversation.
+
+If the human asks questions, answer them and update the Q&A log before proceeding. If the answers change scope, sources, dispositions, work units, or acceptance, revise the SPEC and ask for approval again. If the human marks `Needs Revision`, revise and re-present. If the human marks `Blocked`, stop and record the blocker.
+
+In `autonomous_goal`, create or record the SPEC and continue only when no blocking questions remain and no higher-priority instruction requires approval. Do not fabricate human approval; use `Approval: not required by autonomous_goal intake` or equivalent wording instead.
+
+Agents may propose dispositions such as `proposed_current_scope` or `proposed_deferred`, but only explicit user approval may convert them into `in_current_scope`, `explicit_user_deferred`, or `out_of_scope_by_user` when the distinction changes scope. Keep proposed agent interpretation separate from final human decisions.
+
+If `autonomous_goal` finds a blocking question or human decision point, use Resume After Human Decision instead of treating the autonomous path as failed. Autonomous execution may pause for the smallest necessary decision and then continue from the saved checkpoint after the human answers.
+
 ## Codex Goal Lifecycle
 
 This skill is loop-oriented. Complete intake is mandatory before goal binding. After all required intake decisions are answered, bind the workflow to a Codex goal only when the completed intake and governing environment both authorize goal-oriented work.
@@ -53,10 +109,31 @@ Use this lifecycle:
 9. Use `update_goal` only for terminal `complete` or `blocked` states when the environment supports that action.
 10. Mark the goal complete only after acceptance evidence supports completion and no required supervisor work remains.
 11. Distinguish workflow/unit BLOCKED from Codex goal blocked. Mark a Codex goal blocked only after the same material blocker repeats across the required consecutive goal turns and no meaningful progress remains.
-12. On resume after compaction or continuation, read the active goal first, then reconcile workflow docs and current artifacts.
+12. On resume after compaction, continuation, or human answer, read the active goal first, then reconcile workflow docs and current artifacts.
+13. If the prior Codex goal is terminal `blocked old`, do not assume it can be reopened. Continue from workflow state when safe; create or reuse a new active workflow state only when complete intake still authorizes goal binding, and reference the old blocked goal as history.
 
 If the environment has no goal tool or goal creation is not permitted, state the intended goal objective in the supervisor report and continue with workflow docs or another state artifact as the fallback state container.
 
+## Resume After Human Decision
+
+Use this protocol when `autonomous_goal` or another supervised path stops to ask a human for clarification, scope disposition, approval, waiver, final disposition, or any other blocking decision.
+
+Before asking the human:
+
+- Record the blocker in `.workflow/SPEC.md`, `.workflow/WORKFLOW.md`, `.workflow/GOAL-STATE.md`, or the inline state packet. Include the blocked artifact, exact question, affected requirement ids, affected work units, last completed step, and recorded next action.
+- Ask the smallest decision that can unblock progress. Do not re-ask complete intake unless a required intake decision is missing, contradicted, or directly changed by the blocker.
+- Mark the workflow, SPEC item, unit, or worker as waiting or blocked. Do not mark the Codex goal terminal `blocked` for a first material blocker when meaningful progress can continue after the human answers.
+
+When the human answers:
+
+- Classify the answer as one or more of: clarification, scope change, requirement waiver, explicit deferral, blocker resolution, final disposition, intake change, or workflow cancellation.
+- Update the SPEC Q&A log, requirement coverage dispositions, decision source, and any `DECISIONS.md`, `WORKFLOW.md`, or `GOAL-STATE.md` resume fields before continuing.
+- Do not restart intake unless the answer changes a required intake decision: objective/source, execution path, mode, delegation, final disposition, mutation boundaries, or state artifacts. If it does, ask only the affected intake item(s), then resume.
+- Re-run only the affected downstream steps: source coverage, SPEC, work-unit split, acceptance rows, dossiers, worker plan, verification, or final disposition. Preserve unaffected completed units and evidence.
+- Invalidate stale work units, acceptance rows, dossiers, or worker reports whose assumptions changed. Do not reuse them as green evidence.
+- Continue from the recorded `Next Action`. If the recorded next action is missing, derive the next action from the latest non-terminal workflow artifact and state the derivation in the report.
+- If the old Codex goal is still active and relevant, reuse it. If it is terminal `blocked old` and cannot be reopened, reference it as history and continue with workflow docs or a newly authorized goal binding.
+
 ## Operating Contract
 
 - After complete intake, ground the workflow in sources before creating work units.
@@ -65,6 +142,7 @@ If the environment has no goal tool or goal creation is not permitted, state the
 - Do not infer execution path, mode, delegation, final disposition, or boundaries from keywords, action verbs, or intent guesses.
 - Classify the workflow as `autonomous_goal` or `human_in_loop` only from completed intake answers before delegating workers or beginning implementation.
 - Explicit invocation always requires complete intake, work units, dossiers, worker-agent contracts, scoped handoffs, report schema, and verification; do this even for trivial tasks.
+- Preserve source-scope fidelity: do not translate controlling-source requirements into weaker proxy checks unless the user explicitly approves the narrower scope or waiver.
 - Always produce a plan after complete intake. In `human_in_loop`, make it an approval packet and stop for approval. In `autonomous_goal`, make it an execution plan and continue only when the completed intake authorizes that path.
 - Do not begin implementation until complete intake and the path gate are satisfied, at least one work unit exists, at least one concrete dossier exists, worker-agent contracts exist, and no stop gate applies.
 - Delegate workers only through an automated supported delegation transport after complete intake and the path gate authorize delegation. If no supported transport exists, use same-session phased mode only when intake allowed it; otherwise stop as `worker_agent_unavailable`.
@@ -73,7 +151,9 @@ If the environment has no goal tool or goal creation is not permitted, state the
 - Treat same-session verification as a self-check, not independent verification. Separate verifier-agent verification may be labeled `independent-verifier` only when genuinely performed by a separate worker agent or thread.
 - Prefer explicit PASS/FAIL/BLOCKED states over soft completion language.
 - Stop instead of improvising when sources are missing, contradictory, materially stale, or too vague to produce acceptance criteria.
+- Treat unimplemented material source requirements found in residual risks, skipped checks, future work, or `next_recommended_action` as open work, not PASS evidence.
 - Keep provenance optional; require enough outcome detail for another agent to resume.
+- When resuming after a human decision, update state first, invalidate changed downstream artifacts, and continue from the recorded next action instead of restarting the whole workflow.
 - Treat companion skills as optional phase tools, not an automatic cascade. Use the smallest set needed for the current risk.
 
 ## Skills And Workers
@@ -155,29 +235,33 @@ Negative example: "Using Workflow Supervisor, generate an API and create the pro
 2. Restate the objective, constraints, non-goals, known sources, and unknowns from the completed intake.
 3. Bind or reconcile the Codex goal only after complete intake and only when no unrelated active goal prevents binding.
 4. Build or request a source corpus map. Use `$source-corpus` when source authority, freshness, or contradictions matter.
-5. Split the objective into bounded work units. Use `$work-unit` for ambiguous or multi-phase goals. If the task is tiny, create exactly one work unit named `WU-001`.
-6. Choose a loop policy before starting work: sequential or parallel, retry limits, approval gates, budgets, goal update cadence, and blocker rules. Use `$loop-policy` when the policy is not obvious.
-7. Build dossiers for the first implementation units and any planned verification, repair, or documentation workers. Use `$dossier-builder` when delegating work to another agent or when the task has boundaries.
-8. Assign worker roles with explicit allowed and forbidden behavior. Use `$worker-roles` for multi-agent, native-thread, or portable-worker work.
-9. Select the execution path:
+5. Create the source-requirement coverage ledger. If any material source requirement cannot be classified, mapped to work, or explicitly deferred, stop and ask for the missing scope decision.
+6. Create the SPEC review packet or `.workflow/SPEC.md` from the source corpus and coverage ledger.
+7. Run the SPEC Q&A gate. In `human_in_loop`, stop until the human asks questions, receives answers or revisions, and explicitly approves the SPEC. In `autonomous_goal`, continue only when no blocking questions remain and approval is not required by intake.
+8. Split the objective into bounded work units from the approved or non-blocked SPEC and coverage ledger. Use `$work-unit` for ambiguous or multi-phase goals. If the task is tiny and the ledger has no deferred material requirements, create exactly one work unit named `WU-001`.
+9. Choose a loop policy before starting work: sequential or parallel, retry limits, approval gates, budgets, goal update cadence, and blocker rules. Use `$loop-policy` when the policy is not obvious.
+10. Build dossiers for the first implementation units and any planned verification, repair, or documentation workers. Use `$dossier-builder` when delegating work to another agent or when the task has boundaries.
+11. Assign worker roles with explicit allowed and forbidden behavior. Use `$worker-roles` for multi-agent, native-thread, or portable-worker work.
+12. Select the execution path:
    - `human_in_loop`: use when selected in completed intake or when a higher-priority rule requires human approval after intake.
    - `autonomous_goal`: use only when selected in completed intake and no higher-priority rule requires human approval.
-10. If `.workflow/` artifacts will be used in a Git-backed codebase, ensure `.gitignore` contains `.workflow/` before writing them.
-11. Present the path-specific plan:
+13. If `.workflow/` artifacts will be used in a Git-backed codebase, ensure `.gitignore` contains `.workflow/` before writing them.
+14. Present the path-specific plan:
    - `human_in_loop`: approval packet with plan, work units, worker delegation plan, approval gates, stop gates, and first dossiers. Stop until the human approves or revises it.
    - `autonomous_goal`: execution plan with the same contents plus autonomous boundaries, allowed actions, stop gates, repair limits, and final disposition policy. Continue after recording it only when complete intake authorized that path.
-12. After the path gate is satisfied, delegate named workers from the worker delegation plan through the selected automated transport. Send each worker only its role, dossier, sources, acceptance rows, stop gates, and report schema.
-13. Collect one terminal report from each worker. If a worker asks a human-facing question, convert it to `BLOCKED` and have the supervisor ask the user only when the path policy permits.
-14. Verify independently where possible. Use `$acceptance-matrix` to map every requirement to evidence. Start verifier workers only after the relevant implementer report is available.
-15. If verification FAILs, convert findings into repair tickets and route them to a repair-author or implementer repair worker. Do not expand scope during repair.
-16. Re-run verification after repairs. Continue only until PASS, BLOCKED, repair limit, or path stop.
-17. Start documenter workers only after source, implementation, verification, or repair evidence exists, unless the documenter is explicitly creating planning state.
-18. If verification BLOCKs, report the blocker and stop or ask for the missing decision.
-19. Use `$workflow-docs` to create or refresh reusable Markdown artifacts under `<workspace>/.workflow/` when the workflow must persist across context loss, agents, or sessions.
-20. When all material acceptance rows are PASS or waived, apply the final disposition policy:
+15. After the path gate is satisfied, delegate named workers from the worker delegation plan through the selected automated transport. Send each worker only its role, dossier, sources, acceptance rows, stop gates, and report schema.
+16. Collect one terminal report from each worker. If a worker asks a human-facing question, convert it to `BLOCKED` and have the supervisor ask the user only when the path policy permits.
+17. Verify independently where possible. Use `$acceptance-matrix` to map every requirement to evidence. Start verifier workers only after the relevant implementer report is available.
+18. If verification FAILs, convert findings into repair tickets and route them to a repair-author or implementer repair worker. Do not expand scope during repair.
+19. Re-run verification after repairs. Continue only until PASS, BLOCKED, repair limit, or path stop.
+20. Start documenter workers only after source, implementation, verification, or repair evidence exists, unless the documenter is explicitly creating planning state.
+21. If verification BLOCKs, record the resume checkpoint, report the blocker, and stop or ask for the missing decision. When the human answers, use Resume After Human Decision.
+22. Use `$workflow-docs` to create or refresh reusable Markdown artifacts under `<workspace>/.workflow/` when the workflow must persist across context loss, agents, or sessions.
+23. Audit skipped checks, residual risks, future work, and next recommended actions against the source-requirement coverage ledger. If any material source requirement appears there without an explicit user deferral or waiver, mark the workflow FAIL/BLOCKED and create more work units or ask for a scope decision.
+24. When all material acceptance rows are PASS or waived, apply the final disposition policy:
    - `human_in_loop`: use the completed intake final disposition; if it is `ask_at_end`, ask the human to choose PR, push main, or keep local.
    - `autonomous_goal`: use the completed intake final disposition. If it is `ask_at_end`, stop and ask before taking any final disposition action.
-21. Finish with an outcome report that names execution path, goal status, sources, work units, delegated workers, checks, skipped checks, residual risks, final disposition decision, and next action.
+25. Finish with an outcome report that names execution path, goal status, sources, SPEC decision, coverage ledger disposition, work units, delegated workers, checks, skipped checks, residual risks, final disposition decision, and next action.
 
 ## Execution Paths
 
@@ -185,10 +269,12 @@ Negative example: "Using Workflow Supervisor, generate an API and create the pro
 
 Use `human_in_loop` when the completed intake selects it, or when a higher-priority rule requires human approval after intake. If the user has not answered the execution-path intake item, stop and ask for that answer instead of inferring a path.
 
-The first supervisor deliverable is a plan for approval, not implementation. The approval packet must include:
+The first review deliverable after source coverage is the SPEC review packet, not implementation. After the SPEC Q&A gate is approved, the supervisor presents the implementation approval packet. The approval packet must include:
 
 - objective and non-goals
 - source corpus summary and gaps
+- source-requirement coverage ledger summary
+- SPEC review status, Q&A summary, and decision
 - work units and sequence
 - worker delegation plan with names, roles, dossiers, dependencies, start conditions, and transport
 - acceptance matrix summary
@@ -203,6 +289,8 @@ Use `autonomous_goal` only when the completed intake selects it. Phrases such as
 
 - objective and non-goals
 - source corpus summary and gaps
+- source-requirement coverage ledger summary
+- SPEC review status, Q&A summary, and approval policy
 - work units and sequence
 - worker delegation plan with names, roles, dossiers, dependencies, start conditions, and transport
 - acceptance matrix summary
@@ -214,6 +302,8 @@ The final disposition must come from the completed intake. Direct push to the ma
 
 Even in `autonomous_goal`, stop and ask when any required intake answer is missing or ambiguous, required sources are missing, acceptance cannot be verified, a worker needs scope expansion, an irreversible action lacks intake authorization, or higher-priority instructions require approval.
 
+When `autonomous_goal` stops for a human decision, it should usually leave the Codex goal active and mark only the workflow artifact, SPEC item, work unit, or worker as waiting or blocked. After the human answers, resume from the recorded next action and refresh only the affected downstream artifacts.
+
 ## Portable Worker Delegation
 
 After the path gate is satisfied, use the selected automated worker transport. The portable default is the package helper:
@@ -293,6 +383,9 @@ Stop when:
 - source authority cannot be established
 - sources contradict each other on a material requirement
 - the requested scope cannot fit into a bounded work unit
+- the coverage ledger is missing, incomplete, or contains material requirements classified as future work without explicit user deferral
+- human-in-loop SPEC approval is missing, marked Needs Revision, marked Blocked, or has unanswered Q&A
+- a human decision was answered but affected downstream coverage, SPEC, work units, acceptance, dossiers, or verification have not been refreshed
 - mandatory approval packet, work unit, dossier, worker-agent contract, or acceptance matrix is missing
 - allowed and forbidden surfaces cannot be named
 - acceptance cannot be verified with evidence
@@ -303,6 +396,7 @@ Stop when:
 - an irreversible action is requested without explicit authorization in the completed intake
 - a worker asks to expand scope without supervisor or human approval
 - final verification is not green and no waiver evidence exists
+- residual risks, skipped checks, future work, or next actions contain unimplemented material source requirements
 
 ## Final Report Shape
 
@@ -313,8 +407,11 @@ Report:
 - Goal status and whether a Codex goal was created, reused, skipped, completed, or blocked
 - Objective handled
 - Sources used and gaps
+- SPEC status, Q&A summary, and human decision or autonomous approval policy
+- Source-requirement coverage ledger summary, including deferred or blocked material requirements
 - Work units completed or remaining
 - Approval question id and whether `WAITING_FOR_HUMAN -> ACTIVE` occurred
+- Human decision resume status, affected artifacts, and whether stale downstream artifacts were invalidated
 - Dossiers created or missing
 - Workers delegated, blocked, unavailable, or skipped
 - Worker lifecycle status for each role

package/skills/workflow-supervisor/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Workflow Supervisor"
   short_description: "Run autonomous or human-gated workflows"
-  default_prompt: "Use $workflow-supervisor to run the complete intake gate first. Ask every required intake question and stop until the user explicitly answers all of them. Do not infer or skip steps from keywords such as autonomous, work until done, approval, generate, or create. Start planning or work only after complete intake is satisfied."
+  default_prompt: "Use $workflow-supervisor to run the complete intake gate first. Ask every required intake question and stop until the user explicitly answers all of them. Do not infer or skip steps from keywords such as autonomous, work until done, approval, generate, or create. After intake, create a source-requirement coverage ledger and SPEC review gate before work units, preserve source requirements in acceptance rows, and do not hide unimplemented material requirements in residual risks or future work."
 
 policy:
   allow_implicit_invocation: false