workflow-supervisor 0.1.3 → 0.1.4

package/CHANGELOG.md

@@ -0,0 +1,109 @@
+# Changelog
+
+This changelog was reconstructed from npm publish metadata and git history after the first four package versions were published without GitHub releases or tags.
+
+## 0.1.4 - 2026-06-19
+
+Prepared for npm publication.
+
+### Added
+
+- Added profile-based supervisor execution with `lean_work_unit_runner`, `strict_full_workflow`, and `planning_only`.
+- Added compact lean-runner ledger guidance for large bounded backlogs that need lower memory and less ceremony.
+- Added native worker resource lifecycle rules for thread and subagent transports.
+
+### Changed
+
+- Changed strict worker lifecycle from logical closeout only to `planned -> handed_off -> acknowledged -> reported -> verified -> resource_closed -> closed`.
+- Required native worker transports to record resource ids, close actions, and close results before final workflow outcome.
+- Made one-shot portable delegation the preferred worker path when it satisfies the work, because it avoids resident native workers.
+
+### Fixed
+
+- Prevented completed Codex subagents from remaining open after workflow-supervisor runs by requiring `close_agent` for every recorded native `agent_id`.
+- Blocked final PASS when any native worker has no recorded close result.
+- Reduced large-backlog memory pressure by defaulting lean execution to same-session phased work unless workers are explicitly authorized or risk escalation requires them.
+
+### Verified
+
+- Expanded lifecycle tests to cover profile selection, lean ledgers, native worker resource ids, `close_agent`, and close-result gates.
+
+## 0.1.3 - 2026-06-17
+
+Published to npm: 2026-06-17 22:09:08 UTC
+
+Commit: `154bbd7`
+
+### Added
+
+- Added resumable SPEC gate behavior so broad source-controlled workflows can pause for human review before final work units, dossiers, and implementation.
+- Added resume guidance for autonomous workflows that block on a human decision, including updates to workflow state, goal state, and decision artifacts.
+- Expanded troubleshooting guidance for broad roadmap scope, residual risks that hide required work, and SPEC review before work units.
+
+### Changed
+
+- Hardened workflow-supervisor scope coverage so material source requirements, roadmap phases, exit criteria, named systems, and numeric targets must be mapped to work units, explicitly deferred, blocked, or marked non-material.
+- Updated acceptance, loop-policy, work-unit, and workflow-docs instructions to preserve source requirement strength and avoid quiet downgrades.
+
+### Verified
+
+- Expanded workflow-supervisor lifecycle tests for source coverage, SPEC review, and resume behavior.
+
+## 0.1.2 - 2026-06-17
+
+Published to npm: 2026-06-17 16:00:10 UTC
+
+Commit: `b449656`
+
+### Changed
+
+- Reworked the workflow-supervisor skill around a stricter worker-agent supervisor architecture.
+- Made explicit supervisor invocation require full intake, work units, dossiers, worker-agent contracts, scoped handoffs, report schema, and verification even for small tasks.
+- Clarified that implementation, verification, repair-authoring, and documentation are separate worker-agent responsibilities when an automated worker path is available.
+- Rewrote the README around the strict worker supervisor model and the current package workflow.
+
+### Verified
+
+- Added lifecycle coverage for strict supervisor invocation behavior.
+
+## 0.1.1 - 2026-06-15
+
+Published to npm: 2026-06-15 10:59:19 UTC
+
+Commit: `ee4c02b`
+
+### Added
+
+- Added portable worker delegation for Codex and Claude Code through `workflow-supervisor delegate`.
+- Added `WorkerReportV1` and `DossierV1` schema artifacts plus dossier validation before delegation.
+- Added `delegate-doctor` for adapter inspection and optional probe runs.
+- Added project-scope `.workflow/` ignore handling for local workflow state.
+- Added portable delegation documentation and tests for install, delegation, and lifecycle behavior.
+
+### Changed
+
+- Renamed the primary package executable path around `workflow-supervisor` while keeping `workflow-skills` as an executable alias.
+- Narrowed certified install/delegation targets to Codex, Claude Code, and generic Markdown contexts.
+- Strengthened validation to include adapter metadata and schema artifacts.
+
+### Verified
+
+- Added Node test coverage for delegate CLI behavior, installation behavior, portable delegation, and supervisor lifecycle handling.
+
+## 0.1.0 - 2026-06-14
+
+Published to npm: 2026-06-14 23:35:57 UTC
+
+Source: npm tarball contents. The GitHub release tag for this version is a reconstructed source snapshot from the npm tarball because no exact matching commit exists in the branch history for this first publish.
+
+### Added
+
+- Initial npm package for the workflow-supervisor skill pack.
+- Added the bundled skills: `workflow-supervisor`, `worker-roles`, `acceptance-matrix`, `dossier-builder`, `source-corpus`, `loop-policy`, `work-unit`, and `workflow-docs`.
+- Added the `workflow-supervisor` and `workflow-skills` executables for listing, validating, installing, uninstalling, and emitting portable context.
+- Added Codex, Claude Code, OpenCode, HermesAgent, and generic adapter metadata, plus package documentation, troubleshooting notes, compatibility notes, and a README overview.
+- Added packaging metadata, test coverage, and prepublish validation through `npm run validate`.
+
+### Verified
+
+- Initial package validation covered skill folder structure, `SKILL.md` metadata, and publishable package layout.

package/README.md

@@ -1,8 +1,8 @@
 # Workflow Supervisor
 
-Workflow Supervisor is a strict supervision skill pack for agent work that needs to stay organized, resumable, and evidence-backed.
+Workflow Supervisor is a profile-based supervision skill pack for agent work that needs to stay organized, resumable, evidence-backed, and proportional to the work.
 
-It is for moments when you do not want an agent to jump straight into implementation, lose the thread halfway through, verify its own work, or quietly skip important handoffs. You ask for the supervisor, the supervisor asks the right setup questions, turns the work into small units, creates worker dossiers, delegates scoped work to real worker agents when possible, verifies the results, and leaves a clear outcome trail.
+It is for moments when you do not want an agent to lose the thread halfway through, quietly skip scope, or turn a large backlog into an unreviewable blur. You ask for the supervisor, the supervisor selects the right execution profile, keeps the work units explicit, verifies results with evidence, and leaves a clear outcome trail. Heavy multi-agent ceremony is available when risk justifies it; large pure backlogs can use a lean runner that keeps the agent focused on delivery.
 
 Example prompt:
 
@@ -19,10 +19,12 @@ The correct first response is not code. The correct first response is an intake
 Workflow Supervisor gives you a repeatable workflow for serious agent tasks:
 
 - a complete intake before work starts
