feature: mechanism for sync archived Spectra spec deltas with subsequent capability extensions

[kiki830621]

Problem

Source: surfaced during /idd-verify #47 (codex P3 #6).

/idd-all-chain capability spec at openspec/specs/idd-all-chain/spec.md 是 archived from #44 (add-idd-all-chain-skill change)。但 #47 落地後 spec 沒同步更新 — Phase 0 描述仍是 4 道 gate (git/auth/issue OPEN/cluster branch),沒有第 5 道 diagnosis-readiness gate。

實務上 archived spec 是 frozen contract;後續 capability 擴展(#47 / 預期的 #46 multi-root)沒有清楚的 mechanism 把 delta 推回 archived spec。

Type

feature (process / infrastructure)

Expected

定義 archived spec sync mechanism。可能方向:

• a. 後續 change 用 MODIFIED 修改 archived spec(類似 spectra apply 的 spec delta,但 source 是 archived)
• b. 每次擴展都是新 capability(idd-all-chain-v2 / idd-all-chain-multi-root),不修 archived
• c. Archive 內維護 changelog appendix(spec.md + extensions.md),不動 frozen 部分

Priority

P3 (process improvement;不影響 #47 本身落地,但長期影響 spec discipline)

---

Current Status

Phase: closed
Last updated: 2026-05-18 by idd-close → idd-update

Key Decisions

• Closed as won't-fix (premise obsoleted on inspection)
• spectra archive already applies spec deltas to canonical main spec — Option (a) in issue body IS the existing mechanism
• Vocabulary drift surfaced: issue body's "archived spec" conflated main spec with change snapshot

Scope Changes

• (none — no implementation)

Blocking

• (none)

Resolution

• /spectra-discuss #54 (2026-05-18) — 4 assumptions confirmed
• Diagnosis comment Strategy items: - [ ] → - [-] with won't-fix reason
• Closing summary: feature: mechanism for sync archived Spectra spec deltas with subsequent capability extensions #54 (comment)
• Validated live by feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46 archive run (Specs applied: idd-all-chain, idd-spawn-manifest (added: 1, modified: 6))

Commits

• (none — no code shipped)

[kiki830621]

Diagnosis

Type

feature (process / infrastructure — Spec lifecycle mechanism)

Analysis

Issue body 列了 3 個 design directions:

• a. MODIFIED archived spec — 後續 change 對 archived spec 用 MODIFIED delta(類似 spectra-apply 的 spec delta 但 source 是 archived)
• b. New capability per extension — idd-all-chain-v2 / idd-all-chain-multi-root 各自獨立,不修 archived
• c. Archive 內 changelog appendix — spec.md(frozen)+ extensions.md(累加 entries),不動 frozen 部分

Trade-off 評估

Option	Audit clarity	Implementation cost	Frozen-spec discipline	Cross-spec ripple risk
a. MODIFIED archived	High(single source)	Medium(改 spectra-apply 容許 archived path)	Broken(frozen 概念失效)	Low(spec authority centralized)
b. New capability	Medium(分散但各自完整)	Low(沿用既有 capability mechanism)	Preserved(archived 真 frozen)	High(每個擴展都要 cross-spec consistency check)
c. Changelog appendix	Medium(audit 在 appendix)	Medium(新檔案 convention)	Preserved partial	Medium

個人 lean:Option b — 跟 IDD 的 capability-version-evolution mental model 最 match:

• archived idd-all-chain v1.0 spec → frozen
• feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 ship → 新 capability idd-all-chain v1.1(diagnosis-readiness gate)— 但其實是同 capability 的 minor evolution
• 真 multi-root(feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46)的話可以視為 v2.0 / new capability

但 issue 標題談的是「mechanism」,代表要先決定哪個 option,這本身就是 design discussion 不能在 diagnose 階段 unilateral 決。

Inherent Spectra-tier signal

本 issue 影響:

• 新 published convention for future spec lifecycle(tooling 與 reviewers 要 follow)
• 跨 capabilities ripple:每個 archived capability 都受影響
• Architectural decision with long-term maintenance implications:選 a/b/c 後 IDD 的 spec evolution culture 永遠跟著走

這 3 點滿足 Layer 2 + Layer 3 — Spectra tier。

Impact

• 影響的工作流:future spec evolution (idd-all-chain ext, idd-spawn-manifest ext, idd-orchestrator-modes ext, ...任何 archived capability 想擴展)
• 影響的檔案(per option):
  • Option a:spectra-app 改 spec delta source(third-party — 跨 plugin coordination)
  • Option b:無(既有 mechanism;只需 docs 約定 naming + cross-link)
  • Option c:新 reference doc + spectra-archive workflow extension
• 影響的使用者流程:設計 review 階段 author 要先決定 path(若 a/b/c 沒 docs 的話)

Strategy

Won't-fix reason (2026-05-18): Premise obsoleted by spectra archive's existing spec delta apply mechanism. Validated via #46 archive run (Specs applied: idd-all-chain, idd-spawn-manifest (added: 1, modified: 6, removed: 0)). openspec/specs/<cap>/spec.md is canonical evolving main spec, not frozen archived snapshot. Option (a) MODIFIED-requirements path IS the current mechanism. Lineage tooling concern is orthogonal — not opening sister ticket per YAGNI.

(Spectra path — discuss first to converge,以下是 propose 階段預期 task list:)

• [-] /spectra-discuss 收斂 a/b/c trade-off + pick(本 diagnose lean b 但需 user 確認)
• [-] /spectra-propose 起草 proposal 含 mechanism doc + workflow examples
• [-] design.md 含 case study:feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47(diagnosis-readiness gate)如何 fit chosen mechanism
• [-] 若選 b(無新 mechanism):docs 寫進 references/spec-evolution.md 或類似 location
• [-] 若選 a:跨 plugin coordination + spectra-app contract refinement
• [-] 若選 c:新 reference doc spec + spectra-archive workflow update

Complexity

Spectra (Layer 2 + Layer 3 都命中)

理由:

• Layer 2 命中:選 a/b/c 任一都 publishes new convention (tooling / reviewers / future authors 都要 follow)— is published API for "future callers" of spec lifecycle process
• Layer 3a 命中:spec.md per-capability 是既有 published spec — modify 規則改變影響每個 archived spec 的 normative behavior
• Layer 3b 命中:Cross-spec impact — 任何 capability 要擴展都觸到本 mechanism
• Layer 3c 命中:Architectural decision long-term implications — 改 IDD 的 spec evolution culture

Layer V — vagueness check:

• V1: 3 — what 清楚(define mechanism),但沒指定哪個 option
• V4: 4 — Acceptance 模糊 (沒 explicit "done when X" criteria for spec lifecycle decision)
• Triggered: yes (V4=4)

但 V4=4 default 是 proceed anyway per attribute-assessment.md anchors。Spectra path 本來就會在 spectra-discuss 階段 converge 這些 ambiguity,所以 proceed 合理。

Risks

• Decision avalanche:本 mechanism 一旦 ship,所有 archived spec 都受影響 — error 一次後續一連串 cascade
• Spectra-app upstream dependency (option a):若選 a,需協調 third-party plugin
• Verify 困難:mechanism design correctness 不好用 6-AI 自動 verify — 需要 case study 驗證(feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 適合作 reference)

Recommended Path

Spectra (default — discuss first) → /spectra-discuss。

理由:3 個 design options 沒 explicit 收斂的 winner;spectra-discuss 是 design alignment 的 safety net,在這種 architectural decision 不該 skip。

[kiki830621]

Closing Summary — Won't Fix

Resolution: won't-fix — premise obsoleted on inspection. No code change shipped; mechanism already exists.

Problem

#54 claimed openspec/specs/idd-all-chain/spec.md was a "frozen archived spec" generated from #44, with no mechanism for subsequent capability extensions (#47, #46) to push delta back to the archived spec. Issue body proposed 3 options:

• (a) Subsequent change uses MODIFIED to edit archived spec
• (b) New capability per extension (idd-all-chain-v2)
• (c) Maintain extensions changelog appendix alongside frozen archive

Root Cause (of the misdiagnosis)

Vocabulary confusion: #54 conflated two distinct artifacts:

Artifact	Status	Role
openspec/specs/<cap>/spec.md	canonical evolving main spec	Source of truth; updated by every spectra archive run
openspec/changes/archive/<date-name>/specs/<cap>/spec.md	frozen change snapshot	History of what one change proposed; immutable

#54 body called the former "archived spec" because it was created by spectra archive. But it isn't archived — it's the live canonical spec that subsequent spectra archive runs continue to apply deltas to.

Solution

No code change. Closing as won't-fix because:

1. Option (a) is the existing mechanism, not a missing one. spectra archive already applies ## MODIFIED Requirements / ## ADDED Requirements deltas to main specs.
2. Validated this session via feature: /idd-all-chain accept multiple root issues with DFS/BFS traversal (default DFS) #46 archive run (2026-05-18):

   ✓ Archived: multi-root-traversal-idd-all-chain → 2026-05-18-multi-root-traversal-idd-all-chain
   Specs applied: idd-all-chain, idd-spawn-manifest (added: 1, modified: 6, removed: 0, renamed: 0)
   

   Main spec openspec/specs/idd-all-chain/spec.md now contains v2.60.0 multi-root + DFS/BFS + per-root halt content — proof that subsequent change can and does modify the spec that was originally created by spectra archive.
3. Option (b) (new capability per extension) would fragment the capability namespace unnecessarily — every extension would create idd-all-chain-v2, idd-all-chain-v3 etc., losing single-source-of-truth audit value.
4. Option (c) (extensions changelog appendix) is solving for a non-problem given Option (a) already works.

Orthogonal Concern (not opened)

There may be a real but separate "spec lineage tooling" gap — no spectra spec-history <capability> CLI to view how a capability spec evolved across change archives. This is unrelated to the "missing sync mechanism" framing of #54 and not painful enough yet to justify a sister ticket. YAGNI — file only if recurring need emerges.

Verification

• /spectra-discuss #54 (2026-05-18) — 4 assumptions presented, all confirmed by user
• Live evidence: /spectra-archive multi-root-traversal-idd-all-chain (2026-05-18) successfully applied 6 modified + 1 added requirement to main spec across 2 capabilities (idd-all-chain, idd-spawn-manifest)
• Strategy section checklist items in Diagnosis comment converted - [ ] → - [-] with reason (commit)

Changes

(No commits. Won't-fix close — premise invalidated, no implementation required.)

Vocabulary Note

Surface noted: vocabulary drift on "archived spec" (issue body) vs main spec / change snapshot. Not opening openspec/LANGUAGE.md for single occurrence (YAGNI); if confusion recurs, formalize then.

Distribution Sync

• Detected: plugin (issue-driven-dev marketplace member)
• Choice: not applicable — won't-fix close, no code shipped, no version bump needed
• Outcome: this issue closed without reaching user-facing distribution surface
• At: 2026-05-18T08:10:00Z