@anhth2/spec-driven-dev-plugin 0.9.0 → 0.9.2

package/ARCHITECTURE.md

@@ -222,7 +222,7 @@ spec-driven-dev/
     └── platform-guide.template.md
 ```
 
-> Build output (gitignored): `commands/*.md`, `skills/**/SKILL.md`, and `core/` (the distributable copied into a consumer's `.agent/` by `--init`). Consumer-side tester artifacts live in the shared spec repo under `feedback/bug-reports/` and `feedback/bdd-proposals/`.
+> Build output (gitignored): `commands/*.md`, `skills/**/SKILL.md`, and `core/` (the distributable copied into a consumer's `.agent/` by `--init`). Consumer-side tester artifacts live in the shared spec repo under `feedback/bug-reports/` and `feedback/bdd-proposals/`. In umbrella mode the **API contract (tech-docs)** also lives in the shared spec repo (`{spec_source}/specs/tech-docs/`) so BE and FE/App read the same contract via the spec submodule.
 
 ---
 

package/bin/index.js

@@ -204,7 +204,6 @@ if (isInit) {
           `    path: "${s.name}"`,
           `    module: "${s.module || 'TODO'}"`,
           `    specs_dir: "${s.name}/specs/bdd"`,
-          `    tech_docs_dir: "${s.name}/specs/tech-docs"`,
         ].join('\n')).join('\n');
       } else {
         servicesBlock = [
@@ -212,7 +211,6 @@ if (isInit) {
           `  #   path: "{service-submodule-dir}"`,
           `  #   module: "{stack-module}"`,
           `  #   specs_dir: "{service-dir}/specs/bdd"`,
-          `  #   tech_docs_dir: "{service-dir}/specs/tech-docs"`,
         ].join('\n');
       }
 
