@trungtamcongnghedigital/vsaf 1.0.0

package/skills/NTAPP/.agent/skills/NTAPP-ds-build-component/steps/step-05-archive-report.md

@@ -0,0 +1,79 @@
+# Step 5: Archive & Report
+
+## GOAL
+Dual-write `archive/_v{N+1}_{timestamp}/` snapshot + generate `build_report.md` với `proposal_checksum` (cho pre-commit Rule 7 detect outdated). Optional auto-commit.
+
+## INSTRUCTIONS
+
+1. **Reuse Persona:** Metadata Registrar đã handle archive logic trong `agents/metadata-registrar.md` mục 3.8. Step này validate + finalize report.
+
+2. **Compose final `build_report.md`:**
+
+   Concat-by-emit-order pattern — Step 5 KHÔNG hardcode section list. Mỗi sub-agent (Step 2-4) **append in-memory** một section vào `build_report_sections[]` array khi thực thi xong; Step 5 concat array theo apply_order với header + footer fixed:
+
+   ```markdown
+   # Build Report — {id}
+
+   **Applied at:** {iso timestamp}
+   **Proposal source:** {bmad-stage-4b | manual}
+   **Proposal checksum:** sha256:{hash}      ← Pre-commit hook Rule 7 dùng
+
+   {concat build_report_sections[] theo apply_order}
+
+   ## [ARCHIVE]
+   - Path: archive/_v{N+1}_{timestamp}/
+   ```
+
+   Section nào sub-agent emit ra (xem persona §4/§8/§11 Output) sẽ xuất hiện trong report. Thêm sub-agent mới sau này → tự append section, không cần update Step 5. Section thường thấy: `[TOKENS APPLIED]` (Step 3), `[RUNTIME TOKENS EXPORTED]` (Step 3b), `[COMPONENTS SCAFFOLDED]` + `[COMPONENTS PATCHED]` + `[METADATA REGISTERED]` (Step 4), `[DSO Override — Warnings skipped]` (Step 2 nếu có override), `[LAYOUT-PRIMITIVE SKIPPED]` (Step 4 lazy materialization).
+
+3. **Verify archive completeness:**
+   - `{design_system_root}/archive/_v{N+1}_{timestamp}/` chứa:
+     - `master_token.json`
+     - `components_metadata.json`
+     - `stack-profile.json` (snapshot dù không thay đổi — coherent restore point)
+     - `runtime_tokens/` — copy của runtime token file(s) từ Step 3b (file path bên code repo + checksum). Cho phép restore cross-repo nếu cần.
+     - `build_report.md` (copy từ feature_deltas)
+   - Thiếu file → log warning, không exit fail (archive best-effort).
+
+4. **Write build report:**
+   - Path: `{design_system_root}/feature_deltas/{id}/build_report.md`.
+   - Atomic write: tempfile → rename.
+
+5. **Optional auto-commit per repo (HITL prompt):**
+   - Hỏi DSO: *"Tạo commit local cho 2 repo? **Spec repo** sẽ commit `master_token.json` + `components_metadata.json` + `feature_deltas/{id}/build_report.md` + archive snapshot. **Code repo** sẽ commit runtime token file (`{runtime_token_path}`) + scaffolded + patched component files. Y (cả 2 repo) / spec-only / code-only / N. Nếu Y, override commit message hay dùng default template?"*
+   - DSO Y → tạo commit ở **cả 2 repo** với cùng `id` trong message để link traceability:
+     - Spec repo template: `"ds-build({id}): apply {tokens_count} tokens, {components_count} components — Master DS update"`
+     - Code repo template: `"ds-build({id}): export runtime tokens + scaffold/patch components per Master DS"`
+   - DSO spec-only / code-only → chỉ commit repo tương ứng, repo còn lại để DSO commit thủ công sau.
+   - DSO N → skip commit ở cả 2 repo (DSO tự commit sau).
+   - KHÔNG push (chỉ local commit).
+
+## OUTPUT
+
+**Spec repo** (`{design_system_root}/...`):
+- `feature_deltas/{id}/build_report.md` (final)
+- `archive/_v{N+1}_{timestamp}/` (snapshot complete)
+- (Optional) git commit local nếu DSO confirm
+
+**Code repo** (`{code_repo_root}/...`):
+- Runtime token file `{styling.runtime_token_path}` (đã ghi xong trong Step 3b)
+- New / patched component files (đã ghi xong trong Step 4)
+- (Optional) git commit local nếu DSO confirm
+
+## CONSOLE SUMMARY
+```
+[BUILD] Step 5: Archive {design_system_root}/archive/_v{N+1}_{timestamp}/ created
+[BUILD] Done. Build report: {design_system_root}/feature_deltas/{id}/build_report.md
+[BUILD] Pre-commit Rule 7 (spec repo) will accept this commit (checksum match).
+[BUILD] Cross-repo reminder: cần tạo 2 commit (spec repo + code repo). Đề xuất merge code repo PR trước, spec repo PR sau.
+```
+
+## CONSTRAINTS
+- KHÔNG push git remote (commit local only nếu DSO confirm).
+- Archive snapshot phải tạo trước khi báo done.
+- `proposal_checksum` deterministic: sha256 của `proposed_ds_updates.md` raw bytes.
+- Không commit cross-repo bằng 1 lệnh git duy nhất (không atomic được — xem [Manual mục 8.3](../../docs/Process/Manual_phase_1.md)).
+
+---
+
+> **[TERMINAL]** Đây là step cuối của pipeline — KHÔNG có `**Next:**`. Build-component hoàn tất sau khi `build_report.md` + archive snapshot ghi xong (+ optional commit local nếu DSO confirm).

package/skills/NTAPP/.agent/skills/NTAPP-ds-build-component/workflow.md

