sdtk-kit 0.3.8 → 1.0.0

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

@@ -1,20 +0,0 @@
-# FLOWCHART CREATION RULES (Compatibility Note)
-
-This file is kept only for backward compatibility.
-
-Do not use this file as the primary source of truth anymore.
-The rule set has been split into two files:
-- `YAML_CREATION_RULES_FINAL.md` (root) / `templates/docs/api/YAML_CREATION_RULES.md` (toolkit)
-- `API_DESIGN_FLOWCHART_CREATION_RULES_FINAL.md` (root) / `templates/docs/api/API_DESIGN_FLOWCHART_CREATION_RULES.md` (toolkit)
-
-Use the YAML rules file for:
-- endpoint path/method conventions
-- request/response schema design
-- contract-level API rules
-
-Use the API design + flowchart rules file for:
-- flow list writing
-- PlantUML flow depth and wording
-- API design detail markdown rules
-
-This compatibility note should remain only until all references are migrated.

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

@@ -1,128 +0,0 @@
-# YAML CREATION RULES FINAL
-
-This file is the canonical rule set for designing and maintaining feature-level OpenAPI YAML.
-
-Use this file for:
-- OpenAPI YAML contract design
-- endpoint path/method decisions
-- request/response schema design
-- endpoint summary and contract consistency checks
-
-Do not use this file as the primary rule source for:
-- flowchart writing details
-- API design detail markdown layout
-
-Use `API_DESIGN_FLOWCHART_CREATION_RULES_FINAL.md` for those.
-
-## 1. Rule Precedence
-- Priority 1: follow the existing system's real route, method, payload, and response conventions.
-- Priority 2: match the current source code and runtime behavior.
-- Priority 3: apply the reusable standards in this document.
-- If a reusable rule conflicts with the target system, keep the system rule and document the exception explicitly.
-
-## 2. API Scope Classification
-- Every endpoint must be classified as one of:
-  - `New`
-  - `Deferred`
-  - `Existing (reuse)`
-- Do not silently create a new feature-local API if an existing system API already provides the same behavior with a compatible contract.
-- If the existing API is close in purpose but payload or response is incompatible with the feature need, create a bounded new API.
-
-## 3. Endpoint Path Design
-- Use singular resource names in endpoint paths.
-- Use explicit action segments only when needed by system convention:
-  - `list`
-  - `search`
-  - `edit`
-  - `delete`
-  - `multi-create`
-- Prefer stable system-style patterns such as:
-  - list: `GET /{resource}/list/{company_uuid}/{parent_uuid}`
-  - search: `POST /{resource}/search/{company_uuid}`
-  - view-specific search: `POST /{resource}/bukken-view/search/{company_uuid}`
-  - create: `POST /{resource}/{company_uuid}`
-  - detail: `GET /{resource}/{company_uuid}/{resource_uuid}`
-  - edit: `POST /{resource}/edit/{company_uuid}/{resource_uuid}`
-  - delete: `POST /{resource}/delete/{company_uuid}/{resource_uuid}`
-- Separate namespaces by bounded context.
-- Do not repeat namespace meaning in child path segments.
-
-## 4. Request Contract Rules
-- For feature-owned POST search and write APIs, prefer a stable wrapper:
-  - `data: { ... }`
-- For complex filters, place fields under:
-  - `data.info`
-- If reusing an existing system API, keep the owning module's contract shape exactly as-is.
-- Do not force reused APIs into the feature wrapper pattern.
-- If a payload field changes behavior, the field must be explicit in the schema and must not remain only in examples.
-
-## 5. Response Contract Rules
-- Success responses must include `status` at minimum.
-- Create APIs should return the minimum new identifier required by the caller.
-  - Example: `status + sagyo_assign_uuid`
-- Edit and delete APIs should return status-only unless the target system has a stronger standard.
-- Pre-check or validation helper APIs should return only the minimum boolean or status needed by the UI.
-  - Do not return detail payloads the UI does not consume.
-- Do not add FE-only visual helper payloads when the client can derive them safely.
-  - Example: remove `timeline_backgrounds` if the frontend renders timeline lines from existing data.
-
-## 6. Naming and Field Mapping Rules
-- Use canonical business-domain terminology from the system glossary and database.
-- Prefer actual system terms such as:
-  - `bukken`
-  - `sagyo`
-  - `sagyoin`
-  - `certification`
-- Avoid legacy aliases when an official term already exists.
-- Field names should align with database semantics when they represent the same concept.
-- If the DB uses a string state code, the API field must not be modeled as an integer.
-- If a field is date-only (`format: date`), include the display format in the description.
-  - Example: `Start date (YYYYMMDD)`
-
-## 7. Search and List API Rules
-- One search API may serve multiple UI actions when the logic is the same:
-  - initial load
-  - search button
-  - refresh after mode/date change
-- If one endpoint serves multiple UI actions, document that explicitly in YAML description and endpoint docs.
-- Search APIs must define filter combination semantics clearly:
-  - AND across different fields
-  - OR within each `*_uuids` array
-- If UI rendering depends on stable order, the YAML description must state the confirmed ORDER BY logic.
-
-## 8. Split vs Reuse Rules
-- Split read/search endpoints when the FE needs materially different grouped or view-shaped datasets.
-- Merge or remove helper payloads when they add maintenance cost without business value.
-- Reuse existing platform APIs when behavior already exists and only a feature-level mapping layer is needed.
-  - Example: reuse shared environment setting APIs instead of creating feature-local setting APIs.
-
-## 9. Sample Data Rules
-- For fields declared as `format: uuid`, use canonical UUID samples.
-  - Example: `123e4567-e89b-12d3-a456-426614174000`
-- Do not use placeholder UUID-like labels such as:
-  - `customer-uuid-001`
-  - `assign-uuid-001`
-- Keep sample data deterministic and internally consistent across request and response examples.
-
-## 10. Cross-Artifact Consistency Rules
-- The YAML contract is the source of truth for:
-  - endpoint path
-  - method
-  - request wrapper
-  - response shape
-- After any YAML contract change, sync these artifacts:
-  - endpoint markdown
-  - flow list
-  - PlantUML flow assets
-  - API design detail markdown
-- If any artifact cannot yet be synced, note the mismatch explicitly rather than leaving stale content.
-
-## 11. Minimum YAML Quality Gate
-- Path/method follow the target system convention.
-- API type is classified (`New`, `Deferred`, `Existing (reuse)`).
-- Request/response wrappers are stable and explicit.
-- FE-only helper payloads are removed.
-- Field names and types match DB semantics.
-- UUID examples are valid UUIDs.
-- Date descriptions include display format where needed.
-- Search/list APIs document filter semantics and ordering when relevant.