+- a profile choice between `lean_work_unit_runner`, `strict_full_workflow`, and `planning_only`
 - 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
+- a compact ledger for high-throughput work-unit execution
 - dossiers that tell each worker exactly what to do and what not to touch
 - separate implementer, verifier, repair, and documenter responsibilities
 - structured worker reports instead of loose prose
@@ -31,7 +33,7 @@ Workflow Supervisor gives you a repeatable workflow for serious agent tasks:
 - durable `.workflow/` state when the work needs to survive context loss
 - a final report with checks, risks, workers, and next actions
 
-The main design choice is simple: the supervisor coordinates, workers do scoped work, and the CLI stays small.
+The main design choice is simple: supervision is mandatory when requested, but overhead is profile-dependent. Work units preserve clarity. Workers, dossiers, and independent verifier loops are tools for strict or escalated work, not a default tax on every unit.
 
 ## The Mental Model
 
@@ -88,9 +90,35 @@ flowchart TB
 
 ## What Happens When You Invoke It
 
-When you explicitly invoke `workflow-supervisor`, `$workflow-supervisor`, or say to use the skill, the workflow enters `strict_full_workflow`.
+When you explicitly invoke `workflow-supervisor`, `$workflow-supervisor`, or say to use the skill, the first decision is the execution profile:
 
-Strict mode means task size does not matter. Even if the request is "make a function that adds two numbers", explicit supervisor invocation still means the full workflow:
+- `lean_work_unit_runner`: for large, already-bounded work-unit backlogs where throughput and low memory matter.
+- `strict_full_workflow`: for ambiguous, high-risk, delegated, security-sensitive, source-of-truth, publication, or cross-system work.
+- `planning_only`: for intake, sequencing, risk review, and recommendations without implementation.
+
+Lean mode keeps work units but removes per-unit ceremony. It uses one upfront scope contract, one compact ledger, targeted checks, and strict escalation gates:
+
+```text
+select next ready unit
+-> inspect only needed sources
+-> patch or update the allowed surface
+-> run the targeted check
+-> update one ledger row
+-> continue until batch checkpoint, blocker, or final disposition
+```
+
+A lean unit is not ready unless it has:
+
+```yaml
+id:
+source_ref:
+scope:
+done:
+check:
+status:
+```
+
+Strict mode is still available when risk justifies it. In strict mode, task size does not matter. The full workflow is:
 
 1. Ask the complete intake packet.
 2. Build or record the source corpus.
@@ -108,20 +136,21 @@ Strict mode means task size does not matter. Even if the request is "make a func
 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.
+Profile selection exists to prevent both failure modes: skipping supervision when work is risky, and drowning simple or already-bounded work in process.
 
 ## Intake
 
-The supervisor must get explicit answers to these seven items before planning deeply, creating a goal, delegating workers, implementing, publishing, or taking irreversible action:
+The supervisor must get explicit answers to these eight items before planning deeply, creating a goal, delegating workers, implementing, publishing, or taking irreversible action:
 
 ```text
 1. Objective and source: what artifact, spec, repo path, document, ticket, or source set controls the work?
-2. Execution path: autonomous_goal or human_in_loop?
-3. Mode: sequential, parallel where safe, or staged parallel?
-4. Delegation: automated worker delegation, native threads/subagents if available, or same-session phased?
-5. Final disposition: keep local, open PR, push main, deploy/publish, or ask at the end?
-6. Boundaries: may I install dependencies, call external services, use credentials, or only edit local files?
-7. State artifacts: create .workflow docs, use another artifact directory, or keep state inline?
+2. Profile: lean_work_unit_runner, strict_full_workflow, or planning_only?
+3. Execution path: autonomous_goal or human_in_loop?
+4. Mode: sequential, parallel where safe, or staged parallel?
+5. Delegation: same-session phased, automated worker delegation, or native threads/subagents if available?
+6. Final disposition: keep local, open PR, push main, deploy/publish, or ask at the end?
+7. Boundaries: may I install dependencies, call external services, use credentials, or only edit local files?
+8. State artifacts: compact ledger, .workflow docs, another artifact directory, or inline state?
 ```
 
 If any answer is missing or vague, the supervisor asks only for the missing pieces and stops. Phrases like "work autonomously", "just do it", or "use your judgment" do not fill in the missing intake fields.
@@ -156,10 +185,10 @@ complete intake
 The worker lifecycle is tracked separately:
 
 ```text
-planned -> handed_off -> acknowledged -> reported -> verified -> closed
+planned -> handed_off -> acknowledged -> reported -> verified -> resource_closed -> closed
 ```
 
-This makes it possible to see where the workflow is, which worker owns which piece, what evidence exists, and what should happen next.
+This makes it possible to see where the workflow is, which worker owns which piece, what evidence exists, what native resource was opened, and whether that resource was closed. A native worker is not closed just because it returned a report.
 
 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.
 
@@ -199,7 +228,7 @@ Common workflow files:
 | `.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. |
+| `.workflow/WORKER-MAP.md` | `workflow-supervisor`, `worker-roles`, `workflow-docs` | Worker names, roles, transports, native resource ids, lifecycle, reports, close results, blockers. |
 | `.workflow/ACCEPTANCE-MATRIX.md` | `acceptance-matrix`, `workflow-docs` | Evidence rows and material PASS, FAIL, BLOCKED states. |
 | `.workflow/VERIFICATION-REPORT.md` | verifier worker, `acceptance-matrix`, `workflow-docs` | Verification evidence, findings, skipped checks, residual risks. |
 | `.workflow/REPAIR-TICKETS.md` | repair worker, `workflow-docs` | Repair tasks tied to failed rows or verifier findings. |
@@ -313,9 +342,11 @@ Every delegated worker returns this machine-shaped report:
 
 The supervisor trusts the report shape, not loose prose. A PASS without evidence is invalid. A verifier that edits implementation is invalid. A worker that asks the human directly is converted into a blocker for the supervisor to route.
 
+For native threads or subagents, the report is only the work result. The supervisor must also close the native resource. For Codex subagents, record the returned `agent_id` and call `close_agent` after the report, timeout, failure, blocker, cancellation, or invalid-output result is captured. Final outcome is blocked while any native worker lacks a close result.
+
 ## How The Supervisor Talks To Workers
 
-The portable worker path is one CLI command:
+The portable worker path is one CLI command and is preferred when it satisfies the work because it is one-shot:
 
 ```bash
 workflow-supervisor delegate \
@@ -351,9 +382,11 @@ workflow-supervisor delegate-doctor --agent all --probe --require-pass
 
 If a worker adapter is missing, unauthenticated, times out, returns invalid output, edits forbidden surfaces, or returns PASS without evidence, the delegate command returns a structured `BLOCKED` report.
 
