sdtk-kit 0.3.7 → 0.3.8

package/assets/toolkit/toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md

@@ -19,12 +19,13 @@ A flow-action spec should include, at minimum:
 
 1. `Abbreviations`
 2. `Feature overview`
-3. `Screen flow action` (with PlantUML)
-4. `Screen layout spec by flow action`
-5. `System processing flow`
-6. `Open questions`
-7. `Screen - API mapping`
-8. `Document history`
+3. `Assumptions`
+4. `Screen flow action` (with PlantUML)
+5. `Screen layout spec by flow action`
+6. `System processing flow`
+7. `Open questions`
+8. `Screen - API mapping`
+9. `Document history`
 
 If a section is not in scope, keep the section and mark explicitly as `N/A` with reason.
 
@@ -40,7 +41,34 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 - Table rows must keep column count consistent with the header (no broken or merged rows).
 - Avoid single-line merged content that collapses multiple logical items into one table row.
 
-### 3.1 Language and Encoding Standards (EN Artifacts)
+### 3.1 Action Table Mapping Completion Rules
+
+- After API endpoint spec and database spec are available, the action-table columns `Attribute`, `DB Column`, `Size`, and `Default Value` must not be left blank when the mapping can be derived from current source-of-truth inputs.
+- Fill these four columns only after the relevant API contract and DB schema are stable enough to be treated as the current source of truth for the active phase.
+- Source priority for filling the four columns:
+  1. `docs/api/*_ENDPOINTS.md` and OpenAPI YAML for request/response contract
+  2. `docs/database/DATABASE_SPEC_*.md` for physical column names, nullability, storage shape, and query-source aliases
+  3. confirmed flow/business rules for default state and behavior
+  4. design source (Figma/Excel) for screen label and control type only
+- `Attribute` rules:
+  - input item: use the canonical request payload path
+  - display item: use the canonical response path
+  - UI-only item: use `ui.*` namespace
+- `DB Column` rules:
+  - use physical DB column names or query-source aliases from the API/database spec
+  - if multiple columns participate, list them explicitly
+  - if the control is UI-only, write `N/A`
+- `Size` rules:
+  - document data format/type, not pixel width
+  - prefer canonical forms such as `uuid`, `DATE (YYYY-MM-DD)`, `DATETIME`, `TIME (HH:mm)`, `boolean`, `array[uuid]`, `enum(...)`, `JSON string`
+  - prefer DB storage type first; if not available, fall back to API schema type/format
+- `Default Value` rules:
+  - use confirmed business, UI, or runtime defaults
+  - if the default comes from settings or environment, state that clearly
+  - if not finalized, use `TBD` and keep or raise an open-question reference in `Note`
+- If screen labels conflict with canonical API/DB naming, preserve the original screen label in the visible screen columns, but keep `Attribute` and `DB Column` aligned to API/DB source of truth and explain the mismatch in `Note`.
+
+### 3.2 Language and Encoding Standards (EN Artifacts)
 
 - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
 - JP labels, if provided by the input, should be kept in a clearly marked appendix or note column, not in the default item table columns.
@@ -49,12 +77,19 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
 - Keep canonical terminology stable across documents (for example: `bukken`, `sagyo`, `customer employee`).
 
-### 3.2 Markdown Structure Hygiene
+### 3.3 Markdown Structure Hygiene
 
 - Keep each heading on its own line; do not concatenate multiple headings/sections on one line.
 - Keep metadata blocks (`Information`, `Note`, `Behavior notes`) as structured bullet blocks, not single compressed lines.
 - Keep image, table, and separator (`---`) boundaries explicit to preserve parser/render stability.
 
+### 3.4 Assumptions Section
+
+- Every flow-action spec must include a top-level `## Assumptions` section.
+- Use this table format exactly: `# | Assumption | Verified | Risk if wrong`.
+- Keep assumptions explicit when downstream mapping or behavior depends on an unresolved decision.
+- If an assumption affects UI behavior, API mapping, or DB mapping, reflect the risk in `Note` and keep or raise the related `OQ-xx` item.
+
 ## 4. Item Numbering and Duplication Rules
 
 - Use one numbering mode only: `global across document`.