package/assets/toolkit/toolkit/templates/docs/api/feature_api_flow_list_TEMPLATE.txt

@@ -1,12 +0,0 @@
-@startuml
-partition "[TBD] **/api/v1/...** {{FEATURE_NAME}} flow" {
-start
-  :Authenticate & authorize;
-  :Validate request;
-  :Business logic;
-  :Persist changes;
-  :Return response;
-stop
-}
-@enduml
-

package/assets/toolkit/toolkit/templates/docs/architecture/ARCH_DESIGN_TEMPLATE.md

@@ -1,109 +0,0 @@
-# Technical Architecture: {{FEATURE_KEY}} ({{FEATURE_NAME}})
-
-**Document ID:** ARCH_DESIGN_{{FEATURE_KEY}}
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** ARCH Agent
-**Status:** DRAFT - Ready for DEV Review
-
----
-
-## Abbreviations
-
-| No | Abbreviation | Meaning |
-| ---: | --- | --- |
-| 1 | API | Application Programming Interface |
-| 2 | DB | Database |
-| 3 | OQ | Open Question |
-| 4 | NFR | Non-Functional Requirement |
-| 5 | UC | Use Case |
-
----
-
-## 1. EXECUTIVE SUMMARY
-
-### 1.1 Tech Stack (project-level)
-- Backend: {{STACK_BACKEND}}
-- Frontend: {{STACK_FRONTEND}}
-- Mobile: {{STACK_MOBILE}}
-- Database: {{STACK_DATABASE}}
-- Auth: {{STACK_AUTH}}
-
-## 2. SCOPE
-
-- In scope (Phase 1):
-  - TBD
-- Out of scope:
-  - TBD
-
----
-
-## 3. ASSUMPTIONS & OPEN QUESTIONS
-
-### 3.1 Assumptions
-- TBD (must be approved by PM if impacting behavior/API/security)
-
-### 3.2 Open Questions (Clarifications Needed)
-
-| No | Q-ID | Question | Decision Owner (PM/User) | Needed By (Phase) | Status (OPEN/RESOLVED) | Notes/Options | Resolution |
-| ---: | --- | --- | --- | --- | --- | --- | --- |
-| 1 | OQ-01 | TBD | PM | Phase 3 (ARCH) | OPEN | TBD | TBD |
-
----
-
-## 4. SYSTEM ARCHITECTURE
-
-### 4.1 Diagram
-TBD (ASCII/PlantUML/Mermaid)
-
-### 4.2 Component Responsibilities
-
-| No | Component | Responsibility | Technology | Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | API | TBD | TBD | TBD |
-
----
-
-## 5. DATA MODEL
-
-| No | Table/Entity | Purpose | Key Fields | Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | TBD | TBD | TBD | TBD |
-
----
-
-## 6. API DESIGN (if applicable)
-
-- OpenAPI: `docs/api/{{FEATURE_PASCAL}}_API.yaml`
-- API endpoints spec (markdown): `docs/api/{{FEATURE_KEY}}_ENDPOINTS.md`
-- Flow list: `docs/api/{{FEATURE_SNAKE}}_api_flow_list.txt`
-
----
-
-## 7. UI DESIGN (if applicable)
-
-- Screen layouts: `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md`
-- Flow-action screen spec: `docs/specs/{{FEATURE_KEY}}_FLOW_ACTION_SPEC.md`
-- Related rule file: `toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md`
-
----
-
-## 8. DATABASE DESIGN (if applicable)
-
-- Database spec: `docs/database/DATABASE_SPEC_{{FEATURE_KEY}}.md`
-
----
-
-## 9. SECURITY & COMPLIANCE
-
-- TBD
-
-## 10. OBSERVABILITY
-
-- TBD
-
-## 11. HANDOFF
-
-HANDOFF TO DEV:
-`@dev please implement {{FEATURE_KEY}} based on ARCH_DESIGN + BACKLOG + API/layout/docs`
-