+Native thread or subagent transports may be used only when the environment exposes the full lifecycle: create, wait or receive a terminal report, and close. If a native transport can start workers but cannot close them, the supervisor records `worker_resource_close_unavailable` and uses portable delegation or same-session phased work only when intake allows it.
+
 ## No Silent Fallbacks
 
-If the environment can create, message, or delegate to worker agents, the supervisor must use real workers for implementation, verification, repair, and documentation responsibilities.
+In `strict_full_workflow` with worker delegation selected, if the environment can create, message, or delegate to worker agents, the supervisor must use real workers for implementation, verification, repair, and documentation responsibilities.
 
 If it cannot, it must record:
 
@@ -363,7 +396,7 @@ worker_agent_unavailable
 
 Then it must stop for a human decision unless complete intake explicitly selected `same_session_phased`.
 
-Same-session phased work is allowed only when selected. Verification in that mode is a `self-check`, not an `independent-verifier`.
+In `lean_work_unit_runner`, same-session phased execution is the default unless the user explicitly authorizes workers for a batch or escalation. Verification in same-session mode is a `focused-check` or `self-check`, not an `independent-verifier`.
 
 ## Install
 
@@ -538,11 +571,11 @@ If you are an agent using this package:
 
 1. Do not start work before complete intake.
 2. Do not infer missing permissions from words like "autonomous", "generate", or "work until done".
-3. If `$workflow-supervisor` is explicit, always create at least one work unit.
-4. Do not delegate without a valid `DossierV1`.
-5. Use separate worker agents when supported by the environment.
-6. Do not silently collapse worker agents into same-session roleplay.
-7. Treat same-session verification as `self-check`, not `independent-verifier`.
+3. If `$workflow-supervisor` is explicit, select `lean_work_unit_runner`, `strict_full_workflow`, or `planning_only` before heavy planning.
+4. Always keep work units explicit; lean mode uses a compact ledger instead of full per-unit ceremony.
+5. Do not delegate without a valid `DossierV1`.
+6. Use separate worker agents in strict or explicitly delegated work, not by default for lean execution.
+7. Treat same-session verification as `focused-check` or `self-check`, not `independent-verifier`.
 8. Trust only structured `WorkerReportV1` results from delegated workers.
 9. Treat verifier edits as invalid.
 10. Keep `.workflow/` ignored and local unless the user explicitly asks to publish it.

package/docs/artifacts.md

@@ -8,6 +8,7 @@ In Git-backed codebases, `.workflow/` is local working state. Ensure `<workspace
 
 ## Workflow Control
 
+- `.workflow/LEDGER.md`
 - `.workflow/WORKFLOW.md`
 - `.workflow/SOURCE-CORPUS.md`
 - `.workflow/WORK-UNITS.md`
@@ -40,3 +41,7 @@ In Git-backed codebases, `.workflow/` is local working state. Ensure `<workspace
 ## State Medium
 
 Markdown is the default, but state may also be an inline brief, spreadsheet tab, ticket set, design annotation, CRM note, runbook, decision log, slide appendix, whiteboard note, or chat continuation note.
+
+For `lean_work_unit_runner`, prefer one compact ledger over multiple workflow documents. Each executable row should carry `id`, `source_ref`, `scope`, `done`, `check`, `status`, touched surfaces, and blockers. Escalated units may link to strict-mode SPEC, dossier, or verification artifacts only when needed.
+
+For native thread or subagent delegation, `WORKER-MAP.md` must record the native resource id, terminal report, close action, and close result. Do not mark a native worker closed until the resource close is recorded.

package/docs/portable-delegation.md

@@ -18,6 +18,10 @@ complete intake
 -> final supervisor report
 ```
 
+This document describes strict or explicitly delegated execution. `lean_work_unit_runner` normally stays in same-session phased execution with a compact ledger and targeted checks. It should enter portable delegation only when the user authorizes workers for a batch or a unit hits a strict-mode escalation trigger.
+
+Prefer portable delegation over native threads or subagents when it satisfies the work. Portable delegation is one-shot, so the worker process exits after the report. Native thread or subagent transports are allowed only when the supervisor can record the native resource id and call the matching close operation after terminal report, timeout, blocker, cancellation, or invalid output.
+
 The supervisor remains the only coordinator. Workers do not ask the human questions, choose final disposition, expand scope, approve plans, or talk to each other. If a worker needs a decision, it returns `BLOCKED` with a `blocking_question`; only the supervisor asks the user.
 
 ## Non-Goals
@@ -163,6 +167,7 @@ For git workspaces, the surface guard compares pre/post git status. Mutable role
 | Repair expands scope | Reject unless the repair dossier explicitly allowed the new surfaces and criteria. |
 | Units touch same surfaces | Run sequentially. Parallel delegation requires proven disjoint mutable surfaces. |
 | Platform has no native subagents | Fine. Each role is a fresh one-shot CLI process. |
+| Native subagent close is unavailable | Do not spawn it. Return `worker_resource_close_unavailable` and use portable delegation or same-session phased work only if intake allowed it. |
 | Platform output differs | Platform output is not the contract. `WorkerReportV1` is the only supervisor input. |
 | Platform cannot support a role safely | Adapter role is unsupported. Supervisor chooses another certified adapter or blocks. |
 | Full support is claimed but one CLI is absent | `delegate-doctor --agent all --probe --require-pass` exits nonzero and names the missing adapter. |

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 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.
+Coordinate explicit supervised or agent-loop workflows with profile-based overhead. It starts by selecting `lean_work_unit_runner`, `strict_full_workflow`, or `planning_only`, then completes the intake needed for that profile before implementation, goal binding, worker delegation, or final disposition. The user must answer required intake items; the supervisor must not infer path, mode, delegation, final disposition, or boundaries from vague keywords. Lean mode is for large already-bounded work-unit backlogs: it keeps a compact ledger with unit id, source reference, scope, done signal, check, status, touched surfaces, and blockers, then executes one ready unit at a time with targeted checks and escalation gates. Strict mode 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 before execution. In autonomous goal mode, human clarification pauses resume from recorded workflow state after the answer updates only affected downstream artifacts. Strict mode can orchestrate named workers from dossiers through the portable delegate command or an approved native adapter. Native threads and subagents require a recorded native resource id plus a close result, such as `close_agent` for Codex subagents, before a worker is `closed`. 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`
 

package/docs/troubleshooting.md

@@ -23,6 +23,16 @@ Use `.workflow/GOAL-STATE.md` or a workflow continuation document. The superviso
 
 Use `$workflow-docs` with a minimal artifact request. The skill must reject "create every document just in case."
 
