@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.
- package/CHANGELOG.md +16 -0
- package/package.json +2 -2
- package/packages/tools/architecture/dist/index.js +11 -1
- package/packages/tools/architecture/dist/tsconfig.tsbuildinfo +1 -1
- package/packages/tools/architecture/index.ts +7 -1
- package/packages/tools/codegraph/dist/index.js +201 -15
- package/packages/tools/codegraph/dist/tsconfig.tsbuildinfo +1 -1
- package/packages/tools/codegraph/index.ts +204 -15
- package/scripts/test.sh +39 -0
- package/skills/init-project-html/SKILL.md +67 -58
- package/skills/init-project-html/lib/atlas/assets/architecture.css +2 -1
- package/skills/init-project-html/lib/atlas/render.js +11 -1
- package/skills/init-project-html/lib/atlas/schema.js +44 -7
- package/skills/init-project-html/references/TEMPLATE_SPEC.md +20 -0
- package/skills/init-project-html/references/architecture.md +35 -35
- package/skills/init-project-html/references/definition.md +12 -17
- package/skills/update-project-html/README.md +16 -27
- package/skills/update-project-html/SKILL.md +54 -41
- package/skills/update-project-html/references/architecture.md +35 -35
- package/skills/update-project-html/references/definition.md +12 -17
|
@@ -1,40 +1,40 @@
|
|
|
1
|
-
# apltk architecture —
|
|
1
|
+
# apltk architecture — Declarative Architecture Diagram CLI
|
|
2
2
|
|
|
3
|
-
##
|
|
4
|
-
|
|
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>` |
|
|
15
|
-
| `--spec <spec_dir>` |
|
|
16
|
-
| `--no-render` |
|
|
17
|
-
| `--no-open` | `open`
|
|
18
|
-
| `--dry-run` |
|
|
19
|
-
| `--out <dir>` | `diff`
|
|
20
|
-
| `--clean` |
|
|
21
|
-
| `--all` |
|
|
22
|
-
| `--json` | `status`
|
|
23
|
-
| `--evidence <level[:source]>` |
|
|
24
|
-
|
|
25
|
-
##
|
|
26
|
-
- **`open`** —
|
|
27
|
-
- **`diff`** —
|
|
28
|
-
- **`render`** —
|
|
29
|
-
- **`validate`** —
|
|
30
|
-
- **`status`** —
|
|
31
|
-
- **`scan --src <dir>`** —
|
|
32
|
-
- **`undo [--steps <n>]`** —
|
|
33
|
-
- **`merge --spec <dir> | --all`** —
|
|
34
|
-
|
|
35
|
-
## Mutation
|
|
36
|
-
|
|
37
|
-
|
|
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
|
-
-
|
|
97
|
-
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
19
|
-
|
|
20
|
-
-
|
|
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`
|
|
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
|
|
29
|
-
- Every mutation traces to a specific file + diff hunk; absent code never produces atlas entries
|
|
30
|
-
-
|
|
31
|
-
-
|
|
32
|
-
|
|
33
|
-
|
|
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) —
|
|
38
|
-
- [`../init-project-html/SKILL.md`](../init-project-html/SKILL.md) — semantic rulebook
|
|
39
|
-
- [`../
|
|
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:
|
|
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
|
-
|
|
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
|
-
-
|
|
14
|
-
-
|
|
15
|
-
-
|
|
16
|
-
-
|
|
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
|
-
>
|
|
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.
|
|
27
|
+
### 2. Measure architecture drift
|
|
29
28
|
|
|
30
|
-
|
|
29
|
+
Before deciding the update scope, compare the atlas against the current code:
|
|
31
30
|
|
|
32
|
-
-
|
|
33
|
-
-
|
|
34
|
-
-
|
|
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
|
-
|
|
37
|
-
-
|
|
38
|
-
-
|
|
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.
|
|
39
|
+
### 3. Filter diff noise
|
|
41
40
|
|
|
42
|
-
|
|
43
|
-
- **保留**:新增或修改的 API route、service 邏輯、資料庫操作、模組邊界變更
|
|
44
|
-
- **過濾**:formatting 調整、config 值變更(非結構變更)、純測試檔案、型別定義調整(非邊界影響)、註解或文檔變更
|
|
41
|
+
Analyze the diff scope and filter non-architectural changes:
|
|
45
42
|
|
|
46
|
-
|
|
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
|
-
|
|
46
|
+
Map the filtered diff hunks to the affected features.
|
|
49
47
|
|
|
50
|
-
|
|
48
|
+
### 4. Cross-reference code with the current atlas
|
|
51
49
|
|
|
52
|
-
|
|
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
|
-
|
|
52
|
+
### 5. Update the atlas via `apltk` CLI
|
|
55
53
|
|
|
56
|
-
|
|
57
|
-
1. 定義功能模塊及其下屬子模塊。
|
|
58
|
-
2. 定義子模塊之間的關係、呼叫、錯誤處理、資料流、回滾等架構關係
|
|
59
|
-
3. 定義子模塊內部的函數、變數、資料流及錯誤處理。
|
|
54
|
+
Use `apltk architecture` commands to update the architecture diagram:
|
|
60
55
|
|
|
61
|
-
|
|
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>
|
|
64
|
+
apltk architecture function add --feature <slug> --submodule <slug> --name <fn> \
|
|
65
|
+
--evidence inferred:src/auth/controller.ts:42
|
|
64
66
|
```
|
|
65
67
|
|
|
66
|
-
|
|
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
|
|
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 —
|
|
1
|
+
# apltk architecture — Declarative Architecture Diagram CLI
|
|
2
2
|
|
|
3
|
-
##
|
|
4
|
-
|
|
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>` |
|
|
15
|
-
| `--spec <spec_dir>` |
|
|
16
|
-
| `--no-render` |
|
|
17
|
-
| `--no-open` | `open`
|
|
18
|
-
| `--dry-run` |
|
|
19
|
-
| `--out <dir>` | `diff`
|
|
20
|
-
| `--clean` |
|
|
21
|
-
| `--all` |
|
|
22
|
-
| `--json` | `status`
|
|
23
|
-
| `--evidence <level[:source]>` |
|
|
24
|
-
|
|
25
|
-
##
|
|
26
|
-
- **`open`** —
|
|
27
|
-
- **`diff`** —
|
|
28
|
-
- **`render`** —
|
|
29
|
-
- **`validate`** —
|
|
30
|
-
- **`status`** —
|
|
31
|
-
- **`scan --src <dir>`** —
|
|
32
|
-
- **`undo [--steps <n>]`** —
|
|
33
|
-
- **`merge --spec <dir> | --all`** —
|
|
34
|
-
|
|
35
|
-
## Mutation
|
|
36
|
-
|
|
37
|
-
|
|
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
|
-
-
|
|
97
|
-
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|