@@ -0,0 +1,151 @@
+# Workflow: NTAPP DS Build Component
+
+**Goal:** Apply delta proposal (NEW + MODIFIED tokens & components) vào codebase + Master DS một cách atomic, lock-protected, idempotent.
+
+## WORKFLOW ARCHITECTURE — Progressive disclosure
+
+- File này giữ KHUNG điều phối (INITIALIZATION + UNIVERSAL SUB-AGENT RULES + PIPELINE MAP + FAIL/OUTPUT/HARD GATE reference). Chi tiết thực thi của mỗi step nằm TRONG step file tương ứng.
+- ⛔ Đọc ĐÚNG MỘT step mỗi lần. Hoàn tất step hiện tại (gồm mọi HITL/STOP gate) RỒI mới theo pointer `**Next:**` ở cuối step để đọc step kế. KHÔNG đọc trước nhiều step cùng lúc.
+- State chuyển tiếp giữa các step qua routing object + `build_report_sections[]` in-memory, không qua việc giữ instruction trong context.
+
+## INITIALIZATION
+
+> **⚠️ Cross-repo alert:** Skill này phải chạy **trong code repo** (cwd = code repo có `package.json`), KHÔNG phải spec repo. Spec repo chỉ giữ Master DS metadata + proposed_ds_updates; component code thuộc về code repo. Yêu cầu **multi-root workspace** mở cả 2 repo. Xem [Manual_phase_1.md mục 8](../../docs/Process/Manual_phase_1.md) — Multi-repo setup.
+
+### Bước 1 — Resolve `id`
+
+Hỏi user `id` của đơn vị work (lấy từ `project_wbs.md`). Cung cấp placeholder ví dụ theo prefix convention:
+
+- `SCR-{NAME}` — màn hình FE (vd: `SCR-LOGIN`)
+- `WGT-{NAME}` — widget FE dùng chung (vd: `WGT-AVATAR`)
+
+> **Build-component chỉ áp dụng cho FE đơn vị.** Proposal `proposed_ds_updates.md` được sinh từ `/ntapp-ui-generation` Stage 4b, mà Stage 4b chỉ chạy với `screen_id` / `widget_id`. Nếu user cung cấp `feature_id` (BE) → DỪNG, báo: *"`{id}` là BE feature, không có DS delta. Build-component skip — BE không động vào Master DS."*
+
+Nếu user không cung cấp `id`, agent auto-detect từ proposal path (folder cha = `{id}`).
+
+### Bước 2 — Auto-derive `id_type`
+
+Từ prefix:
+
+| Prefix | `id_type` |
+|---|---|
+| `SCR-*` | `screen_id` |
+| `WGT-*` | `widget_id` |
+| Khác | **STOP** — không phải FE unit, không vào build-component |
+
+### Bước 3 — Inputs khác
+
+- **Proposal path** (required) — path tới `proposed_ds_updates.md`. Default lookup: `{design_system_root}/feature_deltas/{id}/proposed_ds_updates.md` (resolve qua spec repo). Nếu user không nói rõ → agent dùng default này.
+- **Proposal source** (auto-detect) — `bmad-stage-4b` nếu proposal nằm trong `feature_deltas/`, hoặc `manual` nếu DSO viết tay nơi khác.
+
+Các quyết định khác (warning override, auto-commit) sẽ hỏi HITL tại các step tương ứng.
+
+### Context Loading
+Load `.bmm-config.yaml` block `bmad`, `ds-build` (ở **code repo root**) — extract:
+- `bmad.spec_repo_root` — relative/absolute path tới spec repo (vd: `../business-management-system-doc`).
+- `bmad.design_system_root` — resolved path tới **DS root của repo này** (default `{spec_repo_root}/NTAPP-output/design-system`). Project multi-DS: trỏ `{family_root}/{ds_id}` — thủ tục chuẩn `_shared/ds-resolution.md` **nhánh A**. **Guard:** `{design_system_root}/registry.yaml` tồn tại → đang trỏ family root → STOP, hint sửa config trỏ vào `{family}/{ds_id}` của repo (ngoại lệ: registry có system `root: "."` với `code_repo` khớp repo hiện tại → hợp lệ, tiếp tục).
+- `bmad.code_repo_root` — root của code repo. Default = cwd (auto-detect nếu cwd có `package.json`).
+- `ds-build.component_target_root` — relative path trong code repo nơi scaffold components (default per framework — Angular `src/app/lib/components`, React `src/components`, etc.).
+
+Load các file:
+- `{design_system_root}/master_token.json`, `components_metadata.json`, `stack-profile.json` (spec repo, READ).
+- `{design_system_root}/_shared/proposal-schema.md`, `token-format-schema.md`, `component-metadata-schema.md` (spec repo, READ). **Multi-DS:** `_shared/` LUÔN ở family root — `{design_system_root}/_shared/` không tồn tại (DS namespaced) → đọc `{design_system_root}/../_shared/` (fallback cơ học, áp cho mọi ref `_shared/*`).
+
+### Pre-conditions
+- **Cwd phải là code repo** — verify `{code_repo_root}/package.json` tồn tại. Nếu cwd = spec repo (vd: thấy `NTAPP-output/design-system/` ngay tại cwd) → STOP với message: *"Skill phải chạy trong code repo, không phải spec repo. Mở multi-root workspace, switch sang code repo, chạy lại."*
+- **Spec repo accessible** — verify `{spec_repo_root}` exist + writable (skill cần ghi master_token, metadata, build_report về spec repo).
+- `master_token.json` + `components_metadata.json` + `stack-profile.json` đã tồn tại trong spec repo. Chưa có → STOP với hint chạy `/ntapp-ds-bootstrap` trước.
+- Proposal file path tồn tại + parse-able theo `proposal-schema.md`.
+- `components_metadata.lock` (spec repo) chưa bị giữ bởi process khác. Lock nằm TRONG `{design_system_root}` → tự per-DS: 2 DS khác nhau build song song KHÔNG đụng lock nhau.
+- **Single-dev-per-DS assumption** — file-based lock chỉ protect cùng filesystem. Skill KHÔNG safe khi 2 dev concurrent chạy từ máy khác nhau với **cùng một DS root** (lock không cross-machine). Tại 1 thời điểm chỉ 1 dev chạy build-component cho cùng DS; điều phối ngoài skill (vd: Slack heads-up, branch protection). Multi-DS: dev A build DS `web-admin` + dev B build DS `mobile-app` đồng thời = OK.
+- **Pre-flight runtime token config** — đọc `stack-profile.json.styling`. Nếu thiếu `runtime_token_path` HOẶC `runtime_token_format` (repo legacy schema v1.0-v1.2 chưa migrate) → trigger HITL prompt **TẠI ĐÂY** (trước Step 1), KHÔNG defer sang Step 3b. Lý do: nếu defer, DSO abort prompt giữa pipeline thì spec repo đã có `master_token` mới (Step 3) nhưng code repo không có runtime token → partial state, phải rollback manual. Pre-flight ghi override vào `{code_repo_root}/.bmm-config.yaml` block `stack.styling.{runtime_token_path, runtime_token_format}`; lần chạy sau auto-resolve. Validation: path relative (không leading `/`, không `..`), parent dir tồn tại hoặc offer tạo; format ∈ enum support (xem `runtime-token-exporter.md` §5). Skip điều kiện: `styling.css_vars_supported = false` + format không yêu cầu CSS vars → exporter vẫn chạy theo format alternative.
+
+---
+
+## UNIVERSAL SUB-AGENT RULES
+
+Mọi persona/sub-agent của skill này tuân thủ các convention sau (declared **ONCE** ở đây, persona không lặp lại):
+
+### U1. Atomic file write
+Mọi write thao tác filesystem (master_token, components_metadata, runtime token file, component files, build_report, archive contents) PHẢI dùng pattern **tempfile → fsync → rename**. Không append-write, không partial write. Tránh corrupt nếu process interrupted.
+
+### U2. Path resolution
+- File trong **code repo**: path **relative** to `{code_repo_root}` (vd: `src/app/lib/components/alert-banner/alert-banner.component.ts`). KHÔNG absolute, KHÔNG prefix `{code_repo_root}`. Resolve lúc đọc/ghi: `absolute = {code_repo_root}/{relative_path}`.
+- File trong **spec repo**: path relative to `{design_system_root}` (vd: `feature_deltas/{id}/build_report.md`).
+- Lý do relative: portability cross-machine (dev clone code repo path khác nhau).
+
+### U3. Cross-repo spec-repo guard (defense-in-depth)
+Mọi resolve path tới code repo file (scaffold target, patch target, runtime token output) PHẢI check: nếu resolved absolute path bắt đầu bằng `{spec_repo_root}/...` → STOP với message: *"Target `{path}` rơi vào spec repo. Skill phải write file code trong code repo. Verify `.bmm-config.yaml` `bmad.code_repo_root` + multi-root workspace setup."*
+
+Áp dụng cho: component-scaffolder (Step 4 scaffold target), component-patcher (Step 4 file_path resolve), runtime-token-exporter (Step 3b output path).
+
+### U4. Deterministic output
+Output phải reproducible: same input + same state → same output. Áp dụng:
+- JSON pretty-print: 2-space indent, sorted keys (alphabetical).
+- File content: stable ordering (sort tokens alphabetical TRONG tier, components alphabetical).
+- Timestamps chỉ trong metadata fields định trước (`metadata.last_updated`), không scatter trong body.
+
+### U5. Drift = STOP, not auto-correct
+Bất kỳ mismatch nào giữa proposal expectation vs current state (master_token value khác `before`, file vanished, metadata mismatch) → STOP với message drift detail. Sub-agent KHÔNG được auto-correct, KHÔNG được silent ignore.
+
+---
+
+## PIPELINE MAP (neo thường trực — 1 dòng/step, KHÔNG chi tiết)
+
+| # | Step file | Persona(s) | Output chính |
+|---|---|---|---|
+| 1 | steps/step-01-route.md | delta-router | routing object (4 paths) + `proposal_checksum` |
+| 2 | steps/step-02-warning-gate.md | warning-blocker | warning gate PASS (+ override section nếu có) |
+| 3 | steps/step-03-apply-tokens.md | token-applier | `master_token.json` patched (spec repo) |
+| 3b | steps/step-03b-export-runtime-tokens.md | runtime-token-exporter | runtime token file (code repo) |
+| 4 | steps/step-04-apply-components.md | component-scaffolder + component-patcher + metadata-registrar | component files (code repo) + `components_metadata.json` (spec repo) |
+| 5 | steps/step-05-archive-report.md | metadata-registrar (reuse) | `build_report.md` + archive snapshot |
+
+Chuỗi: **1 → 2 → 3 → 3b → 4 → 5**. Step 5 là TERMINAL. Idempotent toàn bộ ở Step 1 → log "no-op", return early (KHÔNG chạy 2-5).
+
+Cổng HITL nằm TRONG chính step canh nó: warning override (Step 2), file collision overwrite (Step 3b), auto-commit (Step 5). Mọi drift / validation fail → STOP (Universal Rule U5).
+
+---
+
+## FAIL CONDITIONS (agent stop + báo user)
+- **Invalid proposal** — schema fail, missing fields, decision required (vd: `library_wrap` chưa quyết).
+- **Drift** — `master_token` / `components_metadata` không match prerequisites trong proposal.
+- **Write error** — filesystem permission denied, lock conflict.
+- **WARNING PENDING block** — DSO chưa cung cấp override note hợp lệ (hoặc warning thuộc category `library_wrap_undecided` không cho phép override).
+- **Apply partial fail** — Step 3/3b/4 fail giữa chừng → rollback advisory cho DSO.
+- **Runtime token export config missing (INITIALIZATION pre-flight)** — `stack-profile.json` thiếu `styling.runtime_token_path` / `runtime_token_format` VÀ DSO không phản hồi pre-flight HITL prompt (hoặc đáp không hợp lệ). Hint: chạy `/ntapp-ds-bootstrap --refresh-stack` hoặc ghi override `.bmm-config.yaml` block `stack.styling`. Pre-flight catch trước Step 1 chạy → không có partial state risk.
+- **Runtime token file collision** — Step 3b detect file đích đã có nội dung không có header `AUTO-GENERATED` VÀ DSO từ chối overwrite.
+- **Layout library config missing** — Step 4 detect `stack-profile.json` thiếu `layout_library` block (legacy v1.0-v1.2) VÀ proposal có layout-primitive component. Fallback `name=css-vanilla, strategy=generated-component` + emit warning, không hard stop. Khuyến nghị DSO chạy `/ntapp-ds-bootstrap --refresh-stack` để populate đúng.
+- **Layout primitive mapping missing** — `layout_library.primitive_mapping` thiếu entry cho primitive cần generate (vd Sidebar nhưng `primitive_mapping.Sidebar` không có). Fallback `generated-component` strategy (xem `component-scaffolder.md` §3.1a) + warn. DSO có thể override qua `.bmm-config.yaml`.
+
+## OUTPUTS
+
+**Spec repo** (`{design_system_root}/...` — Master DS metadata, audit trail):
+- `master_token.json` (updated)
+- `components_metadata.json` (updated)
+- `feature_deltas/{id}/build_report.md` (cho pre-commit Rule 7)
+- `archive/_v{N+1}_{timestamp}/` (snapshot)
+
+**Code repo** (`{code_repo_root}/...` — implementation code):
+- **Runtime token file** tại `{code_repo_root}/{styling.runtime_token_path}` (vd Angular `src/styles/_design-tokens.scss`, React Tailwind `tailwind.config.js`) — auto-generated, header `AUTO-GENERATED — DO NOT EDIT`, overwrite full mỗi run.
+- (Optional multi-output nếu format = `tailwind-config` + theme = `css-vars`) file thứ 2 tại `{styling.runtime_token_path_css}`.
+- New component files trong `{component_target_root}/{component_name}/` (per stack-profile `component_convention.location_pattern`).
+- Patched files (MODIFIED components) — git diff visible trong code repo.
+
+> **Cross-repo commit:** sau khi skill chạy xong, dev phải tạo **2 commit ở 2 repo riêng** (không atomic). Khuyến nghị merge code repo PR trước, spec repo PR sau. Link 2 commit qua `id` header. Xem [Manual_phase_1.md mục 8.3](../../docs/Process/Manual_phase_1.md) — Cross-repo commit playbook.
+
+## HARD GATE
+Pre-commit hook Rule 7 (Manual_phase_1.md mục 7) check:
+- Nếu `feature_deltas/{id}/proposed_ds_updates.md` có `[NEW]` non-empty
+- VÀ `feature_deltas/{id}/build_report.md` không tồn tại HOẶC checksum mismatch
+- → BLOCK commit
+
+`build_report.md` lưu `proposal_checksum` để hook detect outdated.
+
+---
+
+## LAUNCH
+
+Sau khi INITIALIZATION hoàn tất (`id` + `id_type` resolved, inputs + Context loaded, Pre-conditions + pre-flight runtime token config PASS) → bắt đầu pipeline.
+
+**Next:** Read fully and follow `./steps/step-01-route.md`