+## Large backlogs run slowly or exhaust memory
+
+Use `lean_work_unit_runner` instead of `strict_full_workflow` when the source already contains clear work units and the user's priority is throughput. Keep one compact ledger with `id`, `source_ref`, `scope`, `done`, `check`, `status`, touched surfaces, and blockers. Run one unit at a time by default, avoid subagents unless explicitly authorized, avoid broad scans unless required for the current unit, and checkpoint by batch rather than rewriting full workflow docs after every unit.
+
+Do not remove work units to make the process lean. If a unit cannot name its boundary, done signal, or targeted check, mark it `blocked` or escalate that unit to strict mode.
+
+## Native subagents remain open after completion
+
+Treat this as a lifecycle bug, not a cosmetic cleanup task. A terminal report or completed notification does not close a native Codex subagent. Record every native worker id in `WORKER-MAP.md`, call the native close action such as `close_agent` after the terminal report or blocker is captured, and block the final outcome if any native worker lacks a close result. Prefer one-shot portable delegation when it satisfies the work.
+
 ## Verification rubber-stamps the result
 
 Use `$acceptance-matrix` for formal evidence rows. A PASS requires row-by-row evidence or explicit waiver evidence.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "workflow-supervisor",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Portable workflow supervision skills for Codex, Claude Code, and generic agent workspaces.",
   "type": "module",
   "repository": {
@@ -19,9 +19,15 @@
     "skills",
     "adapters",
     "schemas",
-    "docs",
+    "docs/artifacts.md",
+    "docs/cli.md",
+    "docs/compatibility.md",
+    "docs/portable-delegation.md",
+    "docs/skill-reference.md",
+    "docs/troubleshooting.md",
     "assets",
     "bin",
+    "CHANGELOG.md",
     "README.md",
     "LICENSE"
   ],

package/skills/loop-policy/SKILL.md

@@ -28,11 +28,12 @@ Do not create goals for small direct tasks. A goal is the state container for op
 
 ## Policy Dimensions
 
+- Profile: `lean_work_unit_runner`, `strict_full_workflow`, or `planning_only`; choose before heavy artifacts, goals, workers, or implementation.
 - Intake: whether every required intake decision has an explicit user answer, and which unanswered items must be re-asked before any work can start.
 - Execution path: autonomous_goal or human_in_loop, from completed intake only.
 - Mode: sequential, parallel, staged parallel, or discovery-first, from completed intake only.
 - Approval: none, before worker delegation, before implementation, before verification, before repair, before publication, before irreversible action, before each unit, or path-gated.
-- Delegation orchestration: selected transport, adapter availability, naming scheme, start timing, supervisor checkpoint cadence, terminal report collection, and stop behavior when automated delegation is unavailable.
+- Delegation orchestration: selected transport, adapter availability, naming scheme, start timing, supervisor checkpoint cadence, terminal report collection, native resource close behavior, and stop behavior when automated delegation is unavailable.
 - Repair limit: maximum repair loops per unit.
 - Budget: time, token, command, cost, or file-change limits.
 - Escalation: when to ask the user, delegate to a specialist worker, or stop.
@@ -45,20 +46,32 @@ Do not create goals for small direct tasks. A goal is the state container for op
 Use this default unless the task says otherwise:
 
 ```yaml
+profile_selection: before goal creation, heavy planning, worker delegation, implementation, verification, repair, final disposition, publication, or irreversible action
+profiles:
+  lean_work_unit_runner: large bounded backlog, pure work units, low-footprint direct execution, compact ledger, no default subagents
+  strict_full_workflow: ambiguous, high-risk, delegated, source-of-truth, security, external-service, publication, or broad interpretation work
+  planning_only: intake, scope review, sequencing, risks, and recommendations without implementation
 intake_required_when: every supervisor invocation before goal creation, planning beyond intake, worker delegation, implementation, verification, repair, final disposition, publication, or irreversible action
 intake_question_count: ask the complete intake packet first; on follow-up ask every unanswered or ambiguous item
-required_intake_decisions: objective_and_source, execution_path, mode, delegation, final_disposition, mutation_boundaries, state_artifacts
+required_intake_decisions: objective_and_source, profile, execution_path, mode, delegation, final_disposition, mutation_boundaries, state_artifacts
 use_judgment_defaults: none; user must answer every required intake decision explicitly
-keyword_shortcuts: forbidden; do not infer path, mode, delegation, final disposition, or boundaries from prompt keywords
+keyword_shortcuts: forbidden for path, mode, delegation, final disposition, and boundaries; profile may be selected only from explicit user intent plus controlling source
 mode: from completed intake only
 execution_path: from completed intake only
 approval_gate: path-gated; complete intake before any path-specific plan; human approval for human_in_loop plans; explicit completed-intake authorization for autonomous_goal; explicit completed-intake authorization for irreversible or user-visible publication
 repair_limit_per_unit: 2
 parallel_allowed_when: units do not share mutable surfaces
-worker_delegation_rule: after complete intake, path gate, concrete dossier, and supported automated transport
-native_transport_rule: after complete intake, path gate, and concrete dossier when the environment exposes approved thread or subagent tools
+worker_delegation_rule: strict mode after complete intake, path gate, concrete dossier, supported automated transport, and supported resource close; lean mode only after explicit authorization or escalation trigger
+native_transport_rule: after complete intake, path gate, concrete dossier, and confirmed close operation when the environment exposes approved thread or subagent tools
 worker_name_template: wf/<workflow-slug>/<unit-id>-<role>-<dossier-slug>
-supervisor_checkpoint_cadence: after worker start, terminal report, repair ticket creation, re-verification, and final disposition
+supervisor_checkpoint_cadence: after worker start, native resource id capture, terminal report, native resource close, repair ticket creation, re-verification, and final disposition
+native_worker_lifecycle:
+  required_fields: worker_name, transport, native_resource_id, status, terminal_report, close_action, close_result
+  codex_close_action: close_agent
+  final_outcome_gate: blocked if any native worker lacks close_result
+lean_checkpoint_cadence: after each unit ledger update, at user-selected batch size, on blocker, on risk escalation, and final outcome
+lean_unit_readiness: id, source_ref, scope, done, check, status
+lean_resource_gates: no unapproved subagents, no broad scans unless needed for current unit, one active unit by default, stop or ask when memory/process churn threatens throughput
 final_disposition_policy: from completed intake only; if set to ask_at_end, stop and ask at final disposition
 workflow_unit_blocked_after: first material blocker may stop the unit while the Codex goal remains active
 codex_goal_blocked_after: same material blocker across 3 consecutive goal turns and no meaningful progress
@@ -88,11 +101,21 @@ Do not run units in parallel when they edit the same files, documents, datasets,
 
 ```yaml
 workflow:
