sdtk-kit 0.3.9 → 1.0.0

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

@@ -1,229 +0,0 @@
-# {{FEATURE_KEY}} API ENDPOINTS
-
-**Document ID:** {{FEATURE_KEY}}_ENDPOINTS
-**Version:** 1.0.0
-**Date:** {{DATE}}
-**Author:** ARCH Agent
-**Status:** DRAFT
-**Related Specs:** `docs/specs/BA_SPEC_{{FEATURE_KEY}}.md`, `docs/specs/{{FEATURE_KEY}}_FLOW_ACTION_SPEC.md`, `docs/database/DATABASE_SPEC_{{FEATURE_KEY}}.md`, `docs/api/{{FEATURE_KEY}}_API_DESIGN_DETAIL.md`
-
----
-
-## Abbreviations
-
-| No | Abbreviation | Meaning |
-| ---: | --- | --- |
-| 1 | API | Application Programming Interface |
-| 2 | DB | Database |
-| 3 | UI | User Interface |
-| 4 | BR | Business Rule |
-| 5 | UC | Use Case |
-| 6 | OQ | Open Question |
-
----
-
-## Domain Keywords
-
-| No | Keyword | Source Term | Meaning Used In This API Spec |
-| ---: | --- | --- | --- |
-| 1 | `resource_a` | TBD | TBD |
-| 2 | `resource_b` | TBD | TBD |
-
----
-
-## Table of Contents
-
-1. [Overview](#1-overview)
-2. [Authentication & Authorization](#2-authentication--authorization)
-3. [Common Response Formats](#3-common-response-formats)
-4. [Core APIs](#4-core-apis)
-5. [Master/Reuse APIs](#5-masterreuse-apis)
-6. [Error Codes Reference](#6-error-codes-reference)
-7. [Appendices](#appendix-a-data-model-reference)
-8. [Document History](#document-history)
-
----
-
-## 1. Overview
-
-### 1.1 Base URL
-```
-{BASE_URL}/api
-```
-
-### 1.2 API Versioning
-Current version: `v1` (confirm final path policy in BA/ARCH decisions).
-
-### 1.3 Content Type
-- Request: `application/json`
-- Response: `application/json`
-
-### 1.4 Date/Time Format
-- Date: `YYYY-MM-DD`
-- DateTime: `YYYY-MM-DDTHH:mm:ss` (or timezone-aware per project decision)
-
-### 1.5 Endpoint Naming Convention
-- Apply `YAML_CREATION_RULES.md` for API contract rules and `API_DESIGN_FLOWCHART_CREATION_RULES.md` for flow/depth alignment.
-- Keep resource naming and method policy consistent across all sections.
-
----
-
-## 2. Authentication & Authorization
-
-### 2.1 Authentication
-All endpoints require Bearer token authentication unless explicitly documented.
-
-### 2.2 Permission Model
-
-| No | Permission | Description | Allowed Operations |
-| ---: | --- | --- | --- |
-| 1 | `feature:view` | Read permission | Read/search endpoints |
-| 2 | `feature:edit` | Write permission | Create/edit/delete endpoints |
-
----
-
-## 3. Common Response Formats
-
-### 3.1 Success Response
-```json
-{
-  "status": 0,
-  "msg": "success",
-  "data": {},
-  "errors": []
-}
-```
-
-### 3.2 Error Response
-```json
-{
-  "status": 100,
-  "msg": "validation error",
-  "data": {},
-  "errors": [
-    {
-      "field": "field_name",
-      "code": "INVALID",
-      "detail": "TBD"
-    }
-  ]
-}
-```
-
-### 3.3 Pagination Parameters
-
-| No | Parameter | Type | Default | Description |
-| ---: | --- | --- | --- | --- |
-| 1 | `page` | integer | 1 | Page number |
-| 2 | `page_size` | integer | 20 | Items per page |
-
----
-
-## 4. Core APIs
-
-### 4.1 METHOD /api/... (TBD)
-
-**Description:** TBD  
-**Related Use Cases:** UC-xx  
-**Authentication:** Required (`feature:view` or `feature:edit`)
-
-**Request Schema:**
-
-| No | Field | Type | Required | Description |
-| ---: | --- | --- | --- | --- |
-| 1 | `field_1` | string | Yes | TBD |
-
-**Request Example:**
-```http
-METHOD /api/...
-Authorization: Bearer {token}
-Content-Type: application/json
-```
-
-```json
-{
-  "field_1": "value"
-}
-```
-
-**Response Schema (key fields):**
-```json
-{
-  "status": 0,
-  "msg": "success",
-  "data": {
-    "items": []
-  },
-  "errors": []
-}
-```
-
-**Possible Error Codes:**
-
-| No | Code | Description |
-| ---: | --- | --- |
-| 1 | `ERR-xxx` | TBD |
-
----
-
-## 5. Master/Reuse APIs
-
-| No | Method | Endpoint | API Type | Description |
-| ---: | --- | --- | --- | --- |
-| 1 | GET | /api/... | Existing (reuse) | TBD |
-
----
-
-## 6. Error Codes Reference
-
-### 6.1 Standard HTTP Status Codes
-
-| No | Code | Description |
-| ---: | --- | --- |
-| 1 | 200 | Success |
-| 2 | 400 | Bad Request |
-| 3 | 401 | Unauthorized |
-| 4 | 403 | Forbidden |
-| 5 | 404 | Not Found |
-| 6 | 409 | Conflict |
-| 7 | 500 | Internal Server Error |
-
-### 6.2 Application Error Codes
-
-| No | Code | HTTP Status | Description |
-| ---: | --- | --- | --- |
-| 1 | `ERR-VALIDATION` | 400 | Request validation failed |
-| 2 | `ERR-AUTH` | 401/403 | Auth/permission failure |
-| 3 | `ERR-CONFLICT` | 409 | Business conflict |
-
----
-
-## Appendix A: Data Model Reference
-
-| No | Entity | Key Fields | Notes |
-| ---: | --- | --- | --- |
-| 1 | TBD | TBD | TBD |
-
----
-
-## Appendix B: API Endpoint Summary
-
-| No | Method | Endpoint | API Type | Description |
-| ---: | --- | --- | --- | --- |
-| 1 | METHOD | /api/... | New | TBD |
-
----
-
-## Appendix C: API Required For Screen Logic
-
-| No | Method | Endpoint | API Type | Description (screen logic) | Spec can confirm (Q&A) |
-| ---: | --- | --- | --- | --- | --- |
-| 1 | METHOD | /api/... | New | TBD | TBD |
-
----
-
-## Document History
-
-| No | Version | Date | Author | Changes |
-| ---: | --- | --- | --- | --- |
-| 1 | 1.0.0 | {{DATE}} | ARCH Agent | Initial template-based version |

package/assets/toolkit/toolkit/templates/docs/api/FEATURE_API_TEMPLATE.yaml

@@ -1,20 +0,0 @@
-openapi: '3.0.3'
-info:
-  title: '{{FEATURE_NAME}} API'
-  version: '1.0.0'
-  description: |
-    # {{FEATURE_NAME}} API
-    - FeatureKey: {{FEATURE_KEY}}
-servers:
-  - url: /api/v1
-security:
-  - Bearer: []
-paths: {}
-components:
-  securitySchemes:
-    Bearer:
-      type: http
-      scheme: bearer
-      description: Access token
-  schemas: {}
-

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 |