workflow-supervisor 0.1.1 → 0.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +397 -317
- package/bin/workflow-skills.mjs +3 -2
- package/docs/skill-reference.md +5 -5
- package/docs/troubleshooting.md +16 -0
- package/package.json +1 -1
- package/skills/acceptance-matrix/SKILL.md +29 -2
- package/skills/loop-policy/SKILL.md +5 -2
- package/skills/work-unit/SKILL.md +19 -0
- package/skills/workflow-docs/SKILL.md +2 -1
- package/skills/workflow-docs/references/goal-resume.md +48 -3
- package/skills/workflow-docs/references/templates.md +2 -0
- package/skills/workflow-docs/references/workflow-control.md +149 -0
- package/skills/workflow-supervisor/SKILL.md +174 -27
- package/skills/workflow-supervisor/agents/openai.yaml +1 -1
package/bin/workflow-skills.mjs
CHANGED
|
@@ -8,8 +8,9 @@ import { fileURLToPath } from "node:url";
|
|
|
8
8
|
|
|
9
9
|
const __dirname = path.dirname(fileURLToPath(import.meta.url));
|
|
10
10
|
const packageRoot = path.resolve(__dirname, "..");
|
|
11
|
-
const
|
|
12
|
-
const
|
|
11
|
+
const packageJson = JSON.parse(fs.readFileSync(path.join(packageRoot, "package.json"), "utf8"));
|
|
12
|
+
const PACKAGE_NAME = packageJson.name || "workflow-supervisor";
|
|
13
|
+
const PACKAGE_VERSION = packageJson.version;
|
|
13
14
|
const WORKER_REPORT_SCHEMA_PATH = path.join(packageRoot, "schemas", "worker-report-v1.schema.json");
|
|
14
15
|
const DOSSIER_SCHEMA_PATH = path.join(packageRoot, "schemas", "dossier-v1.schema.json");
|
|
15
16
|
const ADAPTERS_ROOT = path.join(packageRoot, "adapters");
|
package/docs/skill-reference.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
## `workflow-supervisor`
|
|
4
4
|
|
|
5
|
-
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,
|
|
5
|
+
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.
|
|
6
6
|
|
|
7
7
|
## `source-corpus`
|
|
8
8
|
|
|
@@ -10,7 +10,7 @@ Rank and reconcile sources when authority, freshness, contradictions, access rig
|
|
|
10
10
|
|
|
11
11
|
## `work-unit`
|
|
12
12
|
|
|
13
|
-
Split broad work into bounded units with objective, scope, dependencies, readiness, done criteria, verification, sequencing, and parallel-safety notes.
|
|
13
|
+
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.
|
|
14
14
|
|
|
15
15
|
## `dossier-builder`
|
|
16
16
|
|
|
@@ -22,12 +22,12 @@ Define role contracts and solo-mode phase separation. It prevents role bleed: ve
|
|
|
22
22
|
|
|
23
23
|
## `acceptance-matrix`
|
|
24
24
|
|
|
25
|
-
Create formal evidence-mapped acceptance rows for high-risk, supervised, ambiguous, resumable, or delegated workflows.
|
|
25
|
+
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.
|
|
26
26
|
|
|
27
27
|
## `loop-policy`
|
|
28
28
|
|
|
29
|
-
Define execution path, execution mode, worker delegation, approval gates, repair limits, parallel safety, no-progress rules, and Codex goal tool policy.
|
|
29
|
+
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.
|
|
30
30
|
|
|
31
31
|
## `workflow-docs`
|
|
32
32
|
|
|
33
|
-
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.
|
|
33
|
+
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
CHANGED
|
@@ -27,6 +27,22 @@ Use `$workflow-docs` with a minimal artifact request. The skill must reject "cre
|
|
|
27
27
|
|
|
28
28
|
Use `$acceptance-matrix` for formal evidence rows. A PASS requires row-by-row evidence or explicit waiver evidence.
|
|
29
29
|
|
|
30
|
+
## A broad roadmap becomes one giant work unit
|
|
31
|
+
|
|
32
|
+
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.
|
|
33
|
+
|
|
34
|
+
## Residual risks contain required work
|
|
35
|
+
|
|
36
|
+
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.
|
|
37
|
+
|
|
38
|
+
## Humans need to review scope before work units
|
|
39
|
+
|
|
40
|
+
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.
|
|
41
|
+
|
|
42
|
+
## Autonomous workflow paused for a human decision
|
|
43
|
+
|
|
44
|
+
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.
|
|
45
|
+
|
|
30
46
|
## An existing skill folder blocks install
|
|
31
47
|
|
|
32
48
|
Use:
|
package/package.json
CHANGED
|
@@ -15,15 +15,39 @@ This skill owns evidence rows and supervisor verdict mapping. `$work-unit` may d
|
|
|
15
15
|
|
|
16
16
|
- Every requirement needs evidence.
|
|
17
17
|
- Evidence must name a source, command, artifact, UI state, test, inspection, or user decision.
|
|
18
|
+
- Acceptance rows must preserve the source requirement's strength: named systems, quantities, live/integration wording, exit criteria, and "must" language.
|
|
19
|
+
- A weaker proxy check is not equivalent evidence unless the user explicitly waives or narrows the original requirement.
|
|
18
20
|
- PASS requires all material rows to be satisfied or explicitly waived by the user.
|
|
19
21
|
- FAIL requires at least one material row with unmet evidence.
|
|
20
22
|
- BLOCKED applies when evidence cannot be obtained or sources conflict.
|
|
21
23
|
- Residual risks must not be hidden inside PASS.
|
|
24
|
+
- 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.
|
|
25
|
+
|
|
26
|
+
## Source Fidelity Rules
|
|
27
|
+
|
|
28
|
+
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:
|
|
29
|
+
|
|
30
|
+
- named integrations or providers
|
|
31
|
+
- corpus sizes, question counts, coverage thresholds, or latency/cost budgets
|
|
32
|
+
- "live" versus artifact-only behavior
|
|
33
|
+
- required data sources, credentials, services, or indexes
|
|
34
|
+
- roadmap phase exit criteria
|
|
35
|
+
- mandatory checks, screenshots, reports, or review states
|
|
36
|
+
|
|
37
|
+
Do not downgrade requirements while making them testable. Examples of invalid substitutions:
|
|
38
|
+
|
|
39
|
+
- live service load/query verification -> generated export file only
|
|
40
|
+
- required validation corpus size -> small starter fixture
|
|
41
|
+
- named provider support -> generic extension hook
|
|
42
|
+
- required analysis and report generation -> keyword metadata only
|
|
43
|
+
- provider-backed extraction or indexing -> deterministic placeholder logic
|
|
44
|
+
|
|
45
|
+
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.
|
|
22
46
|
|
|
23
47
|
## Row Shape
|
|
24
48
|
|
|
25
|
-
| ID | Requirement | Evidence Required | Verification Method | Adversarial Check | Status | Evidence |
|
|
26
|
-
|
|
49
|
+
| ID | Source Ref | Requirement | Evidence Required | Verification Method | Adversarial Check | Status | Evidence |
|
|
50
|
+
|---|---|---|---|---|---|---|---|
|
|
27
51
|
|
|
28
52
|
Use statuses: Pending, PASS, FAIL, BLOCKED, Waived.
|
|
29
53
|
|
|
@@ -46,6 +70,9 @@ Consider:
|
|
|
46
70
|
- missing citation or unsupported claim
|
|
47
71
|
- document structure regression
|
|
48
72
|
- stakeholder requirement omitted
|
|
73
|
+
- source requirement weakened or omitted
|
|
74
|
+
- roadmap exit criteria demoted to future work
|
|
75
|
+
- material requirement hidden in residual risks
|
|
49
76
|
- artifact cannot be reused by a fresh agent or human
|
|
50
77
|
|
|
51
78
|
## Verification Report Shape
|
|
@@ -21,7 +21,8 @@ For loop-oriented supervisor work, define how the workflow uses Codex goals afte
|
|
|
21
21
|
- goal_state_mirror_cadence: each work unit, each verification result, each repair loop, and final outcome
|
|
22
22
|
- goal_completion_rule: evidence required before completion
|
|
23
23
|
- goal_blocked_rule: same material blocker across the required consecutive goal turns and no meaningful progress
|
|
24
|
-
- goal_resume_rule: read active goal before workflow docs,
|
|
24
|
+
- goal_resume_rule: read active goal before workflow docs, reconcile state, and continue from the recorded next action after human decisions
|
|
25
|
+
- human_decision_resume_rule: ask the smallest blocking decision, update state, invalidate only affected downstream artifacts, and resume without restarting intake unless intake changed
|
|
25
26
|
|
|
26
27
|
Do not create goals for small direct tasks. A goal is the state container for open-ended loops, not a wrapper around every command.
|
|
27
28
|
|
|
@@ -36,7 +37,7 @@ Do not create goals for small direct tasks. A goal is the state container for op
|
|
|
36
37
|
- Budget: time, token, command, cost, or file-change limits.
|
|
37
38
|
- Escalation: when to ask the user, delegate to a specialist worker, or stop.
|
|
38
39
|
- Completion: evidence required before marking done.
|
|
39
|
-
- Resume: artifacts needed before pausing or
|
|
40
|
+
- Resume: artifacts needed before pausing, compacting, or waiting for a human decision.
|
|
40
41
|
- Mutation conflict: whether units touch the same mutable surfaces or decisions.
|
|
41
42
|
|
|
42
43
|
## Default Policy
|
|
@@ -63,6 +64,7 @@ workflow_unit_blocked_after: first material blocker may stop the unit while the
|
|
|
63
64
|
codex_goal_blocked_after: same material blocker across 3 consecutive goal turns and no meaningful progress
|
|
64
65
|
completion_requires: acceptance evidence plus residual risk report
|
|
65
66
|
resume_requires: workflow state or outcome doc for long workflows
|
|
67
|
+
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
|
|
66
68
|
missing_prerequisites: discovery-first, not failure
|
|
67
69
|
goal_start: after complete intake only; create only when completed intake and environment authorize goal binding, otherwise mirror state in docs
|
|
68
70
|
goal_state_mirror_cadence: after unit terminal states and final outcome
|
|
@@ -98,6 +100,7 @@ escalation_rules:
|
|
|
98
100
|
stop_gates:
|
|
99
101
|
completion_rule:
|
|
100
102
|
resume_artifacts:
|
|
103
|
+
human_decision_resume_rule:
|
|
101
104
|
goal_policy:
|
|
102
105
|
final_disposition_policy:
|
|
103
106
|
```
|
|
@@ -43,6 +43,23 @@ Work-unit drafts coarse done criteria only. Use `$acceptance-matrix` when those
|
|
|
43
43
|
|
|
44
44
|
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.
|
|
45
45
|
|
|
46
|
+
## One-Pass Collapse Guard
|
|
47
|
+
|
|
48
|
+
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.
|
|
49
|
+
|
|
50
|
+
Treat these as separate-unit signals:
|
|
51
|
+
|
|
52
|
+
- roadmap phases or milestones
|
|
53
|
+
- multiple external data sources, providers, services, or credentials
|
|
54
|
+
- live system integration plus local artifact fallback
|
|
55
|
+
- extraction/indexing/retrieval/evaluation/reporting layers with different evidence needs
|
|
56
|
+
- numeric targets such as corpus size, eval question count, latency budget, or coverage threshold
|
|
57
|
+
- implementation work that would otherwise be described as residual risk, future work, or next recommended action
|
|
58
|
+
|
|
59
|
+
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.
|
|
60
|
+
|
|
61
|
+
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.
|
|
62
|
+
|
|
46
63
|
## Output Shape
|
|
47
64
|
|
|
48
65
|
```yaml
|
|
@@ -60,10 +77,12 @@ units:
|
|
|
60
77
|
forbidden_surfaces:
|
|
61
78
|
readiness:
|
|
62
79
|
done_criteria:
|
|
80
|
+
source_requirements_covered:
|
|
63
81
|
verification:
|
|
64
82
|
sequence:
|
|
65
83
|
parallel_groups:
|
|
66
84
|
blocked_units:
|
|
85
|
+
deferred_or_out_of_scope_requirements:
|
|
67
86
|
first_recommended_unit:
|
|
68
87
|
```
|
|
69
88
|
|
|
@@ -62,6 +62,7 @@ For documentation work, start with `DOCUMENTATION-BRIEF.md` unless the user prov
|
|
|
62
62
|
|
|
63
63
|
- `.workflow/WORKFLOW.md`: overall objective, policy, state, units, and next action.
|
|
64
64
|
- `.workflow/SOURCE-CORPUS.md`: source map, authority ranking, contradictions, gaps.
|
|
65
|
+
- `.workflow/SPEC.md`: human-reviewable interpretation contract, requirement coverage, Q&A, and approval decision before final work units.
|
|
65
66
|
- `.workflow/WORK-UNITS.md`: decomposition and sequencing.
|
|
66
67
|
- `.workflow/DOSSIER.md`: delegation contract for one unit.
|
|
67
68
|
- `.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
|
|
|
71
72
|
- `.workflow/DECISIONS.md`: durable decisions, assumptions, and reversals.
|
|
72
73
|
- `.workflow/HANDOFF.md`: resume state for another agent or session.
|
|
73
74
|
- `.workflow/OUTCOME.md`: final status, checks, risks, and next step.
|
|
74
|
-
- `.workflow/GOAL-STATE.md`: optional fallback
|
|
75
|
+
- `.workflow/GOAL-STATE.md`: optional fallback or mirror for Codex goal state, terminal blocked-goal history, and human-decision resume checkpoints.
|
|
75
76
|
- `.workflow/DOCUMENTATION-BRIEF.md`: audience, purpose, document type, reader task, channel, owner, approvers, and success criteria.
|
|
76
77
|
- `.workflow/CONTENT-INVENTORY.md`: existing materials, reusable sections, gaps, stale areas, and owners.
|
|
77
78
|
- `.workflow/OUTLINE.md`: information architecture, section hierarchy, and required content.
|
|
@@ -12,19 +12,28 @@ In Git-backed codebases, ensure `<workspace>/.gitignore` contains `.workflow/` b
|
|
|
12
12
|
## Goal Binding
|
|
13
13
|
|
|
14
14
|
- Goal Binding: created | reused | skipped | unavailable | conflict
|
|
15
|
-
- Goal Status: active | complete | blocked | unknown
|
|
15
|
+
- Goal Status: active | complete | blocked | blocked old | unknown
|
|
16
16
|
- Last Goal Tool Action: get_goal | create_goal | update_goal | none
|
|
17
17
|
- Next Allowed Goal Action:
|
|
18
18
|
- Goal Objective:
|
|
19
|
+
- Previous Blocked Goal Reference:
|
|
20
|
+
- Human Decision Needed:
|
|
21
|
+
- Human Decision Answer:
|
|
22
|
+
- Resume From:
|
|
23
|
+
- Artifacts To Refresh:
|
|
24
|
+
- Stale Artifacts Invalidated:
|
|
19
25
|
```
|
|
20
26
|
|
|
21
27
|
## Goal-Aware OUTCOME.md Fields
|
|
22
28
|
|
|
23
29
|
```md
|
|
24
30
|
Goal Binding: created | reused | skipped | unavailable | conflict
|
|
25
|
-
Goal Status: active | complete | blocked | unknown
|
|
31
|
+
Goal Status: active | complete | blocked | blocked old | unknown
|
|
26
32
|
Last Goal Tool Action: get_goal | create_goal | update_goal | none
|
|
27
33
|
Next Allowed Goal Action:
|
|
34
|
+
Previous Blocked Goal Reference:
|
|
35
|
+
Resume From:
|
|
36
|
+
Human Decision Resume Status:
|
|
28
37
|
```
|
|
29
38
|
|
|
30
39
|
## GOAL-STATE.md
|
|
@@ -40,10 +49,18 @@ created | reused | skipped | unavailable | conflict
|
|
|
40
49
|
|
|
41
50
|
## Goal Status
|
|
42
51
|
|
|
43
|
-
active | complete | blocked | unknown
|
|
52
|
+
active | complete | blocked | blocked old | unknown
|
|
44
53
|
|
|
45
54
|
## Why A Goal Was Created Or Skipped
|
|
46
55
|
|
|
56
|
+
## Previous Blocked Goal
|
|
57
|
+
|
|
58
|
+
Goal Reference:
|
|
59
|
+
|
|
60
|
+
Reason:
|
|
61
|
+
|
|
62
|
+
Use As History Only: yes | no
|
|
63
|
+
|
|
47
64
|
## Active Goal Conflict
|
|
48
65
|
|
|
49
66
|
## Last Tool Action
|
|
@@ -56,9 +73,37 @@ get_goal | create_goal | update_goal | none
|
|
|
56
73
|
|
|
57
74
|
## Current Work Unit
|
|
58
75
|
|
|
76
|
+
## Current Blocker
|
|
77
|
+
|
|
78
|
+
## Human Decision Needed
|
|
79
|
+
|
|
80
|
+
Question:
|
|
81
|
+
|
|
82
|
+
Smallest Sufficient Answer:
|
|
83
|
+
|
|
84
|
+
## Human Decision Answer
|
|
85
|
+
|
|
86
|
+
Answer:
|
|
87
|
+
|
|
88
|
+
Decision Type: clarification | scope change | requirement waiver | explicit deferral | blocker resolution | final disposition | intake change | workflow cancellation
|
|
89
|
+
|
|
90
|
+
## Resume Checkpoint
|
|
91
|
+
|
|
92
|
+
Last Completed Step:
|
|
93
|
+
|
|
94
|
+
Next Action:
|
|
95
|
+
|
|
96
|
+
Artifacts To Refresh:
|
|
97
|
+
|
|
98
|
+
Stale Artifacts Invalidated:
|
|
99
|
+
|
|
59
100
|
## Completion Rule
|
|
60
101
|
|
|
61
102
|
## Blocked Rule
|
|
62
103
|
|
|
63
104
|
## Resume Instructions
|
|
64
105
|
```
|
|
106
|
+
|
|
107
|
+
## Human Decision Resume Rule
|
|
108
|
+
|
|
109
|
+
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.
|
|
@@ -34,6 +34,7 @@ Includes:
|
|
|
34
34
|
|
|
35
35
|
- `WORKFLOW.md`
|
|
36
36
|
- `SOURCE-CORPUS.md`
|
|
37
|
+
- `SPEC.md`
|
|
37
38
|
- `WORK-UNITS.md`
|
|
38
39
|
- `DOSSIER.md`
|
|
39
40
|
- `WORKER-MAP.md`
|
|
@@ -42,6 +43,7 @@ Includes:
|
|
|
42
43
|
- `REPAIR-TICKETS.md`
|
|
43
44
|
- `DECISIONS.md`
|
|
44
45
|
- `HANDOFF.md`
|
|
46
|
+
- `GOAL-STATE.md`
|
|
45
47
|
- `OUTCOME.md`
|
|
46
48
|
|
|
47
49
|
## Goal And Resume
|
|
@@ -38,6 +38,21 @@ Git rule: in a Git-backed codebase, ensure `<workspace>/.gitignore` contains `.w
|
|
|
38
38
|
|
|
39
39
|
## Stop Gates
|
|
40
40
|
|
|
41
|
+
## Blocking Decision
|
|
42
|
+
|
|
43
|
+
| ID | Blocked Artifact | Question | Affected Requirements | Affected Work Units | Status | Answer Source |
|
|
44
|
+
|---|---|---|---|---|---|---|
|
|
45
|
+
|
|
46
|
+
## Resume Checkpoint
|
|
47
|
+
|
|
48
|
+
Last Completed Step:
|
|
49
|
+
|
|
50
|
+
Next Action:
|
|
51
|
+
|
|
52
|
+
Artifacts To Refresh:
|
|
53
|
+
|
|
54
|
+
Stale Artifacts Invalidated:
|
|
55
|
+
|
|
41
56
|
## Next Action
|
|
42
57
|
```
|
|
43
58
|
|
|
@@ -65,6 +80,80 @@ Git rule: in a Git-backed codebase, ensure `<workspace>/.gitignore` contains `.w
|
|
|
65
80
|
## Allowed Next Action
|
|
66
81
|
```
|
|
67
82
|
|
|
83
|
+
## SPEC.md
|
|
84
|
+
|
|
85
|
+
```md
|
|
86
|
+
# SPEC
|
|
87
|
+
|
|
88
|
+
Status: Draft | Approved | Needs Revision | Blocked
|
|
89
|
+
|
|
90
|
+
## Objective
|
|
91
|
+
|
|
92
|
+
## Source Of Truth
|
|
93
|
+
|
|
94
|
+
| Source | Role | Notes |
|
|
95
|
+
|---|---|---|
|
|
96
|
+
|
|
97
|
+
## Interpreted Scope
|
|
98
|
+
|
|
99
|
+
## Non-Goals
|
|
100
|
+
|
|
101
|
+
## Requirement Coverage
|
|
102
|
+
|
|
103
|
+
| ID | Source Ref | Requirement | Proposed Disposition | Final Disposition | Decision Source | Work Unit | Acceptance Row |
|
|
104
|
+
|---|---|---|---|---|---|---|---|
|
|
105
|
+
|
|
106
|
+
## Deferred, Out-Of-Scope, Or Blocked Items
|
|
107
|
+
|
|
108
|
+
| ID | Requirement | Status | Reason | Needed Decision |
|
|
109
|
+
|---|---|---|---|---|
|
|
110
|
+
|
|
111
|
+
## Proposed Work Units
|
|
112
|
+
|
|
113
|
+
| Work Unit | Objective | Depends On | Verification |
|
|
114
|
+
|---|---|---|---|
|
|
115
|
+
|
|
116
|
+
## Acceptance Summary
|
|
117
|
+
|
|
118
|
+
## Assumptions And Risks
|
|
119
|
+
|
|
120
|
+
## Open Questions
|
|
121
|
+
|
|
122
|
+
| ID | Question | Asked By | Answer | Status |
|
|
123
|
+
|---|---|---|---|---|
|
|
124
|
+
|
|
125
|
+
## Q&A Log
|
|
126
|
+
|
|
127
|
+
| ID | Question | Answer | Spec Change Required | Status |
|
|
128
|
+
|---|---|---|---|---|
|
|
129
|
+
|
|
130
|
+
## Resume Checkpoint
|
|
131
|
+
|
|
132
|
+
Blocked At:
|
|
133
|
+
|
|
134
|
+
Required Human Decision:
|
|
135
|
+
|
|
136
|
+
Affected Requirement IDs:
|
|
137
|
+
|
|
138
|
+
Affected Work Units:
|
|
139
|
+
|
|
140
|
+
Next Action After Answer:
|
|
141
|
+
|
|
142
|
+
Artifacts To Refresh:
|
|
143
|
+
|
|
144
|
+
Stale Artifacts Invalidated:
|
|
145
|
+
|
|
146
|
+
## Human Verification
|
|
147
|
+
|
|
148
|
+
Reviewer:
|
|
149
|
+
|
|
150
|
+
Decision: Approved | Needs Revision | Blocked
|
|
151
|
+
|
|
152
|
+
Decision Source:
|
|
153
|
+
|
|
154
|
+
Notes:
|
|
155
|
+
```
|
|
156
|
+
|
|
68
157
|
## WORK-UNITS.md
|
|
69
158
|
|
|
70
159
|
```md
|
|
@@ -249,6 +338,66 @@ Acceptance Criteria:
|
|
|
249
338
|
## Next Recommended Action
|
|
250
339
|
```
|
|
251
340
|
|
|
341
|
+
## GOAL-STATE.md
|
|
342
|
+
|
|
343
|
+
```md
|
|
344
|
+
# Goal State
|
|
345
|
+
|
|
346
|
+
## Objective
|
|
347
|
+
|
|
348
|
+
## Goal Binding
|
|
349
|
+
|
|
350
|
+
created | reused | skipped | unavailable | conflict
|
|
351
|
+
|
|
352
|
+
## Goal Status
|
|
353
|
+
|
|
354
|
+
active | complete | blocked | blocked old | unknown
|
|
355
|
+
|
|
356
|
+
## Previous Blocked Goal
|
|
357
|
+
|
|
358
|
+
Goal Reference:
|
|
359
|
+
|
|
360
|
+
Reason:
|
|
361
|
+
|
|
362
|
+
Use As History Only: yes | no
|
|
363
|
+
|
|
364
|
+
## Last Tool Action
|
|
365
|
+
|
|
366
|
+
get_goal | create_goal | update_goal | none
|
|
367
|
+
|
|
368
|
+
## Next Allowed Goal Action
|
|
369
|
+
|
|
370
|
+
## Last Completed Step
|
|
371
|
+
|
|
372
|
+
## Current Work Unit
|
|
373
|
+
|
|
374
|
+
## Current Blocker
|
|
375
|
+
|
|
376
|
+
## Human Decision Needed
|
|
377
|
+
|
|
378
|
+
Question:
|
|
379
|
+
|
|
380
|
+
Smallest Sufficient Answer:
|
|
381
|
+
|
|
382
|
+
## Human Decision Answer
|
|
383
|
+
|
|
384
|
+
Answer:
|
|
385
|
+
|
|
386
|
+
Decision Type: clarification | scope change | requirement waiver | explicit deferral | blocker resolution | final disposition | intake change | workflow cancellation
|
|
387
|
+
|
|
388
|
+
## Resume Checkpoint
|
|
389
|
+
|
|
390
|
+
Next Action:
|
|
391
|
+
|
|
392
|
+
Artifacts To Refresh:
|
|
393
|
+
|
|
394
|
+
Stale Artifacts Invalidated:
|
|
395
|
+
|
|
396
|
+
## Completion Rule
|
|
397
|
+
|
|
398
|
+
## Blocked Rule
|
|
399
|
+
```
|
|
400
|
+
|
|
252
401
|
## OUTCOME.md
|
|
253
402
|
|
|
254
403
|
```md
|