+profile:
 intake:
 execution_path:
 mode:
 approval_gates:
 delegation_policy:
+native_worker_lifecycle:
+  required_close_action:
+  open_native_workers:
+lean_policy:
+  ledger:
+  unit_readiness:
+  batch_checkpoint:
+  focused_check:
+  escalation_triggers:
 repair_limit:
 parallel_rules:
 budgets:

package/skills/workflow-docs/SKILL.md

@@ -61,11 +61,12 @@ For documentation work, start with `DOCUMENTATION-BRIEF.md` unless the user prov
 ## Artifact Selection
 
 - `.workflow/WORKFLOW.md`: overall objective, policy, state, units, and next action.
+- `.workflow/LEDGER.md`: compact lean-runner state for large bounded backlogs, with one row per work unit and targeted check evidence.
 - `.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.
+- `.workflow/WORKER-MAP.md`: worker names, roles, transports, native resource ids, dossiers, dependencies, start conditions, report status, close actions, close results, and supervisor checkpoints.
 - `.workflow/ACCEPTANCE-MATRIX.md`: verifiable done criteria.
 - `.workflow/VERIFICATION-REPORT.md`: evidence-backed PASS/FAIL/BLOCKED report.
 - `.workflow/REPAIR-TICKETS.md`: actionable repair tasks from verifier findings.

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

@@ -56,6 +56,39 @@ Stale Artifacts Invalidated:
 ## Next Action
 ```
 
+## LEDGER.md
+
+Use this for `lean_work_unit_runner` when the backlog is already bounded and the workflow needs high throughput with human-verifiable state.
+
+```md
+# Lean Work Unit Ledger
+
+Profile: lean_work_unit_runner
+Execution Path:
+Mode:
+Delegation:
+Final Disposition:
+Batch Checkpoint:
+
+## Scope Contract
+
+Objective:
+Controlling Backlog Or Source:
+Allowed Surfaces:
+Forbidden Surfaces:
+Escalation Triggers:
+
+## Units
+
+| ID | Source Ref | Scope | Done Signal | Check | Status | Touched Surfaces | Evidence | Blocker Or Next Action |
+|---|---|---|---|---|---|---|---|---|
+
+## Batch Checkpoints
+
+| Batch | Units | Result | Checks | Human Review Needed | Next Action |
+|---|---|---|---|---|---|
+```
+
 ## SOURCE-CORPUS.md
 
 ```md
@@ -226,14 +259,16 @@ Notes:
 ```md
 # Worker Map
 
-| Worker Name | Role | Transport | Work Unit | Dossier | Start Condition | Dependencies | Status | Terminal Report |
-|---|---|---|---|---|---|---|---|---|
+| Worker Name | Role | Transport | Native Resource ID | Work Unit | Dossier | Start Condition | Dependencies | Status | Terminal Report | Close Action | Close Result |
+|---|---|---|---|---|---|---|---|---|---|---|---|
 
 ## Supervisor Checkpoints
 
 ## Blocked Workers
 
 ## Closed Workers
+
+Closed means the terminal report has been consumed and any native thread or subagent resource has a recorded close result. For Codex subagents, record the `spawn_agent` id as Native Resource ID and `close_agent` as Close Action. A workflow with open native workers must remain BLOCKED until the close result is recorded.
 ```
 
 ## ACCEPTANCE-MATRIX.md

package/skills/workflow-supervisor/SKILL.md

@@ -1,15 +1,77 @@
 ---
 name: workflow-supervisor
-description: Coordinate supervised multi-agent workflows. Trigger whenever the user explicitly invokes workflow-supervisor, $workflow-supervisor, supervised workflow, dossiers, work units, worker agents, handoffs, approval gates, durable resume, or workflow-state documentation. When explicitly invoked, always run the full strict supervisor workflow regardless of task size; do not downscope, skip human approval or complete intake, skip dossiers, skip work units, skip worker-agent contracts, skip worker handoffs, or skip verification because a task appears simple. When not explicitly invoked, use only for workflows with hard supervisor triggers such as multi-agent handoff, durable resume, high-risk verification, contradictory or missing sources, multi-unit scope, repair loops, approval gates, or workflow-state documentation.
+description: Coordinate supervised workflows with profile-based overhead. Trigger whenever the user explicitly invokes workflow-supervisor, $workflow-supervisor, supervised workflow, lean work-unit runner, dossiers, work units, worker agents, handoffs, approval gates, durable resume, or workflow-state documentation. When explicitly invoked, first select the correct profile: lean_work_unit_runner for large already-bounded backlogs or low-footprint direct execution, strict_full_workflow for ambiguous/high-risk/source-of-truth/delegated work, or planning_only for intake and sequencing. Do not run strict ceremony just because the skill was named. When not explicitly invoked, use only for workflows with hard supervisor triggers such as multi-agent handoff, durable resume, high-risk verification, contradictory or missing sources, multi-unit scope, repair loops, approval gates, or workflow-state documentation.
 ---
 
 # Workflow Supervisor
 
-Use this skill as the coordinating spine for supervised multi-agent work. The supervisor owns decomposition, worker-agent handoff quality, loop discipline, stop gates, and outcome reporting. It may do source discovery and reporting itself, but implementation, verification, repair-ticket writing, and documentation must be treated as separate worker-agent responsibilities when an automated worker path is available. Native threads, subagents, or the portable delegate command are transports for those worker agents.
+Use this skill as the coordinating spine for supervised work. The supervisor owns decomposition, execution profile selection, loop discipline, stop gates, optional worker-agent handoff quality, and outcome reporting. It may do source discovery, implementation, focused verification, and reporting itself in lean mode. In strict mode, implementation, verification, repair-ticket writing, and documentation must be treated as separate worker-agent responsibilities when an automated worker path is available. Native threads, subagents, or the portable delegate command are transports for those worker agents.
 
-## Strict Explicit Invocation Contract
+## Execution Profiles
 
-When the user explicitly invokes `workflow-supervisor`, `$workflow-supervisor`, or says to use this skill, the workflow is in `strict_full_workflow` mode. Task size is irrelevant. Do not decide that a request is too small, too easy, local-only, or single-file to receive the full workflow.
+When the user explicitly invokes `workflow-supervisor`, `$workflow-supervisor`, or says to use this skill, first classify the workflow profile before creating heavy artifacts, goals, worker plans, dossiers, or subagents.
+
+Use `lean_work_unit_runner` when the source already contains bounded work units, tickets, issues, checklist rows, or backlog entries and the user's priority is throughput, low memory, direct execution, or many pure units. Lean mode is for "do the next unit" execution, not for interpreting a broad source of truth from scratch.
+
+Use `strict_full_workflow` when the task is ambiguous, high-risk, source-of-truth driven, regulated, delegated to multiple workers, externally published, security-sensitive, cross-system, or missing clear work-unit boundaries.
+
+Use `planning_only` when the user wants intake, backlog shaping, sequencing, risk review, or a plan without implementation.
+
+If the profile is unclear after reading the user's request and controlling source, ask one profile question and stop. Do not default to strict ceremony merely because the skill was named.
+
+### Lean Work Unit Runner
+
+Lean mode optimizes for large-unit throughput while preserving non-ambiguity and human-verifiable state. It keeps work units as the backbone and removes per-unit ceremony that does not directly improve execution.
+
+Lean mode requires exactly one upfront scope contract before the first unit starts:
+
+- objective and controlling backlog/source
+- selected profile: `lean_work_unit_runner`
+- execution path: `autonomous_goal` or `human_in_loop`
+- execution mode: usually `sequential`; parallel only for proven disjoint surfaces
+- delegation: default `same_session_phased`; workers/subagents only with explicit authorization for a specific batch or risk
+- final disposition and mutation boundaries
+- state medium: one compact ledger, usually inline or `.workflow/LEDGER.md`
+- batch size or checkpoint cadence for human review
+
+Lean mode requires a backlog where each executable unit has:
+
+```yaml
+id:
+source_ref:
+scope:
+done:
+check:
+status: pending | active | pass | fail | blocked | escalated
+notes:
+```
+
+Do not start a lean unit unless its boundary and done signal are clear. If a unit lacks `scope`, `done`, or `check`, mark it `blocked` and ask for the smallest missing decision, or split it into smaller units. Do not hide ambiguity in notes.
+
+Lean per-unit loop:
+
+1. Select the next ready unit from the ledger.
+2. Inspect only the files, artifacts, or source slices needed for that unit.
+3. Apply the smallest implementation that satisfies the unit.
+4. Run the unit's targeted check, or record the exact reason the check is blocked.
+5. Update one ledger row with status, touched surfaces, check result, and residual risk if any.
+6. Continue to the next ready unit until the batch checkpoint, blocker, resource gate, or final disposition.
+
+Lean mode must not create per-unit SPEC files, full dossiers, worker maps, repair-ticket documents, or documenter passes by default. Use inline unit contracts and one compact ledger. Batch documentation and outcome reporting at checkpoints or final closeout.
+
+Escalate a lean unit to `strict_full_workflow` or pause for human review when:
+
+- source requirements conflict or are materially incomplete
+- the unit touches broad architecture, security, data loss, credentials, production systems, billing, legal/compliance, public API contracts, migrations, or destructive operations
+- the unit cannot name a targeted check or human-inspectable evidence
+- multiple units unexpectedly touch the same shared surface and need re-sequencing
+- repair repeats without new evidence
+- the user asks for independent verification, subagents, PR, deploy, publish, or external-service action
+- memory, process count, broad scans, or context churn threatens execution throughput
+
+Lean verification is proportional. Use `focused-check` for the unit or batch. Use `independent-verifier` only when a risk trigger or user instruction justifies the extra cost. A lean PASS requires the ledger to show every completed unit's source reference, done signal, check or substitute evidence, and touched surfaces.
+
+### Strict Full Workflow
 
 Strict mode always requires:
 
@@ -22,13 +84,13 @@ Strict mode always requires:
 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`.