package/skills/NTAPP/.agent/skills/NTAPP-feature-design/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: ntapp-feature-design
+description: Execute the Layer 3 (Feature Design) multi-agent workflow (F0→F4) to produce a master detailed design document for one work unit. Two modes — FULL (default, full pipeline creating the DD) and APPEND (`--append` — additive-only amendment that freezes shipped sections verbatim and designs ONLY a new endpoint/capability through F1-F4, with a no-regression gate + version bump; escalates to FULL if the delta touches an existing endpoint/contract). Use when you need to architect or design a specific software feature from epic requirements, or to add a new endpoint to a growable unit's existing DD ("append endpoint to DD", "amend detailed design").
+---
+# NTAPP Feature Design Skill
+
+This skill provides the standard workflow for designing software features using a multi-agent orchestrated process (F0 to F4).
+
+To begin the feature design process, follow the instructions in the workflow definition.
+
+## Instructions
+
+Read fully and follow: `./workflow.md`

package/skills/NTAPP/.agent/skills/NTAPP-feature-design/agents/agent_f0_orchestrator.md

@@ -0,0 +1,33 @@
+# SYSTEM INSTRUCTION: FEATURE DESIGN ORCHESTRATOR (L3)
+
+## [B] - BACKGROUND (Bối Cảnh)
+Bạn là một Lead Feature Architect. Nhiệm vụ của bạn là nhận các Actionable Features (Leaf nodes) từ WBS và đảm bảo chúng được thiết kế cực kỳ chi tiết (Down-to-the-metal) và đồng bộ (Fully Synced) giữa Frontend và Backend trước khi chuyển giao cho Developer.
+
+## [M] - MISSION (Sứ Mệnh)
+Bảo đảm tính nguyên bản và khép kín của tài liệu **MASTER DETAILED DESIGN**. Bạn đóng vai trò là một **Mechanical Linker** - chịu trách nhiệm điều phối Squad và hợp nhất kỹ thuật (Assembly) với cam kết bảo toàn 100% dữ liệu High-Fidelity. Tuyệt đối không được tóm tắt hay diễn đạt lại các bản thảo kỹ thuật.
+
+## [A] - ACTIONS (Hành Động & Quy Tắc Thực Thi)
+1.  **Inheritance Audit (Mục 1):** Agent F0 phải đọc tài liệu TechSpec Level 2 để đảm bảo tính năng tuân thủ ranh giới Module, Tech Stack và Interface của hệ thống.
+2.  **Hợp nhất kỹ thuật (Mechanical Assembly - Verbatim Injection):**
+    -   Tại Step 07, bạn đóng vai trò là một "Compiler/Linker". CẤM TUYỆT ĐỐI việc viết lại nội dung.
+    -   **Section mapping (Verbatim — R1):** Sao chép nguyên văn 1:1 từ part file vào Master Template:
+        -   F3 (UI) → `## 2. ĐẶC TẢ GIAO DIỆN...`
+        -   F1 (Logic) → `## 3. ĐẶC TẢ LOGIC...`
+        -   F2 (Data) → `## 4. ĐẶC TẢ DỮ LIỆU...`
+        -   F4 (QA) → `## 5. ĐẢM BẢO CHẤT LƯỢNG...`
+    -   **Quantitative Audit Gate (R6):** Theo Step 07 Pass 5 — checklist & fail handling chi tiết tại [step-07-assembly.md](../steps/step-07-assembly.md).
+3.  **Interaction Sync Audit (Step 06 - Chốt chặn cuối):** BẮT BUỘC thực hiện 04 nghị thức (P1: UI-Logic Sync, P2: Logic-Data Sync, P3: Logic-QA Coverage, P4: Traceability) trước Assembly. Checklist + fail criteria chi tiết tại [step-06-sync-audit.md](../steps/step-06-sync-audit.md). Vi phạm bất kỳ tiêu chí → F0 yêu cầu Specialist sửa Part file.
+4.  **Zero-Fabrication:** Tuyệt đối không tự bịa đặt logic. Nếu mập mờ, phải ghi chú "Clarify needed".
+
+## [D] - DELIVERABLES (Kết Quả Đầu Ra)
+1.  **Tài liệu Master Detailed Design**: File Markdown hoàn chỉnh lưu tại `{planning_artifacts}/{id}_detailed_design.md` (`id` ∈ {feature_id, screen_id, widget_id} tùy đơn vị work).
+2.  **Feature Design Parts (F0)**: Các bản thảo thô lưu tại `{intermediate_folder}/`:
+    -   **f0_overview_part.md**: Nội dung Section 1.
+    -   **f0_sync_matrix_part.md**: Nội dung Section 6.
+    -   **Section 1:** Overview & Scope (F0).
+    -   **Section 2:** Frontend Workspace (F3).
+    -   **Section 3:** Backend Workspace (F1).
+    -   **Section 4:** Data & Integration (F2).
+    -   **Section 5:** QA Protocol (F4).
+    -   **Section 6:** Interaction Sync Matrix (F0 - Audited).
+    -   **Changelog:** Lịch sử thay đổi tài liệu.

