@seanmars/tospec 0.14.2 → 0.15.0
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
|
@@ -6,6 +6,14 @@
|
|
|
6
6
|
|
|
7
7
|
tospec 是一套 spec-driven development CLI: 以 schema 定義文件結構與工作流程, 進度由檔案系統狀態推算, 開發方法則封裝於 Skill 之中, 使 AI 工具 (Claude Code / Codex) 得以循序完成需求釐清、規格撰寫、設計、任務拆解、實作到歸檔的完整流程.
|
|
8
8
|
|
|
9
|
+
## [0.15.0] - 2026-08-12
|
|
10
|
+
|
|
11
|
+
本版本修正 `tospec-archive` 略過 sync 的觸發字眼過於寬鬆的問題: 判斷「使用者要求略過 sync」的例句原本包含裸字的 `"just archive"`, 但這個詞只是「archive」在一般語句中的強調用法, 與明確要求略過 sync 在語意上無法區分.
|
|
12
|
+
|
|
13
|
+
### 修正
|
|
14
|
+
|
|
15
|
+
- **`tospec-archive` 的略過 sync 觸發字眼收斂為明確指名 sync**: `ARCHIVE_BODY` Step 1 原以例句清單 (`"archive without syncing"`, `"just archive"`) 判斷使用者是否要求略過 sync, 但 `"just archive"` 只是「archive」一詞的強調用法, 一句仍然期望預設 sync 照常執行的請求 (例如「等修好後 just archive 一下」) 會被誤判為略過指令, 使變更未經比對即合併進 `tospec/specs/`, 且過程不會有任何錯誤或警告. 根本原因不在例句本身, 而在判斷依據是「例句清單」而非「規則」: 只要清單中留有一個與「archive」重疊的詞, 讀取該提示的 agent 就會據以比對, 移除單一例句無法阻止下一個相似詞重蹈覆轍. 現改為陳述規則本身 — 使用者的請求必須明確指名 sync 才算數 (`"archive without sync"`, `"skip the sync"`), 單獨出現「archive」一詞不構成略過指令. `change-verification` 的對應 Requirement 新增一則反例情境, 記錄「僅提及 archive 不觸發略過」這條先前規格未涵蓋的行為; `test/core/shared/skill-generation.test.ts` 新增文字斷言, 確保產生的四個 archive surface (skill 本文與 command 各三份) 皆不殘留裸字的 `"just archive"` 觸發詞.
|
|
16
|
+
|
|
9
17
|
## [0.14.2] - 2026-07-31
|
|
10
18
|
|
|
11
19
|
本版本新增 `tospec skill-metrics`: 一份以本機網頁呈現的耗時報告, 回答「哪個 Skill 最花時間、哪個最不穩定、工作實際發生在哪些日子」. 資料同時取自 Claude Code 與 Codex, 但兩種來源的歸屬精準度不同, 因此在任何位置都不合併為單一數字. 為此將 dashboard 的本機伺服器基礎設施抽離為共用模組 — 其中兩項是信任邊界, 複製一份等同於製造一個修好第一份也不會消失的漏洞.
|
|
@@ -257,6 +265,7 @@ Dashboard 進化為可背景常駐、多專案並存的服務, 並補上 TDD 導
|
|
|
257
265
|
|
|
258
266
|
- 新增 `prepack` script 與 npm publish 的準備設定, 完備套件發行流程.
|
|
259
267
|
|
|
268
|
+
[0.15.0]: https://github.com/seanmars/tospec/compare/v0.14.2...v0.15.0
|
|
260
269
|
[0.14.2]: https://github.com/seanmars/tospec/compare/v0.14.1...v0.14.2
|
|
261
270
|
[0.14.1]: https://github.com/seanmars/tospec/compare/v0.14.0...v0.14.1
|
|
262
271
|
[0.14.0]: https://github.com/seanmars/tospec/compare/v0.13.0...v0.14.0
|
|
@@ -6,7 +6,7 @@ Archive merges the change's delta specs into \`tospec/specs/\` permanently, so i
|
|
|
6
6
|
|
|
7
7
|
Take these in order; the first that matches wins.
|
|
8
8
|
|
|
9
|
-
1. **The user
|
|
9
|
+
1. **The user's request unambiguously names sync as what to skip** ("archive without sync", "skip the sync") — honor that. Skip the sync and archive **without** \`--require-sync\` (Step 2, not-synced branch). This is checked first on purpose: an explicit instruction outranks the default, and what was removed is the unsolicited question, not the user's authority. A request that merely contains the word "archive" (e.g. "just archive this") does not count on its own — that word is also the ordinary verb for the whole workflow, so matching on it alone risks skipping a sync the user never asked to skip.
|
|
10
10
|
2. **No delta specs at all** (e.g. a purely cosmetic issue fix with no behavior change) — there is no spec-vs-code drift to find. Skip straight to Step 2 and archive directly. Under a schema that requires deltas (sdd), such a change also needs \`skip_specs: true\` in its \`.tospec.yaml\` or validation will refuse it — set that once, and only when the change truly has no externally observable effect. Never write a delta spec just to get past the gate.
|
|
11
11
|
3. **Otherwise the change produced delta specs** (a non-empty \`specs/<capability>/spec.md\` under the change dir), so behavior was added or changed and drift is possible. Run the \`tospec-sync\` workflow now, without asking. There is no question to put: declining would mean knowingly publishing a spec that may not describe the code, so a prompt here spends the user's attention without buying a decision.
|
|
12
12
|
|
package/package.json
CHANGED