sdtk-kit 0.3.9 → 1.0.0

package/assets/toolkit/toolkit/templates/docs/specs/BA_SPEC_TEMPLATE.md

@@ -1,139 +0,0 @@
-# BA SPEC: {{FEATURE_KEY}} ({{FEATURE_NAME}})
-
-**Document ID:** BA_SPEC_{{FEATURE_KEY}}
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** BA Agent
-**Status:** DRAFT - Ready for PM Review
-
----
-
-## Abbreviations
-
-| No | Abbreviation | Meaning |
-| ---: | --- | --- |
-| 1 | API | Application Programming Interface |
-| 2 | DB | Database |
-| 3 | UI | User Interface |
-| 4 | UX | User Experience |
-| 5 | BR | Business Rule |
-| 6 | UC | Use Case |
-| 7 | AC | Acceptance Criteria |
-| 8 | NFR | Non-Functional Requirement |
-| 9 | OQ | Open Question |
-| 10 | REQ | Requirement |
-
----
-
-## 1. DOMAIN ANALYSIS
-
-### 1.1 Domain Glossary
-
-| No | Term | Definition | Example |
-| ---: | --- | --- | --- |
-| 1 | TBD | TBD | TBD |
-
-### 1.2 Business Rules
-
-| No | Rule ID | Rule Description | Type | Related REQ |
-| ---: | --- | --- | --- | --- |
-| 1 | BR-01 | TBD | Mandatory | REQ-01 |
-
-### 1.3 Non-Functional Requirements
-
-| No | NFR ID | Category | Requirement | Target |
-| ---: | --- | --- | --- | --- |
-| 1 | NFR-01 | Performance | TBD | TBD |
-
----
-
-## 2. USE CASES
-
-| No | UC ID | Use Case Name | Primary Actor | Related REQ |
-| ---: | --- | --- | --- | --- |
-| 1 | UC-01 | TBD | TBD | REQ-01 |
-
----
-
-## 3. DATA MODEL (Logical)
-
-| No | Entity | Description | Key Fields |
-| ---: | --- | --- | --- |
-| 1 | TBD | TBD | TBD |
-
----
-
-## 4. CONTRACTS SUMMARY
-
-### 4.1 API Endpoints (High-level)
-
-| No | Endpoint | Method | Purpose | Related UC |
-| ---: | --- | --- | --- | --- |
-| 1 | `/api/v1/...` | GET | TBD | UC-01 |
-
-### 4.2 UI Screens (if applicable)
-
-| No | Screen ID | Screen Name | Purpose | Related UC |
-| ---: | --- | --- | --- | --- |
-| 1 | SCR-01 | TBD | TBD | UC-01 |
-
-### 4.3 Acceptance Criteria (high-level)
-
-| No | AC ID | Acceptance Criteria | Related UC | Related BR |
-| ---: | --- | --- | --- | --- |
-| 1 | AC-01-01 | TBD | UC-01 | BR-01 |
-
----
-
-## 5. RISKS & OPEN QUESTIONS
-
-### 5.1 Risks
-
-| No | Risk ID | Risk | Probability | Impact | Mitigation |
-| ---: | --- | --- | --- | --- | --- |
-| 1 | R-01 | TBD | Medium | Medium | TBD |
-
-### 5.2 Open Questions
-
-| No | Q-ID | Question | Type | Priority | Decision Owner (PM/User) | Status (OPEN/RESOLVED) | Notes/Options | Resolution |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- |
-| 1 | OQ-01 | TBD | Business | High | PM | OPEN | TBD | TBD |
-
----
-
-## 6. TRACEABILITY SUMMARY
-
-| No | REQ ID | Use Cases | Business Rules | Acceptance Criteria | Status |
-| ---: | --- | --- | --- | --- | --- |
-| 1 | REQ-01 | UC-01 | BR-01 | AC-01-01 | COVERED |
-
----
-
-## 7. HANDOFF
-
-HANDOFF TO PM:
-`@pm BA_SPEC_{{FEATURE_KEY}} is ready. Please create PRD_{{FEATURE_KEY}}.md + BACKLOG_{{FEATURE_KEY}}.md`
-
-Next:
-`@arch please design architecture for {{FEATURE_KEY}} after PM review`
-
-NOTE:
-`@pm please resolve Open Questions (OQ-xx) above; if any cannot be resolved from existing docs, please confirm with the user (final stakeholder).`
-
----
-
-## APPENDIX A: Source Requirements (Original VI/JP) - keep as-is
-
-If the input requirements were provided in Vietnamese/Japanese, paste them here unchanged.
-
-## APPENDIX B: English Translation (of Appendix A)
-
-Provide an English translation of Appendix A (literal, for traceability).
-
----
-
-## Document History
-
-| No | Version | Date | Author | Changes |
-| ---: | --- | --- | --- | --- |
-| 1 | 1.0.0 | {{DATE}} | BA Agent | Initial template-based version |