+10. A worker lifecycle record using `planned -> handed_off -> acknowledged -> reported -> verified -> resource_closed -> 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.
+Worker agents are mandatory when strict mode is selected and the environment provides worker, subagent, thread, or portable delegation tools with a complete lifecycle: start, terminal report collection, and resource close. 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.
 
-If the environment cannot create, message, or delegate to worker agents, record `worker_agent_unavailable` and stop for the human decision unless completed intake explicitly selected `same_session_phased`. Do not silently collapse worker agents into same-session work.
+If the environment cannot create, message, delegate to, and close worker agents, record `worker_agent_unavailable` or `worker_resource_close_unavailable` and stop for the human decision unless completed intake explicitly selected `same_session_phased`. Do not silently collapse worker agents into same-session work.
 
 Do not nest supervisors recursively. A worker agent that receives a supervisor-scoped dossier must perform its assigned role instead of spawning another supervisor layer unless the parent supervisor explicitly asks for a child supervisor.
 
@@ -141,12 +203,14 @@ When the human answers:
 - Run the complete intake gate before goal creation, worker delegation, implementation, publication, or other irreversible action.
 - 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.
+- Explicit invocation always requires profile selection before heavy planning. `strict_full_workflow` requires complete intake, work units, dossiers, worker-agent contracts, scoped handoffs, report schema, and verification. `lean_work_unit_runner` requires an upfront scope contract, bounded work units, a compact ledger, focused checks, and escalation gates instead of full per-unit ceremony.
 - 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.
+- Do not begin strict 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.
+- Do not begin lean implementation until the scope contract is recorded, the backlog contains at least one ready unit, the compact ledger exists or can be kept inline, the current unit has source reference, scope, done signal, and check, and no escalation 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`.
 - Do not start implementer, verifier, repair-author, or documenter workers before complete intake and the path gate are satisfied; role-specific start conditions are additional gates after that.
+- Do not use native thread or native subagent workers unless the environment exposes a close operation for that transport. For Codex subagents, the supervisor must call `close_agent` for every `spawn_agent` id after the worker reaches a terminal report, times out, blocks, fails validation, is cancelled, or is no longer needed.
 - Keep roles separate: implementers implement, verifiers verify, repair authors write tickets, documenters update workflow artifacts, and the supervisor coordinates.
 - 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.
@@ -165,11 +229,26 @@ Treat these as distinct mechanisms:
 - Skill: reusable instructions loaded into the current agent.
 - Worker: a role-scoped automated execution run that receives one dossier and returns one terminal report.
 - Portable worker delegation: the package helper command, `workflow-supervisor delegate --agent <agent> --role <role> --unit <unit-id> --cwd <workspace> --dossier <path>`, which invokes an installed platform CLI and normalizes its report.
-- Native thread or subagent: an environment-specific transport a worker adapter may use when it is available and authorized.
+- Native thread or subagent: an environment-specific transport a worker adapter may use only when it can also close the native worker resource after use.
 - Same-session phased mode: the current agent performs roles sequentially. Verification in this mode is a self-check, not independent verification.
 
 Start workers only after complete intake and the path gate are satisfied, at least one work unit exists, a concrete dossier exists, the loop policy authorizes delegation, and the environment exposes an automated supported transport. If environment rules require explicit user approval for user-visible native thread creation, obtain it before using that transport. Do not use manual copy/paste handoff as the primary path. If automated delegation is unavailable, mark the unit `worker_agent_unavailable` unless completed intake explicitly selected same-session phased work.
 
