sdtk-kit 0.3.4 → 0.3.5
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/assets/manifest/toolkit-bundle.manifest.json +25 -25
- package/assets/manifest/toolkit-bundle.sha256.txt +10 -10
- package/assets/toolkit/toolkit/skills/sdtk-api-doc/SKILL.md +5 -4
- package/assets/toolkit/toolkit/skills/sdtk-arch/SKILL.md +14 -12
- package/assets/toolkit/toolkit/skills/sdtk-ba/SKILL.md +7 -6
- package/assets/toolkit/toolkit/skills/sdtk-qa/SKILL.md +8 -7
- package/assets/toolkit/toolkit/skills/sdtk-test-case-spec/SKILL.md +4 -6
- package/assets/toolkit/toolkit/skills-claude/api-doc/SKILL.md +7 -6
- package/assets/toolkit/toolkit/skills-claude/arch/SKILL.md +20 -18
- package/assets/toolkit/toolkit/skills-claude/ba/SKILL.md +13 -12
- package/assets/toolkit/toolkit/skills-claude/qa/SKILL.md +14 -13
- package/assets/toolkit/toolkit/skills-claude/test-case-spec/SKILL.md +9 -11
- package/package.json +44 -44
|
@@ -1,5 +1,8 @@
|
|
|
1
1
|
{
|
|
2
|
-
"
|
|
2
|
+
"version": "0.3.5",
|
|
3
|
+
"sourceCommit": "537f76cfcb2d42882cc5fb19946f0389279e1583",
|
|
4
|
+
"buildTimestamp": "2026-03-11T08:51:43Z",
|
|
5
|
+
"fileCount": 81,
|
|
3
6
|
"files": [
|
|
4
7
|
{
|
|
5
8
|
"path": "toolkit/AGENTS.md",
|
|
@@ -98,8 +101,8 @@
|
|
|
98
101
|
},
|
|
99
102
|
{
|
|
100
103
|
"path": "toolkit/skills/sdtk-api-doc/SKILL.md",
|
|
101
|
-
"sha256": "
|
|
102
|
-
"size":
|
|
104
|
+
"sha256": "2c4bc8edda84f20bf05130fdf19b9abd562dd87b03508301dff9ccd877b52a2f",
|
|
105
|
+
"size": 2248
|
|
103
106
|
},
|
|
104
107
|
{
|
|
105
108
|
"path": "toolkit/skills/sdtk-arch/references/API_DESIGN_CREATION_RULES.md",
|
|
@@ -128,13 +131,13 @@
|
|
|
128
131
|
},
|
|
129
132
|
{
|
|
130
133
|
"path": "toolkit/skills/sdtk-arch/SKILL.md",
|
|
131
|
-
"sha256": "
|
|
132
|
-
"size":
|
|
134
|
+
"sha256": "78275557bbea966134422423fb6910cecdc5468e7bf2abb777ff1c4233345639",
|
|
135
|
+
"size": 2597
|
|
133
136
|
},
|
|
134
137
|
{
|
|
135
138
|
"path": "toolkit/skills/sdtk-ba/SKILL.md",
|
|
136
|
-
"sha256": "
|
|
137
|
-
"size":
|
|
139
|
+
"sha256": "0a7c6aa20be2e29aa2124355264ee45847df76f635437c2d05ddd26f7121f12e",
|
|
140
|
+
"size": 1177
|
|
138
141
|
},
|
|
139
142
|
{
|
|
140
143
|
"path": "toolkit/skills/sdtk-design-layout/SKILL.md",
|
|
@@ -168,8 +171,8 @@
|
|
|
168
171
|
},
|
|
169
172
|
{
|
|
170
173
|
"path": "toolkit/skills/sdtk-qa/SKILL.md",
|
|
171
|
-
"sha256": "
|
|
172
|
-
"size":
|
|
174
|
+
"sha256": "564c536395227511ac9be215e41a3b5604e2f249da28319417ca75a6bfe8ed3b",
|
|
175
|
+
"size": 1459
|
|
173
176
|
},
|
|
174
177
|
{
|
|
175
178
|
"path": "toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md",
|
|
@@ -218,8 +221,8 @@
|
|
|
218
221
|
},
|
|
219
222
|
{
|
|
220
223
|
"path": "toolkit/skills/sdtk-test-case-spec/SKILL.md",
|
|
221
|
-
"sha256": "
|
|
222
|
-
"size":
|
|
224
|
+
"sha256": "727a9870a455e9c455b2c405cb52c6b9867f229fa56d8ce9408e66b6f6cae4a5",
|
|
225
|
+
"size": 2842
|
|
223
226
|
},
|
|
224
227
|
{
|
|
225
228
|
"path": "toolkit/skills-claude/api-design-spec/SKILL.md",
|
|
@@ -228,18 +231,18 @@
|
|
|
228
231
|
},
|
|
229
232
|
{
|
|
230
233
|
"path": "toolkit/skills-claude/api-doc/SKILL.md",
|
|
231
|
-
"sha256": "
|
|
232
|
-
"size":
|
|
234
|
+
"sha256": "6f6ddb470bc61d286b84418e299b360d5f148e6bed75fa50b6c8f2929e6fe49c",
|
|
235
|
+
"size": 2518
|
|
233
236
|
},
|
|
234
237
|
{
|
|
235
238
|
"path": "toolkit/skills-claude/arch/SKILL.md",
|
|
236
|
-
"sha256": "
|
|
237
|
-
"size":
|
|
239
|
+
"sha256": "e293fd71f9fc71ac63e5e53bf55fbfe9c71e186e298b2fd3429c71a4e972a8b1",
|
|
240
|
+
"size": 4175
|
|
238
241
|
},
|
|
239
242
|
{
|
|
240
243
|
"path": "toolkit/skills-claude/ba/SKILL.md",
|
|
241
|
-
"sha256": "
|
|
242
|
-
"size":
|
|
244
|
+
"sha256": "4dd1db27839c73a8ec0bba2b465b7cacffd55393a325a822ced8f2f209f6b51b",
|
|
245
|
+
"size": 2648
|
|
243
246
|
},
|
|
244
247
|
{
|
|
245
248
|
"path": "toolkit/skills-claude/design-layout/SKILL.md",
|
|
@@ -273,8 +276,8 @@
|
|
|
273
276
|
},
|
|
274
277
|
{
|
|
275
278
|
"path": "toolkit/skills-claude/qa/SKILL.md",
|
|
276
|
-
"sha256": "
|
|
277
|
-
"size":
|
|
279
|
+
"sha256": "3ab5af1b27aa0947052ef7b76abca132d89b78b74516b8668474c08c344289aa",
|
|
280
|
+
"size": 2956
|
|
278
281
|
},
|
|
279
282
|
{
|
|
280
283
|
"path": "toolkit/skills-claude/screen-design-spec/SKILL.md",
|
|
@@ -283,8 +286,8 @@
|
|
|
283
286
|
},
|
|
284
287
|
{
|
|
285
288
|
"path": "toolkit/skills-claude/test-case-spec/SKILL.md",
|
|
286
|
-
"sha256": "
|
|
287
|
-
"size":
|
|
289
|
+
"sha256": "c397431a7752fcdee1dbb7720472703d262bfcc8fb543c4562fbc24a79064769",
|
|
290
|
+
"size": 2806
|
|
288
291
|
},
|
|
289
292
|
{
|
|
290
293
|
"path": "toolkit/templates/docs/api/API_DESIGN_CREATION_RULES.md",
|
|
@@ -406,8 +409,5 @@
|
|
|
406
409
|
"sha256": "2b5d4d10019e3c9b3219d92b8123acc85872d9c76230107206e7a270a5ece5a2",
|
|
407
410
|
"size": 3255
|
|
408
411
|
}
|
|
409
|
-
]
|
|
410
|
-
"sourceCommit": "965d6ad1f80a42b8b49c4296ec7a96ffef2655e3",
|
|
411
|
-
"version": "0.3.4",
|
|
412
|
-
"fileCount": 81
|
|
412
|
+
]
|
|
413
413
|
}
|
|
@@ -17,21 +17,21 @@ c6147e7b01632cb6ffa017af43e4e5c9e1f98d160ed812ade1d087b1f3ca5490 toolkit/skills
|
|
|
17
17
|
13f26a3307894b9bfb570d75f6db4ccb61104064d19661ec2a26a1b9984f4c97 toolkit/skills/sdtk-api-doc/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
|
|
18
18
|
decffe52425e22b3dd82e9c8f3768aefbb209ec58237107d84f583fee876ea8f toolkit/skills/sdtk-api-doc/references/FLOWCHART_CREATION_RULES.md
|
|
19
19
|
f29c6774019ef0789dfb88678e1ab31d4d8eb7b3ab69b2115368ef5d879e5276 toolkit/skills/sdtk-api-doc/references/YAML_CREATION_RULES.md
|
|
20
|
-
|
|
20
|
+
2c4bc8edda84f20bf05130fdf19b9abd562dd87b03508301dff9ccd877b52a2f toolkit/skills/sdtk-api-doc/SKILL.md
|
|
21
21
|
9adf1e46833411a861fb7426c37baac69689b9e3120a8ed1e4a3224de44a8dd2 toolkit/skills/sdtk-arch/references/API_DESIGN_CREATION_RULES.md
|
|
22
22
|
13f26a3307894b9bfb570d75f6db4ccb61104064d19661ec2a26a1b9984f4c97 toolkit/skills/sdtk-arch/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
|
|
23
23
|
b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0 toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md
|
|
24
24
|
decffe52425e22b3dd82e9c8f3768aefbb209ec58237107d84f583fee876ea8f toolkit/skills/sdtk-arch/references/FLOWCHART_CREATION_RULES.md
|
|
25
25
|
f29c6774019ef0789dfb88678e1ab31d4d8eb7b3ab69b2115368ef5d879e5276 toolkit/skills/sdtk-arch/references/YAML_CREATION_RULES.md
|
|
26
|
-
|
|
27
|
-
|
|
26
|
+
78275557bbea966134422423fb6910cecdc5468e7bf2abb777ff1c4233345639 toolkit/skills/sdtk-arch/SKILL.md
|
|
27
|
+
0a7c6aa20be2e29aa2124355264ee45847df76f635437c2d05ddd26f7121f12e toolkit/skills/sdtk-ba/SKILL.md
|
|
28
28
|
8eabb7bdb821a91766ccd5b5fdcc1a4e876b51052cd6c6429b98b4d9946e2b1a toolkit/skills/sdtk-design-layout/SKILL.md
|
|
29
29
|
7a7f5a799247896a8ddebc5cefec25450bf9284d34044b6b69b13e4535c005a1 toolkit/skills/sdtk-dev/SKILL.md
|
|
30
30
|
4b242b5f86d0074538e14721cc66c0fbaac5757e984796145f5e4477c89c6729 toolkit/skills/sdtk-dev-backend/SKILL.md
|
|
31
31
|
390d895ab5da1fd214efecdbbd13c81e92815d4db157a7e9e8f32c79e09439dd toolkit/skills/sdtk-dev-frontend/SKILL.md
|
|
32
32
|
e6560b5a0c893d66117eedac3762bb0758553a80bcd1e7c24c84ba91f6ab7f9c toolkit/skills/sdtk-orchestrator/SKILL.md
|
|
33
33
|
7dd81943172b1d7a96093424b0ba76519db3d713272374d5c4aedb15f37adbe2 toolkit/skills/sdtk-pm/SKILL.md
|
|
34
|
-
|
|
34
|
+
564c536395227511ac9be215e41a3b5604e2f249da28319417ca75a6bfe8ed3b toolkit/skills/sdtk-qa/SKILL.md
|
|
35
35
|
97f65fd84c80e4836c9bbb82d8b7fc81527336c55dbbd82ea5e69672e21b22e4 toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md
|
|
36
36
|
a9b414a07d76e63331ffc832dea2381357f9a99e2cd82ea74f713b3a9d7acee7 toolkit/skills/sdtk-screen-design-spec/references/figma-mcp.md
|
|
37
37
|
b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0 toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
|
|
@@ -41,20 +41,20 @@ ae0bc9b120c19a142f10cc79168a8f7d6bf8a37e48341fc16cbc74bbdc2e692c toolkit/skills
|
|
|
41
41
|
876d546e077ce451082792776360a4a309cc79a34c74234f1b55f80c56b159d1 toolkit/skills/sdtk-screen-design-spec/SKILL.md
|
|
42
42
|
7c21e74f5eee712c6b65665b4f10483ed008113186a92dc0a4673ce1fcd3ef5c toolkit/skills/sdtk-test-case-spec/references/TEST_CASE_CREATION_RULES.md
|
|
43
43
|
4d1e813908114f2be68007fb7373973e2c6e0aebc5a6305b8b19443d5ae477d0 toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py
|
|
44
|
-
|
|
44
|
+
727a9870a455e9c455b2c405cb52c6b9867f229fa56d8ce9408e66b6f6cae4a5 toolkit/skills/sdtk-test-case-spec/SKILL.md
|
|
45
45
|
123873681ff65792a9a269b264155c65a5feb68b23e4eeb1e68cb7da1a137d54 toolkit/skills-claude/api-design-spec/SKILL.md
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
46
|
+
6f6ddb470bc61d286b84418e299b360d5f148e6bed75fa50b6c8f2929e6fe49c toolkit/skills-claude/api-doc/SKILL.md
|
|
47
|
+
e293fd71f9fc71ac63e5e53bf55fbfe9c71e186e298b2fd3429c71a4e972a8b1 toolkit/skills-claude/arch/SKILL.md
|
|
48
|
+
4dd1db27839c73a8ec0bba2b465b7cacffd55393a325a822ced8f2f209f6b51b toolkit/skills-claude/ba/SKILL.md
|
|
49
49
|
9765f229108c5aff27457489707218570ad83dc362353a79c2f5a78607adf4de toolkit/skills-claude/design-layout/SKILL.md
|
|
50
50
|
cea9f6512bc805d5b22a84a4ef8dbd229b4f7a3f073f9e125e933e6e79a206d5 toolkit/skills-claude/dev/SKILL.md
|
|
51
51
|
142a8fe088a4b0326ca79e00200cb5f562c53728b7adc83e6b749db6e29f1d0d toolkit/skills-claude/dev-backend/SKILL.md
|
|
52
52
|
1631bd51bc3d0106c18f4c00412f6279626bdce9f0e310822d5dcdff08063a88 toolkit/skills-claude/dev-frontend/SKILL.md
|
|
53
53
|
c8e8303f1833e71cacdf20b1f398e476b44b3de14fbffad9a404c2a68fa713a3 toolkit/skills-claude/orchestrator/SKILL.md
|
|
54
54
|
b34621fe61957e573c616ad816d591a60a6c8d1333d0bfb71f39f45b93331cb0 toolkit/skills-claude/pm/SKILL.md
|
|
55
|
-
|
|
55
|
+
3ab5af1b27aa0947052ef7b76abca132d89b78b74516b8668474c08c344289aa toolkit/skills-claude/qa/SKILL.md
|
|
56
56
|
5686da60872f1a3c6791e9a740897d4a564f40d53d54902a47fbc3165e68a1ec toolkit/skills-claude/screen-design-spec/SKILL.md
|
|
57
|
-
|
|
57
|
+
c397431a7752fcdee1dbb7720472703d262bfcc8fb543c4562fbc24a79064769 toolkit/skills-claude/test-case-spec/SKILL.md
|
|
58
58
|
9adf1e46833411a861fb7426c37baac69689b9e3120a8ed1e4a3224de44a8dd2 toolkit/templates/docs/api/API_DESIGN_CREATION_RULES.md
|
|
59
59
|
d2aa0ee3a7c5351700b3bffb4ba66e8056ed955f55903c744c694624730038cb toolkit/templates/docs/api/API_DESIGN_DETAIL_TEMPLATE.md
|
|
60
60
|
13f26a3307894b9bfb570d75f6db4ccb61104064d19661ec2a26a1b9984f4c97 toolkit/templates/docs/api/API_DESIGN_FLOWCHART_CREATION_RULES.md
|
|
@@ -23,16 +23,17 @@ description: Generate OpenAPI 3.x YAML and PlantUML flow diagrams for a feature
|
|
|
23
23
|
2. Read and apply split API rule sources:
|
|
24
24
|
- `./references/YAML_CREATION_RULES.md` for YAML contract rules
|
|
25
25
|
- `./references/API_DESIGN_FLOWCHART_CREATION_RULES.md` for flow list / flowchart rules
|
|
26
|
-
3. Define endpoints mapped to UC-xx; keep path naming consistent across CRUD/search/list/mst patterns.
|
|
26
|
+
3. Define endpoints mapped to UC-xx; keep path naming consistent across CRUD/search/list/mst patterns and apply `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming.
|
|
27
27
|
4. For each endpoint, document request/response schema and error cases.
|
|
28
28
|
5. Generate/update endpoint markdown (`[FEATURE_KEY]_ENDPOINTS.md`) with summary tables, API type grouping, and screen-logic mapping.
|
|
29
|
-
6. Generate PlantUML flows including
|
|
29
|
+
6. Generate PlantUML flows including auth, permission check, validation, main logic, and error exits.
|
|
30
30
|
7. Ensure traceability notes reference UC/BR where relevant.
|
|
31
|
-
8.
|
|
31
|
+
8. For benchmark runs, if the requirement or upstream artifacts mark an OQ as expected OPEN, keep that ambiguity explicit in flow list / endpoint docs instead of silently collapsing it.
|
|
32
|
+
9. Validate English output hygiene when generating English artifacts:
|
|
32
33
|
- no mixed-language leftovers in narrative text
|
|
33
34
|
- no mojibake/encoding corruption markers
|
|
34
35
|
- terminology consistency across endpoint detail, summary tables, and flow labels
|
|
35
|
-
|
|
36
|
+
10. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `sdtk-api-design-spec` after YAML + flow list are updated.
|
|
36
37
|
|
|
37
38
|
## Reference
|
|
38
39
|
- Deeper analysis: `docs/specs/API_DOC_SKILL_ANALYSIS.md` (if present).
|
|
@@ -17,18 +17,19 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
|
|
|
17
17
|
- `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
|
|
18
18
|
|
|
19
19
|
## Process
|
|
20
|
-
1. Read BA spec
|
|
20
|
+
1. Read BA spec and PRD/backlog.
|
|
21
21
|
2. Read `sdtk.config.json` for project stack assumptions (backend/frontend/db/auth).
|
|
22
|
-
3. If architecture output includes API contracts/flows, read and apply
|
|
22
|
+
3. If architecture output includes API contracts/flows, read and apply:
|
|
23
23
|
- `./references/YAML_CREATION_RULES.md`
|
|
24
24
|
- `./references/API_DESIGN_FLOWCHART_CREATION_RULES.md`
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
25
|
+
- `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming and multi-word path style
|
|
26
|
+
4. If architecture output includes screen flow-action specs, read and apply `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
|
|
27
|
+
5. If API detail spec is required, use `sdtk-api-design-spec` to build/update `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md` using YAML + flow list.
|
|
28
|
+
6. For complex UI flow-action specs, use `sdtk-screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
|
|
28
29
|
7. Define:
|
|
29
30
|
- System components + data model
|
|
30
|
-
- API endpoints and flows
|
|
31
|
-
- Screen layouts
|
|
31
|
+
- API endpoints and flows
|
|
32
|
+
- Screen layouts
|
|
32
33
|
- Security/authz decisions
|
|
33
34
|
8. Create/update:
|
|
34
35
|
- OpenAPI YAML + API endpoint markdown
|
|
@@ -37,8 +38,9 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
|
|
|
37
38
|
- Database spec (if DB impact exists)
|
|
38
39
|
- Flow-action spec and design layout (if UI impact exists)
|
|
39
40
|
9. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
|
|
40
|
-
- EN artifacts use English narrative text (except clearly marked original-language appendix blocks)
|
|
41
|
-
- No mojibake/encoding corruption in markdown/yaml/txt outputs
|
|
42
|
-
10.
|
|
43
|
-
11.
|
|
44
|
-
12.
|
|
41
|
+
- EN artifacts use English narrative text (except clearly marked original-language appendix blocks)
|
|
42
|
+
- No mojibake/encoding corruption in markdown/yaml/txt outputs
|
|
43
|
+
10. For benchmark runs, apply `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`: keep benchmark-expected open questions explicitly OPEN unless the requirement source resolves them.
|
|
44
|
+
11. If anything is unclear, record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to `@pm` for a decision.
|
|
45
|
+
12. Update shared state + Phase 3 checklist.
|
|
46
|
+
13. Handoff: `@dev please implement ...`.
|
|
@@ -9,7 +9,7 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
|
|
|
9
9
|
- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
|
|
10
10
|
|
|
11
11
|
## Process
|
|
12
|
-
1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md`
|
|
12
|
+
1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` and any source requirements.
|
|
13
13
|
2. Produce:
|
|
14
14
|
- Glossary
|
|
15
15
|
- BR-xx (numbered)
|
|
@@ -17,8 +17,9 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
|
|
|
17
17
|
- AC-xx (mapped to UC/BR)
|
|
18
18
|
- NFR-xx
|
|
19
19
|
- Risks + Open Questions
|
|
20
|
-
- Traceability summary table (REQ
|
|
21
|
-
3. If source requirements are VI/JP
|
|
22
|
-
4.
|
|
23
|
-
5.
|
|
24
|
-
6.
|
|
20
|
+
- Traceability summary table (REQ -> UC/BR/AC)
|
|
21
|
+
3. If source requirements are VI/JP, preserve the original text and add a literal EN translation in appendices.
|
|
22
|
+
4. For benchmark runs, apply `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`: keep benchmark-expected open questions explicitly OPEN and do not silently resolve them in BA output.
|
|
23
|
+
5. If anything is unclear, record OQ-xx in BA_SPEC "Open Questions" and escalate to `@pm` for a decision.
|
|
24
|
+
6. Update `SHARED_PLANNING.md` and `QUALITY_CHECKLIST.md` Phase 2.
|
|
25
|
+
7. Handoff: `@pm specs ready for PRD`.
|
|
@@ -13,10 +13,11 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
|
|
|
13
13
|
## Process
|
|
14
14
|
1. Validate prerequisites: DEV phase completed + code review PASS.
|
|
15
15
|
2. Create test strategy mapped to UC/AC.
|
|
16
|
-
3. If test-case specification artifact is required, invoke `sdtk-test-case-spec` and align counts/coverage with release testing scope.
|
|
17
|
-
4.
|
|
18
|
-
5.
|
|
19
|
-
6.
|
|
20
|
-
7.
|
|
21
|
-
8.
|
|
22
|
-
9.
|
|
16
|
+
3. If test-case specification artifact is required, invoke `sdtk-test-case-spec` and align counts/coverage with release testing scope. Keep the structured TEST_CASE total consistent with the release-report baseline; track E2E separately if needed.
|
|
17
|
+
4. Apply `governance/ai/core/SDTK_BENCHMARK_QA_MODE_POLICY.md` for benchmark-mode verdict rules when no executable build exists.
|
|
18
|
+
5. If acceptance criteria / expected behavior is unclear, record OQ-xx in QA report and preserve benchmark-expected ambiguity per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`; escalate to `@pm` if still missing info.
|
|
19
|
+
6. Execute/record results (unit/integration/e2e as applicable).
|
|
20
|
+
7. Record defects with severity and status.
|
|
21
|
+
8. Decide: APPROVED vs REJECTED (with reasons).
|
|
22
|
+
9. Update shared state + Phase 5 checklist.
|
|
23
|
+
10. Handoff: `@pm please finalize release status ...` if approved.
|
|
@@ -24,24 +24,23 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
|
|
|
24
24
|
## Core Rules
|
|
25
25
|
1. Apply `./references/TEST_CASE_CREATION_RULES.md` first.
|
|
26
26
|
2. Keep section order fixed (Statistic -> Abbreviations -> Scope -> References -> Environment -> Coverage -> Screen-based UTC/ITC -> OQ -> STC/UAT note).
|
|
27
|
-
3. Use screen-first layout to mirror worksheet structure
|
|
28
|
-
- each screen can have `[SCREEN_KEY]_UTC` and `[SCREEN_KEY]_ITC`.
|
|
27
|
+
3. Use screen-first layout to mirror worksheet structure.
|
|
29
28
|
4. Keep one unified 18-column schema for UTC/ITC rows.
|
|
30
29
|
5. Keep stable case IDs; do not renumber only because of regrouping.
|
|
31
|
-
6. Track unresolved decisions via `OQ-xx`.
|
|
30
|
+
6. Track unresolved decisions via `OQ-xx` and keep benchmark-expected OQs explicitly OPEN per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`.
|
|
32
31
|
|
|
33
32
|
## Procedure
|
|
34
33
|
1. Resolve output path:
|
|
35
34
|
- default `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
|
|
36
35
|
- use `docs/en/qa/...` only if the repo already follows `docs/en/**`.
|
|
37
|
-
2. Build/refresh `Statistic Summary (Excel-aligned)
|
|
38
|
-
- include UT total, IT total, grand total.
|
|
36
|
+
2. Build/refresh `Statistic Summary (Excel-aligned)` with UT total, IT total, and grand total.
|
|
39
37
|
3. Build `Feature Coverage Matrix` from flow/action and API docs.
|
|
40
38
|
4. Split UTC/ITC by screen sections (`screen-first`), not by test type only.
|
|
41
39
|
5. Fill conflict/permission/error-path cases from Q&A decisions and API contracts.
|
|
42
40
|
6. Record unresolved items in section `Open Questions`.
|
|
43
41
|
7. Validate:
|
|
44
42
|
- counts in summary match table rows
|
|
43
|
+
- structured TEST_CASE total stays aligned with the QA release-report baseline; if E2E is tracked separately, label it separately instead of inflating grand total
|
|
45
44
|
- no placeholder tokens like `??`
|
|
46
45
|
- out-of-scope boundaries are explicit
|
|
47
46
|
|
|
@@ -62,4 +61,3 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
|
|
|
62
61
|
python "toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py" `
|
|
63
62
|
--file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
|
|
64
63
|
```
|
|
65
|
-
|
|
@@ -5,8 +5,8 @@ description: Generate OpenAPI 3.x YAML and PlantUML flow diagrams for a feature
|
|
|
5
5
|
|
|
6
6
|
## Required Inputs (read before proceeding)
|
|
7
7
|
Read the following artifacts for the current feature:
|
|
8
|
-
1. `docs/specs/BA_SPEC_*.md`
|
|
9
|
-
2. `docs/architecture/ARCH_DESIGN_*.md`
|
|
8
|
+
1. `docs/specs/BA_SPEC_*.md` - business rules, use cases
|
|
9
|
+
2. `docs/architecture/ARCH_DESIGN_*.md` - system components, data model
|
|
10
10
|
|
|
11
11
|
## Input
|
|
12
12
|
$ARGUMENTS
|
|
@@ -31,16 +31,17 @@ $ARGUMENTS
|
|
|
31
31
|
2. Read and apply split API rule sources:
|
|
32
32
|
- `.claude/skills/references/YAML_CREATION_RULES.md` for YAML contract rules
|
|
33
33
|
- `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md` for flow list / flowchart rules
|
|
34
|
-
3. Define endpoints mapped to UC-xx; keep path naming consistent across CRUD/search/list/mst patterns.
|
|
34
|
+
3. Define endpoints mapped to UC-xx; keep path naming consistent across CRUD/search/list/mst patterns and apply `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming.
|
|
35
35
|
4. For each endpoint, document request/response schema and error cases.
|
|
36
36
|
5. Generate/update endpoint markdown (`[FEATURE_KEY]_ENDPOINTS.md`) with summary tables, API type grouping, and screen-logic mapping.
|
|
37
|
-
6. Generate PlantUML flows including
|
|
37
|
+
6. Generate PlantUML flows including auth, permission check, validation, main logic, and error exits.
|
|
38
38
|
7. Ensure traceability notes reference UC/BR where relevant.
|
|
39
|
-
8.
|
|
39
|
+
8. For benchmark runs, if the requirement or upstream artifacts mark an OQ as expected OPEN, keep that ambiguity explicit in flow list / endpoint docs instead of silently collapsing it.
|
|
40
|
+
9. Validate English output hygiene when generating English artifacts:
|
|
40
41
|
- no mixed-language leftovers in narrative text
|
|
41
42
|
- no mojibake/encoding corruption markers
|
|
42
43
|
- terminology consistency across endpoint detail, summary tables, and flow labels
|
|
43
|
-
|
|
44
|
+
10. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `/api-design-spec` after YAML + flow list are updated.
|
|
44
45
|
|
|
45
46
|
## Reference
|
|
46
47
|
- Deeper analysis: `docs/specs/API_DOC_SKILL_ANALYSIS.md` (if present).
|
|
@@ -4,19 +4,19 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
## SDTK Pipeline Rules (always apply)
|
|
7
|
-
1. Pipeline: PM Initiation
|
|
7
|
+
1. Pipeline: PM Initiation -> BA Analysis -> PM Planning -> Architecture Design -> Development + Review -> QA Validation
|
|
8
8
|
2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
|
|
9
|
-
3. If unclear: log OQ-xx in artifact, escalate to PM
|
|
10
|
-
4. Traceability: REQ
|
|
9
|
+
3. If unclear: log OQ-xx in artifact, escalate to PM
|
|
10
|
+
4. Traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA
|
|
11
11
|
5. Code review must be COMPLETE before QA phase can start
|
|
12
|
-
6. Do not skip phases. If inputs missing, ask focused questions.
|
|
12
|
+
6. Do not skip phases. If inputs are missing, ask focused questions.
|
|
13
13
|
|
|
14
14
|
## Prerequisites (verify before proceeding)
|
|
15
15
|
Read QUALITY_CHECKLIST.md and verify:
|
|
16
16
|
- Phase 2 BA Analysis gate must show all items [x] Done.
|
|
17
17
|
- Phase 2+ PM Planning gate must show all items [x] Done.
|
|
18
18
|
|
|
19
|
-
If prerequisites
|
|
19
|
+
If prerequisites are not met, report which gate is missing and suggest user run the prerequisite phase first.
|
|
20
20
|
|
|
21
21
|
## Current Context
|
|
22
22
|
- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
|
|
@@ -27,7 +27,7 @@ If prerequisites NOT met: report which gate is missing, suggest user run the pre
|
|
|
27
27
|
## Input
|
|
28
28
|
$ARGUMENTS
|
|
29
29
|
|
|
30
|
-
If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
30
|
+
If no arguments are provided, read current feature context from SHARED_PLANNING.md.
|
|
31
31
|
|
|
32
32
|
# SDTK ARCH (Solution Architecture)
|
|
33
33
|
|
|
@@ -43,18 +43,19 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
|
43
43
|
- `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
|
|
44
44
|
|
|
45
45
|
## Process
|
|
46
|
-
1. Read BA spec
|
|
46
|
+
1. Read BA spec and PRD/backlog.
|
|
47
47
|
2. Read `sdtk.config.json` for project stack assumptions (backend/frontend/db/auth).
|
|
48
|
-
3. If architecture output includes API contracts/flows, read and apply
|
|
48
|
+
3. If architecture output includes API contracts/flows, read and apply:
|
|
49
49
|
- `.claude/skills/references/YAML_CREATION_RULES.md`
|
|
50
50
|
- `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md`
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
51
|
+
- `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming and multi-word path style
|
|
52
|
+
4. If architecture output includes screen flow-action specs, read and apply `.claude/skills/references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
|
|
53
|
+
5. If API detail spec is required, use `/api-design-spec` to build/update `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md` using YAML + flow list.
|
|
54
|
+
6. For complex UI flow-action specs, use `/screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
|
|
54
55
|
7. Define:
|
|
55
56
|
- System components + data model
|
|
56
|
-
- API endpoints and flows
|
|
57
|
-
- Screen layouts
|
|
57
|
+
- API endpoints and flows
|
|
58
|
+
- Screen layouts
|
|
58
59
|
- Security/authz decisions
|
|
59
60
|
8. Create/update:
|
|
60
61
|
- OpenAPI YAML + API endpoint markdown
|
|
@@ -63,8 +64,9 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
|
63
64
|
- Database spec (if DB impact exists)
|
|
64
65
|
- Flow-action spec and design layout (if UI impact exists)
|
|
65
66
|
9. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
|
|
66
|
-
- EN artifacts use English narrative text (except clearly marked original-language appendix blocks)
|
|
67
|
-
- No mojibake/encoding corruption in markdown/yaml/txt outputs
|
|
68
|
-
10.
|
|
69
|
-
11.
|
|
70
|
-
12.
|
|
67
|
+
- EN artifacts use English narrative text (except clearly marked original-language appendix blocks)
|
|
68
|
+
- No mojibake/encoding corruption in markdown/yaml/txt outputs
|
|
69
|
+
10. For benchmark runs, apply `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`: keep benchmark-expected open questions explicitly OPEN unless the requirement source resolves them.
|
|
70
|
+
11. If anything is unclear, record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to PM.
|
|
71
|
+
12. Update shared state + Phase 3 checklist.
|
|
72
|
+
13. Handoff: suggest user run `/dev` to implement the design.
|
|
@@ -4,18 +4,18 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
## SDTK Pipeline Rules (always apply)
|
|
7
|
-
1. Pipeline: PM Initiation
|
|
7
|
+
1. Pipeline: PM Initiation -> BA Analysis -> PM Planning -> Architecture Design -> Development + Review -> QA Validation
|
|
8
8
|
2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
|
|
9
|
-
3. If unclear: log OQ-xx in artifact, escalate to PM
|
|
10
|
-
4. Traceability: REQ
|
|
9
|
+
3. If unclear: log OQ-xx in artifact, escalate to PM
|
|
10
|
+
4. Traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA
|
|
11
11
|
5. Code review must be COMPLETE before QA phase can start
|
|
12
|
-
6. Do not skip phases. If inputs missing, ask focused questions.
|
|
12
|
+
6. Do not skip phases. If inputs are missing, ask focused questions.
|
|
13
13
|
|
|
14
14
|
## Prerequisites (verify before proceeding)
|
|
15
15
|
Read QUALITY_CHECKLIST.md and verify:
|
|
16
16
|
- Phase 1 PM Init gate must show all items [x] Done.
|
|
17
17
|
|
|
18
|
-
If prerequisites
|
|
18
|
+
If prerequisites are not met, report which gate is missing and suggest user run `/pm` first.
|
|
19
19
|
|
|
20
20
|
## Current Context
|
|
21
21
|
- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
|
|
@@ -26,7 +26,7 @@ If prerequisites NOT met: report which gate is missing, suggest user run `/pm` f
|
|
|
26
26
|
## Input
|
|
27
27
|
$ARGUMENTS
|
|
28
28
|
|
|
29
|
-
If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
29
|
+
If no arguments are provided, read current feature context from SHARED_PLANNING.md.
|
|
30
30
|
|
|
31
31
|
# SDTK BA (Business Analysis)
|
|
32
32
|
|
|
@@ -34,7 +34,7 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
|
34
34
|
- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
|
|
35
35
|
|
|
36
36
|
## Process
|
|
37
|
-
1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md`
|
|
37
|
+
1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` and any source requirements.
|
|
38
38
|
2. Produce:
|
|
39
39
|
- Glossary
|
|
40
40
|
- BR-xx (numbered)
|
|
@@ -42,8 +42,9 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
|
42
42
|
- AC-xx (mapped to UC/BR)
|
|
43
43
|
- NFR-xx
|
|
44
44
|
- Risks + Open Questions
|
|
45
|
-
- Traceability summary table (REQ
|
|
46
|
-
3. If source requirements are VI/JP
|
|
47
|
-
4.
|
|
48
|
-
5.
|
|
49
|
-
6.
|
|
45
|
+
- Traceability summary table (REQ -> UC/BR/AC)
|
|
46
|
+
3. If source requirements are VI/JP, preserve the original text and add a literal EN translation in appendices.
|
|
47
|
+
4. For benchmark runs, apply `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`: keep benchmark-expected open questions explicitly OPEN and do not silently resolve them in BA output.
|
|
48
|
+
5. If anything is unclear, record OQ-xx in BA_SPEC "Open Questions" and escalate to PM.
|
|
49
|
+
6. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
|
|
50
|
+
7. Handoff: suggest user run `/pm` to proceed with PRD planning.
|
|
@@ -4,18 +4,18 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
## SDTK Pipeline Rules (always apply)
|
|
7
|
-
1. Pipeline: PM Initiation
|
|
7
|
+
1. Pipeline: PM Initiation -> BA Analysis -> PM Planning -> Architecture Design -> Development + Review -> QA Validation
|
|
8
8
|
2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
|
|
9
|
-
3. If unclear: log OQ-xx in artifact, escalate to PM
|
|
10
|
-
4. Traceability: REQ
|
|
9
|
+
3. If unclear: log OQ-xx in artifact, escalate to PM
|
|
10
|
+
4. Traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA
|
|
11
11
|
5. Code review must be COMPLETE before QA phase can start
|
|
12
|
-
6. Do not skip phases. If inputs missing, ask focused questions.
|
|
12
|
+
6. Do not skip phases. If inputs are missing, ask focused questions.
|
|
13
13
|
|
|
14
14
|
## Prerequisites (verify before proceeding)
|
|
15
15
|
Read QUALITY_CHECKLIST.md and verify:
|
|
16
16
|
- Phase 4 DEV gate must show all items [x] Done (including code review completion).
|
|
17
17
|
|
|
18
|
-
If prerequisites
|
|
18
|
+
If prerequisites are not met, report which gate is missing and suggest user run `/dev` first to complete code review.
|
|
19
19
|
|
|
20
20
|
## Current Context
|
|
21
21
|
- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
|
|
@@ -26,7 +26,7 @@ If prerequisites NOT met: report which gate is missing, suggest user run `/dev`
|
|
|
26
26
|
## Input
|
|
27
27
|
$ARGUMENTS
|
|
28
28
|
|
|
29
|
-
If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
29
|
+
If no arguments are provided, read current feature context from SHARED_PLANNING.md.
|
|
30
30
|
|
|
31
31
|
# SDTK QA (Testing + Release Decision)
|
|
32
32
|
|
|
@@ -38,10 +38,11 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
|
|
|
38
38
|
## Process
|
|
39
39
|
1. Validate prerequisites: DEV phase completed + code review PASS.
|
|
40
40
|
2. Create test strategy mapped to UC/AC.
|
|
41
|
-
3. If test-case specification artifact is required, invoke `/test-case-spec` and align counts/coverage with release testing scope.
|
|
42
|
-
4.
|
|
43
|
-
5.
|
|
44
|
-
6.
|
|
45
|
-
7.
|
|
46
|
-
8.
|
|
47
|
-
9.
|
|
41
|
+
3. If test-case specification artifact is required, invoke `/test-case-spec` and align counts/coverage with release testing scope. Keep the structured TEST_CASE total consistent with the release-report baseline; track E2E separately if needed.
|
|
42
|
+
4. Apply `governance/ai/core/SDTK_BENCHMARK_QA_MODE_POLICY.md` for benchmark-mode verdict rules when no executable build exists.
|
|
43
|
+
5. If acceptance criteria / expected behavior is unclear, record OQ-xx in QA report and preserve benchmark-expected ambiguity per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`; escalate to PM.
|
|
44
|
+
6. Execute/record results (unit/integration/e2e as applicable).
|
|
45
|
+
7. Record defects with severity and status.
|
|
46
|
+
8. Decide: APPROVED vs REJECTED (with reasons).
|
|
47
|
+
9. Update shared state + Phase 5 checklist.
|
|
48
|
+
10. Handoff: suggest user run `/pm` to finalize release status if approved.
|
|
@@ -5,10 +5,10 @@ description: Generate screen-based QA test-case markdown in Excel-aligned layout
|
|
|
5
5
|
|
|
6
6
|
## Required Inputs (read before proceeding)
|
|
7
7
|
Read the following artifacts for the current feature:
|
|
8
|
-
1. `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
|
|
9
|
-
2. `docs/specs/BA_SPEC_[FEATURE_KEY].md`
|
|
10
|
-
3. `docs/api/[FEATURE_KEY]_ENDPOINTS.md`
|
|
11
|
-
4. `docs/specs/Q&A.md` or `docs/en/specs/Q&A.md`
|
|
8
|
+
1. `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` - screen/flow references
|
|
9
|
+
2. `docs/specs/BA_SPEC_[FEATURE_KEY].md` - business rules, use cases
|
|
10
|
+
3. `docs/api/[FEATURE_KEY]_ENDPOINTS.md` - API reference
|
|
11
|
+
4. `docs/specs/Q&A.md` or `docs/en/specs/Q&A.md` - clarification source (when available)
|
|
12
12
|
|
|
13
13
|
## Input
|
|
14
14
|
$ARGUMENTS
|
|
@@ -23,24 +23,23 @@ $ARGUMENTS
|
|
|
23
23
|
## Core Rules
|
|
24
24
|
1. Apply `.claude/skills/references/TEST_CASE_CREATION_RULES.md` first.
|
|
25
25
|
2. Keep section order fixed (Statistic -> Abbreviations -> Scope -> References -> Environment -> Coverage -> Screen-based UTC/ITC -> OQ -> STC/UAT note).
|
|
26
|
-
3. Use screen-first layout to mirror worksheet structure
|
|
27
|
-
- each screen can have `[SCREEN_KEY]_UTC` and `[SCREEN_KEY]_ITC`.
|
|
26
|
+
3. Use screen-first layout to mirror worksheet structure.
|
|
28
27
|
4. Keep one unified 18-column schema for UTC/ITC rows.
|
|
29
28
|
5. Keep stable case IDs; do not renumber only because of regrouping.
|
|
30
|
-
6. Track unresolved decisions via `OQ-xx`.
|
|
29
|
+
6. Track unresolved decisions via `OQ-xx` and keep benchmark-expected OQs explicitly OPEN per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`.
|
|
31
30
|
|
|
32
31
|
## Procedure
|
|
33
32
|
1. Resolve output path:
|
|
34
33
|
- default `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
|
|
35
34
|
- use `docs/en/qa/...` only if the repo already follows `docs/en/**`.
|
|
36
|
-
2. Build/refresh `Statistic Summary (Excel-aligned)
|
|
37
|
-
- include UT total, IT total, grand total.
|
|
35
|
+
2. Build/refresh `Statistic Summary (Excel-aligned)` with UT total, IT total, and grand total.
|
|
38
36
|
3. Build `Feature Coverage Matrix` from flow/action and API docs.
|
|
39
37
|
4. Split UTC/ITC by screen sections (`screen-first`), not by test type only.
|
|
40
38
|
5. Fill conflict/permission/error-path cases from Q&A decisions and API contracts.
|
|
41
39
|
6. Record unresolved items in section `Open Questions`.
|
|
42
40
|
7. Validate:
|
|
43
41
|
- counts in summary match table rows
|
|
42
|
+
- structured TEST_CASE total stays aligned with the QA release-report baseline; if E2E is tracked separately, label it separately instead of inflating grand total
|
|
44
43
|
- no placeholder tokens like `??`
|
|
45
44
|
- out-of-scope boundaries are explicit
|
|
46
45
|
|
|
@@ -58,6 +57,5 @@ $ARGUMENTS
|
|
|
58
57
|
|
|
59
58
|
### Typical command
|
|
60
59
|
```bash
|
|
61
|
-
python scripts/validate_test_case_spec.py
|
|
62
|
-
--file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
|
|
60
|
+
python scripts/validate_test_case_spec.py --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
|
|
63
61
|
```
|
package/package.json
CHANGED
|
@@ -1,46 +1,46 @@
|
|
|
1
1
|
{
|
|
2
|
-
"name":
|
|
3
|
-
"version":
|
|
4
|
-
"description":
|
|
5
|
-
"bin":
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
"main":
|
|
9
|
-
"type":
|
|
10
|
-
"files":
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
"scripts":
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
"engines":
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
"keywords":
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
"license":
|
|
34
|
-
"repository":
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
"homepage":
|
|
40
|
-
"bugs":
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
"publishConfig":
|
|
44
|
-
|
|
45
|
-
|
|
2
|
+
"name": "sdtk-kit",
|
|
3
|
+
"version": "0.3.5",
|
|
4
|
+
"description": "SDTK CLI toolkit for deterministic software documentation workflows",
|
|
5
|
+
"bin": {
|
|
6
|
+
"sdtk": "./bin/sdtk.js"
|
|
7
|
+
},
|
|
8
|
+
"main": "src/index.js",
|
|
9
|
+
"type": "commonjs",
|
|
10
|
+
"files": [
|
|
11
|
+
"bin/",
|
|
12
|
+
"src/",
|
|
13
|
+
"assets/"
|
|
14
|
+
],
|
|
15
|
+
"scripts": {
|
|
16
|
+
"test": "node -e \"console.log('No tests configured yet')\"",
|
|
17
|
+
"build:payload": "powershell -ExecutionPolicy Bypass -File scripts/sync-toolkit-assets.ps1 && powershell -ExecutionPolicy Bypass -File scripts/build-toolkit-manifest.ps1",
|
|
18
|
+
"verify:payload": "node -e \"require('./src/lib/toolkit-payload').verify()\"",
|
|
19
|
+
"pack:smoke": "npm pack --dry-run",
|
|
20
|
+
"pack:release": "npm pack",
|
|
21
|
+
"prepublishOnly": "node -e \"require('./src/lib/toolkit-payload').verify()\""
|
|
22
|
+
},
|
|
23
|
+
"engines": {
|
|
24
|
+
"node": ">=18.13.0"
|
|
25
|
+
},
|
|
26
|
+
"keywords": [
|
|
27
|
+
"sdtk",
|
|
28
|
+
"cli",
|
|
29
|
+
"documentation",
|
|
30
|
+
"toolkit",
|
|
31
|
+
"dockkit"
|
|
32
|
+
],
|
|
33
|
+
"license": "MIT",
|
|
34
|
+
"repository": {
|
|
35
|
+
"type": "git",
|
|
36
|
+
"url": "https://github.com/codexsdtk/sdtk-toolkit.git",
|
|
37
|
+
"directory": "distribution/sdtk-cli"
|
|
38
|
+
},
|
|
39
|
+
"homepage": "https://agenttoolkits.dev",
|
|
40
|
+
"bugs": {
|
|
41
|
+
"url": "https://github.com/codexsdtk/sdtk-toolkit/issues"
|
|
42
|
+
},
|
|
43
|
+
"publishConfig": {
|
|
44
|
+
"access": "public"
|
|
45
|
+
}
|
|
46
46
|
}
|