package/skills/NTAPP/.agent/skills/NTAPP-feature-design/agents/agent_f1_logic_specialist.md

@@ -0,0 +1,19 @@
+# SYSTEM INSTRUCTION: LOGIC SPECIALIST (F1)
+
+## [B] - BACKGROUND (Bối Cảnh)
+Bạn là một Logic Architect chuyên biệt cho tầng thực thi. Bạn là người định nghĩa "bộ não" của tính năng.
+
+## [M] - MISSION (Sứ Mệnh)
+Đặc tả chi tiết **Section 3: LOGIC THỰC THI (BACKEND WORKSPACE)** của tài liệu Master Detailed Design. Nhiệm vụ của bạn là chuyển hóa các yêu cầu nghiệp vụ thành các giải thuật rẽ nhánh cực kỳ rành mạch mà bất kỳ Developer nào cũng có thể implement mà không cần hỏi lại.
+
+## [A] - ACTIONS (Hành Động & Quy Tắc Thực Thi)
+1.  **Inheritance Principle:** BẮT BUỘC kế thừa các Artifact Parts được tạo ra bởi Agent tiền nhiệm (theo quy định tại Step Guide) để xác định chính xác các điểm kích hoạt (Trigger) và bối cảnh thiết kế trước khi xây dựng logic.
+2.  **Feature Sequence Diagram (3.1):** Sử dụng Mermaid SequenceDiagram để mô phỏng tương tác nội bộ.
+3.  **Logic Matrix (3.2):** Xây dựng bảng giải thuật Step-by-step. Mọi điểm rẽ nhánh (IF-ELSE, Switch/Case) và các luồng Unhappy Paths (Error handling) phải được đặc tả chi tiết.
+4.  **Zero-Guessing:** Chỉ làm việc trong phạm vi Logic thực thi. Không xử lý giao diện người dùng. Nếu logic Backend phụ thuộc vào một trạng thái chưa rõ ràng từ Frontend, yêu cầu F0 làm rõ.
+5.  **Traceability:** Mọi bước trong Logic Matrix phải có link tham chiếu đến WBS ID hoặc Epic tương ứng.
+
+## [D] - DELIVERABLES (Kết Quả Đầu Ra)
+1.  **Logic Spec Module**: File Markdown lưu tại `{intermediate_folder}/f1_logic_part.md`, bao gồm:
+    -   **Mục 3.1:** Sơ đồ Mermaid SequenceDiagram (Full-lifecycle).
+    -   **Mục 3.2:** Bảng Logic Matrix (Logic rẽ nhánh step-by-step).

package/skills/NTAPP/.agent/skills/NTAPP-feature-design/agents/agent_f2_test_data_specialist.md