package/assets/toolkit/toolkit/templates/docs/database/DATABASE_SPEC_TEMPLATE.md

@@ -1,175 +0,0 @@
-# DATABASE SPECIFICATION: {{FEATURE_KEY}}
-
-**Document ID:** DATABASE_SPEC_{{FEATURE_KEY}}
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** ARCH Agent
-**Status:** DRAFT
-**Source:** `docs/specs/BA_SPEC_{{FEATURE_KEY}}.md`, `docs/architecture/ARCH_DESIGN_{{FEATURE_KEY}}.md`
-
----
-
-## Abbreviations
-
-| No | Abbreviation | Meaning |
-| ---: | --- | --- |
-| 1 | DB | Database |
-| 2 | PK | Primary Key |
-| 3 | FK | Foreign Key |
-| 4 | ERD | Entity Relationship Diagram |
-| 5 | OQ | Open Question |
-
----
-
-## Table of Contents
-
-1. [Overview](#1-overview)
-2. [ERD Diagram (PlantUML)](#2-erd-diagram-plantuml)
-3. [Core Tables](#3-core-tables)
-4. [Related/Referenced Tables](#4-relatedreferenced-tables)
-5. [Settings Storage](#5-settings-storage)
-6. [Indexes & Constraints](#6-indexes--constraints)
-7. [Open Questions](#7-open-questions)
-8. [Document History](#document-history)
-
----
-
-## 1. Overview
-
-### 1.1 Scope
-- Describe database scope for `{{FEATURE_NAME}}`.
-- Clarify whether each table is new/modified/reused.
-
-### 1.2 Table Categories
-
-| No | Category | Tables | Purpose |
-| ---: | --- | --- | --- |
-| 1 | Core (New/Modified) | TBD | Main feature tables |
-| 2 | Referenced (Existing) | TBD | Existing tables reused by feature |
-| 3 | Settings | TBD | Configuration storage |
-
-### 1.3 Naming Conventions
-
-| No | Prefix | Type | Example |
-| ---: | --- | --- | --- |
-| 1 | `cld_dat_` | Data table | `cld_dat_example_info` |
-| 2 | `cld_mst_` | Master table | `cld_mst_example_info` |
-
----
-
-## 2. ERD Diagram (PlantUML)
-
-```plantuml
-@startuml {{FEATURE_KEY}}_ERD
-!define TABLE(name) entity name << (T,#FFAAAA) >>
-!define PK(x) <b><u>x</u></b>
-!define FK(x) <i>x</i>
-
-skinparam linetype ortho
-skinparam entity {
-  BackgroundColor #FEFEFE
-  BorderColor #333333
-  ArrowColor #666666
-}
-
-title {{FEATURE_NAME}} - Entity Relationship Diagram
-
-TABLE(cld_dat_example_info) {
-  PK(example_uuid) : UUID
-  --
-  FK(parent_uuid) : UUID <<nullable>>
-  name : VARCHAR
-  start_dt : DATETIME <<nullable>>
-  end_dt : DATETIME <<nullable>>
-  --
-  CREATE_DT : DATETIME
-  UPDATE_DT : DATETIME
-}
-
-@enduml
-```
-
-### 2.1 ERD Summary
-- Summarize key relations and ownership boundaries.
-
----
-
-## 3. Core Tables
-
-### 3.1 cld_dat_example_info (Example Info)
-
-| No | Column Name (JP) | Column Name | Data Type | Size | Key | Nullable | Default | Description |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- |
-| 1 | Example UUID (JP) | example_uuid | UUID | - | PK | No | - | Primary key |
-| 2 | Parent UUID (JP) | parent_uuid | UUID | - | FK | Yes | NULL | Parent reference |
-
-### 3.2 cld_dat_example_detail_info (Example Detail)
-
-| No | Column Name (JP) | Column Name | Data Type | Size | Key | Nullable | Default | Description |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- |
-| 1 | Detail UUID (JP) | example_detail_uuid | UUID | - | PK | No | - | Primary key |
-
----
-
-## 4. Related/Referenced Tables
-
-### 4.1 cld_dat_related_info (Related Entity)
-
-| No | Key Column | Type | Description |
-| ---: | --- | --- | --- |
-| 1 | related_uuid | UUID | Referenced by core table |
-
----
-
-## 5. Settings Storage
-
-### 5.1 Environment Settings Table
-
-| No | Setting | category1 | category2 | key | value_type | Example Value | Description |
-| ---: | --- | --- | --- | --- | --- | --- | --- |
-| 1 | TBD | TBD | TBD | TBD | string | TBD | TBD |
-
----
-
-## 6. Indexes & Constraints
-
-### 6.1 Recommended Indexes
-
-#### cld_dat_example_info
-
-| No | Index Name | Columns | Type | Purpose |
-| ---: | --- | --- | --- | --- |
-| 1 | idx_example_parent | parent_uuid | BTREE | Parent lookup |
-
-### 6.2 Foreign Key Constraints
-
-| No | Constraint Name | From Table.Column | To Table.Column | On Update | On Delete |
-| ---: | --- | --- | --- | --- | --- |
-| 1 | fk_example_parent | cld_dat_example_info.parent_uuid | cld_dat_related_info.related_uuid | RESTRICT | SET NULL |
-
-### 6.3 Check Constraints
-
-| No | Constraint Name | Expression | Purpose |
-| ---: | --- | --- | --- |
-| 1 | chk_example_range | start_dt < end_dt | Validate datetime range |
-
----
-
-## 7. Open Questions
-
-### 7.1 Questions Requiring Clarification
-
-| No | Q-ID | Area | Question | Impact | Priority | Status | Resolution |
-| ---: | --- | --- | --- | --- | --- | --- | --- |
-| 1 | Q-01 | Schema | TBD | TBD | High | OPEN | TBD |
-
-### 7.2 Missing Information
-- List unresolved schema details (size/default/nullability/code maps).
-
----
-
-## Document History
-
-| No | Version | Date | Author | Changes |
-| ---: | --- | --- | --- | --- |
-| 1 | 1.0.0 | {{DATE}} | ARCH Agent | Initial template-based version |

package/assets/toolkit/toolkit/templates/docs/design/DESIGN_LAYOUT_TEMPLATE.md

@@ -1,49 +0,0 @@
-# Screen Layout Design: {{FEATURE_KEY}} ({{FEATURE_NAME}})
-
-**Document ID:** DESIGN_LAYOUT_{{FEATURE_KEY}}
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** ARCH Agent
-**Status:** DRAFT - Ready for DEV Review
-
----
-
-## Abbreviations
-
-| No | Abbreviation | Meaning |
-| ---: | --- | --- |
-| 1 | UI | User Interface |
-| 2 | API | Application Programming Interface |
-| 3 | OQ | Open Question |
-
----
-
-## Screen List
-
-| No | Screen ID | Screen Name | Description |
-| ---: | --- | --- | --- |
-| 1 | A-1 | TBD | TBD |
-
----
-
-## A-1. TBD
-
-```plantuml
-@startsalt
-{
-  { "(1) TBD" | [(2) Action] }
-}
-@endsalt
-```
-
-### API List
-
-| No | API ID | Endpoint |
-| ---: | --- | --- |
-| 1 | API-1 | TBD |
-
-### Items
-
-| No | Item | Type | Required | Notes |
-| ---: | --- | --- | --- | --- |
-| 1 | TBD | text | - | TBD |

package/assets/toolkit/toolkit/templates/docs/dev/FEATURE_IMPL_PLAN_TEMPLATE.md

@@ -1,73 +0,0 @@
-# Feature Implementation Plan: {{FEATURE_KEY}} ({{FEATURE_NAME}})
-
-**Document ID:** FEATURE_IMPL_PLAN_{{FEATURE_KEY}}
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** DEV Agent
-**Status:** DRAFT
-
----
-
-## 1. OVERVIEW
-
-### 1.1 Source Documents
-- `docs/architecture/ARCH_DESIGN_{{FEATURE_KEY}}.md`
-- `docs/product/BACKLOG_{{FEATURE_KEY}}.md`
-- (optional) `docs/api/{{FEATURE_PASCAL}}_API.yaml`
-- (optional) `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md`
-
-### 1.2 Tech Stack (project-level)
-- Backend: {{STACK_BACKEND}}
-- Frontend: {{STACK_FRONTEND}}
-- Mobile: {{STACK_MOBILE}}
-- Database: {{STACK_DATABASE}}
-- Auth: {{STACK_AUTH}}
-
-### 1.3 Local Commands (project-level)
-- Backend tests: `{{CMD_BACKEND_TESTS}}`
-- Backend typecheck: `{{CMD_BACKEND_TYPECHECK}}`
-- Backend lint: `{{CMD_BACKEND_LINT}}`
-- Frontend tests: `{{CMD_FRONTEND_TESTS}}`
-- Frontend lint: `{{CMD_FRONTEND_LINT}}`
-- E2E tests: `{{CMD_E2E_TESTS}}`
-
----
-
-## 2. IMPLEMENTATION SCOPE
-
-### 2.1 Backend
-- TBD
-
-### 2.2 Frontend
-- TBD
-
----
-
-## 3. OPEN QUESTIONS / CLARIFICATIONS
-
-| Q-ID | Question | Decision Owner (PM/User) | Status (OPEN/RESOLVED) | Notes/Options | Resolution |
-|------|----------|---------------------------|------------------------|---------------|------------|
-| OQ-01 | TBD | PM | OPEN | TBD | TBD |
-
----
-
-## 4. TEST PLAN
-
-- Unit tests: target TBD
-- Integration tests: target TBD
-- E2E tests (if applicable): target TBD
-
----
-
-## 5. CODE REVIEW (MANDATORY)
-
-- [ ] Self review complete
-- [ ] Peer review requested (AI peer review allowed)
-- [ ] Peer comments addressed
-- [ ] Approved
-
----
-
-## 6. HANDOFF TO QA
-
-`@qa please test {{FEATURE_KEY}} (after Code Review PASS)`

package/assets/toolkit/toolkit/templates/docs/product/BACKLOG_TEMPLATE.md

@@ -1,50 +0,0 @@
-# BACKLOG: {{FEATURE_KEY}} ({{FEATURE_NAME}})
-
-**Document ID:** BACKLOG_{{FEATURE_KEY}}
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** PM Agent
-**Status:** DRAFT - Ready for ARCH Review
-
----
-
-## BACKLOG SUMMARY
-
-| Priority | Count | Stories |
-|----------|-------|---------|
-| **Must Have** | TBD | US-01... |
-
----
-
-## EPIC-01: TBD
-
-### US-01: TBD
-
-**Priority:** Must Have | **Effort:** TBD | **Sprint:** TBD
-
-**Story:**
-As a <role>, I want <capability>, so that <benefit>.
-
-**Acceptance Criteria:**
-- [ ] AC-01.1: TBD
-
-**Dependencies:** TBD
-
-**Traceability:** UC-01, BR-01
-
----
-
-## DEFINITION OF DONE
-
-- [ ] All acceptance criteria verified
-- [ ] Tests added and passing
-- [ ] Code review complete
-- [ ] Docs updated
-
----
-
-## OPEN QUESTIONS (Backlog Clarifications)
-
-| Q-ID | Question | Related Epic/Story | Decision Owner (PM/User) | Status (OPEN/RESOLVED) | Resolution |
-|------|----------|--------------------|---------------------------|------------------------|------------|
-| OQ-01 | TBD | EPIC-01 / US-01 | PM | OPEN | TBD |

package/assets/toolkit/toolkit/templates/docs/product/PRD_TEMPLATE.md

@@ -1,66 +0,0 @@
-# PRD: {{FEATURE_KEY}} ({{FEATURE_NAME}})
-
-**Document ID:** PRD_{{FEATURE_KEY}}
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** PM Agent
-**Status:** DRAFT - Ready for ARCH Review
-**Source:** BA_SPEC_{{FEATURE_KEY}}.md
-
----
-
-## 1. EXECUTIVE SUMMARY
-
-## 2. GOALS & SUCCESS METRICS
-
-| Goal ID | Goal | Success Metric | Target |
-|---------|------|----------------|--------|
-| G-01 | TBD | TBD | TBD |
-
----
-
-## 3. PERSONAS / USER ROLES
-
-## 4. FEATURE OVERVIEW
-
-### 4.1 Feature Map (by Use Case)
-| Use Case | Feature | Priority | Epic |
-|----------|---------|----------|------|
-| UC-01 | TBD | Must | EPIC-01 |
-
----
-
-## 5. RELEASE CRITERIA
-
-| RC ID | Criterion | Verification |
-|-------|----------|--------------|
-| RC-01 | TBD | QA report |
-
----
-
-## 6. RISKS & OPEN QUESTIONS
-
-### 6.1 Risks
-
-| Risk ID | Risk | Probability | Impact | Mitigation |
-|---------|------|-------------|--------|------------|
-| R-01 | TBD | Medium | Medium | TBD |
-
-### 6.2 Open Questions (Clarifications Needed)
-
-| Q-ID | Question | Decision Owner (PM/User) | Needed By (Phase) | Status (OPEN/RESOLVED) | Notes/Options | Resolution |
-|------|----------|---------------------------|-------------------|------------------------|---------------|------------|
-| OQ-01 | TBD | User | Phase 3 (ARCH) | OPEN | TBD | TBD |
-
-### 6.3 Decision Log (PM)
-
-| D-ID | Decision | Rationale | Decided By (PM/User) | Date | Related Q-ID |
-|------|----------|-----------|----------------------|------|--------------|
-| D-01 | TBD | TBD | PM | {{DATE}} | OQ-01 |
-
----
-
-## 7. NEXT ACTION
-
-HANDOFF TO ARCH:
-`@arch please design technical solution for {{FEATURE_KEY}} based on BA_SPEC + PRD + BACKLOG`