@@ -234,6 +232,7 @@ if (isInit) {
         `paths:`,
         `  prd_dir:              "${specSrc}/specs/prd"`,
         `  design_spec_dir:      "${specSrc}/specs/design-spec"`,
+        `  tech_docs_dir:        "${specSrc}/specs/tech-docs"   # API contract — shared (BE pushes here, FE/App read via /sync)`,
         `  domain_knowledge_dir: "${specSrc}/specs/domain-knowledge"`,
         `  business_dictionary:  "${specSrc}/specs/domain-knowledge/business-dictionary.md"`,
         `  core_entities:        "${specSrc}/specs/domain-knowledge/core-entities.md"`,

package/commands/debug.md

@@ -178,13 +178,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/define-product.md

@@ -175,13 +175,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/fix-bug.md

@@ -175,13 +175,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/generate-bdd.md

@@ -173,13 +173,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/generate-code.md

@@ -175,13 +175,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/generate-design-spec.md

@@ -175,13 +175,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/generate-prd.md

@@ -175,13 +175,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 
@@ -450,13 +451,14 @@ Write `{paths.prd_dir}/{domain}/{TICKET-ID}-{slug}.md` using the structure below
 
 ## a. User Story
 
-As a {User role}
-I want to {User goal}
-So that {Business value}
+- **As a** {User role}
+- **I want to** {User goal}
+- **So that** {Business value}
 
 ## b. Scope
 
-In Scope
+**In Scope**
+
 - {Function 1}
 - {Function 2}
 
@@ -464,24 +466,36 @@ In Scope
 
 # 2. Acceptance Criteria
 
-AC1: {Acceptance criterion — testable, observable, no UI details}
-AC2: {Acceptance criterion}
+- **AC1:** {Acceptance criterion — testable, observable, no UI details}
+- **AC2:** {Acceptance criterion}
 
 ---
 
 # 3. Use Case
 
 #### {TICKET-ID}-UC1: {Use Case Name}
-Actor: {User performing the action}
-Description: {Business scenario description — 1 sentence}
-Pre-condition: {Condition that must be true BEFORE use case begins}
-Post-condition: {State / result AFTER use case completes}
 
-Business Rule
-| ID                      | Business Rule                        | Business Logic                            |
-|-------------------------|--------------------------------------|-------------------------------------------|
-| {TICKET-ID}-UC1-BR1     | {Rule — WHAT the system must do}    | - Logic 1<br/>- Logic 2<br/>- Logic 3    |
-| {TICKET-ID}-UC1-BR2     | {Rule}                               | - Logic                                  |
+- **Actor:** {User performing the action}
+- **Description:** {Business scenario description — 1 sentence}
+- **Pre-condition:** {Condition that must be true BEFORE use case begins}
+- **Post-condition:** {State / result AFTER use case completes}
+
+**Business Rule**
+
+| ID | Business Rule |
+|----|---------------|
+| {TICKET-ID}-UC1-BR1 | {Rule — WHAT the system must do} |
+| {TICKET-ID}-UC1-BR2 | {Rule} |
+
+**Business Logic**
+
+**{TICKET-ID}-UC1-BR1:**
+- Logic 1
+- Logic 2
+- Logic 3
+
+**{TICKET-ID}-UC1-BR2:**
+- Logic
 
 ---
 
@@ -503,11 +517,16 @@ flowchart TD
 
 **Screen 1: {Screen Name}**
 
-| Component      | Details                                                         |
-|----------------|-----------------------------------------------------------------|
-| **Screen**     | {Screen name}                                                   |
-| **Components** | - {Component 1}<br/>- {Component 2}<br/>- {Component 3}        |
-| **Actions**    | - {Action 1} → {Result}<br/>- {Action 2} → {Result}           |
+**Screen:** {Screen name}
+
+**Components:**
+- {Component 1}
+- {Component 2}
+- {Component 3}
+
+**Actions:**
+- {Action 1} → {Result}
+- {Action 2} → {Result}
 
 ---
 
@@ -557,6 +576,7 @@ flowchart TD
 - [ ] No banned terms (if dictionary exists)
 - [ ] User Flow includes error path / exception path
 - [ ] Wireframe covers all screens related to Use Cases
+- [ ] **Định dạng (readability)**: User Story / AC / các field của UC (Actor, Description, Pre/Post-condition) viết dạng bullet `- **Label:** …` — mỗi ý MỘT dòng, KHÔNG viết các dòng liền nhau (sẽ bị dồn thành 1 đoạn khi render); có một dòng trống trước và sau mỗi bảng
 
 ## Changelog Section (append at end of PRD)
 

package/commands/generate-prd.tmpl

@@ -98,13 +98,14 @@ Write `{paths.prd_dir}/{domain}/{TICKET-ID}-{slug}.md` using the structure below
 
 ## a. User Story
 
-As a {User role}
-I want to {User goal}
-So that {Business value}
+- **As a** {User role}
+- **I want to** {User goal}
+- **So that** {Business value}
 
 ## b. Scope
 
-In Scope
+**In Scope**
+
 - {Function 1}
 - {Function 2}
 
@@ -112,24 +113,36 @@ In Scope
 
 # 2. Acceptance Criteria
 
-AC1: {Acceptance criterion — testable, observable, no UI details}
-AC2: {Acceptance criterion}
+- **AC1:** {Acceptance criterion — testable, observable, no UI details}
+- **AC2:** {Acceptance criterion}
 
 ---
 
 # 3. Use Case
 
 #### {TICKET-ID}-UC1: {Use Case Name}
-Actor: {User performing the action}
-Description: {Business scenario description — 1 sentence}
-Pre-condition: {Condition that must be true BEFORE use case begins}
-Post-condition: {State / result AFTER use case completes}
 
-Business Rule
-| ID                      | Business Rule                        | Business Logic                            |
-|-------------------------|--------------------------------------|-------------------------------------------|
-| {TICKET-ID}-UC1-BR1     | {Rule — WHAT the system must do}    | - Logic 1<br/>- Logic 2<br/>- Logic 3    |
-| {TICKET-ID}-UC1-BR2     | {Rule}                               | - Logic                                  |
+- **Actor:** {User performing the action}
+- **Description:** {Business scenario description — 1 sentence}
+- **Pre-condition:** {Condition that must be true BEFORE use case begins}
+- **Post-condition:** {State / result AFTER use case completes}
+
+**Business Rule**
+
+| ID | Business Rule |
+|----|---------------|
+| {TICKET-ID}-UC1-BR1 | {Rule — WHAT the system must do} |
+| {TICKET-ID}-UC1-BR2 | {Rule} |
+
+**Business Logic**
+
+**{TICKET-ID}-UC1-BR1:**
+- Logic 1
+- Logic 2
+- Logic 3
+
+**{TICKET-ID}-UC1-BR2:**
+- Logic
 
 ---
 
@@ -151,11 +164,16 @@ flowchart TD
 
 **Screen 1: {Screen Name}**
 
-| Component      | Details                                                         |
-|----------------|-----------------------------------------------------------------|
-| **Screen**     | {Screen name}                                                   |
-| **Components** | - {Component 1}<br/>- {Component 2}<br/>- {Component 3}        |
-| **Actions**    | - {Action 1} → {Result}<br/>- {Action 2} → {Result}           |
+**Screen:** {Screen name}
+
+**Components:**
+- {Component 1}
+- {Component 2}
+- {Component 3}
+
+**Actions:**
+- {Action 1} → {Result}
+- {Action 2} → {Result}
 
 ---
 
@@ -205,6 +223,7 @@ flowchart TD
 - [ ] No banned terms (if dictionary exists)
 - [ ] User Flow includes error path / exception path
 - [ ] Wireframe covers all screens related to Use Cases
+- [ ] **Định dạng (readability)**: User Story / AC / các field của UC (Actor, Description, Pre/Post-condition) viết dạng bullet `- **Label:** …` — mỗi ý MỘT dòng, KHÔNG viết các dòng liền nhau (sẽ bị dồn thành 1 đoạn khi render); có một dòng trống trước và sau mỗi bảng
 
 ## Changelog Section (append at end of PRD)
 

package/commands/generate-spec-manifest.md

@@ -180,13 +180,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/generate-tech-docs.md

@@ -196,13 +196,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 
@@ -453,25 +454,49 @@ Write `{paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md`:
 ---
 
 ## §1. Overview
+
+{Tóm tắt ngắn: UC này implement gì, scope kỹ thuật chính.}
+
 ## §2. API Endpoints
-  *Greenfield:* endpoints được infer từ BDD scenarios — thiết kế mới.
-  *Reverse-document:* mô tả lại API đã tồn tại từ bảng "Existing API Contract" trong PRD.
-    Ghi chú gaps nếu contract thực tế khác với BDD expectations.
-  | Method | Path | Auth/Role | Request | Response |
+
+*Greenfield:* endpoints được infer từ BDD scenarios — thiết kế mới.
+*Reverse-document:* mô tả lại API đã tồn tại từ bảng "Existing API Contract" trong PRD. Ghi chú gaps nếu contract thực tế khác với BDD expectations.
+
+| Method | Path | Auth/Role | Request | Response |
+|--------|------|-----------|---------|----------|
+| {GET/POST/PUT/DELETE} | {/api/v1/...} | {Bearer / role} | `{ field: type }` | `{ field: type }` |
+
 ## §3. Data Model
-  Key entities and relationships.
+
+Key entities and relationships.
+
 ## §4. Service Flow
-  {Client} → Controller → {Facade/Service} → {Repository}
+
+{Client} → Controller → {Facade/Service} → {Repository}
+
 ## §5. Business Rules Implementation
-  | BR-ID | Rule | Implementation approach |
+
+| BR-ID | Rule | Implementation approach |
+|-------|------|-------------------------|
+| {UC-ID}-BR1 | {rule} | {approach} |
+
 ## §6. Error Handling
-  | Scenario | Exception | HTTP Status |
+
+| Scenario | Exception | HTTP Status |
+|----------|-----------|-------------|
+| {scenario} | {ExceptionClass} | {4xx/5xx} |
+
 ## §7. Database Changes
-  Migration scripts or schema changes.
+
+Migration scripts or schema changes.
+
 ## §8. Caching Strategy
-  What to cache, TTL, invalidation triggers.
+
+What to cache, TTL, invalidation triggers.
+
 ## §9. Cross-Service Dependencies
-  External calls, events produced/consumed.
+
+External calls, events produced/consumed.
 
 ## Changelog
 
@@ -480,6 +505,21 @@ Write `{paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md`:
 | 1 | {YYYY-MM-DD} | Initial generation from {UC-ID}.feature (BDD v{bdd_version}) |
 ```
 
+## Publish — share the contract (umbrella + shared spec repo)
+
+If `paths.tech_docs_dir` resolved **under `setup.spec_source`** (e.g. `{spec_source}/specs/tech-docs`), the tech-doc was just written **inside the spec submodule**. It is the cross-team **API contract** — FE/App read it via their own `/sync`. Publish it so they can (2-layer commit):
+
+```bash
+cd {spec_source}
+git add specs/tech-docs/{domain}/{UC-ID}-tech-design.md
+git commit -m "docs({UC-ID}): tech design / API contract"
+git push origin {spec_branch}          # the branch FE/App track in .gitmodules
+cd -
+git add {spec_source} && git commit -m "chore: bump spec pointer ({UC-ID} tech design)"
+```
+
+If `tech_docs_dir` is **local** (single-service, or per-service routing in a multi-service umbrella), skip this — no cross-repo publish needed.
+
 ## Output
 
 # Report Footer — Standard Command Output Format
@@ -549,5 +589,6 @@ Next   : {suggested command with example arguments}
 File: {paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md
 Next: /review-tech-docs {paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md
       ← SA/Lead review required before code generation
+      → if tech-docs live in the shared spec repo: commit + push to the spec submodule (see Publish above) so FE/App `/sync` can read the contract
       → after approved: /generate-code {paths.specs_dir}/{domain}/{UC-ID}-{slug}.feature
 ```

package/commands/generate-tech-docs.tmpl

@@ -101,25 +101,49 @@ Write `{paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md`:
 ---
 
 ## §1. Overview
+
+{Tóm tắt ngắn: UC này implement gì, scope kỹ thuật chính.}
+
 ## §2. API Endpoints
-  *Greenfield:* endpoints được infer từ BDD scenarios — thiết kế mới.
-  *Reverse-document:* mô tả lại API đã tồn tại từ bảng "Existing API Contract" trong PRD.
-    Ghi chú gaps nếu contract thực tế khác với BDD expectations.
-  | Method | Path | Auth/Role | Request | Response |
+
+*Greenfield:* endpoints được infer từ BDD scenarios — thiết kế mới.
+*Reverse-document:* mô tả lại API đã tồn tại từ bảng "Existing API Contract" trong PRD. Ghi chú gaps nếu contract thực tế khác với BDD expectations.
+
+| Method | Path | Auth/Role | Request | Response |
+|--------|------|-----------|---------|----------|
+| {GET/POST/PUT/DELETE} | {/api/v1/...} | {Bearer / role} | `{ field: type }` | `{ field: type }` |
+
 ## §3. Data Model
-  Key entities and relationships.
+
+Key entities and relationships.
+
 ## §4. Service Flow
-  {Client} → Controller → {Facade/Service} → {Repository}
+
+{Client} → Controller → {Facade/Service} → {Repository}
+
 ## §5. Business Rules Implementation
-  | BR-ID | Rule | Implementation approach |
+
+| BR-ID | Rule | Implementation approach |
+|-------|------|-------------------------|
+| {UC-ID}-BR1 | {rule} | {approach} |
+
 ## §6. Error Handling
-  | Scenario | Exception | HTTP Status |
+
+| Scenario | Exception | HTTP Status |
+|----------|-----------|-------------|
+| {scenario} | {ExceptionClass} | {4xx/5xx} |
+
 ## §7. Database Changes
-  Migration scripts or schema changes.
+
+Migration scripts or schema changes.
+
 ## §8. Caching Strategy
-  What to cache, TTL, invalidation triggers.
+
+What to cache, TTL, invalidation triggers.
+
 ## §9. Cross-Service Dependencies
-  External calls, events produced/consumed.
+
+External calls, events produced/consumed.
 
 ## Changelog
 
@@ -128,6 +152,21 @@ Write `{paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md`:
 | 1 | {YYYY-MM-DD} | Initial generation from {UC-ID}.feature (BDD v{bdd_version}) |
 ```
 
+## Publish — share the contract (umbrella + shared spec repo)
+
+If `paths.tech_docs_dir` resolved **under `setup.spec_source`** (e.g. `{spec_source}/specs/tech-docs`), the tech-doc was just written **inside the spec submodule**. It is the cross-team **API contract** — FE/App read it via their own `/sync`. Publish it so they can (2-layer commit):
+
+```bash
+cd {spec_source}
+git add specs/tech-docs/{domain}/{UC-ID}-tech-design.md
+git commit -m "docs({UC-ID}): tech design / API contract"
+git push origin {spec_branch}          # the branch FE/App track in .gitmodules
+cd -
+git add {spec_source} && git commit -m "chore: bump spec pointer ({UC-ID} tech design)"
+```
+
+If `tech_docs_dir` is **local** (single-service, or per-service routing in a multi-service umbrella), skip this — no cross-repo publish needed.
+
 ## Output
 
 {{include:steps/report-footer.md}}
@@ -137,5 +176,6 @@ Write `{paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md`:
 File: {paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md
 Next: /review-tech-docs {paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design.md
       ← SA/Lead review required before code generation
+      → if tech-docs live in the shared spec repo: commit + push to the spec submodule (see Publish above) so FE/App `/sync` can read the contract
       → after approved: /generate-code {paths.specs_dir}/{domain}/{UC-ID}-{slug}.feature
 ```

package/commands/generate-tests.md

@@ -175,13 +175,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/learn.md

@@ -184,13 +184,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---
 

package/commands/propose-scenario.md

@@ -184,13 +184,14 @@ If `services` section is present:
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
+- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **only if step 2 did not already route it to a service** (multi-service umbrellas keep per-service tech-docs). This publishes the BE-authored API contract into the shared spec repo so FE/App can read it via the spec submodule at `/generate-code --phase=integration`.
 - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
 - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 
-> **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
 ---