cabloy 5.1.201 → 5.1.203
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 +17 -0
- package/CONTRIBUTING.md +18 -17
- package/README.md +2 -2
- package/package.json +2 -3
- package/repo-agent-governance/managed-assets.json +33 -33
- package/repo-agent-governance/policies/repository.md +1 -0
- 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 +4 -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 +18 -11
- package/repo-agent-governance/skills/cabloy-workflow/SKILL.md +2 -2
- package/repo-agent-governance/skills/cabloy-workflow/evals/evals.json +1 -1
- package/repo-agent-governance/skills/cabloy-worktree-environment/SKILL.md +5 -5
- package/repo-agent-governance/tests/spec-audit.test.mjs +323 -0
- package/repo-agent-governance/tools/spec-audit/audit.mjs +129 -3
- 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/assets/img/cabloy-admin-tabs-cover-en.png +0 -0
- package/repo-docs/assets/img/cabloy-ai-crud-cover-en.png +0 -0
- package/repo-docs/demo.md +14 -0
- package/repo-docs/frontend/scripts.md +10 -18
- package/repo-docs/fullstack/parallel-worktree-environment.md +2 -2
- package/repo-docs/index.md +2 -2
- package/repo-docs/reference/repo-scripts.md +15 -31
- package/repo-e2e/config/playwright.config.ts +14 -19
- package/repo-e2e/scripts/e2e.test.ts +17 -0
- package/repo-e2e/scripts/e2e.ts +5 -1
- package/repo-e2e/scripts/runE2e.ts +3 -15
- package/repo-e2e/scripts/runE2eArgs.test.ts +21 -17
- package/repo-e2e/scripts/runE2eArgs.ts +16 -29
- package/repo-e2e/scripts/startE2eVona.ts +20 -9
- package/repo-e2e/specs/a-commerce.spec.ts +232 -31
- package/repo-e2e/specs/cabloy-basic.spec.ts +39 -12
- package/repo-e2e/specs/home-user-account.spec.ts +9 -2
- package/scripts/upgrade.test.ts +147 -0
- package/scripts/upgrade.ts +49 -27
- package/vona/packages-cli/cli/package.json +1 -1
- package/vona/packages-cli/cli-set-api/package.json +1 -1
- package/vona/packages-cli/cli-set-api/src/lib/bean/cli.bin.dev.ts +51 -5
- package/vona/packages-cli/cli-set-api/src/lib/command/bin.dev.ts +6 -1
- package/vona/packages-cli/cli-set-api/test/binDevMode.test.ts +52 -0
- package/vona/src/suite/a-commerce/modules/commerce-trade/src/.metadata/index.ts +41 -0
- package/vona/src/suite/a-commerce/modules/commerce-trade/src/controller/e2eFixture.ts +52 -0
- package/vona/src/suite/a-commerce/modules/commerce-trade/src/lib/e2eFixture.ts +224 -0
- package/vona/src/suite/a-commerce/modules/commerce-trade/src/service/e2eFixture.ts +694 -0
- package/vona/src/suite/a-commerce/modules/commerce-trade/test/e2eFixture.test.ts +434 -0
package/.cabloy-version
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
5.1.
|
|
1
|
+
5.1.203
|
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,22 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 5.1.203
|
|
4
|
+
|
|
5
|
+
### Features
|
|
6
|
+
- Update application features.
|
|
7
|
+
|
|
8
|
+
### Improvements
|
|
9
|
+
- Refactor end-to-end tests.
|
|
10
|
+
- Clarify managed E2E resource authorization documentation.
|
|
11
|
+
- Add a video demonstrating second-level tabs for admin multitasking.
|
|
12
|
+
- Update the demo documentation.
|
|
13
|
+
|
|
14
|
+
## 5.1.202
|
|
15
|
+
|
|
16
|
+
### Features
|
|
17
|
+
|
|
18
|
+
- Add a traceability gate for planning baseline reviews.
|
|
19
|
+
|
|
3
20
|
## 5.1.201
|
|
4
21
|
|
|
5
22
|
### Features
|
package/CONTRIBUTING.md
CHANGED
|
@@ -27,23 +27,24 @@ Current CI workflows run on Ubuntu with Node.js 24 after pushes to `main`; do no
|
|
|
27
27
|
|
|
28
28
|
Start with the narrowest meaningful check, then broaden validation when a change crosses a shared boundary.
|
|
29
29
|
|
|
30
|
-
| Purpose
|
|
31
|
-
|
|
|
32
|
-
| Start Vona development
|
|
33
|
-
| Start one Vona development process
|
|
34
|
-
| Start Basic Admin SSR development
|
|
35
|
-
| Start Basic Web SSR development
|
|
36
|
-
| Check formatting
|
|
37
|
-
| Lint
|
|
38
|
-
| Type-check Vona and Zova
|
|
39
|
-
| Run backend tests
|
|
40
|
-
| Run the
|
|
41
|
-
|
|
|
42
|
-
| Build
|
|
43
|
-
| Build Basic
|
|
44
|
-
|
|
|
45
|
-
|
|
|
46
|
-
|
|
30
|
+
| Purpose | Command |
|
|
31
|
+
| ----------------------------------------- | -------------------------- |
|
|
32
|
+
| Start Vona development | `npm run dev` |
|
|
33
|
+
| Start one Vona development process | `npm run dev:one` |
|
|
34
|
+
| Start Basic Admin SSR development | `npm run dev:zova:admin` |
|
|
35
|
+
| Start Basic Web SSR development | `npm run dev:zova:web` |
|
|
36
|
+
| Check formatting | `npm run format` |
|
|
37
|
+
| Lint | `npm run lint` |
|
|
38
|
+
| Type-check Vona and Zova | `npm run tsc` |
|
|
39
|
+
| Run backend tests | `npm run test` |
|
|
40
|
+
| Run the managed local test-mode E2E suite | `npm run test:e2e` |
|
|
41
|
+
| Build required Basic artifacts | `npm run build` |
|
|
42
|
+
| Build Basic Admin SSR and REST artifacts | `npm run build:zova:admin` |
|
|
43
|
+
| Build Basic Web SSR and REST artifacts | `npm run build:zova:web` |
|
|
44
|
+
| Synchronize Zova dependencies into Vona | `npm run deps:vona` |
|
|
45
|
+
| Build the public documentation site | `npm run docs:build` |
|
|
46
|
+
|
|
47
|
+
`npm run test:e2e` starts a fresh runner-managed local Vona worker in test mode and runs Playwright against Vona integrated SSR. Select flat spec basenames directly after the script, for example `npm run test:e2e a-commerce`; place Playwright filters after npm's `--` delimiter, for example `npm run test:e2e a-commerce -- --tag @smoke`. Browser commands consume existing SSR/REST artifacts and do not rebuild them. Confirm exclusive ownership of the effective test database, local Redis namespace, public/runtime paths, application identity, API origin, and listener before starting a test-mode runtime; an available port alone is not sufficient. Externally managed `E2E_BASE_URL` targets are unsupported.
|
|
47
48
|
|
|
48
49
|
The tracked pre-commit hook runs `lint-staged`. It may format staged Markdown and configuration files, and may lint-fix and format staged source files. Review the resulting staged changes and run the relevant explicit checks before submitting.
|
|
49
50
|
|
package/README.md
CHANGED
|
@@ -38,9 +38,9 @@ See the [AI Spec-Driven Development](https://cabloy.com/ai/ai-spec-driven-develo
|
|
|
38
38
|
|
|
39
39
|
## Demonstrations(Videos)
|
|
40
40
|
|
|
41
|
-
### 1.
|
|
41
|
+
### 1. AI Coding in Action: One Prompt for CRUD, SSR & Multitasking (Duration: 3:50)
|
|
42
42
|
|
|
43
|
-
[](https://youtu.be/PV9_By08hDM)
|
|
44
44
|
|
|
45
45
|
## Editions
|
|
46
46
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "cabloy",
|
|
3
|
-
"version": "5.1.
|
|
3
|
+
"version": "5.1.203",
|
|
4
4
|
"gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
|
|
5
5
|
"description": "A Node.js fullstack framework",
|
|
6
6
|
"keywords": [
|
|
@@ -45,8 +45,7 @@
|
|
|
45
45
|
"start": "cd vona && npm run start",
|
|
46
46
|
"start:one": "cd vona && npm run start:one",
|
|
47
47
|
"test": "cd vona && npm run test",
|
|
48
|
-
"test:e2e": "node repo-e2e/scripts/runE2e.ts
|
|
49
|
-
"test:e2e:fast": "node repo-e2e/scripts/runE2e.ts --fast",
|
|
48
|
+
"test:e2e": "node repo-e2e/scripts/runE2e.ts",
|
|
50
49
|
"test:docs:e2e": "npm run docs:build && playwright test --config repo-e2e/docs/playwright.config.ts",
|
|
51
50
|
"db:reset": "cd vona && npm run db:reset",
|
|
52
51
|
"tsc": "npm run tsc:zova && pnpm --dir vona run tsc",
|
|
@@ -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,28 +235,28 @@
|
|
|
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
|
},
|
|
256
256
|
{
|
|
257
257
|
"adapter": "codex",
|
|
258
258
|
"category": "skill",
|
|
259
|
-
"sha256": "
|
|
259
|
+
"sha256": "0d1901134f7222902cfc702275ed7bd83a4e3a1d72c3543a77c8ab5d7cabaa55",
|
|
260
260
|
"source": "skills/cabloy-workflow/evals/evals.json",
|
|
261
261
|
"target": ".agents/skills/cabloy-workflow/evals/evals.json"
|
|
262
262
|
},
|
|
@@ -277,7 +277,7 @@
|
|
|
277
277
|
{
|
|
278
278
|
"adapter": "codex",
|
|
279
279
|
"category": "skill",
|
|
280
|
-
"sha256": "
|
|
280
|
+
"sha256": "ff0760f6fa7c24f561fdcfa07094d9d6e8d82fcef358458a36ff0c38a30ea89e",
|
|
281
281
|
"source": "skills/cabloy-workflow/SKILL.md",
|
|
282
282
|
"target": ".agents/skills/cabloy-workflow/SKILL.md"
|
|
283
283
|
},
|
|
@@ -291,7 +291,7 @@
|
|
|
291
291
|
{
|
|
292
292
|
"adapter": "codex",
|
|
293
293
|
"category": "skill",
|
|
294
|
-
"sha256": "
|
|
294
|
+
"sha256": "791dd8e89b63dfd0714538b3b15d0b4750b6889f538b65f7137bb93f091e02d9",
|
|
295
295
|
"source": "skills/cabloy-worktree-environment/SKILL.md",
|
|
296
296
|
"target": ".agents/skills/cabloy-worktree-environment/SKILL.md"
|
|
297
297
|
},
|
|
@@ -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,28 +571,28 @@
|
|
|
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
|
},
|
|
592
592
|
{
|
|
593
593
|
"adapter": "claude",
|
|
594
594
|
"category": "skill",
|
|
595
|
-
"sha256": "
|
|
595
|
+
"sha256": "0d1901134f7222902cfc702275ed7bd83a4e3a1d72c3543a77c8ab5d7cabaa55",
|
|
596
596
|
"source": "skills/cabloy-workflow/evals/evals.json",
|
|
597
597
|
"target": ".claude/skills/cabloy-workflow/evals/evals.json"
|
|
598
598
|
},
|
|
@@ -613,7 +613,7 @@
|
|
|
613
613
|
{
|
|
614
614
|
"adapter": "claude",
|
|
615
615
|
"category": "skill",
|
|
616
|
-
"sha256": "
|
|
616
|
+
"sha256": "ff0760f6fa7c24f561fdcfa07094d9d6e8d82fcef358458a36ff0c38a30ea89e",
|
|
617
617
|
"source": "skills/cabloy-workflow/SKILL.md",
|
|
618
618
|
"target": ".claude/skills/cabloy-workflow/SKILL.md"
|
|
619
619
|
},
|
|
@@ -627,7 +627,7 @@
|
|
|
627
627
|
{
|
|
628
628
|
"adapter": "claude",
|
|
629
629
|
"category": "skill",
|
|
630
|
-
"sha256": "
|
|
630
|
+
"sha256": "791dd8e89b63dfd0714538b3b15d0b4750b6889f538b65f7137bb93f091e02d9",
|
|
631
631
|
"source": "skills/cabloy-worktree-environment/SKILL.md",
|
|
632
632
|
"target": ".claude/skills/cabloy-worktree-environment/SKILL.md"
|
|
633
633
|
},
|
|
@@ -683,7 +683,7 @@
|
|
|
683
683
|
{
|
|
684
684
|
"adapter": "cursor",
|
|
685
685
|
"category": "policy",
|
|
686
|
-
"sha256": "
|
|
686
|
+
"sha256": "db2467e225f30b74efb312c45572324f75a6a81077e19b7723ffd640a45793f9",
|
|
687
687
|
"source": "policies/repository.md",
|
|
688
688
|
"target": ".cursor/rules/cabloy-governance.mdc"
|
|
689
689
|
},
|
|
@@ -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,28 +921,28 @@
|
|
|
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
|
},
|
|
942
942
|
{
|
|
943
943
|
"adapter": "cursor",
|
|
944
944
|
"category": "skill",
|
|
945
|
-
"sha256": "
|
|
945
|
+
"sha256": "0d1901134f7222902cfc702275ed7bd83a4e3a1d72c3543a77c8ab5d7cabaa55",
|
|
946
946
|
"source": "skills/cabloy-workflow/evals/evals.json",
|
|
947
947
|
"target": ".cursor/skills/cabloy-workflow/evals/evals.json"
|
|
948
948
|
},
|
|
@@ -963,7 +963,7 @@
|
|
|
963
963
|
{
|
|
964
964
|
"adapter": "cursor",
|
|
965
965
|
"category": "skill",
|
|
966
|
-
"sha256": "
|
|
966
|
+
"sha256": "ff0760f6fa7c24f561fdcfa07094d9d6e8d82fcef358458a36ff0c38a30ea89e",
|
|
967
967
|
"source": "skills/cabloy-workflow/SKILL.md",
|
|
968
968
|
"target": ".cursor/skills/cabloy-workflow/SKILL.md"
|
|
969
969
|
},
|
|
@@ -977,7 +977,7 @@
|
|
|
977
977
|
{
|
|
978
978
|
"adapter": "cursor",
|
|
979
979
|
"category": "skill",
|
|
980
|
-
"sha256": "
|
|
980
|
+
"sha256": "791dd8e89b63dfd0714538b3b15d0b4750b6889f538b65f7137bb93f091e02d9",
|
|
981
981
|
"source": "skills/cabloy-worktree-environment/SKILL.md",
|
|
982
982
|
"target": ".cursor/skills/cabloy-worktree-environment/SKILL.md"
|
|
983
983
|
},
|
|
@@ -1005,14 +1005,14 @@
|
|
|
1005
1005
|
{
|
|
1006
1006
|
"adapter": "codex",
|
|
1007
1007
|
"category": "policy",
|
|
1008
|
-
"sha256": "
|
|
1008
|
+
"sha256": "307edb0409d7d723c213c534713d2477ba000f19571e054d5498aeb9578b22bb",
|
|
1009
1009
|
"source": "policies/repository.md",
|
|
1010
1010
|
"target": "AGENTS.md"
|
|
1011
1011
|
},
|
|
1012
1012
|
{
|
|
1013
1013
|
"adapter": "claude",
|
|
1014
1014
|
"category": "policy",
|
|
1015
|
-
"sha256": "
|
|
1015
|
+
"sha256": "307edb0409d7d723c213c534713d2477ba000f19571e054d5498aeb9578b22bb",
|
|
1016
1016
|
"source": "policies/repository.md",
|
|
1017
1017
|
"target": "CLAUDE.md"
|
|
1018
1018
|
}
|
|
@@ -71,6 +71,7 @@ Before inventing a custom implementation path:
|
|
|
71
71
|
- Treat hooks, permissions, local settings, credentials, MCP registration, command discovery, and automatic command execution as platform-specific integrations, not portable rule or skill capabilities.
|
|
72
72
|
- After implementation, do not launch broad reviews automatically; when review is needed, scope it to the current diff and report only high-confidence issues.
|
|
73
73
|
- Do not modify shared environment identity or ports merely to bypass a busy resource. For intentional parallel worktree setup, follow `repo-docs/fullstack/parallel-worktree-environment.md`; otherwise wait for the shared resource or ask the user. Create or change worktree-local environment overrides only through the explicitly invoked `cabloy-worktree-environment` skill and its confirmation phase, and only in `vona/env/.env.local` and `zova/env/.env.local`; never modify flavor-, mode-, app-mode-, or runtime-specific `.env.*.local` files. The skill derives the standard `APP_NAME`, `SERVER_LISTEN_PORT`, `DEV_SERVER_PORT`, `DEV_SERVER_HMR_PORT`, and API-derived `API_BASE_URL` tuple only from Git worktree metadata and fixed port baselines; never read or expose `.env*` content while recommending values. Admin and Web are alternative commands using this shared tuple and must not run concurrently in one worktree; use another linked worktree for concurrent use. Detect the active edition before choosing scripts, and never run `npm run init` as an automatic follow-up.
|
|
74
|
+
- Before `npm run test:e2e`, verify exclusive use of the effective test-database cleanup scope, Redis cleanup namespace, public/runtime paths, and listener; a free port or separate worktree alone is insufficient. If a standing authorization covers this checkout and its resources remain exclusively assigned with no conflicting process, do not repeatedly ask to run the managed suite; if scope or ownership changes or is uncertain, wait or ask. This does not authorize manual resets, broader cleanup, or changing shared configuration. See `repo-docs/reference/repo-scripts.md`.
|
|
74
75
|
- For SSR theme-sensitive frontend work, detect the active edition marker and UI library before making assumptions. Cabloy Basic currently means DaisyUI + Tailwind CSS assumptions; Cabloy Start currently means Vuetify assumptions.
|
|
75
76
|
- In Web SSR without cookie-backed theme resolution, do not treat server reads of `$theme.dark`, `$theme.darkMode`, or `$token` as final browser truth. Keep theme-sensitive SSR branching hydration-tolerant or defer final theme-sensitive decisions to the client.
|
|
76
77
|
- Do not assume Cabloy Basic and Cabloy Start use the same adapter-level SSR theme handoff. Verify the active theme handler and client hydration path before changing SSR theme behavior.
|
|
@@ -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
|
@@ -19,6 +19,8 @@ Use exact instantiated IDs in declaration-body Traceability. A wildcard or abbre
|
|
|
19
19
|
|
|
20
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
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
|
+
|
|
22
24
|
## Minimal connected example
|
|
23
25
|
|
|
24
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.
|
|
@@ -69,7 +71,7 @@ Acceptance checks:
|
|
|
69
71
|
- The selected ATP passes and retains its required proof.
|
|
70
72
|
```
|
|
71
73
|
|
|
72
|
-
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.
|
|
73
75
|
|
|
74
76
|
### test-plan.md
|
|
75
77
|
|
|
@@ -109,7 +111,7 @@ Setup, Procedure, Expected result, Minimum proof, and Traceability must each be
|
|
|
109
111
|
| `WBS-DEMO-10-01` | `not-started` | None; execution has not begun. | Confirm the bounded execution dossier. |
|
|
110
112
|
```
|
|
111
113
|
|
|
112
|
-
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.
|
|
113
115
|
|
|
114
116
|
## Three gates, not one success signal
|
|
115
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 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`;
|
|
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
|
|