@@ -158,6 +193,7 @@ When `Design Source Type` is `generated-draft`:
 - Numbering is global across the document (no resets).
 - No broken image links (for `generated-draft` screens: `.svg` exists or render-skipped note is present).
 - Screen/API mappings are consistent with `*_ENDPOINTS.md`.
+- Assumptions section exists and unresolved assumptions are traceable.
 - Open questions are explicit and traceable.
 - For EN artifact: no leftover VI text outside allowed `Original Text` appendix blocks.
 - No mojibake/encoding corruption markers.

package/assets/toolkit/toolkit/skills/sdtk-ba/SKILL.md

@@ -5,6 +5,10 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
 
 # SDTK BA (Business Analysis)
 
+## Critical Constraints
+- I do not mark BA analysis complete until `REQ`, `UC`, `BR`, and `AC` traceability is explicit.
+- I do not silently resolve business ambiguities that belong to PM or the user.
+
 ## Output
 - `docs/specs/BA_SPEC_[FEATURE_KEY].md`
 

package/assets/toolkit/toolkit/skills/sdtk-design-layout/SKILL.md

@@ -5,6 +5,10 @@ description: Generate UI screen layout documentation for a feature, including Pl
 
 # SDTK Screen Layout Design
 
+## Critical Constraints
+- I do not skip screen IDs or item numbering alignment with the wireframe.
+- I do not hide render limitations; I record when screen preview rendering is unavailable.
+
 ## Output
 - `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`
 

package/assets/toolkit/toolkit/skills/sdtk-dev/SKILL.md

@@ -5,6 +5,10 @@ description: Developer workflow for SDTK. Use when you need to implement a featu
 
 # SDTK DEV (Implementation + Code Review)
 
