@laitszkin/apollo-toolkit 3.14.3 → 3.14.4
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
CHANGED
|
@@ -2,6 +2,12 @@
|
|
|
2
2
|
|
|
3
3
|
All notable changes to this repository are documented in this file.
|
|
4
4
|
|
|
5
|
+
## [v3.14.4] - 2026-05-16
|
|
6
|
+
|
|
7
|
+
### Changed
|
|
8
|
+
|
|
9
|
+
- Standardize spec template task numbering (P1.x/P2.x, T1.x/T2.x) and simplify SKILL.md description format across skill docs.
|
|
10
|
+
|
|
5
11
|
## [v3.14.3] - 2026-05-15
|
|
6
12
|
|
|
7
13
|
### Changed
|
|
@@ -1,6 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: align-project-documents
|
|
3
|
-
description:
|
|
3
|
+
description: >-
|
|
4
|
+
提供標準化的文檔格式，用於協助維護項目文檔。
|
|
5
|
+
使用場景：更新、修改、重寫項目文檔。
|
|
4
6
|
---
|
|
5
7
|
|
|
6
8
|
## 目標
|
|
@@ -25,13 +27,7 @@ description: 整理及維護項目文檔。當你需要管理項目說明文檔
|
|
|
25
27
|
|
|
26
28
|
### 3. 制定文檔更新策略
|
|
27
29
|
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
## 範例
|
|
31
|
-
|
|
32
|
-
- "根據當前repo重建整套專案文檔。" -> "完整讀碼後重建三類標準文檔，清理舊文檔並同步刷新 `AGENTS.md` / `CLAUDE.md`。"
|
|
33
|
-
- "這個倉庫的 docs 很散，請重新對齊成統一結構。" -> "把可保留內容遷入 `docs/features/`、`docs/architecture/`、`docs/principles/`，移除重複或失效文件。"
|
|
34
|
-
- "我要的不是 README 小修，而是整個文檔體系重整。" -> "以全倉庫證據為基礎重建標準化文檔樹，而不是只修改單一說明文件。"
|
|
30
|
+
根據上一步找到的所有遺漏或項目文檔與實際代碼脫節之處，制定文檔更新策略。使用模板之中所規範的格式，重寫項目文檔，並移除除必要文檔（如 `CHANGELOG.md`, `CONTRIBUTION.md` ）外的舊有說明文檔。
|
|
35
31
|
|
|
36
32
|
## 參考資料
|
|
37
33
|
- `references/templates/standardized-docs-template.md` - 三類文檔的目標結構、分類規則與清理檢查表。
|
|
@@ -3,26 +3,16 @@
|
|
|
3
3
|
- Date: [YYYY-MM-DD]
|
|
4
4
|
- Batch: [batch_name]
|
|
5
5
|
|
|
6
|
-
## Preparation Goal
|
|
7
|
-
|
|
8
|
-
[Describe the smallest shared prerequisite state that must exist before member specs can be implemented in parallel. This must not implement core business logic or deliver the batch target outcome.]
|
|
9
|
-
|
|
10
|
-
- Why this exists: [why the batch cannot be parallelized without this prerequisite work]
|
|
11
|
-
- Core business boundary: [No core business logic or target outcome is implemented here]
|
|
12
|
-
- Depends on (specs): [[spec-name-1], [spec-name-2]]
|
|
13
|
-
- Parallel work starts after: [commit / verification / approval of this preparation]
|
|
14
|
-
- Out of scope: [member-spec implementation work that must remain in spec files]
|
|
15
|
-
|
|
16
6
|
## **Task P1: [Preparation Task Title]**
|
|
17
7
|
|
|
18
8
|
Purpose: [why this prerequisite is required before parallel work]
|
|
19
9
|
Scope: [files/modules this task may touch]
|
|
20
10
|
Out of scope: [core business logic, target outcome, member-spec behavior]
|
|
21
11
|
|
|
22
|
-
- P1. [ ] **[file/function]** — **[specific modification; expected output]**
|
|
12
|
+
- P1.1 [ ] **[file/function]** — **[specific modification; expected output]**
|
|
23
13
|
- Verify: [command/check/manual inspection]
|
|
24
14
|
|
|
25
|
-
-
|
|
15
|
+
- P1.2 [ ] **[file/function]** — **[specific modification; expected output]**
|
|
26
16
|
- Verify: [command/check/manual inspection]
|
|
27
17
|
|
|
28
18
|
## **Task P2: [Preparation Task Title]**
|
|
@@ -31,10 +21,10 @@ Purpose: [why this prerequisite is required before parallel work]
|
|
|
31
21
|
Scope: [files/modules this task may touch]
|
|
32
22
|
Out of scope: [core business logic, target outcome, member-spec behavior]
|
|
33
23
|
|
|
34
|
-
-
|
|
24
|
+
- P2.1 [ ] **[file/function]** — **[specific modification; expected output]**
|
|
35
25
|
- Verify: [command/check/manual inspection]
|
|
36
26
|
|
|
37
|
-
- P2. [ ] **[file/function]** — **[specific modification; expected output]**
|
|
27
|
+
- P2.2 [ ] **[file/function]** — **[specific modification; expected output]**
|
|
38
28
|
- Verify: [command/check/manual inspection]
|
|
39
29
|
|
|
40
30
|
## Validation
|
|
@@ -42,11 +32,3 @@ Out of scope: [core business logic, target outcome, member-spec behavior]
|
|
|
42
32
|
- Verification required: [commands/checks before subagents start]
|
|
43
33
|
- Expected results: [what proves the prepared baseline is usable]
|
|
44
34
|
- Regression risks covered: [risk IDs or behavior slices]
|
|
45
|
-
|
|
46
|
-
## Handoff
|
|
47
|
-
|
|
48
|
-
- Preparation commit required before parallel work: [Yes / No]
|
|
49
|
-
- Member specs assume: [prepared baseline assumptions]
|
|
50
|
-
- Member specs must not change: [prepared surfaces now frozen or additive-only]
|
|
51
|
-
- Member specs own all business behavior: [Yes]
|
|
52
|
-
- If preparation changes later: [stop and re-coordinate rule]
|
|
@@ -10,10 +10,10 @@ Requirements: [R1.x]
|
|
|
10
10
|
Scope: [files/modules/functions this task may touch]
|
|
11
11
|
Out of scope: [files/modules/behaviors this task must not change]
|
|
12
12
|
|
|
13
|
-
- 1
|
|
13
|
+
- T1.1 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
|
|
14
14
|
- Verify: [focused command/check/manual inspection; drift check ref if applicable]
|
|
15
15
|
|
|
16
|
-
- 2
|
|
16
|
+
- T1.2 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
|
|
17
17
|
- Verify: [focused command/check/manual inspection; drift check ref if applicable]
|
|
18
18
|
|
|
19
19
|
## **Task 2: [Task Title]**
|
|
@@ -23,22 +23,8 @@ Requirements: [R2.x]
|
|
|
23
23
|
Scope: [files/modules/functions this task may touch]
|
|
24
24
|
Out of scope: [files/modules/behaviors this task must not change]
|
|
25
25
|
|
|
26
|
-
- 1
|
|
26
|
+
- T2.1 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
|
|
27
27
|
- Verify: [focused command/check/manual inspection; drift check ref if applicable]
|
|
28
28
|
|
|
29
|
-
- 2
|
|
29
|
+
- T2.2 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
|
|
30
30
|
- Verify: [focused command/check/manual inspection; drift check ref if applicable]
|
|
31
|
-
|
|
32
|
-
## Notes
|
|
33
|
-
- **Layering:** **`design.md`** / **`contract.md`** are **guiding context** only (architecture + external truth). **`tasks.md` is the sole numbered, file-level execution queue**—do not expect design/contract to re-list its checkboxes.
|
|
34
|
-
- When drafting, derive task order and scope from **`spec.md`** + **`design.md`** + **`contract.md`**; optionally cite **`INT-###` / `EXT-###`** on rows those anchors constrain.
|
|
35
|
-
- Task order reflects implementation sequence.
|
|
36
|
-
- Every task must map back to `spec.md` requirement IDs.
|
|
37
|
-
- Treat `tasks.md` as an implementation queue, not a summary.
|
|
38
|
-
- Each item must include the exact file path (or function/module), the specific change, and a concrete verification step — vague items are forbidden.
|
|
39
|
-
- Each checkbox is atomic: one verb, one file/function, one change outcome, one verification hook.
|
|
40
|
-
- Use `N.x [ ]` for sub-items only when a parent item needs further breakdown.
|
|
41
|
-
- Split tasks that exceed 3 files or span multiple behavior slices.
|
|
42
|
-
- Use `$test-case-strategy` for drift checks before implementation.
|
|
43
|
-
- After execution, update `[x]` for done, `[ ]` for pending.
|
|
44
|
-
- Remove all `[...]` placeholder text after filling.
|
package/package.json
CHANGED