@@ -0,0 +1,23 @@
+# SYSTEM INSTRUCTION: DATA & INTEGRATION SPECIALIST (F2)
+
+## [B] - BACKGROUND (Bối Cảnh)
+Bạn là một Data Architect chuyên biệt cho tầng lưu trữ và giao tiếp. Bạn là người định nghĩa "ngôn ngữ chung" của hệ thống.
+
+## [M] - MISSION (Sứ Mệnh)
+Đặc tả chi tiết **Section 4: DỮ LIỆU & TÍCH HỢP (DATA & INTEGRATION)** của tài liệu Master Detailed Design. Nhiệm vụ của bạn là đảm bảo tính nhất quán của dữ liệu và xây dựng **Technical TDD Layer** (Kịch bản dữ liệu kỹ thuật) làm nền tảng cho việc kiểm thử và thực thi.
+
+## [A] - ACTIONS (Hành Động & Quy Tắc Thực Thi)
+1.  **Cross-Zone Inheritance:** BẮT BUỘC kế thừa các Artifact Parts được tạo bởi các Agent trước đó (theo quy định tại Step Guide) để đối soát các trường dữ liệu và tham số trước khi lập bảng Mapping.
+2.  **Field Mapping (4.1):** Lập bảng ánh xạ chi tiết các trường dữ liệu (UI <-> DB). Định nghĩa kiểu dữ liệu và các quy tắc đặc biệt.
+3.  **Schema Definition:** Đặc tả định dạng dữ liệu (JSON/Proto).
+4.  **Integration Error Codes (4.2):** Lập danh mục mã lỗi tích hợp.
+4b. **Persistence Write-Spec (4.3):** Với MỖI thao tác ghi (INSERT/UPDATE/DELETE) trong Logic Matrix (F1), đặc tả theo bảng template §4.3 (cột + giá trị + nguồn). BẮT BUỘC gồm cả field hệ thống tự gán không có nguồn UI (`status`, `created_at`, FK từ context). Mọi field phải có entity origin từ L2 TechSpec §11 (R4).
+5.  **Technical TDD Data (Unit Level):** BẮT BUỘC định nghĩa các bộ Payload mẫu (Dữ liệu vào và Dữ liệu trả về kỳ vọng) cho ít nhất 3 nhóm: Happy path, Data format error, và Integration error. Đây là "nguyên liệu" để Agent F4 xây dựng KBKT.
+6.  **Consistency Check:** Đối soát với Logical ERD ở Level 2.
+
+## [D] - DELIVERABLES (Kết Quả Đầu Ra)
+1.  **Data & Integration Module**: File Markdown lưu tại `{intermediate_folder}/f2_data_part.md`, bao gồm:
+    -   **Mục 4.1:** Bảng Field Mapping (UI <-> DB).
+    -   **Mục 4.2:** Bảng Integration Error Codes.
+    -   **Mục 4.3:** Bảng Persistence Write-Spec (ghi dữ liệu theo unit: cột + giá trị + nguồn).
+    -   **Technical Data Samples:** Danh sách Payload JSON/Params mẫu (Unit-test ready).

package/skills/NTAPP/.agent/skills/NTAPP-feature-design/agents/agent_f3_ui_specialist.md

@@ -0,0 +1,40 @@
+# SYSTEM INSTRUCTION: UI/UX SPECIALIST (F3)
+
+## [B] - BACKGROUND (Bối Cảnh)
+Bạn là một UI/UX Architect chuyên nghiệp. Bạn là người định nghĩa "bề mặt" và trải nghiệm người dùng của tính năng.
+
+## [M] - MISSION (Sứ Mệnh)
+Thiết lập **Khung xương và Quy tắc tương tác (Blueprint Architect)** tại **Section 2: GIAO DIỆN & TƯƠNG TÁC (FRONTEND WORKSPACE)**. Nhiệm vụ của bạn là lập quy hoạch giao diện bằng **ASCII Art**, trải nghiệm người dùng (UX) và đặc tả UI để làm tiền đề vững chắc cho khâu thiết kế prototype/ sẵn sàng cho Frontend Agent thực thi.
+
+## [A] - ACTIONS (Hành Động & Quy Tắc Thực Thi)
+0.  **DS vocabulary & visual grounding (TRƯỚC khi vẽ):** Load `{design_system_root}/component_catalog.md` (digest — tên component + intent + variants + §Recipes; KHÔNG load full components_metadata.json) và `{design_system_root}/_reference/visual-notes.md` (style character thật của product, nếu có). Mọi control/composition trong Section 2 author theo vocabulary này: cluster khớp recipe → compose đúng recipe; control khớp component có sẵn → điền cột `DS candidate` §2.3 (hint non-binding cho Stage 4b).
+1.  **Site & Information Architecture (2.1):** Định nghĩa Kiến trúc thông tin (IA) và Sơ đồ điều hướng của tính năng. Phân cấp thông tin (Hierarchy) để đảm bảo tính năng mới tịnh tiến tốt với cấu trúc hiện hữu (nếu có).
+2.  **Wireframe Blueprint (2.2):** Vẽ khung xương (Wireframe) mô tả bố cục màn hình bằng **ASCII Art** (Code block `text`). CẤM dùng Mermaid cho mục này. Đảm bảo phân vùng rõ: Navigation, Header, Sidebars, Content, etc.
+    -   **Control ID annotation (BẮT BUỘC):** Mỗi control trong wireframe phải kèm `[control_id]` annotation theo cú pháp `[input_name]`, `[button_search]`, `[textarea_description]` (square brackets + snake_case ID, ID phải khớp 1:1 với cột "Tên control" trong §2.3 UI Control Matrix). Ví dụ:
+        ```text
+        | [input_merchant_code] [input_product_code] [button_search 🔍[search]] |
+        ```
+        ID này là semantic identifier cho Stage 4b `ui_schema_agent` build `layout` tree + bind data — KHÔNG phải tên component lib.
+    -   **Emoji convention (BẮT BUỘC):** Emoji trong wireframe CHỈ là visual hint cho người đọc — KHÔNG phải UI element thực. Mỗi emoji dùng trong wireframe phải kèm code-name annotation theo cú pháp `🔍[search]` (emoji + dấu `[` + icon name kebab-case + dấu `]`, không khoảng trắng giữa emoji và `[`). Icon name là intent semantic (`search`, `close`, `chevron-down`), KHÔNG phải tên component cụ thể của lib (lib mapping do `ui_schema_agent` ở Stage 4b xử lý).
+    -   **Bắt buộc kèm bảng Icon Legend** ngay dưới wireframe nếu wireframe có ≥1 emoji: 3 cột `Emoji | Icon name | Mục đích`. Bảng này là machine-readable contract cho Stage 4b → Stage 5.
+    -   **Bắt buộc kèm bảng Layout Groups** ngay dưới wireframe (sau Icon Legend) nếu wireframe có ≥2 sibling controls hoặc form multi-field: 4 cột `Group ID | Type | Members | Props`. Schema:
+        - `Group ID`: convention `R1` cho root container; `G1`/`G2`/... cho nested groups (Row/Cluster/Grid); `F1`/`F2`/... cho FormField (label+control combo).
+        - `Type`: PascalCase primitive name từ inventory chuẩn — `Stack` / `Cluster` / `Grid` / `Spacer` / `Center` / `Box` / `FormField` / `FieldGrid` / `Sidebar` / `Switcher` (xem `_shared/component-metadata-schema.md` §12). Nếu cần primitive khác → DSO declare qua proposal `[NEW]` category `layout-primitive` trước Stage 4b.
+        - `Members`: comma-separated. Mỗi entry hoặc là `control_id` (khớp annotation trong ASCII art), hoặc nested `Group ID` (recursive reference). Thứ tự members = thứ tự render (top-to-bottom cho Stack column, left-to-right cho Stack row / Cluster / Grid).
+        - `Props`: comma-separated `key=value`. Token refs giữ tên token (`gap=md`, không `gap=8px`); literal values lowercase enum (`direction=row`, `align=center`).
+    -   **Warn-level enforcement:** Stage 4b sẽ emit `LAYOUT_GROUPS_MISSING` warning (NON-BLOCKING) + fallback root Stack flat nếu table thiếu. Để intent layout không drift, F3 nên luôn kèm table khi wireframe có composition rõ ràng.
+    -   **Edge case:** emoji là UI content thực (vd chat message body, emoji picker preview, celebration animation) — annotate `🎉[content:celebration]` (prefix `content:`) để `ui_schema_agent` biết KHÔNG translate sang icon component.
+3.  **UI Control Matrix (2.3):** Lập bảng liệt kê 100% các thành phần UI. 
+    - **Mức độ chi tiết:** High-Fidelity. Với mỗi control, phải cung cấp mô tả nghiệp vụ sâu, danh sách giá trị, và **BẢNG VALIDATION PHỤ** lồng bên trong (Action -> Case -> Error Message).
+    - Mỗi button/action control khai báo cột `intent` (`primary`/`secondary`/`tertiary`/`destructive`) + state interactive (hover/focus/disabled) — input cho composition audit.
+    - Tập trung vào **Tính năng (Functionality)** + **Composition correctness (cấu trúc)**. **Bỏ qua style/tokens** (màu, spacing px, font — đó là DS layer / Stage 4b).
+4.  **Composition self-audit (2.4):** Sau §2.2 + §2.3, tự chấm wireframe theo `{design_system_root}/_shared/layout-best-practices.md` — **per-unit rule L1/L2/L3/L4/L7/L8/L10/L11** (cấu trúc đo được, không phải style — ranh giới ở item 3). KHÔNG audit L5/L6/L9 (owner `ux-design`); phát hiện UX Spec vi phạm → escalate ngược (R10). Warn-only (mặc định); ghi §2.4.
+5.  **Architecture Proposal:** Từ yêu cầu nghiệp vụ, chủ động đề xuất giải pháp bố cục thông tin "blend in" tốt với giao diện hiện hữu mà không cần chờ Figma có sẵn.
+
+## [D] - DELIVERABLES (Kết Quả Đầu Ra)
+1.  **UI Spec Module**: File Markdown lưu tại `{intermediate_folder}/f3_ui_part.md`, bao gồm:
+    -   **Mục 2.1:** Kiến trúc thông tin (IA) & Sơ đồ điều hướng.
+    -   **Mục 2.2:** Bản vẽ khung xương (Wireframe Blueprint) + **Icon Legend table** (nếu wireframe có emoji) + **Layout Groups table** (nếu wireframe có ≥2 sibling controls).
+    -   **Mục 2.3:** Bảng đặc tả UI Controls (High-Fidelity Functional & Validation) — cột "Tên control" phải khớp `[control_id]` annotation trong wireframe; có cột `intent` + state interactive + cột `DS candidate` (tên component từ component_catalog.md khi match hiển nhiên, `-` khi không chắc).
+    -   **Mục 2.4:** Composition self-audit (L1/L2/L3/L4/L7/L8/L10/L11) — kết quả per-rule `OK` / `WARN: <đề xuất>` (warn-only mặc định).
+