+### Native Worker Resource Lifecycle
+
+Logical worker completion is not enough for native thread or subagent transports. A worker is not `closed` until its native resource has also been released.
+
+For every native worker:
+
+1. Record the native resource id immediately after creation, such as the Codex `agent_id` returned by `spawn_agent`, in the worker map.
+2. Record transport, worker name, role, work unit, dossier, start time, and close requirement before waiting on the worker.
+3. Collect one terminal report or mark the worker `BLOCKED` because of timeout, invalid output, unavailable adapter, cancellation, or missing evidence.
+4. Call the native close operation as soon as the terminal report or blocker is captured. For Codex subagents, call `close_agent` with the recorded `agent_id`.
+5. Record the close result and previous native status. Only then move the worker to `resource_closed` and then `closed`.
+6. Before final workflow outcome, audit the worker map. If any native worker has no close result, final status is `BLOCKED` with reason `open_native_worker`.
+
+Native worker ids are resource handles, not evidence. Do not use a completed worker report, a subagent notification, or a wait result as a substitute for closing the native worker. If the close operation fails or is unavailable, stop and report `worker_resource_close_failed` or `worker_resource_close_unavailable`; do not keep spawning replacement workers.
+
 ## Worker Report Schema
 
 Every worker report back to the supervisor must use this schema:
@@ -201,6 +280,7 @@ Do not use keywords to skip intake. Words such as "autonomous", "agent loop", "w
 Required intake decisions:
 
 - Objective and source: what artifact, spec, repo path, document, ticket, or source set controls the work.
+- Profile: `lean_work_unit_runner`, `strict_full_workflow`, or `planning_only`.
 - Execution path: `autonomous_goal` or `human_in_loop`.
 - Execution mode: `sequential`, `parallel_where_safe`, or `staged_parallel`.
 - Delegation: `automated_worker_delegation`, `native_threads_or_subagents_if_available`, or `same_session_phased`.
@@ -215,53 +295,64 @@ Use this question shape for the first intake ask:
 ```text
 Before I start the supervisor loop, answer every intake item:
 1. Objective and source: what artifact, spec, repo path, document, ticket, or source set controls the work?
-2. Execution path: autonomous_goal or human_in_loop?
-3. Mode: sequential, parallel where safe, or staged parallel?
-4. Delegation: automated worker delegation, native threads/subagents if available, or same-session phased?
-5. Final disposition: keep local, open PR, push main, deploy/publish, or ask at the end?
-6. Boundaries: may I install dependencies, call external services, use credentials, or only edit local files?
-7. State artifacts: create `.workflow/` docs, use another artifact directory, or keep state inline?
+2. Profile: lean_work_unit_runner, strict_full_workflow, or planning_only?
+3. Execution path: autonomous_goal or human_in_loop?
+4. Mode: sequential, parallel where safe, or staged parallel?
+5. Delegation: same-session phased, automated worker delegation, or native threads/subagents if available?
+6. Final disposition: keep local, open PR, push main, deploy/publish, or ask at the end?
+7. Boundaries: may I install dependencies, call external services, use credentials, or only edit local files?
+8. State artifacts: compact ledger, `.workflow/` docs, another artifact directory, or inline state?
 ```
 
 If the user answers only some intake items, ask only the unanswered or ambiguous item(s) again and stop. If the user says "use your judgment", treat that item as unanswered; do not substitute defaults. Continue prompting until every required intake decision has an explicit user answer.
 
-Treat `autonomous_goal`, PR creation, direct push, deploy, publication, paid operations, production data changes, and credential use as satisfied only by completed intake answers, not by keywords elsewhere in the prompt.
+Treat `strict_full_workflow`, `autonomous_goal`, PR creation, direct push, deploy, publication, paid operations, production data changes, and credential use as satisfied only by completed intake answers or an explicit profile selection, not by vague keywords elsewhere in the prompt.
 
 Negative example: "Using Workflow Supervisor, generate an API and create the project" is not autonomous authorization and is not complete intake. It names the supervisor and objective, but leaves required intake decisions unresolved. Ask the complete intake packet and stop before implementation.
 
 ## Supervisor Loop
 
 1. Run the complete intake gate. Record explicit user answers. If any required intake answer is missing, vague, or delegated to judgment, ask for the unresolved item(s) and stop.
-2. Restate the objective, constraints, non-goals, known sources, and unknowns from the completed intake.
+2. Restate the selected profile, 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. 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:
+4. If the profile is `lean_work_unit_runner`, run the lean loop:
+   - Confirm the source contains bounded work units or create a short upfront backlog contract. If not possible, pause for a decision or switch to `planning_only` or `strict_full_workflow`.
+   - Create or select one compact ledger instead of full workflow docs.
+   - Verify each ready unit has `id`, `source_ref`, `scope`, `done`, `check`, and `status`.
+   - Present a concise batch plan in `human_in_loop`, or continue in `autonomous_goal` when intake permits it.
+   - Execute one unit at a time with targeted inspection, smallest patch, focused check, ledger update, and checkpoint cadence.
+   - Escalate only the affected unit or batch when a strict-mode trigger appears; do not convert the whole backlog to strict mode unless the source contract is invalid.
+   - Finish with a compact outcome naming units completed, blocked, failed, escalated, checks, skipped checks, residual risks, and final disposition.
+5. If the profile is `planning_only`, stop after source grounding, backlog shape, risks, recommended profile, and approval questions. Do not implement.
+6. If the profile is `strict_full_workflow`, continue the strict loop below.
+7. Build or request a source corpus map. Use `$source-corpus` when source authority, freshness, or contradictions matter.
+8. 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.
+9. Create the SPEC review packet or `.workflow/SPEC.md` from the source corpus and coverage ledger.
+10. 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.
+11. 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`.
+12. 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.
+13. 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.
+14. Assign worker roles with explicit allowed and forbidden behavior. Use `$worker-roles` for multi-agent, native-thread, or portable-worker work.
+15. 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.
-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:
+16. If `.workflow/` artifacts will be used in a Git-backed codebase, ensure `.gitignore` contains `.workflow/` before writing them.
+17. 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.
-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:
+18. 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. For native threads or subagents, record the native resource id immediately and confirm a close operation exists before starting more workers.
+19. 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. For native threads or subagents, close the native resource after the report or blocker is captured.
+20. Verify independently where possible. Use `$acceptance-matrix` to map every requirement to evidence. Start verifier workers only after the relevant implementer report is available.
+21. 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.
+22. Re-run verification after repairs. Continue only until PASS, BLOCKED, repair limit, or path stop.
+23. Start documenter workers only after source, implementation, verification, or repair evidence exists, unless the documenter is explicitly creating planning state.
+24. 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.
+25. Use `$workflow-docs` to create or refresh reusable Markdown artifacts under `<workspace>/.workflow/` when the workflow must persist across context loss, agents, or sessions.
+26. 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.
+27. 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.
-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.
+28. Finish with an outcome report that names profile, execution path, goal status, sources, SPEC decision when strict, coverage or ledger disposition, work units, delegated workers or same-session execution, native worker close status, checks, skipped checks, residual risks, final disposition decision, and next action.
 
 ## Execution Paths
 
@@ -269,7 +360,9 @@ 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 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:
+In `lean_work_unit_runner`, the first review deliverable is the scope contract plus compact ledger and batch checkpoint policy. Stop for approval before the first batch unless the user explicitly selected autonomous execution.
+
+In `strict_full_workflow`, 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
@@ -298,6 +391,8 @@ Use `autonomous_goal` only when the completed intake selects it. Phrases such as
 - stop gates, repair limits, budgets, and escalation rules
 - final disposition policy: `open_pr_when_green`, `push_main_when_green`, or `keep_local_when_green`
 
+For `lean_work_unit_runner`, replace SPEC, coverage-ledger, and worker-delegation details with the scope contract, compact ledger path, unit readiness fields, batch checkpoint cadence, resource gates, focused-check policy, and strict-mode escalation triggers.
+
 The final disposition must come from the completed intake. Direct push to the main branch, PR creation, deploy, publication, paid operations, production data changes, credential use, and destructive operations require explicit answers in the relevant intake fields.
 
 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.
@@ -306,7 +401,7 @@ When `autonomous_goal` stops for a human decision, it should usually leave the C
 
 ## Portable Worker Delegation
 
-After the path gate is satisfied, use the selected automated worker transport. The portable default is the package helper:
+After the path gate is satisfied, use the selected automated worker transport. Prefer the portable delegate path when it satisfies the work because it is one-shot and does not leave a native thread or subagent resource open. The portable default is the package helper:
 
 ```text
 workflow-supervisor delegate --agent <agent> --role <role> --unit <unit-id> --cwd <workspace> --dossier <path>