+## Critical Constraints
+- I do not start implementation before the current `FEATURE_IMPL_PLAN` scope is approved.
+- I do not claim implementation is complete without fresh verification evidence.
+
 ## Outputs
 - `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
 - Code + tests (follow repo conventions)

package/assets/toolkit/toolkit/skills/sdtk-dev-backend/SKILL.md

@@ -5,6 +5,10 @@ description: Generate/modify Python Django REST Framework backend code following
 
 # SDTK Backend (Toolkit conventions)
 
+## Critical Constraints
+- I do not generate backend code without approved API and data-contract sources.
+- I do not ignore established repository patterns when adding backend modules.
+
 ## Process
 1. Check whether this repository already has a backend reference module and follow its patterns.
 2. Follow module structure: `src/backend/<module>/{models,view,service,serializers,validation,enum,urls.py}`.

package/assets/toolkit/toolkit/skills/sdtk-dev-frontend/SKILL.md

@@ -5,6 +5,10 @@ description: Generate/modify React frontend code following the toolkit conventio
 
 # SDTK Frontend (Toolkit conventions)
 
+## Critical Constraints
+- I do not implement screens without current layout and flow-action sources.
+- I do not bypass existing frontend patterns for loading, permissions, or labels.
+
 ## Process
 1. Check whether this repository already has a frontend reference module and follow its patterns.
 2. Follow structure:

package/assets/toolkit/toolkit/skills/sdtk-orchestrator/SKILL.md

@@ -5,6 +5,10 @@ description: Orchestrate a full 6-phase SDLC multi-agent workflow (PM/BA/ARCH/DE
 
 # SDTK Orchestrator (multi-agent workflow)
 
+## Critical Constraints
+- I do not skip mandatory phases or hand off without current-phase evidence.
+- I do not treat planned commands as equivalent to completed work.
+
 ## Initialize
 - Ensure feature key + feature name exist (ask if missing).
 - Read `sdtk.config.json` (project stack + commands) if present.

package/assets/toolkit/toolkit/skills/sdtk-pm/SKILL.md

@@ -5,6 +5,10 @@ description: Product Manager + meta-orchestrator workflow for SDTK. Use when you
 
 # SDTK PM (Entry Point + Planning)
 
+## Critical Constraints
+- I do not hand off PM work until `SHARED_PLANNING.md` and `QUALITY_CHECKLIST.md` reflect the current phase.
+- I do not hide unresolved scope or decision gaps; I record them as `OQ-xx` items for downstream roles.
+
 ## Outputs
 - Phase 1: `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md`
 - Phase 2+ (after BA spec): `docs/product/PRD_[FEATURE_KEY].md` + `docs/product/BACKLOG_[FEATURE_KEY].md`

package/assets/toolkit/toolkit/skills/sdtk-qa/SKILL.md

@@ -5,6 +5,10 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
 
 # SDTK QA (Testing + Release Decision)
 
+## Critical Constraints
+- I do not start QA handoff or release decision work until both DEV review gates PASS.
+- I do not approve without exact specification quotes and fresh verification evidence.
+
 ## Output
 - `docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md`
 - Optional (when detailed test design spec is requested):
@@ -17,10 +21,11 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
 4. Apply `governance/ai/core/SDTK_BENCHMARK_QA_MODE_POLICY.md` for benchmark-mode verdict rules when no executable build exists.
 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.
 6. Execute the required checks, record the commands used, and capture the actual results (unit/integration/e2e or document review evidence as applicable).
-7. Record defects with severity and status.
-8. Decide: APPROVED vs REJECTED only after fresh verification evidence supports the verdict.
-9. Update shared state + Phase 5 checklist.
-10. Handoff: `@pm please finalize release status ...` if approved.
+7. When validating requirement behavior, quote the exact specification text before recording a match or mismatch.
+8. Record defects with severity and status.
+9. Decide: APPROVED vs REJECTED only after fresh verification evidence supports the verdict.
+10. Update shared state + Phase 5 checklist.
+11. Handoff: `@pm please finalize release status ...` if approved.
 
 ## Verification Before Completion
 Apply `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md` and require fresh verification evidence before any QA verdict or handoff.
@@ -32,6 +37,14 @@ Do not:
 
 If the environment cannot run the proving checks, follow the benchmark QA mode policy explicitly and state that the result is not fully verified at runtime.
 
+## Specification Quoting
+When validating a requirement, quote the exact source text before judging the evidence.
+
+Use this format:
+- `Spec says: "[exact quote]" -> Evidence: [match/mismatch + file reference]`
+
+Apply it to BA, PRD or BACKLOG, ARCH, API, DB, and flow-action sources whenever they define the expected behavior.
+
 ## Order-Critical Hard Gate
 Do not start QA handoff, release testing, or release decision work until both DEV review gates are documented as PASS:
 - Stage 1 artifact/spec compliance review

package/assets/toolkit/toolkit/skills/sdtk-screen-design-spec/SKILL.md

@@ -5,6 +5,10 @@ description: Create/update screen flow-action specifications from requirement so
 
 # SDTK Screen Flow Action Spec
 
+## Critical Constraints
+- I do not finalize UI-scope screens without a valid design source type and reference.
+- I do not leave broken image paths or incomplete API mappings in the flow-action spec.
+
 ## Outputs
 - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
 - Optional supporting docs:

package/assets/toolkit/toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md

@@ -19,12 +19,13 @@ A flow-action spec should include, at minimum:
 
 1. `Abbreviations`
 2. `Feature overview`
-3. `Screen flow action` (with PlantUML)
-4. `Screen layout spec by flow action`
-5. `System processing flow`
-6. `Open questions`
-7. `Screen - API mapping`
-8. `Document history`
+3. `Assumptions`
+4. `Screen flow action` (with PlantUML)
+5. `Screen layout spec by flow action`
+6. `System processing flow`
+7. `Open questions`
+8. `Screen - API mapping`
+9. `Document history`
 
 If a section is not in scope, keep the section and mark explicitly as `N/A` with reason.
 
@@ -40,7 +41,34 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 - Table rows must keep column count consistent with the header (no broken or merged rows).
 - Avoid single-line merged content that collapses multiple logical items into one table row.
 
-### 3.1 Language and Encoding Standards (EN Artifacts)
+### 3.1 Action Table Mapping Completion Rules
+
+- After API endpoint spec and database spec are available, the action-table columns `Attribute`, `DB Column`, `Size`, and `Default Value` must not be left blank when the mapping can be derived from current source-of-truth inputs.
+- Fill these four columns only after the relevant API contract and DB schema are stable enough to be treated as the current source of truth for the active phase.
+- Source priority for filling the four columns:
+  1. `docs/api/*_ENDPOINTS.md` and OpenAPI YAML for request/response contract
+  2. `docs/database/DATABASE_SPEC_*.md` for physical column names, nullability, storage shape, and query-source aliases
+  3. confirmed flow/business rules for default state and behavior
+  4. design source (Figma/Excel) for screen label and control type only
+- `Attribute` rules:
+  - input item: use the canonical request payload path
+  - display item: use the canonical response path
+  - UI-only item: use `ui.*` namespace
+- `DB Column` rules:
+  - use physical DB column names or query-source aliases from the API/database spec
+  - if multiple columns participate, list them explicitly
+  - if the control is UI-only, write `N/A`
+- `Size` rules:
+  - document data format/type, not pixel width
+  - prefer canonical forms such as `uuid`, `DATE (YYYY-MM-DD)`, `DATETIME`, `TIME (HH:mm)`, `boolean`, `array[uuid]`, `enum(...)`, `JSON string`
+  - prefer DB storage type first; if not available, fall back to API schema type/format
+- `Default Value` rules:
+  - use confirmed business, UI, or runtime defaults
+  - if the default comes from settings or environment, state that clearly
+  - if not finalized, use `TBD` and keep or raise an open-question reference in `Note`
+- If screen labels conflict with canonical API/DB naming, preserve the original screen label in the visible screen columns, but keep `Attribute` and `DB Column` aligned to API/DB source of truth and explain the mismatch in `Note`.
+
+### 3.2 Language and Encoding Standards (EN Artifacts)
 
 - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
 - JP labels, if provided by the input, should be kept in a clearly marked appendix or note column, not in the default item table columns.
@@ -49,12 +77,19 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
 - Keep canonical terminology stable across documents (for example: `bukken`, `sagyo`, `customer employee`).
 
-### 3.2 Markdown Structure Hygiene
+### 3.3 Markdown Structure Hygiene
 
 - Keep each heading on its own line; do not concatenate multiple headings/sections on one line.
 - Keep metadata blocks (`Information`, `Note`, `Behavior notes`) as structured bullet blocks, not single compressed lines.
 - Keep image, table, and separator (`---`) boundaries explicit to preserve parser/render stability.
 
+### 3.4 Assumptions Section
+
+- Every flow-action spec must include a top-level `## Assumptions` section.
+- Use this table format exactly: `# | Assumption | Verified | Risk if wrong`.
+- Keep assumptions explicit when downstream mapping or behavior depends on an unresolved decision.
+- If an assumption affects UI behavior, API mapping, or DB mapping, reflect the risk in `Note` and keep or raise the related `OQ-xx` item.
+
 ## 4. Item Numbering and Duplication Rules
 
 - Use one numbering mode only: `global across document`.
@@ -158,6 +193,7 @@ When `Design Source Type` is `generated-draft`:
 - Numbering is global across the document (no resets).
 - No broken image links (for `generated-draft` screens: `.svg` exists or render-skipped note is present).
 - Screen/API mappings are consistent with `*_ENDPOINTS.md`.
+- Assumptions section exists and unresolved assumptions are traceable.
 - Open questions are explicit and traceable.
 - For EN artifact: no leftover VI text outside allowed `Original Text` appendix blocks.
 - No mojibake/encoding corruption markers.

package/assets/toolkit/toolkit/skills/sdtk-test-case-spec/SKILL.md

@@ -5,6 +5,10 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
 
 # SDTK Test Case Spec
 
+## Critical Constraints
+- I do not invent test coverage beyond BA, flow-action, and API sources.
+- I do not let test totals drift away from worksheet rows or the QA baseline.
+
 ## Outputs
 - `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
 - Optional project variant:
@@ -28,6 +32,7 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
 4. Keep one unified 18-column schema for UTC/ITC rows.
 5. Keep stable case IDs; do not renumber only because of regrouping.
 6. Track unresolved decisions via `OQ-xx` and keep benchmark-expected OQs explicitly OPEN per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`.
+7. Quote exact BA, API, or flow-action requirement text when a testcase or coverage claim depends on that requirement.
 
 ## Procedure
 1. Resolve output path:
@@ -44,6 +49,12 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
    - no placeholder tokens like `??`
    - out-of-scope boundaries are explicit
 
+## Specification Quoting
+When a testcase, coverage note, or defect check depends on a requirement, quote the exact source text before stating coverage or mismatch.
+
+Use this format:
+- `Spec says: "[exact quote]" -> Evidence: [covered/not covered + file reference]`
+
 ## Role Integration
 - Primary owner: `/qa`.
 - `/qa` uses this skill to design/update reusable test-case specs.

package/assets/toolkit/toolkit/skills/skills.catalog.yaml

@@ -0,0 +1,302 @@
+schema_version: 1
+skills:
+  - name: sdtk-pm
+    phase: pm
+    role_tag: /pm
+    use_when: Start feature scope or produce PM planning artifacts before BA or ARCH handoff.
+    primary_inputs:
+      - source requirements
+      - docs/product/PROJECT_INITIATION_[FEATURE_KEY].md
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+    primary_outputs:
+      - docs/product/PROJECT_INITIATION_[FEATURE_KEY].md
+      - docs/product/PRD_[FEATURE_KEY].md
+      - docs/product/BACKLOG_[FEATURE_KEY].md
+    hard_gates:
+      - Do not hand off without updating SHARED_PLANNING.md and QUALITY_CHECKLIST.md.
+      - Keep unresolved OQ items explicit instead of silently deciding for other roles.
+    references: []
+    prompts: []
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: []
+    pack: core
+
+  - name: sdtk-ba
+    phase: ba
+    role_tag: /ba
+    use_when: Convert PM initiation into a BA spec with glossary, BR, UC, AC, NFR, and traceability.
+    primary_inputs:
+      - docs/product/PROJECT_INITIATION_[FEATURE_KEY].md
+      - source requirements
+    primary_outputs:
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+    hard_gates:
+      - Do not close BA output without explicit REQ to UC or BR or AC traceability.
+      - Keep unresolved OQ items visible for PM resolution.
+    references: []
+    prompts: []
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-pm]
+    pack: core
+
+  - name: sdtk-arch
+    phase: arch
+    role_tag: /arch
+    use_when: Convert BA spec and PM backlog into architecture, API, DB, and UI design artifacts.
+    primary_inputs:
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+      - docs/product/PRD_[FEATURE_KEY].md
+      - docs/product/BACKLOG_[FEATURE_KEY].md
+    primary_outputs:
+      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
+      - docs/api/[FeaturePascal]_API.yaml
+      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
+      - docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md
+      - docs/database/DATABASE_SPEC_[FEATURE_KEY].md
+      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
+      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
+    hard_gates:
+      - For UI scope, DESIGN_LAYOUT must exist before FLOW_ACTION_SPEC.
+      - Keep API, DB, and screen outputs aligned to the same source requirements.
+    references:
+      - toolkit/skills/sdtk-arch/references/YAML_CREATION_RULES.md
+      - toolkit/skills/sdtk-arch/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
+      - toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md
+    prompts: []
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-pm, sdtk-ba]
+    pack: core
+
+  - name: sdtk-dev
+    phase: dev
+    role_tag: /dev
+    use_when: Implement a feature from approved architecture and backlog, then prepare QA handoff.
+    primary_inputs:
+      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
+      - docs/product/BACKLOG_[FEATURE_KEY].md
+      - docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md
+    primary_outputs:
+      - docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md
+      - code changes
+      - tests
+    hard_gates:
+      - Do not implement before the current FEATURE_IMPL_PLAN slice is approved.
+      - Run Stage 1 spec review before Stage 2 code-quality review.
+    references: []
+    prompts:
+      - toolkit/skills/sdtk-dev/prompts/implementer.md
+      - toolkit/skills/sdtk-dev/prompts/spec-reviewer.md
+      - toolkit/skills/sdtk-dev/prompts/code-quality-reviewer.md
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-arch]
+    pack: core
+
+  - name: sdtk-qa
+    phase: qa
+    role_tag: /qa
+    use_when: Validate implementation against specs, run quality gates, and produce a release decision.
+    primary_inputs:
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+      - docs/product/PRD_[FEATURE_KEY].md
+      - docs/product/BACKLOG_[FEATURE_KEY].md
+      - docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md
+    primary_outputs:
+      - docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md
+      - docs/qa/[FEATURE_KEY]_TEST_CASE.md
+    hard_gates:
+      - QA handoff is blocked until DEV Stage 1 and Stage 2 review gates PASS.
+      - Do not issue APPROVED without fresh verification evidence.
+    references: []
+    prompts: []
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-dev]
+    pack: core
+
+  - name: sdtk-orchestrator
+    phase: orchestration
+    role_tag: /orchestrator
+    use_when: Coordinate the full six-phase workflow and keep phase handoffs in order.
+    primary_inputs:
+      - feature key
+      - feature name
+      - sdtk.config.json
+      - SHARED_PLANNING.md
+      - QUALITY_CHECKLIST.md
+    primary_outputs:
+      - phase handoffs
+      - updated SHARED_PLANNING.md
+      - updated QUALITY_CHECKLIST.md
+    hard_gates:
+      - Do not skip mandatory PM or BA or ARCH or DEV or QA phases.
+      - Do not hand off the next phase without evidence from the current phase.
+    references: []
+    prompts: []
+    scripts:
+      - toolkit/scripts/init-feature.ps1
+    runtime_support: [claude, codex]
+    dependencies: []
+    pack: core
+
+  - name: sdtk-dev-backend
+    phase: dev
+    role_tag: /dev-backend
+    use_when: Implement backend code that follows SDTK backend conventions for a scoped feature slice.
+    primary_inputs:
+      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
+      - docs/api/[FeaturePascal]_API.yaml
+      - docs/database/DATABASE_SPEC_[FEATURE_KEY].md
+    primary_outputs:
+      - backend code
+      - backend tests
+    hard_gates:
+      - Do not generate backend code without approved API and data-contract sources.
+      - Follow existing repository patterns before introducing new module structure.
+    references: []
+    prompts: []
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-dev, sdtk-api-doc]
+    pack: core
+
+  - name: sdtk-dev-frontend
+    phase: dev
+    role_tag: /dev-frontend
+    use_when: Implement frontend code that follows SDTK frontend conventions for a scoped feature slice.
+    primary_inputs:
+      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
+      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
+      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
+    primary_outputs:
+      - frontend code
+      - frontend tests
+    hard_gates:
+      - Do not implement screens without the current design and flow-action source.
+      - Preserve existing frontend patterns before introducing new abstractions.
+    references: []
+    prompts: []
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-dev, sdtk-design-layout, sdtk-screen-design-spec]
+    pack: core
+
+  - name: sdtk-api-doc
+    phase: arch
+    role_tag: /api-doc
+    use_when: Generate or update OpenAPI YAML, API endpoints markdown, and flow-list files from architecture scope.
+    primary_inputs:
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
+    primary_outputs:
+      - docs/api/[FeaturePascal]_API.yaml
+      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
+      - docs/api/[feature_snake]_api_flow_list.txt
+    hard_gates:
+      - Do not invent API paths or schemas that contradict BA or ARCH source.
+      - Keep YAML, endpoint markdown, and flow list synchronized.
+    references:
+      - toolkit/skills/sdtk-api-doc/references/YAML_CREATION_RULES.md
+      - toolkit/skills/sdtk-api-doc/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
+    prompts: []
+    scripts: []
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-arch, sdtk-ba]
+    pack: core
+
+  - name: sdtk-api-design-spec
+    phase: arch
+    role_tag: /api-design-spec
+    use_when: Generate API design detail markdown from OpenAPI YAML and API flow list.
+    primary_inputs:
+      - docs/api/[FeaturePascal]_API.yaml
+      - docs/api/[feature_snake]_api_flow_list.txt
+    primary_outputs:
+      - docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md
+      - docs/api/flows/*.puml
+      - docs/api/images/*.svg
+    hard_gates:
+      - Do not drift from the source YAML or flow list.
+      - Do not leave broken flow image embeds in the generated markdown.
+    references:
+      - toolkit/skills/sdtk-api-design-spec/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
+      - toolkit/skills/sdtk-api-design-spec/references/API_DESIGN_CREATION_RULES.md
+    prompts: []
+    scripts:
+      - toolkit/skills/sdtk-api-design-spec/scripts/generate_api_design_detail.py
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-api-doc]
+    pack: core
+
+  - name: sdtk-design-layout
+    phase: arch
+    role_tag: /design-layout
+    use_when: Generate design-layout docs with PlantUML salt wireframes and item tables for UI scope.
+    primary_inputs:
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
+    primary_outputs:
+      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
+      - docs/specs/assets/<feature_snake>/screens/*.svg
+    hard_gates:
+      - Do not skip screen IDs or item numbering alignment with the wireframe.
+      - If rendering is unavailable, record that explicitly instead of pretending render assets exist.
+    references: []
+    prompts: []
+    scripts:
+      - toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-arch, sdtk-ba]
+    pack: core
+
+  - name: sdtk-screen-design-spec
+    phase: arch
+    role_tag: /screen-design-spec
+    use_when: Build flow-action specs from requirement sources, design source references, and API mappings.
+    primary_inputs:
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
+      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
+    primary_outputs:
+      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
+      - docs/specs/assets/<feature_snake>/screens/*
+    hard_gates:
+      - Do not finalize UI-scope screens without a valid design source type and reference.
+      - Do not leave broken image paths or missing API mappings in the spec.
+    references:
+      - toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
+      - toolkit/skills/sdtk-screen-design-spec/references/numbering-rules.md
+      - toolkit/skills/sdtk-screen-design-spec/references/figma-mcp.md
+      - toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md
+    prompts: []
+    scripts:
+      - toolkit/skills/sdtk-screen-design-spec/scripts/validate_flow_action_spec_numbering.py
+      - toolkit/skills/sdtk-screen-design-spec/scripts/renumber_flow_action_spec_global.py
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-arch, sdtk-design-layout]
+    pack: core
+
+  - name: sdtk-test-case-spec
+    phase: qa
+    role_tag: /test-case-spec
+    use_when: Generate reusable screen-based test-case specifications before or during QA execution.
+    primary_inputs:
+      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
+      - docs/specs/BA_SPEC_[FEATURE_KEY].md
+      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
+    primary_outputs:
+      - docs/qa/[FEATURE_KEY]_TEST_CASE.md
+    hard_gates:
+      - Do not invent test coverage that is not grounded in BA, flow-action, or API sources.
+      - Keep totals and structured coverage counts consistent with the QA baseline.
+    references:
+      - toolkit/skills/sdtk-test-case-spec/references/TEST_CASE_CREATION_RULES.md
+    prompts: []
+    scripts:
+      - toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py
+    runtime_support: [claude, codex]
+    dependencies: [sdtk-qa, sdtk-screen-design-spec]
+    pack: core

package/assets/toolkit/toolkit/templates/docs/api/API_DESIGN_CREATION_RULES.md

@@ -7,10 +7,16 @@ The active rule source for API design detail and API flowchart behavior is now:
 - `API_DESIGN_FLOWCHART_CREATION_RULES_FINAL.md` (root)
 - `templates/docs/api/API_DESIGN_FLOWCHART_CREATION_RULES.md` (toolkit)
 
-Use that file for:
+Even in compatibility mode, generated API design detail docs must still include:
+- a top-level `## Assumptions` section
+- this table format: `| # | Assumption | Verified | Risk if wrong |`
+- explicit unresolved assumptions when downstream review depends on them
+
+Use the active rule file for:
 - API design detail markdown structure
 - flowchart integration and synchronization rules
 - error section rules
 - flow summary / notes / login rules
+- assumptions-section requirements
 
 This compatibility note should remain only until all references are migrated.