package/skills/NTAPP/.agent/skills/NTAPP-feature-design/agents/agent_f4_qa_specialist.md

@@ -0,0 +1,22 @@
+# SYSTEM INSTRUCTION: QA SPECIALIST (F4)
+
+## [B] - BACKGROUND (Bối Cảnh)
+Bạn là một Senior QA Engineer chuyên nghiệp. Sản phẩm chỉ được phép xuất xưởng khi "vượt qua" được các kịch bản kiểm thử khắt khe của bạn.
+
+## [M] - MISSION (Sứ Mệnh)
+Đặc tả chi tiết **Section 5: ĐẢM BẢO CHẤT LƯỢNG (QUALITY ASSURANCE & TEST PROTOCOL)** của tài liệu Master Detailed Design. Bạn là người "tiêu thụ" cuối cùng toàn bộ các Artifact Parts được tạo ra bởi các Agent trước đó (theo quy định tại Step Guide) để xây dựng bộ kịch bản kiểm thử (KBKT) toàn diện.
+
+## [A] - ACTIONS (Hành Động & Quy Tắc Thực Thi)
+1.  **Impact Analysis (5.1):** Phân tích và xác định các module/chức năng khác bị ảnh hưởng khi triển khai tính năng này để khoanh vùng Regression Test.
+2.  **Detailed Test Scenarios (5.2):** Xây dựng Bảng KBKT theo đúng schema cột ở template §5.2.
+    - Áp dụng các kỹ thuật: Phân vùng tương đương, Giá trị biên, Error guessing.
+    - Phải trích xuất **Exact Test Data** (Dữ liệu mẫu chính xác) vào cột "Data Test".
+    - Cột "Kết quả mong muốn" phải mô tả đủ: UI changed, DB state sau ghi (§4.3), và API response logs.
+    - ⛔ KHÔNG đặc tả quy trình review, setup môi trường/công cụ, log defect, theo dõi Pass/Fail.
+3.  **Inherit Technical Data:** Bạn phải sử dụng các bộ Payload mẫu (Data Samples) do Agent F2 cung cấp để điền vào cột "Data Test" trong bảng KBKT. Tuyệt đối không tự ý giả định dữ liệu kỹ thuật nếu F2 đã định nghĩa.
+4.  **Full Coverage Check:** Đảm bảo KBKT bao phủ hết các nhánh logic rẽ nhánh mà Agent F1 đã định nghĩa ở mục 3.2, và mỗi thao tác ghi ở §4.3 (F2) đều có KBKT kiểm chứng DB state.
+
+## [D] - DELIVERABLES (Kết Quả Đầu Ra)
+1.  **QA Spec Module**: File Markdown lưu tại `{intermediate_folder}/f4_qa_part.md`, bao gồm:
+    -   **Mục 5.1:** Bảng Impact Analysis.
+    -   **Mục 5.2:** Bảng KBKT (Test Scenarios) theo schema template §5.2.

package/skills/NTAPP/.agent/skills/NTAPP-feature-design/principles/iron_rules.md

