@laitszkin/apollo-toolkit 4.1.0 → 4.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,40 +1,40 @@
1
- # apltk architecture — 宣告式架構圖 CLI
1
+ # apltk architecture — Declarative Architecture Diagram CLI
2
2
 
3
- ## 用途
4
- 透過 YAML 狀態檔案管理 `resources/project-architecture/` 下的架構圖,支援基礎架構圖與 spec 覆蓋層的差異比對與合併。
3
+ ## Purpose
4
+ Manage architecture diagrams under `resources/project-architecture/` via YAML state files. Supports base atlas and spec overlay diff/merge comparison.
5
5
 
6
- ## 用法
6
+ ## Usage
7
7
  ```
8
8
  apltk architecture [verb] [options]
9
9
  ```
10
10
 
11
- ## 全局旗標
12
- | 旗標 | 效果 |
13
- |------|------|
14
- | `--project <root>` | 指定專案根目錄(預設從 cwd 向上搜尋) |
15
- | `--spec <spec_dir>` | 寫入 spec overlay 而非基礎架構圖 |
16
- | `--no-render` | 變更後略過自動重新渲染,可批次多條指令 |
17
- | `--no-open` | `open` `diff` 時不開啟瀏覽器 |
18
- | `--dry-run` | 預覽變更為 JSON diff,不實際寫入 |
19
- | `--out <dir>` | `diff` 的輸出目錄 |
20
- | `--clean` | `merge` 成功後移除 spec overlay 目錄 |
21
- | `--all` | `merge` 時選取所有 pending spec overlay |
22
- | `--json` | `status` 時輸出 JSON |
23
- | `--evidence <level[:source]>` | 為組件標記 observed/inferred/assumed 品質等級 |
24
-
25
- ## 頂層動詞
26
- - **`open`** — 開啟基礎架構圖 HTML,若未渲染則先 bootstrap
27
- - **`diff`** — 收集 `docs/plans/` 下所有 overlay,產生 before/after 檢視器
28
- - **`render`** — 從當前 YAML 狀態重新產生 HTML
29
- - **`validate`** — 驗證架構圖結構完整性(schema + referential integrity
30
- - **`status`** — 顯示摘要(feature/submodule/edge/actor 數量、時間戳、驗證狀態)
31
- - **`scan --src <dir>`** — 掃描目錄結構,輸出 JSON 候選 feature 列表
32
- - **`undo [--steps <n>]`** — 還原最近一次 mutation
33
- - **`merge --spec <dir> | --all`** — spec overlay 合併回基礎架構圖
34
-
35
- ## Mutation 系列
36
-
37
- 所有 mutation 共用 `--project`、`--spec`、`--no-render`、`--dry-run`、`--evidence` 旗標。
11
+ ## Global Flags
12
+ | Flag | Effect |
13
+ |------|--------|
14
+ | `--project <root>` | Specify project root (defaults to upward search from cwd) |
15
+ | `--spec <spec_dir>` | Write to spec overlay instead of base atlas |
16
+ | `--no-render` | Skip auto-render after mutations for batch operations |
17
+ | `--no-open` | Skip browser launch for `open` and `diff` |
18
+ | `--dry-run` | Preview changes as JSON diff without writing |
19
+ | `--out <dir>` | Output directory for `diff` |
20
+ | `--clean` | Remove spec overlay directory after successful `merge` |
21
+ | `--all` | Select all pending spec overlays for `merge` |
22
+ | `--json` | JSON output for `status` |
23
+ | `--evidence <level[:source]>` | Mark component quality tier (observed/inferred/assumed); source supports auto-parsed `file:line` (e.g. `observed:src/foo.ts:42`) |
24
+
25
+ ## Top-Level Verbs
26
+ - **`open`** — Open base atlas HTML in browser; bootstrap if not rendered
27
+ - **`diff`** — Collect all overlays under `docs/plans/`, generate before/after viewer
28
+ - **`render`** — Regenerate HTML from current YAML state
29
+ - **`validate`** — Validate atlas structural integrity (schema + referential integrity)
30
+ - **`status`** — Show summary (feature/submodule/edge/actor counts, timestamp, validation status)
31
+ - **`scan --src <dir>`** — Scan directory structure, output JSON candidate feature list
32
+ - **`undo [--steps <n>]`** — Revert the most recent mutation(s)
33
+ - **`merge --spec <dir> | --all`** — Merge spec overlay(s) into base atlas
34
+
35
+ ## Mutation Series
36
+
37
+ All mutations share `--project`, `--spec`, `--no-render`, `--dry-run`, `--evidence` flags.
38
38
 
39
39
  ### feature
40
40
  ```
@@ -92,7 +92,7 @@ apltk architecture actor add --id <actor-id> [--label "..."]
92
92
  apltk architecture actor remove --id <actor-id>
93
93
  ```
94
94
 
95
- ## 注意事項
96
- - 執行 mutation 後自動重新渲染(除非 `--no-render`)
97
- - 每個 mutation 建立 undo snapshot,可行 `undo` 還原
98
- - 驗證通過後才算架構圖工作完成
95
+ ## Notes
96
+ - Auto-render after every mutation (unless `--no-render`)
97
+ - Each mutation creates an undo snapshot — revert with `undo`
98
+ - Atlas work is not complete until validation passes
@@ -1,25 +1,20 @@
1
- ## 功能模塊
1
+ ## Feature
2
2
 
3
- 功能模塊是直接面向用戶的功能,如:
4
- - 登陸功能
5
- - 註冊功能
6
- - 邀請碼功能
3
+ A feature is a user-facing capability, such as:
4
+ - Login
5
+ - Registration
6
+ - Invite code management
7
7
 
8
- 功能模塊由子模塊的合作、交互實現
8
+ Features are realized through collaboration and interaction of their submodules.
9
9
 
10
- 功能模塊對應 C4 model **Container** 層級:高階功能邊界,可獨立部署或辨識的系統能力單元。
10
+ A feature maps to the C4 model's **Container** level: a high-level functional boundary, deployable or identifiable as a distinct system capability unit.
11
11
 
12
- ## 子模塊
12
+ ## Submodule
13
13
 
14
- 子模塊是功能模塊的關鍵組成部分。具體定義依照代碼的實作邊界得出。
14
+ A submodule is a key building block of a feature. Its exact definition follows the implementation boundaries in the code.
15
15
 
16
- 子模塊對應 C4 model **Component** 層級:功能內部的實作單元(如 controllerservicerepository)。
16
+ A submodule maps to the C4 model's **Component** level: an implementation unit inside a feature (e.g., controller, service, repository).
17
17
 
18
- ## C4 模型層級對照
18
+ ## C4 Level Mapping
19
19
 
20
- | C4 層級 | 對應概念 | 用途 |
21
- |---------|---------|------|
22
- | System Context | 整體系統 + 外部 actor | 定義系統邊界與外部依賴 |
23
- | Container | 功能模塊(feature) | 高階功能邊界 |
24
- | Component | 子模塊(submodule) | 功能內部的實作單元 |
25
- | Code | function 行 | 函式層級細節(選擇性) |
20
+ Refer to the C4 mapping table in `SKILL.md` it is not duplicated here.
@@ -1,42 +1,31 @@
1
1
  # update-project-html
2
2
 
3
- `update-project-html` refreshes the project HTML architecture atlas (`resources/project-architecture/`) so it reflects the latest code changes.
4
-
5
- ## What this skill does
6
-
7
- 1. Reads the current atlas (`atlas.index.yaml` + per-feature YAML) — only affected features (context economy).
8
- 2. Measures architecture drift: compares atlas entries against actual codebase structure.
9
- 3. Resolves the diff scope (`git diff --stat` + `git diff --cached --stat` by default, or `git diff --stat <base>..HEAD` when the user names a ref).
10
- 4. Filters out non-architecture changes (formatting, config-only, test-only, comments).
11
- 5. Maps filtered diff hunks to existing or new features.
12
- 6. Dispatches one write-capable subagent per affected feature to deep-read only its own changed files and apply every intra-feature mutation through `apltk architecture` (no `--spec`).
13
- 7. Waits until every subagent finishes, then declares cross-feature edges, runs `apltk architecture render`, and validates.
14
- 8. Re-measures drift to confirm it is within acceptable range.
3
+ Refreshes the project HTML architecture atlas (`resources/project-architecture/`) to reflect the latest code changes.
15
4
 
16
5
  ## When to use
17
6
 
18
- Use this skill when the task asks you to:
19
-
20
- - update or refresh the existing project architecture diagram after code changes,
21
- - bring `resources/project-architecture/` back in sync with the current branch or a specific commit range,
22
- - reflect a recent PR or batch of commits in the canonical atlas before merging or releasing.
7
+ - The existing atlas is out of sync with the current branch or working tree
8
+ - Code has changed (new routes, modules, service logic) and the atlas needs updating before a release
9
+ - You need to bring `resources/project-architecture/` back in sync after a PR or batch of commits
23
10
 
24
- If no atlas exists yet, use `init-project-html` to bootstrap one. For planned but unshipped work scoped to a `docs/plans/...` spec, use `spec-to-project-html` to write under `<spec_dir>/architecture_diff/` instead of the base atlas.
11
+ If no atlas exists yet, use [`init-project-html`](../init-project-html/SKILL.md) to bootstrap one first.
25
12
 
26
13
  ## Core principles
27
14
 
28
- - The CLI owns atlas state and renderer output; agents never hand-edit `resources/project-architecture/**/*.html`.
29
- - Every mutation traces to a specific file + diff hunk; absent code never produces atlas entries.
30
- - Subagent fan-out is the only safe read pattern: one feature per subagent, no shared source loading.
31
- - Cross-feature wiring happens **after** every subagent finishes never from partial summaries.
32
- - Measure drift before and after: confirm the atlas stays within an acceptable drift threshold.
33
- - Filter diff noise: formatting, config-only, test-only, and comment-only changes never drive atlas mutations.
15
+ - The CLI owns atlas state and rendered output; never hand-edit `resources/project-architecture/**/*.html`
16
+ - Every mutation traces to a specific file + diff hunk; absent code never produces atlas entries
17
+ - Measure drift **before and after**: confirm the atlas stays within acceptable thresholds
18
+ - Filter diff noise: formatting, config-only, test-only, and comment-only changes never drive atlas mutations
19
+
20
+ ## Workflow
21
+
22
+ See [`SKILL.md`](./SKILL.md) for the full 6-step workflow.
34
23
 
35
24
  ## References
36
25
 
37
- - [`SKILL.md`](./SKILL.md) — full workflow and execution rules.
38
- - [`../init-project-html/SKILL.md`](../init-project-html/SKILL.md) — semantic rulebook.
39
- - [`../spec-to-project-html/SKILL.md`](../spec-to-project-html/SKILL.md) — spec overlay flow.
26
+ - [`SKILL.md`](./SKILL.md) — Full workflow and execution rules
27
+ - [`../init-project-html/SKILL.md`](../init-project-html/SKILL.md) — C4 semantic rulebook
28
+ - [`../init-project-html/references/TEMPLATE_SPEC.md`](../init-project-html/references/TEMPLATE_SPEC.md) — Atlas field reference and schema
40
29
 
41
30
  ## License
42
31
 
@@ -1,70 +1,83 @@
1
1
  ---
2
2
  name: update-project-html
3
- description: 當項目架構圖與實際程式碼脫節時,增量刷新架構圖資源。包括基礎 atlas 與渲染 HTML。更新前先測量 drift 程度決定更新範圍。
3
+ description: Incrementally refresh the architecture atlas when the project diagram drifts from actual code. Measures drift before updating to determine scope, then updates the base atlas and re-renders HTML.
4
4
  ---
5
5
 
6
- ## 目標
6
+ ## Goal
7
7
 
8
- 根據目前分支、工作區或指定提交範圍內的程式碼變更,增量刷新基礎 atlas 與渲染 HTML
9
- 使架構圖持續和實際程式碼保持一致。
8
+ Incrementally refresh the base atlas and rendered HTML based on code changes in the current branch, working tree, or a specified commit range.
9
+ Keep the architecture diagram continuously aligned with the actual codebase.
10
10
 
11
- ## 驗收條件
11
+ ## Acceptance Criteria
12
12
 
13
- - 所有子模塊之間的 edge 的定義被更新到貼合最新代碼實踐
14
- - 所有子模塊內部的 edge 的定義被更新到貼合最新代碼實踐
15
- - 架構圖完整展示整個系統之中子模塊之間的關係以及功能模塊之間的關係
16
- - 已測量架構圖與程式碼的 drift 程度,確認更新範圍合理
17
- - diff 中不影響架構的變更(formatting、config-only、test-only)已被過濾
13
+ - Architecture drift has been measured before and after the update; the update scope is justified
14
+ - All cross-module and intra-module edges reflect the latest code
15
+ - Every declared component is backed by source code evidence (`evidence.sourceFile:sourceLine`); unresolved ones are tagged `inferred`
16
+ - Non-architectural changes (formatting, config-only, test-only) have been filtered from the diff
18
17
 
19
- ## 工作流程
18
+ ## Workflow
20
19
 
21
- ### 1. 查看現有架構圖
20
+ ### 1. Review the current atlas
22
21
 
23
- 閱讀現有架構圖。
24
- 整理功能模塊之間、子模塊之間的關係等重要資訊。
22
+ Read the existing architecture diagram.
23
+ Capture the relationship between features and submodules.
25
24
 
26
- > 只讀取 `atlas.index.yaml` + 受影響 feature YAML 檔案。不讀取無關的 feature 或未變更的模組,以維持 context economy
25
+ > Read only `atlas.index.yaml` + the YAML files of affected features. Do not read unrelated features or unchanged modules to preserve context economy.
27
26
 
28
- ### 2. 測量架構 drift
27
+ ### 2. Measure architecture drift
29
28
 
30
- 在決定更新範圍前,先比對架構圖與當前程式碼的偏離程度:
29
+ Before deciding the update scope, compare the atlas against the current code:
31
30
 
32
- - 比較 `atlas.index.yaml` 與當前目錄結構:是否有新增 / 移除的目錄或模組?
33
- - 比較各 feature YAML 中的檔案路徑與實際程式碼:是否有檔案已不存在或搬移?
34
- - 量化 drift:新增 + 移除 + 修改的 entries 數量 / entries 數量
31
+ - Compare `atlas.index.yaml` with the current directory structure: are there added / removed directories or modules?
32
+ - Compare file paths in each feature YAML against the actual codebase: are any files missing or moved?
33
+ - Quantify drift: count of added + removed + modified entries / total entries
35
34
 
36
- 根據 drift 程度決定更新策略:
37
- - **低 drift(< 20%)**:只更新受 diff 影響的 feature
38
- - **高 drift(≥ 20%)**:建議標記為重大偏離,通知用戶後考慮全面重新初始化(使用 `init-project-html`)
35
+ Determine the update strategy based on drift severity:
36
+ - **Low drift (< 20%)**: Update only the features affected by the diff
37
+ - **High drift (≥ 20%)**: Flag as significant divergence, notify the user and recommend a full re-initialization via `init-project-html`
39
38
 
40
- ### 3. 過濾 diff 噪聲
39
+ ### 3. Filter diff noise
41
40
 
42
- 分析 diff 範圍,過濾不影響架構的變更類型:
43
- - **保留**:新增或修改的 API route、service 邏輯、資料庫操作、模組邊界變更
44
- - **過濾**:formatting 調整、config 值變更(非結構變更)、純測試檔案、型別定義調整(非邊界影響)、註解或文檔變更
41
+ Analyze the diff scope and filter non-architectural changes:
45
42
 
46
- 將過濾後的 diff hunk 對應到受影響的 feature。
43
+ - **Keep**: New or modified API routes, service logic, database operations, module boundary changes
44
+ - **Filter**: Formatting adjustments, config value changes (non-structural), test-only files, type definition adjustments (no boundary impact), comment or documentation changes
47
45
 
48
- ### 4. 對照代碼庫及當前架構圖
46
+ Map the filtered diff hunks to the affected features.
49
47
 
50
- 並行調度 subagents 完成代碼與架構圖的對照任務,驗證架構圖是否存在錯誤或遺漏。
48
+ ### 4. Cross-reference code with the current atlas
51
49
 
52
- ### 5. 通過 `apltk` cli 工具更新當前架構圖
50
+ Dispatch subagents in parallel to cross-reference the code against the architecture diagram and verify whether the atlas has errors or omissions.
53
51
 
54
- 使用 `apltk` cli 工具,按照以下流程完成架構圖的更新:
52
+ ### 5. Update the atlas via `apltk` CLI
55
53
 
56
- 在操作前先閱讀 `references/architecture.md` 了解所有參數細節。
57
- 1. 定義功能模塊及其下屬子模塊。
58
- 2. 定義子模塊之間的關係、呼叫、錯誤處理、資料流、回滾等架構關係
59
- 3. 定義子模塊內部的函數、變數、資料流及錯誤處理。
54
+ Use `apltk architecture` commands to update the architecture diagram:
60
55
 
61
- 當從 diff 推斷 component 時,使用 `--evidence inferred` 標記品質等級。例如:
56
+ Consult `references/architecture.md` for CLI flag details (parameter reference, mutation series).
57
+
58
+ 1. Define features and their submodules.
59
+ 2. Define inter-submodule relationships: calls, error handling, data flow, rollback, and other architectural connections.
60
+ 3. Define intra-submodule functions, variables, data flows, and error handling.
61
+
62
+ When inferring components from a diff hunk, use `--evidence inferred` with a `file:line` source. For example:
62
63
  ```
63
- apltk architecture function add --feature <slug> --submodule <slug> --name <fn> --evidence "inferred:<source-path>"
64
+ apltk architecture function add --feature <slug> --submodule <slug> --name <fn> \
65
+ --evidence inferred:src/auth/controller.ts:42
64
66
  ```
65
67
 
66
- 更新完成後再次測量 drift,確認已降低至可接受範圍。
68
+ After completing the update, re-measure drift to confirm it has been reduced to an acceptable range.
69
+
70
+ ### 6. Self-review
71
+
72
+ Confirm the following before finishing:
73
+
74
+ - [ ] Drift is now within acceptable range (< 20%)
75
+ - [ ] Filtered diff noise (formatting, config-only, test-only) did not drive any atlas mutations
76
+ - [ ] Every new or modified component carries evidence (`observed` for source-confirmed, `inferred` otherwise)
77
+ - [ ] All edges affected by changed code have been reviewed and updated
78
+ - [ ] Atlas passes `apltk architecture validate`
67
79
 
68
- ## 參考資料
80
+ ## References
69
81
 
70
- - `references/architecture.md` — apltk architecture 工具的完整參數說明。在步驟 5 更新架構圖前閱讀,了解 mutation 指令與 --evidence 旗標的行為。
82
+ - `references/architecture.md` — Full parameter reference for the apltk architecture tool (consult when CLI flag details are needed).
83
+ - `references/definition.md` — Detailed definitions of feature and submodule.
@@ -1,40 +1,40 @@
1
- # apltk architecture — 宣告式架構圖 CLI
1
+ # apltk architecture — Declarative Architecture Diagram CLI
2
2
 
3
- ## 用途
4
- 透過 YAML 狀態檔案管理 `resources/project-architecture/` 下的架構圖,支援基礎架構圖與 spec 覆蓋層的差異比對與合併。
3
+ ## Purpose
4
+ Manage architecture diagrams under `resources/project-architecture/` via YAML state files. Supports base atlas and spec overlay diff/merge comparison.
5
5
 
6
- ## 用法
6
+ ## Usage
7
7
  ```
8
8
  apltk architecture [verb] [options]
9
9
  ```
10
10
 
11
- ## 全局旗標
12
- | 旗標 | 效果 |
13
- |------|------|
14
- | `--project <root>` | 指定專案根目錄(預設從 cwd 向上搜尋) |
15
- | `--spec <spec_dir>` | 寫入 spec overlay 而非基礎架構圖 |
16
- | `--no-render` | 變更後略過自動重新渲染,可批次多條指令 |
17
- | `--no-open` | `open` `diff` 時不開啟瀏覽器 |
18
- | `--dry-run` | 預覽變更為 JSON diff,不實際寫入 |
19
- | `--out <dir>` | `diff` 的輸出目錄 |
20
- | `--clean` | `merge` 成功後移除 spec overlay 目錄 |
21
- | `--all` | `merge` 時選取所有 pending spec overlay |
22
- | `--json` | `status` 時輸出 JSON |
23
- | `--evidence <level[:source]>` | 為組件標記 observed/inferred/assumed 品質等級 |
24
-
25
- ## 頂層動詞
26
- - **`open`** — 開啟基礎架構圖 HTML,若未渲染則先 bootstrap
27
- - **`diff`** — 收集 `docs/plans/` 下所有 overlay,產生 before/after 檢視器
28
- - **`render`** — 從當前 YAML 狀態重新產生 HTML
29
- - **`validate`** — 驗證架構圖結構完整性(schema + referential integrity
30
- - **`status`** — 顯示摘要(feature/submodule/edge/actor 數量、時間戳、驗證狀態)
31
- - **`scan --src <dir>`** — 掃描目錄結構,輸出 JSON 候選 feature 列表
32
- - **`undo [--steps <n>]`** — 還原最近一次 mutation
33
- - **`merge --spec <dir> | --all`** — spec overlay 合併回基礎架構圖
34
-
35
- ## Mutation 系列
36
-
37
- 所有 mutation 共用 `--project`、`--spec`、`--no-render`、`--dry-run`、`--evidence` 旗標。
11
+ ## Global Flags
12
+ | Flag | Effect |
13
+ |------|--------|
14
+ | `--project <root>` | Specify project root (defaults to upward search from cwd) |
15
+ | `--spec <spec_dir>` | Write to spec overlay instead of base atlas |
16
+ | `--no-render` | Skip auto-render after mutations for batch operations |
17
+ | `--no-open` | Skip browser launch for `open` and `diff` |
18
+ | `--dry-run` | Preview changes as JSON diff without writing |
19
+ | `--out <dir>` | Output directory for `diff` |
20
+ | `--clean` | Remove spec overlay directory after successful `merge` |
21
+ | `--all` | Select all pending spec overlays for `merge` |
22
+ | `--json` | JSON output for `status` |
23
+ | `--evidence <level[:source]>` | Mark component quality tier (observed/inferred/assumed); source supports auto-parsed `file:line` (e.g. `observed:src/foo.ts:42`) |
24
+
25
+ ## Top-Level Verbs
26
+ - **`open`** — Open base atlas HTML in browser; bootstrap if not rendered
27
+ - **`diff`** — Collect all overlays under `docs/plans/`, generate before/after viewer
28
+ - **`render`** — Regenerate HTML from current YAML state
29
+ - **`validate`** — Validate atlas structural integrity (schema + referential integrity)
30
+ - **`status`** — Show summary (feature/submodule/edge/actor counts, timestamp, validation status)
31
+ - **`scan --src <dir>`** — Scan directory structure, output JSON candidate feature list
32
+ - **`undo [--steps <n>]`** — Revert the most recent mutation(s)
33
+ - **`merge --spec <dir> | --all`** — Merge spec overlay(s) into base atlas
34
+
35
+ ## Mutation Series
36
+
37
+ All mutations share `--project`, `--spec`, `--no-render`, `--dry-run`, `--evidence` flags.
38
38
 
39
39
  ### feature
40
40
  ```
@@ -92,7 +92,7 @@ apltk architecture actor add --id <actor-id> [--label "..."]
92
92
  apltk architecture actor remove --id <actor-id>
93
93
  ```
94
94
 
95
- ## 注意事項
96
- - 執行 mutation 後自動重新渲染(除非 `--no-render`)
97
- - 每個 mutation 建立 undo snapshot,可行 `undo` 還原
98
- - 驗證通過後才算架構圖工作完成
95
+ ## Notes
96
+ - Auto-render after every mutation (unless `--no-render`)
97
+ - Each mutation creates an undo snapshot — revert with `undo`
98
+ - Atlas work is not complete until validation passes
@@ -1,25 +1,20 @@
1
- ## 功能模塊
1
+ ## Feature
2
2
 
3
- 功能模塊是直接面向用戶的功能,如:
4
- - 登陸功能
5
- - 註冊功能
6
- - 邀請碼功能
3
+ A feature is a user-facing capability, such as:
4
+ - Login
5
+ - Registration
6
+ - Invite code management
7
7
 
8
- 功能模塊由子模塊的合作、交互實現
8
+ Features are realized through collaboration and interaction of their submodules.
9
9
 
10
- 功能模塊對應 C4 model **Container** 層級:高階功能邊界,可獨立部署或辨識的系統能力單元。
10
+ A feature maps to the C4 model's **Container** level: a high-level functional boundary, deployable or identifiable as a distinct system capability unit.
11
11
 
12
- ## 子模塊
12
+ ## Submodule
13
13
 
14
- 子模塊是功能模塊的關鍵組成部分。具體定義依照代碼的實作邊界得出。
14
+ A submodule is a key building block of a feature. Its exact definition follows the implementation boundaries in the code.
15
15
 
16
- 子模塊對應 C4 model **Component** 層級:功能內部的實作單元(如 controllerservicerepository)。
16
+ A submodule maps to the C4 model's **Component** level: an implementation unit inside a feature (e.g., controller, service, repository).
17
17
 
18
- ## C4 模型層級對照
18
+ ## C4 Level Mapping
19
19
 
20
- | C4 層級 | 對應概念 | 用途 |
21
- |---------|---------|------|
22
- | System Context | 整體系統 + 外部 actor | 定義系統邊界與外部依賴 |
23
- | Container | 功能模塊(feature) | 高階功能邊界 |
24
- | Component | 子模塊(submodule) | 功能內部的實作單元 |
25
- | Code | function 行 | 函式層級細節(選擇性) |
20
+ Refer to the C4 mapping table in `SKILL.md` it is not duplicated here.