@@ -320,7 +415,7 @@ workflow-supervisor validate-dossier <path> --role <role> --unit <unit-id> --jso
 
 If the dossier does not pass `DossierV1` validation, do not start the worker. Create a discovery dossier, ask for the missing decision, or mark the unit BLOCKED.
 
-Adapters may use native threads, native subagents, or one-shot CLI execution underneath, but the supervisor consumes only the normalized worker report. Use `workflow-supervisor delegate-doctor --agent <agent> --probe` to test the installed local adapter before relying on it for a workflow. If automated delegation is unavailable, mark execution as `worker_agent_unavailable` unless completed intake selected `same_session_phased`.
+Adapters may use native threads, native subagents, or one-shot CLI execution underneath, but the supervisor consumes only the normalized worker report plus the transport lifecycle result. Use `workflow-supervisor delegate-doctor --agent <agent> --probe` to test the installed local adapter before relying on it for a workflow. If automated delegation is unavailable, mark execution as `worker_agent_unavailable` unless completed intake selected `same_session_phased`. If native delegation is available but native close is unavailable, mark execution as `worker_resource_close_unavailable` and choose portable delegation or same-session phased only when intake permits it.
 
 Name workers deterministically from the workflow, unit, role, and dossier:
 
@@ -342,7 +437,7 @@ Use one worker per role per work unit unless the loop policy explicitly allows b
 - kickoff: role, dossier, sources, acceptance rows, stop gates, report schema
 - checkpoint: request status, blockers, or clarification without expanding scope
 - repair delegation: failed rows, verifier findings, allowed repair surfaces, checks
-- closeout: collect terminal report and confirm no further action is expected
+- closeout: collect terminal report, close any native worker resource, and confirm no further action is expected
 
 Workers must not ask the human questions directly, choose final disposition, approve plans, expand scope, or message each other. They return `PASS`, `FAIL`, or `BLOCKED` using the assigned report schema. The supervisor routes blockers, repairs, and human questions.
 
@@ -379,10 +474,13 @@ If any item is unknown and material, stop and ask for the missing decision or ma
 
 Stop when:
 
+- the profile is missing or unclear and cannot be selected from explicit user intent plus controlling source
 - any required intake answer is missing, vague, delegated to judgment, or contradicted by another intake answer
 - source authority cannot be established
 - sources contradict each other on a material requirement
 - the requested scope cannot fit into a bounded work unit
+- `lean_work_unit_runner` is selected but the backlog lacks clear unit ids, source references, boundaries, done signals, or targeted checks
+- `lean_work_unit_runner` finds a strict-mode risk trigger and the user has not authorized escalation, deferral, or a narrower 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
@@ -395,6 +493,7 @@ Stop when:
 - the selected path is `autonomous_goal` but it was inferred from prompt wording instead of a completed intake answer
 - an irreversible action is requested without explicit authorization in the completed intake
 - a worker asks to expand scope without supervisor or human approval
+- a native thread or subagent worker has no recorded close result
 - final verification is not green and no waiver evidence exists
 - residual risks, skipped checks, future work, or next actions contain unimplemented material source requirements
 
@@ -403,18 +502,20 @@ Stop when:
 Report:
 
 - Status: PASS, FAIL, BLOCKED, or PARTIAL
+- Profile: lean_work_unit_runner, strict_full_workflow, or planning_only
 - Execution path: autonomous_goal or human_in_loop
 - 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
+- Work units completed, blocked, failed, escalated, or remaining
+- Compact ledger path or inline ledger summary when in lean mode
 - 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
+- Worker lifecycle status for each role, including native resource ids and close results when native threads or subagents were used
 - Verification evidence
 - Repairs performed or recommended
 - Checks run and skipped

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. 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."
+  short_description: "Run lean, strict, or planning-only supervised workflows"
+  default_prompt: "Use $workflow-supervisor to select the execution profile first: lean_work_unit_runner for large bounded backlogs and low-footprint direct execution, strict_full_workflow for ambiguous/high-risk/delegated work, or planning_only for sequencing without implementation. Ask required intake questions and stop until the user explicitly answers all missing items. Do not infer path, mode, delegation, final disposition, or boundaries from vague keywords. In lean mode, keep work units and a compact ledger, avoid subagents unless explicitly authorized, run targeted checks, and escalate unclear or risky units. In strict mode, 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. Prefer one-shot portable delegation when it satisfies the work. If native threads or subagents are used, record each native resource id, call the native close action such as close_agent after terminal report or blocker capture, and block final outcome if any native worker lacks a close result."
 
 policy:
   allow_implicit_invocation: false