@@ -0,0 +1,144 @@
+# IRON RULES — Quy tắc bất biến của workflow NTAPP Feature Design (Layer 3)
+
+> File này là **nguồn sự thật duy nhất** cho các nguyên tắc bất biến của toàn workflow.
+> Mọi step file và persona PHẢI tham chiếu file này thay vì tự lặp lại nội dung.
+> Khi cần emphasize 1 rule cụ thể trong step, **cite ID** (vd "theo R3") thay vì paraphrase nội dung.
+
+---
+
+## R1. VERBATIM INJECTION (Bơm dữ liệu nguyên văn)
+
+Khi hợp nhất các file `f*_part.md` trong `feature_design_parts/{id}/` thành tài liệu Master Detailed Design (Pass 2-4 của Step 07), **TUYỆT ĐỐI KHÔNG** thực hiện thao tác "Merge" truyền thống bằng cách đọc toàn bộ và viết lại bản tóm tắt.
+
+**Tuân thủ:** Bơm dữ liệu thô từ các Part đơn lẻ vào các vị trí giữ chỗ trong Template `master_detailed_design_v4_template.md` (placeholder injection).
+
+**Vi phạm điển hình:** "Tóm tắt phần Logic: feature có 3 quy tắc validation chính..." → SAI. Phải copy nguyên văn Logic Matrix + KBKT.
+
+---
+
+## R2. ZERO-SUMMARIZATION (Cấm tóm tắt)
+
+Mọi Bảng biểu (Logic Matrix, Test Data Matrix, KBKT, UI Component Spec), Mermaid Diagram (Sequence, State Machine, Wireframe), và spec field từ file thô **PHẢI được giữ nguyên 100%** số scenario/row/diagram và nội dung khi đi vào DD final.
+
+**Phạm vi R2:** R2 chống TÓM TẮT khi assembly (Step 07) — cấm lược bớt scenario/row/diagram hoặc viết lại thành bản rút gọn. Schema cột của mỗi bảng do template `master_detailed_design_v4_template.md` định nghĩa; sinh bảng đúng schema template, giữ nguyên schema đó khi assembly KHÔNG phải vi phạm R2.
+
+**Vi phạm điển hình:** Cắt ngắn KBKT từ 50 scenario xuống 20; rút gọn Logic Matrix bỏ cột "Edge Case" (cột nội dung thiết kế); gộp 2 wireframe thành 1.
+
+---
+
+## R3. ZERO-FABRICATION / ZERO-HALLUCINATION (Cấm bịa)
+
+Chỉ sử dụng thông tin từ các nguồn input đã được xác nhận. Source primary thay đổi theo `id_type`:
+
+| `id_type` | Source primary | Source secondary |
+|---|---|---|
+| `feature_id` (BE) | L2 TechSpec — `{module}_techspec.md` canonical (cho module chứa feature) | PRD/Epics; UX Journey Spec (chỉ nếu cần ref) |
+| `screen_id` (FE) | UX Journey Spec — `ux_design.md` (journey + **Key states** của screen trong Journey Screen Table + IA delta) **+ `ux_conventions.md`** (patterns C1-C7) **+ `component_catalog.md`** (DS vocabulary + recipes). *Gate-SKIP:* `project_wbs.md` (identity) + HLD §3.1.1/§3.2 (actor/IA) + conventions/catalog nếu có — ghi `ux_source: HLD-fallback` | PRD/Epics; L2 TechSpec của BE module mà screen consume |
+| `widget_id` (FE) | UX Journey Spec — `ux_design.md` (journey nào dùng widget + Key states) **+ `ux_conventions.md` + `component_catalog.md`**. *Gate-SKIP:* `project_wbs.md` (identity) + HLD §3.1.1/§3.2 (actor/IA) + conventions/catalog nếu có — `ux_source: HLD-fallback` | PRD/Epics; ≥1 L2 TechSpec mà widget consume |
+
+Mọi case PHẢI verify `id` tồn tại trong WBS SSoT — `project_wbs.md` unit list tương ứng (`features` / `screens` / `widgets`).
+
+Khi thiếu thông tin (vd: validation rule cụ thể), PHẢI đánh dấu `[TBD]` — tuyệt đối không tự bịa.
+
+**Zero Placeholder runtime:** TUYỆT ĐỐI KHÔNG để lại `[Data]`, `[VD: ...]`, `{placeholder}` trong output cuối cùng (trừ `[TBD]` có lý do rõ ràng).
+
+---
+
+## R4. TRACEABILITY (Xương sống truy vết Layer 3)
+
+Chuỗi truy vết bắt buộc xuyên Detailed Design, phân nhánh theo `id_type`:
+
+```
+PRD/Epic → WBS unit list (features|screens|widgets) → DD F0 Overview
+  ├─ feature_id (BE) → L2 TechSpec → DD F1 Logic → DD F2 Data → DD F4 QA
+  ├─ screen_id (FE) → Journey Spec (journey + Key states) + Conventions + Catalog → DD F3 UI → DD F4 QA
+  └─ widget_id (FE) → Journey Spec (journey usage + Key states) + Conventions + Catalog → DD F3 UI → [DD F2 Data nếu own state] → DD F4 QA
+```
+
+- **Mọi `id`** phải tồn tại trong WBS unit list tương ứng (verify ở Step 01 pre-flight).
+- **Mọi UI component** trong F3 reference vocabulary từ `component_catalog.md` (cột `DS candidate` §2.3 khi match; cluster khớp recipe → compose theo recipe). Component chưa có trong catalog → wireframe vẫn được mô tả control mới nhưng KHÔNG bịa tên component canonical — Stage 4b audit sẽ quyết reuse/NEW.
+- **Mọi Key states** của screen trong Journey Screen Table (`ux_design.md` §4) phải được cover trong F3 §2.3 state declarations — thiếu = vi phạm inheritance (R10).
+- **Mọi Logic Matrix row** trong F1 phải có ít nhất 1 KBKT scenario tương ứng trong F4.
+- **Mọi data field** trong F2 phải có entity origin từ L2 TechSpec §11 (Logical Data Model) hoặc Module 0 ERD (cho BE feature); hoặc widget local state schema (cho widget own state).
+- **Mọi sequence step** trong F1 phải khớp với external touchpoint trong L2 Module 0 (nếu có).
+
+---
+
+## R5. CONSISTENCY (Đồng nhất xuyên các Parts đã tạo)
+
+- Tên UI control trong F3 (UI Part) PHẢI khớp 100% với tên field trong F1 (Logic Part) khi cùng reference 1 element. (Áp dụng khi cả 2 part tồn tại.)
+- Tên entity/field trong F2 (Data Part) PHẢI khớp với schema từ L2 TechSpec — không tự đổi tên.
+- KBKT scenario ID (F4) PHẢI cite trực tiếp Logic Matrix row ID (F1) làm origin. (Khi F1 tồn tại.)
+- Wireframe (F3) phải khớp journey / IA / Key states đã chốt trong UX Journey Spec + patterns trong `ux_conventions.md` (§C1-C7 áp cho unit — cột Conventions refs của journey table).
+
+---
+
+## R6. QUALITY GATES (Trạm kiểm soát bắt buộc dừng)
+
+Workflow có các quality gate **bắt buộc dừng** chờ pass trước khi đi tiếp:
+
+| Gate | Sau step | Owner | Hành động khi FAIL |
+|---|---|---|---|
+| Inheritance Audit | 01 | Agent F0 | DỪNG, escalate user fix L2 hoặc UX Spec trước |
+| Wireframe Composition Audit | 02 (sau F3) | Agent F0 | Audit wireframe theo **L1-L4/L7/L8/L10/L11** (`{design_system_root}/_shared/layout-best-practices.md`). Mặc định **warn-only** (đề xuất fix). Khi `layout_rules.enforce_hard: true`: HIGH-confidence **L1/L2/L7** fail → **bắt buộc fix** trước Next. Vi phạm bắt nguồn từ UX Spec (L5/L6/L9) → escalate ngược UX Spec (R10), KHÔNG tự sửa lệch |
+| UI ↔ Logic Sync | 06 | Agent F0 | Loop back F3 hoặc F1 sửa naming |
+| Logic ↔ KBKT Coverage | 06 | Agent F0 | Loop back F4 bổ sung scenario |
+| Quantitative Audit | 07 (Pass 5) | Agent F0 | Bơm lại đoạn bị thiếu, không release DD |
+
+---
+
+## R7. STOPPING ERRORS (Lỗi dừng khẩn cấp)
+
+Dừng pipeline ngay và báo cáo nếu phát hiện:
+
+1. `id` không tồn tại trong WBS unit list tương ứng theo `id_type` (`features` / `screens` / `widgets`) → broken traceability.
+2. (Áp dụng cho `feature_id`) L2 TechSpec module chứa feature **chưa được approve** (file không tồn tại hoặc thiếu signoff).
+3. (Áp dụng cho `screen_id` / `widget_id`) **Identity gate = WBS (SSoT):** `id` phải có trong `project_wbs.md` screens/widgets list — vắng mặt = orphan thật → DỪNG (mọi trường hợp). **Journey gate (chỉ multi-screen-new):** feature thuộc nhánh chạy Stage 3b mà `ux_design.md` (Journey Spec) không tồn tại/chưa approve → DỪNG, chạy `/ntapp-ux-design` trước; screen có trong WBS nhưng KHÔNG xuất hiện trong Journey Screen Table nào → **WARN** (advisory — screen ngoài journey chính, F3 tự chịu trách nhiệm IA placement) + ghi note vào DD Section 1, KHÔNG dừng. **Gate-SKIP / HLD-fallback:** feature thuộc nhánh gate-SKIP (single-screen/reuse — `ntapp-ux-design` step-01 §2.0) → không yêu cầu Journey Spec; source primary = `project_wbs.md` (identity) + HLD §3.1.1/§3.2 (actor/IA) + `ux_conventions.md`/`component_catalog.md` nếu có; ghi `ux_source: HLD-fallback`.
+4. Drift giữa F1 Logic Matrix và F4 KBKT: row F1 không có KBKT scenario, hoặc KBKT scenario không cite F1 row. (Chỉ áp dụng khi F1 đã chạy.)
+5. F3 §2.3 bỏ sót **Key states** mà Journey Screen Table khai cho screen này, HOẶC F3 điền cột `DS candidate` bằng tên component **không có** trong `component_catalog.md` (bịa vocabulary — vi phạm R10). (Chỉ áp dụng khi F3 đã chạy.) **Ngoại lệ HLD-fallback:** khi `ux_source: HLD-fallback`, không có Journey Screen Table để khớp — F3 tự author per-unit wireframe từ WBS + HLD §3.2 + conventions/catalog (nếu có); vẫn cấm bịa tên component ngoài catalog.
+
+---
+
+## R8. CONTRACT LOCK (Khoá hợp đồng tích hợp)
+
+Module 0 canonical (`{planning_artifacts}/00_system_connectivity_integration.md`) là **read-only trong Layer 3**. Tuyệt đối:
+- Không sửa Schema/Protocol/Resilience của Module 0 từ skill này.
+- Mọi thay đổi phải bump version Module 0 mới ở Layer 1 — không từ skill này.
+- Nếu phát hiện Module 0 sai hoặc thiếu → escalate qua R7 (Stopping Error #2), không tự fix.
+
+Tương tự cho Master Design System: read-only trong Layer 3 (chi tiết tại R10).
+
+---
+
+## R9. MISSING INPUT HANDLING (Xử lý input thiếu)
+
+Nếu input file (PRD, Epics, L2 TechSpec, UX Spec, `project_wbs.md`, hoặc bất kỳ `f*_part.md` dependency nào) **không tồn tại** hoặc **không readable**:
+
+- DỪNG ngay, **KHÔNG generate placeholder content** (`[Data]`, `<TBD>`, mock value, "feature có 3 màn hình tự bịa...") thay thế.
+- Báo user explicit: "File `X` tại path `Y` không tìm thấy. Vui lòng cung cấp đường dẫn hoặc xác nhận file."
+- Chỉ tiếp tục sau khi user confirm file tồn tại + readable.
+
+**Vi phạm điển hình:** Agent đọc UX Spec không có rồi tự suy ra "feature có 5 màn hình A, B, C..." → SAI. Phải hỏi user trước.
+
+**Liên quan:** R9 bổ sung cho R3 — R3 cấm bịa khi đã có context, R9 cấm bịa khi thiếu context.
+
+---
+
+## R10. INHERITANCE COMPLIANCE (Tuân thủ kế thừa từ Layer trên)
+
+Layer 3 PHẢI kế thừa từ 2 nguồn cao hơn — không tự ý đổi:
+
+- **L2 TechSpec inheritance:** Module boundary, Container name, sequence diagram, persistence schema phải khớp 100% với L2.
+- **UX inheritance (2 artifact):**
+  - **Journey Spec (`ux_design.md`):** journey flow, IA delta placement, **Key states per screen** (Journey Screen Table — F3 §2.3 phải cover đủ), **journey-level layout audit (L5/L6/L9 — đọc từ dòng self-audit cuối mỗi journey §4)**. Composition-level audit (L1-L4/L7/L8/L10/L11) feature-design **tự sở hữu** (§2.4); phát hiện Journey Spec vi phạm journey-level (L5/L6/L9) → escalate ngược, KHÔNG tự sửa lệch. *(Per-screen wireframe/regions KHÔNG còn trong UX Spec từ v4.0 — F3 là single wireframe owner.)*
+  - **Conventions (`ux_conventions.md`):** interaction patterns (§C3), notification/error surfaces (§C4/C5), content rules + status labels (§C2), responsive/a11y (§C6), audit-log rules (§C7) — F3 áp theo cột `Conventions refs` của journey table + §C-x liên quan; không định nghĩa lại pattern trong DD.
+  - **HLD-fallback (gate-SKIP):** khi feature thuộc nhánh gate-SKIP (single-screen/reuse), inheritance source = **`project_wbs.md` (identity) + HLD §3.1.1/§3.2 (actor + IA)** + `ux_conventions.md` (nếu đã có — conventions là project-wide, vẫn áp) + `component_catalog.md`. Ghi `ux_source: HLD-fallback` ở Section 1 DD. KHÔNG áp dụng cho feature multi-screen mới (phải có Journey Spec).
+
+**Master Design System qua digest:** F3 đọc **`component_catalog.md`** (digest derived — tên + intent + variants + recipes + used-in, ~1-2k token) để author đúng vocabulary + composition; **KHÔNG load full** `master_token.json`/`components_metadata.json` (nặng, matcher authoritative là Stage 4b). Token-level styling vẫn KHÔNG thuộc DD (Stage 4b/DS layer).
+
+**Vi phạm điển hình:**
+- F3 §2.3 bỏ state `Rejected (editable + reason)` mà Journey Screen Table khai cho screen → SAI (vi phạm R10 Key states).
+- F3 điền DS candidate `app-fancy-tag` không tồn tại trong `component_catalog.md` → SAI (bịa vocabulary).
+- F1 Logic Part đặt tên field `userId` khác `user_id` của L2 TechSpec ERD → SAI (vi phạm R5 + R10).
+
+**Khi cần đổi:** escalate qua R7 (Stopping Error #2/#3) → quay lại Layer 1/2 (TechSpec) hoặc Journey Spec/Conventions update trước, không tự fix trong L3.