cabloy 5.1.200 → 5.1.202
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/.cabloy-version +1 -1
- package/CHANGELOG.md +21 -0
- package/README.md +6 -0
- package/package.json +1 -1
- package/repo-agent-governance/managed-assets.json +21 -21
- package/repo-agent-governance/skills/cabloy-spec-execution/SKILL.md +3 -2
- package/repo-agent-governance/skills/cabloy-spec-execution/references/execution-protocol.md +1 -1
- package/repo-agent-governance/skills/cabloy-spec-execution/references/status-and-evidence.md +11 -10
- package/repo-agent-governance/skills/cabloy-spec-generation/SKILL.md +1 -1
- package/repo-agent-governance/skills/cabloy-spec-generation/references/canonical-spec-input.md +6 -2
- package/repo-agent-governance/skills/cabloy-spec-generation/references/repo-specs-document-set.md +16 -13
- package/repo-agent-governance/skills/cabloy-spec-generation/references/traceability-and-status-rules.md +19 -12
- package/repo-agent-governance/tests/spec-audit.test.mjs +493 -0
- package/repo-agent-governance/tools/spec-audit/audit.mjs +189 -5
- package/repo-agent-governance/tools/spec-charts/generate-implementation-charts.mjs +26 -7
- package/repo-agent-governance/tools/spec-charts/generate-implementation-charts.test.mjs +82 -0
- package/repo-agent-governance/tools/spec-charts/spec-parser.mjs +40 -1
- package/repo-docs/ai/ai-spec-driven-development.md +1 -0
- package/repo-docs/ai/playbook-spec-execution.md +3 -2
- package/repo-docs/ai/playbook-spec-generation.md +1 -1
- package/repo-docs/assets/img/cabloy-admin-ssr-cover-en.png +0 -0
- package/repo-docs/index.md +6 -0
package/.cabloy-version
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
5.1.
|
|
1
|
+
5.1.202
|
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,26 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 5.1.202
|
|
4
|
+
|
|
5
|
+
### Features
|
|
6
|
+
|
|
7
|
+
- Add a traceability gate for planning baseline reviews.
|
|
8
|
+
|
|
9
|
+
## 5.1.201
|
|
10
|
+
|
|
11
|
+
### Features
|
|
12
|
+
|
|
13
|
+
- Support scoped spec traceability exceptions.
|
|
14
|
+
|
|
15
|
+
### Bug Fixes
|
|
16
|
+
|
|
17
|
+
- Fix the CabloyJS Admin SSR video.
|
|
18
|
+
|
|
19
|
+
### Improvements
|
|
20
|
+
|
|
21
|
+
- Add the CabloyJS Admin SSR video to the demonstrations.
|
|
22
|
+
- Refine the spec parser.
|
|
23
|
+
|
|
3
24
|
## 5.1.200
|
|
4
25
|
|
|
5
26
|
### Features
|
package/README.md
CHANGED
|
@@ -36,6 +36,12 @@ For Cabloy Start, clone the [Cabloy Start repository](https://github.com/cabloy/
|
|
|
36
36
|
|
|
37
37
|
See the [AI Spec-Driven Development](https://cabloy.com/ai/ai-spec-driven-development).
|
|
38
38
|
|
|
39
|
+
## Demonstrations(Videos)
|
|
40
|
+
|
|
41
|
+
### 1. Can an Admin Site Use SSR? CabloyJS in Three Practical Demos (Duration: 1:16)
|
|
42
|
+
|
|
43
|
+
[](https://youtu.be/786IQhRdr1I)
|
|
44
|
+
|
|
39
45
|
## Editions
|
|
40
46
|
|
|
41
47
|
Cabloy is available through two complete project baselines, each maintained in its own repository:
|
package/package.json
CHANGED
|
@@ -179,21 +179,21 @@
|
|
|
179
179
|
{
|
|
180
180
|
"adapter": "codex",
|
|
181
181
|
"category": "skill",
|
|
182
|
-
"sha256": "
|
|
182
|
+
"sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
|
|
183
183
|
"source": "skills/cabloy-spec-execution/references/execution-protocol.md",
|
|
184
184
|
"target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
|
|
185
185
|
},
|
|
186
186
|
{
|
|
187
187
|
"adapter": "codex",
|
|
188
188
|
"category": "skill",
|
|
189
|
-
"sha256": "
|
|
189
|
+
"sha256": "d9bc04fff4781daed907508efb36efe7e60fcf8d2de98e0089b175273f29e14e",
|
|
190
190
|
"source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
|
|
191
191
|
"target": ".agents/skills/cabloy-spec-execution/references/status-and-evidence.md"
|
|
192
192
|
},
|
|
193
193
|
{
|
|
194
194
|
"adapter": "codex",
|
|
195
195
|
"category": "skill",
|
|
196
|
-
"sha256": "
|
|
196
|
+
"sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
|
|
197
197
|
"source": "skills/cabloy-spec-execution/SKILL.md",
|
|
198
198
|
"target": ".agents/skills/cabloy-spec-execution/SKILL.md"
|
|
199
199
|
},
|
|
@@ -221,7 +221,7 @@
|
|
|
221
221
|
{
|
|
222
222
|
"adapter": "codex",
|
|
223
223
|
"category": "skill",
|
|
224
|
-
"sha256": "
|
|
224
|
+
"sha256": "f4051409e04e5557a3d45415b8111e6a70b7bfa013b52ee75553ace29d28531c",
|
|
225
225
|
"source": "skills/cabloy-spec-generation/references/canonical-spec-input.md",
|
|
226
226
|
"target": ".agents/skills/cabloy-spec-generation/references/canonical-spec-input.md"
|
|
227
227
|
},
|
|
@@ -235,21 +235,21 @@
|
|
|
235
235
|
{
|
|
236
236
|
"adapter": "codex",
|
|
237
237
|
"category": "skill",
|
|
238
|
-
"sha256": "
|
|
238
|
+
"sha256": "17aaee04e0db0bce9b09d72eb55181d062b0024974ed72014681be1c8490a6a1",
|
|
239
239
|
"source": "skills/cabloy-spec-generation/references/repo-specs-document-set.md",
|
|
240
240
|
"target": ".agents/skills/cabloy-spec-generation/references/repo-specs-document-set.md"
|
|
241
241
|
},
|
|
242
242
|
{
|
|
243
243
|
"adapter": "codex",
|
|
244
244
|
"category": "skill",
|
|
245
|
-
"sha256": "
|
|
245
|
+
"sha256": "4174bef895433d6bdfd6238c6a90391e825e1dce90194cfd47bd6aa2d7a02494",
|
|
246
246
|
"source": "skills/cabloy-spec-generation/references/traceability-and-status-rules.md",
|
|
247
247
|
"target": ".agents/skills/cabloy-spec-generation/references/traceability-and-status-rules.md"
|
|
248
248
|
},
|
|
249
249
|
{
|
|
250
250
|
"adapter": "codex",
|
|
251
251
|
"category": "skill",
|
|
252
|
-
"sha256": "
|
|
252
|
+
"sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
|
|
253
253
|
"source": "skills/cabloy-spec-generation/SKILL.md",
|
|
254
254
|
"target": ".agents/skills/cabloy-spec-generation/SKILL.md"
|
|
255
255
|
},
|
|
@@ -515,21 +515,21 @@
|
|
|
515
515
|
{
|
|
516
516
|
"adapter": "claude",
|
|
517
517
|
"category": "skill",
|
|
518
|
-
"sha256": "
|
|
518
|
+
"sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
|
|
519
519
|
"source": "skills/cabloy-spec-execution/references/execution-protocol.md",
|
|
520
520
|
"target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
|
|
521
521
|
},
|
|
522
522
|
{
|
|
523
523
|
"adapter": "claude",
|
|
524
524
|
"category": "skill",
|
|
525
|
-
"sha256": "
|
|
525
|
+
"sha256": "d9bc04fff4781daed907508efb36efe7e60fcf8d2de98e0089b175273f29e14e",
|
|
526
526
|
"source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
|
|
527
527
|
"target": ".claude/skills/cabloy-spec-execution/references/status-and-evidence.md"
|
|
528
528
|
},
|
|
529
529
|
{
|
|
530
530
|
"adapter": "claude",
|
|
531
531
|
"category": "skill",
|
|
532
|
-
"sha256": "
|
|
532
|
+
"sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
|
|
533
533
|
"source": "skills/cabloy-spec-execution/SKILL.md",
|
|
534
534
|
"target": ".claude/skills/cabloy-spec-execution/SKILL.md"
|
|
535
535
|
},
|
|
@@ -557,7 +557,7 @@
|
|
|
557
557
|
{
|
|
558
558
|
"adapter": "claude",
|
|
559
559
|
"category": "skill",
|
|
560
|
-
"sha256": "
|
|
560
|
+
"sha256": "f4051409e04e5557a3d45415b8111e6a70b7bfa013b52ee75553ace29d28531c",
|
|
561
561
|
"source": "skills/cabloy-spec-generation/references/canonical-spec-input.md",
|
|
562
562
|
"target": ".claude/skills/cabloy-spec-generation/references/canonical-spec-input.md"
|
|
563
563
|
},
|
|
@@ -571,21 +571,21 @@
|
|
|
571
571
|
{
|
|
572
572
|
"adapter": "claude",
|
|
573
573
|
"category": "skill",
|
|
574
|
-
"sha256": "
|
|
574
|
+
"sha256": "17aaee04e0db0bce9b09d72eb55181d062b0024974ed72014681be1c8490a6a1",
|
|
575
575
|
"source": "skills/cabloy-spec-generation/references/repo-specs-document-set.md",
|
|
576
576
|
"target": ".claude/skills/cabloy-spec-generation/references/repo-specs-document-set.md"
|
|
577
577
|
},
|
|
578
578
|
{
|
|
579
579
|
"adapter": "claude",
|
|
580
580
|
"category": "skill",
|
|
581
|
-
"sha256": "
|
|
581
|
+
"sha256": "4174bef895433d6bdfd6238c6a90391e825e1dce90194cfd47bd6aa2d7a02494",
|
|
582
582
|
"source": "skills/cabloy-spec-generation/references/traceability-and-status-rules.md",
|
|
583
583
|
"target": ".claude/skills/cabloy-spec-generation/references/traceability-and-status-rules.md"
|
|
584
584
|
},
|
|
585
585
|
{
|
|
586
586
|
"adapter": "claude",
|
|
587
587
|
"category": "skill",
|
|
588
|
-
"sha256": "
|
|
588
|
+
"sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
|
|
589
589
|
"source": "skills/cabloy-spec-generation/SKILL.md",
|
|
590
590
|
"target": ".claude/skills/cabloy-spec-generation/SKILL.md"
|
|
591
591
|
},
|
|
@@ -865,21 +865,21 @@
|
|
|
865
865
|
{
|
|
866
866
|
"adapter": "cursor",
|
|
867
867
|
"category": "skill",
|
|
868
|
-
"sha256": "
|
|
868
|
+
"sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
|
|
869
869
|
"source": "skills/cabloy-spec-execution/references/execution-protocol.md",
|
|
870
870
|
"target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
|
|
871
871
|
},
|
|
872
872
|
{
|
|
873
873
|
"adapter": "cursor",
|
|
874
874
|
"category": "skill",
|
|
875
|
-
"sha256": "
|
|
875
|
+
"sha256": "d9bc04fff4781daed907508efb36efe7e60fcf8d2de98e0089b175273f29e14e",
|
|
876
876
|
"source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
|
|
877
877
|
"target": ".cursor/skills/cabloy-spec-execution/references/status-and-evidence.md"
|
|
878
878
|
},
|
|
879
879
|
{
|
|
880
880
|
"adapter": "cursor",
|
|
881
881
|
"category": "skill",
|
|
882
|
-
"sha256": "
|
|
882
|
+
"sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
|
|
883
883
|
"source": "skills/cabloy-spec-execution/SKILL.md",
|
|
884
884
|
"target": ".cursor/skills/cabloy-spec-execution/SKILL.md"
|
|
885
885
|
},
|
|
@@ -907,7 +907,7 @@
|
|
|
907
907
|
{
|
|
908
908
|
"adapter": "cursor",
|
|
909
909
|
"category": "skill",
|
|
910
|
-
"sha256": "
|
|
910
|
+
"sha256": "f4051409e04e5557a3d45415b8111e6a70b7bfa013b52ee75553ace29d28531c",
|
|
911
911
|
"source": "skills/cabloy-spec-generation/references/canonical-spec-input.md",
|
|
912
912
|
"target": ".cursor/skills/cabloy-spec-generation/references/canonical-spec-input.md"
|
|
913
913
|
},
|
|
@@ -921,21 +921,21 @@
|
|
|
921
921
|
{
|
|
922
922
|
"adapter": "cursor",
|
|
923
923
|
"category": "skill",
|
|
924
|
-
"sha256": "
|
|
924
|
+
"sha256": "17aaee04e0db0bce9b09d72eb55181d062b0024974ed72014681be1c8490a6a1",
|
|
925
925
|
"source": "skills/cabloy-spec-generation/references/repo-specs-document-set.md",
|
|
926
926
|
"target": ".cursor/skills/cabloy-spec-generation/references/repo-specs-document-set.md"
|
|
927
927
|
},
|
|
928
928
|
{
|
|
929
929
|
"adapter": "cursor",
|
|
930
930
|
"category": "skill",
|
|
931
|
-
"sha256": "
|
|
931
|
+
"sha256": "4174bef895433d6bdfd6238c6a90391e825e1dce90194cfd47bd6aa2d7a02494",
|
|
932
932
|
"source": "skills/cabloy-spec-generation/references/traceability-and-status-rules.md",
|
|
933
933
|
"target": ".cursor/skills/cabloy-spec-generation/references/traceability-and-status-rules.md"
|
|
934
934
|
},
|
|
935
935
|
{
|
|
936
936
|
"adapter": "cursor",
|
|
937
937
|
"category": "skill",
|
|
938
|
-
"sha256": "
|
|
938
|
+
"sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
|
|
939
939
|
"source": "skills/cabloy-spec-generation/SKILL.md",
|
|
940
940
|
"target": ".cursor/skills/cabloy-spec-generation/SKILL.md"
|
|
941
941
|
},
|
|
@@ -97,8 +97,8 @@ Stop and route back to the relevant planning authority if any of the following a
|
|
|
97
97
|
- the suite identity, ownership, or target boundary is unresolved;
|
|
98
98
|
- PRD/SRS/ADR/WBS/test-plan records contradict one another;
|
|
99
99
|
- a controlling `TODO(confirm)` or unaccepted ADR remains;
|
|
100
|
-
- a predecessor is
|
|
101
|
-
- the selected task is already `verified`, explicitly `deferred`, or currently `blocked`;
|
|
100
|
+
- a predecessor is neither `verified` nor formally opted-in `planning-complete` with a named-reviewer, revision-scoped documentary closure disposition, or its required evidence is absent; a planning-complete edge does not authorize execution;
|
|
101
|
+
- the selected task is already `verified` or `planning-complete`, explicitly `deferred`, or currently `blocked`;
|
|
102
102
|
- a persisted field/schema change lacks an explicit decision about incrementing `vonaModule.fileVersion`;
|
|
103
103
|
- the working tree contains overlapping unclassified changes that make attribution or rollback unclear;
|
|
104
104
|
- authorization, tenant isolation, privacy, lifecycle, transaction, concurrency, idempotency, or ownership behavior is unspecified for a material risk;
|
|
@@ -139,6 +139,7 @@ Record proof under `references/status-and-evidence.md`, preserving the establish
|
|
|
139
139
|
Set status accurately:
|
|
140
140
|
|
|
141
141
|
- `in-progress` while work or verification remains open;
|
|
142
|
+
- `planning-complete` only for an opted-in documentary/design task after explicit named-reviewer, revision-scoped planning-closure disposition and linked planning evidence; never infer source/ATP closure or next-task approval;
|
|
142
143
|
- `implementation-complete` when source work is complete but ATP/release proof remains;
|
|
143
144
|
- `verified` only after all applicable WBS checks and ATPs have durable linked redacted evidence;
|
|
144
145
|
- `blocked`, `waived`, or `deferred` only with the required details.
|
|
@@ -61,7 +61,7 @@ Before implementation, verify:
|
|
|
61
61
|
|
|
62
62
|
- the WBS target exists and is bounded;
|
|
63
63
|
- every material linked requirement has a technical contract and ATP;
|
|
64
|
-
- predecessor
|
|
64
|
+
- each predecessor is `verified`, or is `planning-complete` with its own formal `Completion mode: planning-only.` declaration, named-reviewer revision-scoped disposition and documentary proof; neither `implementation-complete` nor a traceability exception satisfies this edge;
|
|
65
65
|
- no controlling `TODO(confirm)`, unaccepted ADR, waiver, or failed gate remains unresolved;
|
|
66
66
|
- the selected task is not already `verified`, `deferred`, or `blocked`;
|
|
67
67
|
- source ownership and the target API/state/page boundary are unambiguous;
|
package/repo-agent-governance/skills/cabloy-spec-execution/references/status-and-evidence.md
CHANGED
|
@@ -56,15 +56,16 @@ Do not create an empty `evidence/` directory, placeholder `EVD-*` record, or fab
|
|
|
56
56
|
|
|
57
57
|
Use the suite’s canonical status meanings:
|
|
58
58
|
|
|
59
|
-
| Status | Meaning
|
|
60
|
-
| ------------------------- |
|
|
61
|
-
| `not-started` | Defined, but implementation or acceptance evidence has not started.
|
|
62
|
-
| `in-progress` | Work or verification has started, but closure checks remain.
|
|
63
|
-
| `
|
|
64
|
-
| `
|
|
65
|
-
| `
|
|
66
|
-
| `
|
|
67
|
-
| `
|
|
59
|
+
| Status | Meaning |
|
|
60
|
+
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
61
|
+
| `not-started` | Defined, but implementation or acceptance evidence has not started. |
|
|
62
|
+
| `in-progress` | Work or verification has started, but closure checks remain. |
|
|
63
|
+
| `planning-complete` | An opted-in documentary/design-only WBS task has a named-reviewer, revision-scoped planning-closure disposition and retained planning proof; not source or ATP closure. |
|
|
64
|
+
| `implementation-complete` | Source work is reported complete, but required ATP or release evidence is incomplete. |
|
|
65
|
+
| `verified` | Applicable WBS checks and ATPs passed, with durable traceable evidence containing revision, environment, exact procedure, result, and redacted artifact location. |
|
|
66
|
+
| `blocked` | A dependency, unresolved decision, failed gate, attribution problem, or missing required proof prevents closure. |
|
|
67
|
+
| `waived` | A temporary exception has an owner, reason, affected scope, and expiry; expiry becomes a release blocker. |
|
|
68
|
+
| `deferred` | Explicitly postponed scope; it is not complete or verified. |
|
|
68
69
|
|
|
69
70
|
The normal path is:
|
|
70
71
|
|
|
@@ -72,7 +73,7 @@ The normal path is:
|
|
|
72
73
|
not-started -> in-progress -> implementation-complete -> verified
|
|
73
74
|
```
|
|
74
75
|
|
|
75
|
-
`blocked`, `waived`, and `deferred` are explicit states, not shortcuts to completion. Mark
|
|
76
|
+
A genuinely documentary/design-only task can instead follow `not-started -> in-progress -> planning-complete`, but only when its formal WBS declaration contains `Completion mode: planning-only.`, its own checks have revision-scoped documentary evidence, and a named reviewer explicitly records the planning-closure disposition. `authority-only` traceability is not this opt-in. `planning-complete` satisfies a predecessor dependency edge but never grants successor execution approval, accepts another ADR, completes source, or passes a linked prospective runtime ATP. The Gantt shows its status separately; verified totals and the burndown's active-minus-verified remainder still count only `verified`. `implementation-complete`, `waived` and `deferred` are not completed prerequisites. `blocked`, `waived`, and `deferred` are explicit states, not shortcuts to completion. Mark an implementation task `in-progress` only after approved implementation or verification actually begins. A generated file, successful scaffold, passing typecheck, code review, manual walkthrough, screenshot, or unrelated broad test pass cannot by itself produce `verified`.
|
|
76
77
|
|
|
77
78
|
A task may be `implementation-complete` when source work is complete but an ATP, browser check, paired build, release gate, redaction decision, or durable artifact remains. A phase can be verified without implying that a separately defined integration or release phase is verified.
|
|
78
79
|
|
|
@@ -128,7 +128,7 @@ npm run spec:check -- <suite> --lightweight
|
|
|
128
128
|
|
|
129
129
|
For incremental legacy gaps, report the missing definition/owner/link and affected chain without silently changing business meaning. If correction needs a new decision, request it and report the update as incomplete at that gate. Lightweight results must state skipped owners/chain coverage; never advertise a full-suite pass.
|
|
130
130
|
|
|
131
|
-
Planning creation alone initializes delivery as `not-started`, `deferred`, or specifically `blocked`. Preserve carried-forward observed evidence with its revision/authority limits. Do not run init, database reset, scaffolding, deployment/provider operations, or acceptance tests as an automatic consequence of planning.
|
|
131
|
+
Planning creation alone initializes delivery as `not-started`, `deferred`, or specifically `blocked`. `planning-complete` is only available to a formally opted-in documentary/design task after its own checks receive revision-scoped proof and a named-reviewer closure disposition; it is not ATP verification or permission to execute a successor. Preserve carried-forward observed evidence with its revision/authority limits. Do not run init, database reset, scaffolding, deployment/provider operations, or acceptance tests as an automatic consequence of planning.
|
|
132
132
|
|
|
133
133
|
## 10. Finish with a bounded execution handoff
|
|
134
134
|
|
package/repo-agent-governance/skills/cabloy-spec-generation/references/canonical-spec-input.md
CHANGED
|
@@ -17,6 +17,10 @@ References in matrices, related-record lists, progress, evidence, templates, wil
|
|
|
17
17
|
|
|
18
18
|
Use exact instantiated IDs in declaration-body Traceability. A wildcard or abbreviated range is an aggregate summary, not an exact association or substitute for missing definitions. Keep associations explicit even if a downstream summary matrix repeats them. The audit must derive associations from the declaration body, not nearby unrelated sections.
|
|
19
19
|
|
|
20
|
+
For a genuinely cross-cutting engineering contract without a product requirement, an atomic SRS bullet may carry `Traceability exception: technical-only — <record-specific rationale>` on its definition line. This exempts only the incoming PRD association; its outgoing WBS mapping remains required. For a documentary planning or release gate with no independent executable scenario, a WBS task may carry `Traceability exception: authority-only — <record-specific rationale>` in its declaration body. This exempts only the outgoing ATP association; its incoming SRS mapping remains required. Use exactly one well-formed field on the correct definition and explain the alternative authority or retained documentary checks. The auditor rejects malformed, empty, duplicated, or wrong-kind exceptions. Neither classification waives the underlying contract, delivery checks, applicable ATPs, revision-scoped evidence, or release approval; never use one merely to silence a missing real link.
|
|
21
|
+
|
|
22
|
+
For a Phase 10 task that reviews the entire planning baseline rather than implementing one SRS or executing one ATP, use the separate `Traceability mode: planning-baseline-review` classification and accepted local ADR review authority described in `traceability-and-status-rules.md`. It exempts only that WBS task's incoming SRS and outgoing ATP checks. Do not combine it with a `Traceability exception` or apply it to product-delivery, contract-loop, migration, or release work. Classification alone does not establish approval, proof, `planning-complete` eligibility, or `verified` status; a separate task-local `Completion mode: planning-only.` declaration is required for planning closure.
|
|
23
|
+
|
|
20
24
|
## Minimal connected example
|
|
21
25
|
|
|
22
26
|
These are neutral **syntax examples**, not business requirements to copy into a real suite. All four IDs are exact and unique. Production bodies must describe the approved domain.
|
|
@@ -67,7 +71,7 @@ Acceptance checks:
|
|
|
67
71
|
- The selected ATP passes and retains its required proof.
|
|
68
72
|
```
|
|
69
73
|
|
|
70
|
-
Each phase has explicit Dependencies, using `none` when no predecessor exists. Task-level Dependencies override the phase Dependencies for that task; they are not accumulated automatically. Do not rely on an empty dependency label to mean none. Keep phases dependency-ordered and task scope bounded. WBS bodies own linked IDs, tasks, and checks; progress does not add them.
|
|
74
|
+
Each phase has explicit Dependencies, using `none` when no predecessor exists. Task-level Dependencies override the phase Dependencies for that task; they are not accumulated automatically. Do not rely on an empty dependency label to mean none. Keep phases dependency-ordered and task scope bounded. WBS bodies own linked IDs, tasks, and checks; progress does not add them. For a genuinely documentary/design-only task, the formal task declaration may add exactly one `Completion mode: planning-only.` field. This opt-in is not a phase default or a traceability exception: its own checks still need a named reviewer, a revision-scoped planning-closure disposition and linked documentary proof before progress can say `planning-complete`. Keep linked prospective runtime ATPs intact and unpassed.
|
|
71
75
|
|
|
72
76
|
### test-plan.md
|
|
73
77
|
|
|
@@ -107,7 +111,7 @@ Setup, Procedure, Expected result, Minimum proof, and Traceability must each be
|
|
|
107
111
|
| `WBS-DEMO-10-01` | `not-started` | None; execution has not begun. | Confirm the bounded execution dossier. |
|
|
108
112
|
```
|
|
109
113
|
|
|
110
|
-
Resolve columns by header names (`WBS ID` and `Status`), never fixed cell positions. Additional/reordered columns are allowed. Require one row for every formal WBS task when constructing the complete chart model. Preserve the established status vocabulary and explain blockers/waivers precisely.
|
|
114
|
+
Resolve columns by header names (`WBS ID` and `Status`), never fixed cell positions. Additional/reordered columns are allowed. Require one row for every formal WBS task when constructing the complete chart model. Preserve the established status vocabulary and explain blockers/waivers precisely. `planning-complete` is valid only for a task declaring `Completion mode: planning-only.` in its WBS body; it satisfies a predecessor dependency edge but does not grant successor execution approval, count as verified, or reduce the verified-based burndown remainder.
|
|
111
115
|
|
|
112
116
|
## Three gates, not one success signal
|
|
113
117
|
|
package/repo-agent-governance/skills/cabloy-spec-generation/references/repo-specs-document-set.md
CHANGED
|
@@ -137,10 +137,12 @@ Every WBS entry should state:
|
|
|
137
137
|
- primary source areas or ownership boundaries;
|
|
138
138
|
- bounded tasks;
|
|
139
139
|
- acceptance/completion checks;
|
|
140
|
-
- linked PRD, SRS, and ATP identifiers;
|
|
140
|
+
- linked PRD, SRS, and ATP identifiers where a real adjacent-authority association exists; a genuine documentary planning/release gate without an independent ATP uses the explicit `authority-only` classification and retains its SRS association and review evidence as specified in `canonical-spec-input.md`. A whole-baseline planning review with neither a specific SRS nor a formal ATP instead uses `planning-baseline-review` and an accepted local ADR review authority as specified in `traceability-and-status-rules.md`;
|
|
141
141
|
- whether it is planned, implemented, or awaiting evidence.
|
|
142
142
|
|
|
143
|
-
|
|
143
|
+
For a documentary/design-only task, declare `Completion mode: planning-only.` in that task's formal WBS body. The declaration makes `planning-complete` eligible only after the task's own checks receive a named-reviewer, revision-scoped closure disposition and retained documentary proof; it does not close linked future runtime ATPs or approve subsequent implementation. This is independent of `planning-baseline-review` and the `authority-only` traceability exception. Other tasks keep ordinary implementation and ATP closure rules.
|
|
144
|
+
|
|
145
|
+
Begin with a documentation/decision implementation gate before feature work. A planning-baseline review gate does not execute an ATP or acquire `verified` status from its audit classification. For differing Web/Admin strategies, split shared-site integration and independent-site delivery into separate frontend tasks when their source facts, dependencies, or proof differ. An unresolved strategy or exact runtime identifier may block only the affected implementation task; preserve runnable discovery work and unaffected backend or audience work as accurately actionable. Prefer vertical, verifiable increments. Include migration and release hardening as explicit work. Keep `implementation-complete` distinct from `verified`.
|
|
144
146
|
|
|
145
147
|
## Test-plan template contract
|
|
146
148
|
|
|
@@ -188,17 +190,18 @@ Use:
|
|
|
188
190
|
|
|
189
191
|
Initialize a new suite with statuses such as `not-started`, `deferred`, or explicitly `blocked`; do not mark planning work as verified. Use this vocabulary:
|
|
190
192
|
|
|
191
|
-
| Status | Meaning
|
|
192
|
-
| ------------------------- |
|
|
193
|
-
| `not-started` | Defined, but implementation or acceptance evidence has not started.
|
|
194
|
-
| `in-progress` | Work started, but closure checks are incomplete.
|
|
195
|
-
| `
|
|
196
|
-
| `
|
|
197
|
-
| `
|
|
198
|
-
| `
|
|
199
|
-
| `
|
|
200
|
-
|
|
201
|
-
|
|
193
|
+
| Status | Meaning |
|
|
194
|
+
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
195
|
+
| `not-started` | Defined, but implementation or acceptance evidence has not started. |
|
|
196
|
+
| `in-progress` | Work started, but closure checks are incomplete. |
|
|
197
|
+
| `planning-complete` | An explicitly opted-in planning task's own documentary checks have a named-reviewer, revision-scoped closure disposition and linked proof; not runtime verification. |
|
|
198
|
+
| `implementation-complete` | Source work is reported complete, but required ATP evidence or release gates are incomplete. |
|
|
199
|
+
| `verified` | Required ATP evidence is observed and retained with revision, environment, procedure, result, and redacted artifact location. |
|
|
200
|
+
| `blocked` | A dependency, unresolved decision, or failed gate prevents closure. |
|
|
201
|
+
| `waived` | A temporary exception with owner, reason, and expiry; expiry makes it a release blocker. |
|
|
202
|
+
| `deferred` | Explicitly postponed scope, not completed scope. |
|
|
203
|
+
|
|
204
|
+
A `planning-complete` predecessor satisfies its dependency edge, not the next task's design/approval gates; keep a blocked successor blocked. Verified/remaining burndown counts still count only `verified` as complete. Progress must remain a derived register. It may point to evidence but must not become a second requirements document. Include a decision-register entry for each material site strategy and show strategy/identifier deferral as a blocker only on affected frontend/site WBS branches; source reading, planning, or a selected strategy alone is not implementation evidence.
|
|
202
205
|
|
|
203
206
|
## ADR 0001 template contract
|
|
204
207
|
|
|
@@ -47,7 +47,13 @@ Minimum cardinality for a material in-scope requirement:
|
|
|
47
47
|
- at least one ATP scenario;
|
|
48
48
|
- zero evidence records before execution, and at least one retained evidence record before `verified`.
|
|
49
49
|
|
|
50
|
-
A single ATP may prove several related requirements, but the matrices must make the relationship explicit. A WBS item may cover several contracts, but it still needs bounded completion checks.
|
|
50
|
+
A single ATP may prove several related requirements, but the matrices must make the relationship explicit. A WBS item may cover several contracts, but it still needs bounded completion checks. The full-chain minimum applies to material in-scope product requirements; a separately sourced engineering obligation or a documentary coordination gate need not invent a product parent or an executable ATP. Use the narrowly scoped declaration-local `Traceability exception` classifications in `canonical-spec-input.md` only for those genuine cases. The unaffected direction still needs an exact-ID link, and review/closure still needs applicable retained proof. An exception is not a deferred status, evidence waiver, acceptance result, or release approval.
|
|
51
|
+
|
|
52
|
+
### Planning-baseline review gate
|
|
53
|
+
|
|
54
|
+
A WBS task that solely reviews and approves the whole PRD/SRS/WBS/ATP baseline before feature work may declare `Traceability mode: planning-baseline-review` in its own Phase 10 task body. It must name a local accepted boundary ADR under `decisions/` as `Review authority: [ADR](./decisions/<file>.md)`, and retain substantive Tasks and Acceptance checks for the baseline review. It must not claim to implement a specific SRS contract or execute a formal ATP, including in its title, Tasks, or Acceptance checks. The ADR may use the existing `## Status` followed by `Accepted` or `Accepted.` convention; the auditor does not require new owner or acceptance fields in the ADR, and acceptance of the ADR alone does not prove the review occurred. This explicit process gate alone is exempt from the WBS-specific SRS incoming and ATP outgoing exact-ID checks in the complete audit; all product-chain definitions, ordinary WBS tasks, references, dependencies, and progress remain checked. It cannot classify implementation, migration, contract-loop, release, or mixed-scope work. Do not infer this type from a title, task number, review status, or a summary table, and do not combine it with `Traceability exception: authority-only`.
|
|
55
|
+
|
|
56
|
+
This differs from `authority-only`, which still requires an exact SRS incoming link and exempts only the ATP outgoing link. Both traceability classifications are independent of `Completion mode: planning-only.`; neither makes a task eligible for `planning-complete`. An audit exception is not approval or proof: the ADR decision owner must separately accept the baseline, and the progress record must retain that review's attributable approval before `verified` is appropriate. It does not create an ATP execution record, change any business traceability, or relax the evidence rule for other WBS work.
|
|
51
57
|
|
|
52
58
|
## Authority-first updates
|
|
53
59
|
|
|
@@ -67,17 +73,18 @@ Downstream records do not silently override authority. Charts cannot authorize s
|
|
|
67
73
|
|
|
68
74
|
## Status semantics
|
|
69
75
|
|
|
70
|
-
| Status | Meaning
|
|
71
|
-
| ------------------------- |
|
|
72
|
-
| `not-started` | Defined, but implementation or acceptance evidence has not started.
|
|
73
|
-
| `in-progress` | Work or verification has started, but closure checks are incomplete.
|
|
74
|
-
| `
|
|
75
|
-
| `
|
|
76
|
-
| `
|
|
77
|
-
| `
|
|
78
|
-
| `
|
|
79
|
-
|
|
80
|
-
|
|
76
|
+
| Status | Meaning |
|
|
77
|
+
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
78
|
+
| `not-started` | Defined, but implementation or acceptance evidence has not started. |
|
|
79
|
+
| `in-progress` | Work or verification has started, but closure checks are incomplete. |
|
|
80
|
+
| `planning-complete` | Opted-in documentary/design-only WBS checks have a named-reviewer, revision-scoped closure disposition and retained planning proof; source and ATP remain unproven. |
|
|
81
|
+
| `implementation-complete` | Source work is reported complete, but required ATP or release evidence is incomplete. |
|
|
82
|
+
| `verified` | Applicable WBS checks and ATPs passed, and durable evidence contains revision, environment, exact procedure, result, and redacted artifact location. |
|
|
83
|
+
| `blocked` | A failed gate, dependency, or unresolved decision prevents closure. |
|
|
84
|
+
| `waived` | A temporary exception explicitly approved with owner, reason, and expiry. |
|
|
85
|
+
| `deferred` | Explicitly postponed scope; it is not complete or verified. |
|
|
86
|
+
|
|
87
|
+
For a newly created plan, initialize delivery rows as `not-started`, `deferred`, or `blocked` as appropriate. Creating Markdown files never makes a task `planning-complete`, implementation `implementation-complete`, or ATP `verified`. Only a formally declared `Completion mode: planning-only.` task with documentary acceptance checks, revision-scoped evidence and an explicit named-reviewer closure disposition may reach `planning-complete`; `authority-only` traceability does not establish this eligibility. A planning-complete predecessor satisfies its WBS dependency edge, but blocked/deferred/waived successors stay gated and require their own decisions and approvals. `implementation-complete`, `waived` and `deferred` do not satisfy predecessor completion. Only `verified` contributes to verified totals and the verified-based burndown remainder.
|
|
81
88
|
|
|
82
89
|
### README and ADR decision-status consistency
|
|
83
90
|
|