package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md

@@ -1,220 +0,0 @@
-# Flow Action Spec Creation Rules for AI Agents
-
-This document defines reusable rules for creating and updating screen flow-action specifications
-(for example `docs/specs/*_FLOW_ACTION_SPEC.md`).
-
-## 1. Scope and Goal
-
-- Produce a screen-level specification that is traceable from BA/ARCH to FE/BE implementation.
-- Keep one source of truth for:
-  - screen flow
-  - UI items and actions
-  - API calls per action
-  - screen-to-API mapping
-- Keep documentation implementation-aware and review-friendly.
-
-## 2. Mandatory Document Structure
-
-A flow-action spec should include, at minimum:
-
-1. `Abbreviations`
-2. `Feature overview`
-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.
-
-## 3. Table Standards
-
-- Every table must include a `No` column (sequential numbering).
-- Use stable headers for action tables:
-  - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
-- Use stable headers for API mapping tables:
-  - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
-- Use stable headers for screen mapping:
-  - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
-- 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 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.
-- Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
-- If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
-- 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.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`.
-- Number values must increase across all action tables in the document.
-- DESIGN_LAYOUT wireframe markers are a separate screen-local visual system. They may reset per screen and do not need to numerically equal the global action-table `No`.
-- Avoid duplicate item descriptions for the same UI control across screens unless behavior differs.
-- If duplicate number is intentional (rare), annotate reason in `Note`.
-
-## 5. Screen Section Rules
-
-For each screen section:
-
-- Provide metadata:
-  - official screen name
-  - Screen ID
-  - Design Source Type
-  - Design Source Reference
-- Embed one representative image per screen (from Figma, screenshot, or generated layout).
-- Provide one action table.
-- Provide one API mapping table.
-- If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
-
-## 5.1 Design Source Modes
-
-Each screen section must declare a design source using one of these modes:
-
-| Mode | When | Design Source Reference |
-|------|------|----------------------|
-| `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
-| `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
-| `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
-
-Rules:
-- For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
-- When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
-- The flow-action spec and the design-layout doc must remain separate documents.
-- When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
-
-## 5.2 Wireframe Marker Mapping for Generated-Draft Screens
-
-For generated-draft screens with rendered design-layout images:
-
-- Treat wireframe markers as screen-local visual references only.
-- Keep action-table `No` global across the document per section 4.
-- Add a wireframe marker mapping table directly under the screen image.
-- Use this stable header:
-  - `No | Wireframe Marker | Action Table No | Item Name | Notes`
-- Map only the items visibly present on the wireframe image.
-- If an action-table row is not visible on the wireframe, state `Not shown on wireframe` in `Notes` instead of inventing a marker.
-- If the wireframe label and the action-table label differ slightly, keep the action-table item name and explain the label difference in `Notes`.
-
-## 6. API Traceability Rules
-
-- Every actionable UI event that changes state must map to a write API.
-- Every data-loading UI event must map to a read/search API.
-- If one endpoint serves multiple actions (initial load, search, refresh), state this explicitly.
-- If no API is called for an action, state `No API` and explain why.
-
-## 7. PlantUML Rules for Screen Flow
-
-- Use new-style PlantUML activity diagram syntax only for screen-flow diagrams.
-- Allowed activity constructs include: `start`, `stop`, `partition "..." {}`, `:Activity;`, `->`, `if/then/else/endif`, `fork`, `fork again`, `end fork`, and `note right/left`.
-- Do not mix legacy activity syntax such as `(*)`, `-->`, or `[edge label]` with new-style activity actions like `:Activity;`.
-- Validate renderability before handoff. If a renderer is unavailable in the current environment, at minimum keep the block internally consistent with new-style activity syntax only.
-- Use `\\n` for multi-line labels in activity nodes and notes.
-- Keep diagram at navigation/action level (not low-level SQL or backend internals).
-- Ensure screen names in PlantUML match section names in layout spec.
-
-## 8. Data Source and Asset Rules
-
-- Prioritize source order:
-  1. Confirmed design source (for example Figma)
-  2. Confirmed requirement files (Excel/spec)
-  3. User-provided screenshots
-- Store images in repository-relative filesystem paths.
-- Reference images in markdown using file-relative paths from the spec file's directory.
-- Do not keep temporary local absolute paths in markdown.
-
-### 8.1 Rendered Screen Images for Generated-Draft Screens
-
-When `Design Source Type` is `generated-draft`:
-- Screen preview images may be rendered from `DESIGN_LAYOUT_[FEATURE_KEY].md` PlantUML SALT wireframes.
-- Renderer: `toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py`
-- Expected output path (filesystem): `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
-- Markdown image path (file-relative from `docs/specs/*_FLOW_ACTION_SPEC.md`): `assets/<feature_snake>/screens/<screen_id>.svg`
-- DESIGN_LAYOUT markers inside the image are screen-local visual references and may reset per screen; use the wireframe mapping table to bridge them to the global action-table `No`.
-- If the rendered `.svg` file exists, use the file-relative markdown path in the `Screen image:` reference.
-- If rendering is unavailable or the `.svg` does not exist, replace the image line with:
-  `> Screen image not rendered in this environment. See Design Source Reference for layout.`
-- Do not leave a broken image reference pointing to a non-existent file.
-
-## 9. Consistency with Other Specs
-
-- Align terms with:
-  - BA spec glossary
-  - API endpoints spec
-  - Database spec
-- If terminology differs across docs, raise an open question and add a temporary mapping note.
-- Keep endpoint paths in flow-action spec consistent with API endpoint spec.
-
-## 10. Open Questions and Uncertainty Handling
-
-- Capture unresolved items in `Open questions` table.
-- Do not invent UI behavior or API contracts when source is ambiguous.
-- Mark uncertain mappings as `Draft` and include impacted files/sections.
-
-## 11. Change Management
-
-- On each update:
-  - update impacted screen sections
-  - update API mapping tables
-  - update screen-to-API mapping summary
-  - append one row in document history
-- Never overwrite past history rows.
-
-## 12. Final Checklist Before Handoff
-
-- PlantUML renders successfully.
-- All mandatory sections exist.
-- All tables include `No`.
-- 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.
-- Headings/tables are structurally clean (no merged lines that break readability/traceability).

package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md

@@ -1,197 +0,0 @@
-# {{FEATURE_NAME}} - Screen Flow Action Specification
-
-**Document ID:** {{FEATURE_KEY}}_FLOW_ACTION_SPEC
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** ARCH Agent
-**Status:** DRAFT
-**Related Specs:** `docs/specs/BA_SPEC_{{FEATURE_KEY}}.md`, `docs/api/{{FEATURE_KEY}}_ENDPOINTS.md`, `docs/database/DATABASE_SPEC_{{FEATURE_KEY}}.md`
-
----
-
-## Abbreviations
-
-| No | Abbreviation | Meaning |
-| ---: | --- | --- |
-| 1 | UI | User Interface |
-| 2 | UX | User Experience |
-| 3 | API | Application Programming Interface |
-| 4 | FE | Frontend |
-| 5 | BE | Backend |
-| 6 | OQ | Open Question |
-
----
-
-## 1) Feature overview
-
-### 1.1 Background and user needs
-- TBD
-
-### 1.2 Target features in scope
-- TBD
-
-### 1.3 Implementation direction
-- TBD
-
-## Assumptions
-
-| # | Assumption | Verified | Risk if wrong |
-| ---: | --- | --- | --- |
-| 1 | TBD | No | TBD |
-
----
-
-## 2) Screen flow action
-
-### 2.1 Flow diagram (PlantUML)
-
-```plantuml
-@startuml
-skinparam shadowing false
-skinparam activityBackgroundColor #FEFEFE
-skinparam activityBorderColor #333333
-
-title {{FEATURE_NAME}} - Screen Flow Action
-
-start
-partition "Main Flow" {
-  :SCR-01 Screen A;
-  note right
-    User reviews the main list and selects an action.
-  end note
-  -> Open detail;
-  :SCR-02 Screen B;
-}
-stop
-@enduml
-```
-
-### 2.2 Mapping to major screens
-
-| No | Screen Group | Screen Name | Screen ID | Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | Main | Screen A | SCR-01 | TBD |
-| 2 | Main | Screen B | SCR-02 | TBD |
-
----
-
-## 3) Screen layout spec by flow action
-
-> Standard item table format:
-> `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
-
-### 3.1 Screen A
-
-Information:
-- Screen ID: SCR-01
-- Design Source Type: source-backed | generated-draft | none
-- Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
-
-Screen image:
-<!-- Use a file-relative markdown path from docs/specs/, not a project-root docs/specs/assets/... path. -->
-![3.1 Screen A](assets/{{FEATURE_SNAKE}}/screens/scr_01.svg)
-
-<!-- If the .svg file does not exist (render unavailable), replace the image line above with: -->
-<!-- > Screen image not rendered in this environment. See Design Source Reference for layout. -->
-
-#### Wireframe Marker Mapping (Draft)
-
-> Generated-draft wireframe markers are screen-local visual references. Map each visible marker to the global action-table `No` used below.
-
-| No | Wireframe Marker | Action Table No | Item Name | Notes |
-| ---: | --- | ---: | --- | --- |
-| 1 | marker-1 | 1 | Item A | Visible on wireframe |
-| 2 | marker-2 | 2 | Item B | Visible on wireframe |
-
-| No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| 1 | Item A | Button | - | - | - | - | Click | TBD | TBD |
-| 2 | Item B | Input | string | column_a | 100 | empty | Input | TBD | TBD |
-
-#### API Mapping (Draft)
-
-| No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | Initial load | Main area | `GET /api/...` | Load initial dataset |
-| 2 | Click search | No 1 | `POST /api/.../search` | Refresh grid |
-
----
-
-### 3.2 Screen B
-
-Information:
-- Screen ID: SCR-02
-- Design Source Type: source-backed | generated-draft | none
-- Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
-
-Screen image:
-<!-- Use a file-relative markdown path from docs/specs/, not a project-root docs/specs/assets/... path. -->
-![3.2 Screen B](assets/{{FEATURE_SNAKE}}/screens/scr_02.svg)
-
-<!-- If the .svg file does not exist (render unavailable), replace the image line above with: -->
-<!-- > Screen image not rendered in this environment. See Design Source Reference for layout. -->
-
-#### Wireframe Marker Mapping (Draft)
-
-> Generated-draft wireframe markers are screen-local visual references. Map each visible marker to the global action-table `No` used below.
-
-| No | Wireframe Marker | Action Table No | Item Name | Notes |
-| ---: | --- | ---: | --- | --- |
-| 1 | marker-1 | 3 | Item C | Visible on wireframe |
-
-| No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| 3 | Item C | Toggle | boolean | flag_a | - | false | Toggle | TBD | TBD |
-
-#### API Mapping (Draft)
-
-| No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | Change mode | No 3 | `POST /api/.../edit/{uuid}` | Persist mode |
-
----
-
-## 4) System processing flow
-
-### 4.1 Initial load
-1. Validate screen permissions.
-2. Load settings/profile context.
-3. Load main dataset.
-
-### 4.2 Create/Update/Delete flow
-1. Validate request.
-2. Execute write API.
-3. Refresh read dataset.
-
----
-
-## 5) Notes
-
-- Keep item numbering strategy explicit (`global` or `per-screen`).
-- Do not duplicate item descriptions across screens unless behavior differs.
-
----
-
-## 6) Open questions
-
-| No | Scope | Question | Impact |
-| ---: | --- | --- | --- |
-| 1 | UI | TBD | TBD |
-| 2 | API | TBD | TBD |
-
----
-
-## 7) Screen - API Mapping
-
-| No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs |
-| ---: | --- | --- | --- | --- | --- |
-| 1 | 3.1 Screen A | SCR-01 | `GET /api/...` | `POST /api/...` | TBD |
-| 2 | 3.2 Screen B | SCR-02 | `POST /api/.../search` | `POST /api/.../edit/{uuid}` | TBD |
-
----
-
-## Document History
-
-| No | Version | Date | Author | Changes |
-| ---: | --- | --- | --- | --- |
-| 1 | 1.0.0 | {{DATE}} | ARCH Agent | Initial template-based version |

package/assets/toolkit/toolkit/templates/handoffs/ARCH_TO_DEV.md

@@ -1,31 +0,0 @@
-# ARCH to DEV Handoff
-
-## Required Inputs
-- `docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md`
-- `docs/product/BACKLOG_[FEATURE_KEY].md`
-- when applicable:
-  - `docs/api/[FeaturePascal]_API.yaml`
-  - `docs/api/[FEATURE_KEY]_ENDPOINTS.md`
-  - `docs/database/DATABASE_SPEC_[FEATURE_KEY].md`
-  - `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`
-  - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
-
-## Required Outputs
-- `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
-- code and tests
-- Stage 1 and Stage 2 review evidence before QA handoff
-
-## Mandatory Checks
-- ARCH outputs are current and reference the same feature scope.
-- UI scope includes `DESIGN_LAYOUT` before `FLOW_ACTION_SPEC`.
-- API and DB source-of-truth files are available when implementation depends on them.
-
-## Forbidden Shortcuts
-- Do not start implementation before `FEATURE_IMPL_PLAN` is written and approved.
-- Do not treat architecture assumptions as verified facts without citing the source.
-
-## Handoff Message Shape
-- Feature: `[FEATURE_KEY]`
-- Required implementation slice: file or module scope
-- Required proving checks: test or lint or build commands
-- Upstream blockers or assumptions: explicit list

package/assets/toolkit/toolkit/templates/handoffs/BA_TO_ARCH.md

@@ -1,28 +0,0 @@
-# BA to ARCH Handoff
-
-## Required Inputs
-- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
-- `docs/product/PRD_[FEATURE_KEY].md`
-- `docs/product/BACKLOG_[FEATURE_KEY].md`
-- current `SHARED_PLANNING.md`
-
-## Required Outputs
-- `docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md`
-- API, DB, and UI design artifacts when in scope
-- updated `SHARED_PLANNING.md`
-- updated `QUALITY_CHECKLIST.md`
-
-## Mandatory Checks
-- `REQ -> UC/BR/AC` traceability exists in BA output.
-- unresolved `OQ-xx` items are visible to ARCH.
-- ARCH knows whether API, DB, and UI scope are required.
-
-## Forbidden Shortcuts
-- Do not jump into implementation details before architecture scope is mapped.
-- Do not hide unresolved business rules inside architecture assumptions.
-
-## Handoff Message Shape
-- Feature: `[FEATURE_KEY]`
-- In-scope use cases: `UC-xx`
-- Key business rules: `BR-xx`
-- Blocking open questions: `OQ-xx` or `None`

package/assets/toolkit/toolkit/templates/handoffs/DEV_STAGE1_SPEC_REVIEW.md

@@ -1,26 +0,0 @@
-# DEV Stage 1 Spec Review
-
-## Required Inputs
-- implementation diff or changed files
-- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
-- `docs/api/[FeaturePascal]_API.yaml` and `docs/api/[FEATURE_KEY]_ENDPOINTS.md` when API scope exists
-- `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` when UI scope exists
-- `docs/database/DATABASE_SPEC_[FEATURE_KEY].md` when data scope exists
-
-## Required Outputs
-- PASS or FAIL verdict
-- mismatch table with exact file references
-- explicit handoff decision to Stage 2 or back to DEV
-
-## Mandatory Checks
-- code matches BA, API, DB, and flow-action requirements line by line
-- missing mappings and drift are called out explicitly
-- unresolved assumptions that affect behavior are treated as blockers
-
-## Verification Evidence
-- quote the exact specification text before declaring a match or mismatch
-- use: `Spec says: "[exact quote]" -> Evidence: [match/mismatch + file reference]`
-
-## Forbidden Shortcuts
-- Do not start with style or maintainability feedback.
-- Do not trust the implementer report without checking artifacts directly.

package/assets/toolkit/toolkit/templates/handoffs/DEV_STAGE2_CODE_QUALITY_REVIEW.md

@@ -1,20 +0,0 @@
-# DEV Stage 2 Code Quality Review
-
-## Required Inputs
-- Stage 1 review result marked PASS
-- implementation diff or changed files
-- relevant test or lint outputs
-
-## Required Outputs
-- PASS or FAIL verdict
-- quality findings with file references
-- recommendation for QA handoff readiness
-
-## Mandatory Checks
-- Stage 1 spec review already passed
-- naming, structure, tests, and maintainability are reviewed
-- verification commands cited are fresh and relevant to the current diff
-
-## Forbidden Shortcuts
-- Do not reopen Stage 1 requirement matching as a substitute for quality review.
-- Do not declare QA-ready without confirming Stage 1 PASS and fresh verification evidence.

package/assets/toolkit/toolkit/templates/handoffs/DEV_TO_QA.md

@@ -1,23 +0,0 @@
-# DEV to QA Handoff
-
-## Required Inputs
-- `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
-- implementation diff summary
-- Stage 1 spec review PASS evidence
-- Stage 2 code-quality review PASS evidence
-- fresh test or lint outputs used for QA handoff
-
-## Required Outputs
-- QA test scope
-- explicit release-risk notes
-- updated `SHARED_PLANNING.md`
-- updated `QUALITY_CHECKLIST.md`
-
-## Mandatory Checks
-- both DEV review gates are PASS
-- verification evidence is fresh
-- known limitations or assumptions are recorded, not hidden
-
-## Forbidden Shortcuts
-- Do not hand off to QA with only one review gate complete.
-- Do not describe expected behavior as if it were verified runtime evidence.