Complexity routing: vagueness 應該是一階信號,但目前 4 層 gate 都沒衡量需求清晰度

[kiki830621]

Problem

Original text (使用者口述,2026-05-04):
「判斷要走 simple, plan, spectra 的情況下,vagueness 應該是重要的判斷標準,但現在好像沒有」
— Source: /idd-issue invocation arguments

解讀

現行 idd-diagnose 的 Complexity 判定(rules/sdd-integration.md)用 4 層 gate:

Layer	衡量什麼
Layer 1(Simple disqualifier)	交付物形態(narrative / ad-hoc analysis / 多檔獨立)
Layer 2(Spectra necessary)	是否有 published API/protocol/skill/tool surface
Layer 3(Spectra confirmation)	是否動到 spec normative 行為、跨 2+ specs、架構決策
Layer P(Plan signals)	檔案互依、5+ ordered steps、decision-heavy diagnosis、risk-sensitive boundary、cross-file refactor

全部都在量「改動的形狀」(scope / surface / risk),沒有一條在量「需求本身的清晰度」。

唯一沾到邊的:

• Layer P 的 Decision-heavy with multiple valid approaches —— 但前提是 diagnosis 已經列出 2+ 策略,代表 diagnosis 已經做完且收斂。對「issue body 本身就含糊到 diagnose 都做不下去」的情境沒覆蓋。
• Why spectra-discuss is the default for Spectra rationale 提到「AI 常常高估 diagnosis 完整度」 —— 但這是 Spectra path 內 的安全網,不是把 vagueness 拉前到 routing 決策本身。

Type

refactor(改進既有 routing 規則)

Why vagueness 應該是一階信號

Issue 的 vagueness 跟改動的 scope 是 正交 的兩個維度:

                 Scope: 小                         Scope: 大
                 ┌─────────────────────────────────┬─────────────────────────────────┐
Vague needs:     │ A. 「menu 感覺怪怪的,改一下」   │ B. 「整個 onboarding 流程要重做」  │
                 │   一檔可能就改完,但不知道要改   │   範圍大,且方向也不清楚           │
                 │   什麼 → 現在會被判 Simple      │   → 現在大機率判 Spectra(對)     │
                 ├─────────────────────────────────┼─────────────────────────────────┤
Clear needs:     │ C. 「這行 typo,改 'recieve' →  │ D. 「把 5 個 walker 抽出 visitor   │
                 │     'receive'」                 │     protocol,介面設計如附圖」     │
                 │   → Simple(對)                  │   → 現在判 Plan(對)              │
                 └─────────────────────────────────┴─────────────────────────────────┘

問題集中在 quadrant A:scope 小 + 需求模糊 → 現行邏輯判 Simple → AI 直接進 TDD loop → pattern-match 一個方向就動手 → 改完才發現「不是這個意思」。

這正是 spectra-discuss 想防的失敗模式,但 Simple path 完全沒有對應的 alignment gate。Plan path 的 EnterPlanMode 雖然能擋,但前提是先被路由到 Plan;vagueness 沒進入 routing 信號的話,quadrant A 永遠不會被路到 Plan。

Expected

rules/sdd-integration.md 應該把 Vagueness Layer 加進 4 層 gate,作為 routing 決策的一階信號。可能的 shape(待 diagnose):

1. 新增 Layer V (Vagueness signals) —— 與 Layer P 並列,任一命中就升級到 Plan(或 Spectra,看程度)

   • Issue body 含 hedge 語(「感覺」「好像」「之類的」「順便」「之類」「something like」「somehow」)
   • 缺 expected/actual(bug type)或缺 acceptance criteria(feature type)
   • 含 open question(「該用 X 還是 Y?」「要不要也包含 Z?」)
   • 比較性訴求無基準(「改得好一點」「比較順」「更符合直覺」)
   • 多個並列名詞模糊指涉(「相關的東西」「類似的地方」)

2. Layer 2 reformulation —— Spectra 不只看「有沒有 published API」,也看「需求是否需要先對齊才能定 contract」。Vague Spectra-shaped issue → spectra-discuss(本來就是 default,但這次 routing 應該主動點出 vagueness 是觸發因素)

3. 新增 disqualifier 反向:即使 Layer 1 命中(narrative / ad-hoc),如果 vagueness 同時很高,可能要 escalate 到 Plan 而不是 Simple —— 例如「abstract 重寫,但風格、長度、目標讀者都沒講」應該先 Plan-mode 對齊再寫。

Actual

目前的 4 層 gate 完全沒有 vagueness 軸。所以:

• Quadrant A(small + vague)→ 一律 Simple → AI 直接動手 → 高機率改錯方向
• 即使 issue body 含「感覺怪怪的」「之類的」「再順便處理 X」這種 obvious hedge,也不會升級
• 唯一補救是 user 主動指定 --complexity Plan 或寫超詳細的 issue —— 但這就是把責任推給 user

Impact

• 失敗模式:Quadrant A issue 走 Simple path → AI 改完 → user「這不是我要的」→ revert/重做 → 多一輪
• 頻率:高。日常很多 ad-hoc 改善請求(「這個 UI 有點怪」「reports 看起來不太對」)都落在 quadrant A
• 目前的 workaround:user 自己升級到 Plan,或在 issue body 一開始就寫死 acceptance criteria —— 但 IDD 的 promise 是 routing 由 skill 判定,不是讓 user 預先 self-route

關聯設計線索

• rules/sdd-integration.md "Why spectra-discuss is the default for Spectra" —— 已承認 vagueness 存在,但只在 Spectra 內部處理
• idd-diagnose Step 3.5 是判定點,新增 Layer V 應該在這裡
• MANIFESTO.md 5-axis bug-fix model —— 可能要新增「alignment axis」對應 vagueness
• 與 linked-context sister sweep(IC_R011)正交:那個是「漏抓 sibling」,這個是「主軸本身就模糊」

Next Step

/issue-driven-dev:idd-diagnose #NNN(實際 issue # 由建立後填入)

Linked-Context Siblings Filed (v2.48.0+ #529)

(none — no orphan sibling mentions in linked context)

Current Status

Phase: closed
Last updated: 2026-05-04 by idd-close

Key Decisions

• Verdict = Spectra → spectra-discuss → propose → apply → archive 完整 lifecycle
• Approach C 選定 (Step 3.4 in idd-diagnose,不新增獨立 skill,維持 6-skill plugin surface)
• Heuristic = AI Likert 6-point per-axis (V1, V4),trigger threshold per-axis ≥ 4 — 不用 keyword matching
• Hybrid 3-option (clarify / proceed / escalate) default 隨 max score 變
• Meta-rule 屬性評分用 Likert,不用 keyword 抽到 .claude/rules/attribute-assessment.md,session-wide via @import
• 5-axis bug-fix model → 6-axis (新增 Alignment quality,evidence = Layer V)

Scope Changes

• 比原 issue 描述新增:meta-rule 抽出獨立檔(超越 vagueness 適用範圍);MANIFESTO 6-axis 擴充

Blocking

• (none — closed)

Commits

• b2899e6 feat: Layer V Vagueness Pre-check for complexity routing (Complexity routing: vagueness 應該是一階信號,但目前 4 層 gate 都沒衡量需求清晰度 #12)

Spectra Change

• add-vagueness-layer-routing archived to openspec/changes/archive/2026-05-04-add-vagueness-layer-routing/
• Main spec at openspec/specs/routing-vagueness-layer/spec.md (9 normative requirements)

[kiki830621]

Diagnosis

Type

refactor

Current State Analysis

rules/sdd-integration.md v2.36+ 的 4 層 gate 確實 完全沒衡量需求清晰度。逐層 cross-check:

Layer	衡量	與 vagueness 的關係
Layer 1	交付物形態	❌ 無
Layer 2	published API surface	❌ 無(看的是「contract 的存在」,不是「contract 的清晰度」)
Layer 3	spec normative / 多 specs / 架構決策	❌ 無
Layer P	檔案互依 / 5+ steps / decision-heavy / risk / cross-file refactor	⚠️ 部分 — 「decision-heavy」是 diagnosis 階段已收斂出 2+ 策略,不是 「issue body 含糊到 diagnose 都做不下去」

→ 原 issue 的診斷正確:vagueness 軸是缺的。

Vagueness 不是單一概念,有四種子類

原 issue 把 vagueness 當單一信號處理。實際拆解:

子類	例子	現行處理
V1: Vague WHAT	「menu 感覺怪怪的,改一下」	❌ 完全沒覆蓋 → 判 Simple → AI 動手
V2: Vague HOW	「要做 X,但 regex splice vs DOM walker 不確定」	✅ Layer P "decision-heavy" 已覆蓋(前提:diagnosis 列出 2+ 策略)
V3: Vague SCOPE	「修 login,順便看一下其他 auth 問題」	❌ Linked-context sister sweep(IC_R011)只負責 surface,不影響 routing
V4: Vague ACCEPTANCE	「reports 看起來不太對,改順一點」	❌ 沒覆蓋

只有 V2 已被覆蓋。V1/V3/V4 都會被路到 Simple。

風險評估(改 routing rule 的影響範圍)

rules/sdd-integration.md 是 published spec,被多處消費:

• idd-diagnose Step 3.5 — 直接讀 4 層 gate 邏輯
• idd-all Phase 3 — orchestrator 解析 Complexity verdict 路 sub-skill
• idd-implement Step 2.5 — parser 讀 ### Complexity 區段
• MANIFESTO.md 5-axis bug-fix model — IDD 對外論述
• idd-route plugin(若安裝)— agent recommendation 用 complexity 當 input
• 既有 issue 的 diagnosis comments(backward compat)

→ 加 Layer V 必須:

1. 不破壞既有 verdict 解析(Simple / Plan / Spectra / SDD-warranted)
2. 既有 diagnoses 不需重判(只影響新 diagnoses)
3. Heuristic 要可解釋(spec 必須給 explicit 範例,不能讓 AI 自由心證)

設計空間有兩個 fork(這是核心 open question)

Approach A: Vagueness 升級 routing tier(複用既有 gate)

Vagueness signals 命中:
  + scope 小      → Plan(走 EnterPlanMode 對齊 plan)
  + scope 大      → Spectra(走 spectra-discuss 對齊方向)

• ✅ 複用既有 approval gate,不新增 skill
• ❌ EnterPlanMode 的設計是「approve 一個 plan」,不是「澄清要做什麼」 — 語意有錯位
• ❌ 把 vagueness 跟 scope 混進同一個 verdict,future debug 難分清楚是哪個信號觸發

Approach B: 新增 idd-clarify step,正交於 routing

diagnose →
  ├─ vagueness 命中 → idd-clarify(對齊 issue body)→ 重 diagnose
  └─ vagueness 沒命中 → 照舊 routing

• ✅ 「clarify」與「approve plan」語意分離,各司其職
• ✅ Clarify 後產出的是 更新後的 issue body(append comment + 更新 Current Status),不只是 routing 結果 — 留下 audit trail
• ❌ 新 skill,plugin surface 增加
• ❌ 與 spectra-discuss 功能有 overlap(都是「對齊」)→ 需要邊界定義

Approach C(混合,我傾向):

• 不新增 skill。在 idd-diagnose Step 3.5 之前插入 Step 3.4: Vagueness Pre-check:
  • 偵測 V1/V3/V4 信號
  • 如果命中 → AskUserQuestion 3 選項:
    • clarify now(追問 → 取得使用者澄清 → 把澄清 append 到 issue body / Diagnosis 才往下走 routing)
    • proceed anyway(使用者明示「我有 mental model,先動手」→ 跳過,記在 audit trail)
    • escalate(把 verdict bump 到 Spectra 走 spectra-discuss)
• 然後才跑 Layer 1-3-P
• 不是 vague 的 issue 完全感受不到差異

Strategy

必要(不需 spectra-discuss 即可決定)

• rules/sdd-integration.md 加一節 "Vagueness as a routing signal",定義 V1/V3/V4 子類 + heuristic + 例子
• idd-diagnose SKILL.md 加 Step 3.4(Vagueness Pre-check)在 Step 3.5 之前
• Step 3.4 的 AskUserQuestion 3 選項實作(clarify / proceed / escalate)
• Diagnosis Report 新增 ### Vagueness 區段(triggered signals + 使用者選擇 + audit trail)
• MANIFESTO.md 補「alignment axis」段落,把 vagueness 放進五軸框架

待 spectra-discuss 對齊(open questions)

• Approach A vs B vs C — 上方三種的選擇影響 plugin surface(要不要加 idd-clarify skill?)
• Heuristic 怎麼定 — 中文 hedge 詞清單?要不要 multi-language regex?要不要用 LLM judge 而非 keyword?
• 與 Layer 1 disqualifier 的互動 — 「abstract 重寫但風格沒講」應該維持 Simple(Layer 1 命中)還是 escalate Plan?(原 issue 提案是後者,但會破壞 Layer 1 的 "fluid narrative is dead weight to Plan" 立論)
• Backward compat — 既有 issue 不需重判,但 --ignore-vagueness flag 要不要加?
• 與 IC_R011 sister sweep 的關係 — V3(vague scope)跟 sister sweep 表面像,但 V3 是「主軸範圍模糊」,sister sweep 是「主軸清楚 + 周邊有 sibling」 — spec 要明確界定
• AI 自評 vagueness 的可靠性 — heuristic 命中後 AI 把問題 surface 給 user 確認,這個 AI judge step 本身可能 false positive(每個 issue 都被當成 vague)→ 需要明確 anti-pattern

Complexity

Spectra

Layer 2 命中:rules/sdd-integration.md 是 published spec,被 idd-diagnose / idd-all / idd-implement / idd-route / MANIFESTO 多處消費。改 4 層 gate 結構就是改對外 contract。

Layer 3 命中(三項全中):

• ✅ Modifies normative behavior of existing published spec(4 層 gate 是 SHALL routing logic)
• ✅ Affects 2+ existing specs(sdd-integration.md + idd-diagnose/SKILL.md Step 3.5 + idd-implement Step 2.5 parser + idd-all Phase 3 + MANIFESTO.md)
• ✅ Architectural decision with long-term maintenance implications(4 層 gate 已穩定多版,加第 5 層是結構性決定;後續 maintainer 都要學新邏輯)

為何不是 Plan:Plan 是「明確改動 + 內部複雜度」,但這個 issue 的 design space 還有 fork(Approach A/B/C),Heuristic 還沒定,跨多個 spec consumer。直接走 Plan 會在 EnterPlanMode 才發現「啊原來方向選錯」,用 spectra-discuss 把 Approach A/B/C + heuristic shape 對齊後才寫 proposal 比較省。

為何不能 opt-out 直接 spectra-propose:open questions 一堆(上面 6 條),不滿足 Step 4 opt-out 的「zero open questions」條件。

Risks

• Heuristic miscalibration — 太敏感:每個中文 issue 含「順便」「之類的」都被升級 → 噪音;太鬆:V1/V3/V4 仍漏網 → 沒解到問題
• 跨語言 — 中文 hedge marker(「感覺」「好像」「之類」「順便」)≠ 英文(somehow / kinda / something like / also could)— heuristic 要 bilingual
• AI judge 漂移 — 若用 LLM 自評 vagueness,不同 model / context 判定不一致 → routing 不穩定
• 過度設計 — 若 Approach B(新 idd-clarify skill)被選,plugin surface 從 6 → 7 個 skill,認知負擔上升
• 與既有 IC_R011 / sister sweep 邊界模糊 — V3(vague scope)跟 sibling concerns 表面相似,user 可能搞不清何時該用哪個
• Backward compat — 既有 diagnosis comment 大量 Simple verdict 沒做 vagueness check,新邏輯不該追溯重判,但 idd-list / idd-report 等列表要不要把舊 verdict 標記「pre-Vagueness-Layer」?

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

none surfaced

[kiki830621]

Spectra change linked

This issue's design + implementation has been captured as Spectra change add-vagueness-layer-routing in this repo.

Artifacts:

• proposal.md — Why / What Changes / Capabilities / Impact
• design.md — D1–D6 decisions (Approach C / Likert 6-point / Hybrid 3-option / 5-layer order / meta-rule placement / 6-axis MANIFESTO) + R1–R6 risks
• specs/routing-vagueness-layer/spec.md — 9 normative requirements with scenarios + example tables
• tasks.md — 34 tasks across 9 groups (all complete)

Implementation summary (v2.50.0):

• ✅ NEW idd-diagnose Step 3.4 Vagueness Pre-check (Layer V) between Layer 1 and Layer 2
• ✅ NEW .claude/rules/attribute-assessment.md codifying meta-principle "attribute scoring SHALL use Likert, not keyword" + V1/V4 6-point anchors
• ✅ NEW CLAUDE.md @.claude/rules/attribute-assessment.md import (session-wide)
• ✅ Updated rules/sdd-integration.md with Layer V section + 5-layer order + retrospective dry-run table
• ✅ Updated idd-implement Step 2.5 + idd-all Phase 3 parsers to strip via X suffix
• ✅ Updated idd-all unattended mode to auto-apply proceed anyway + audit trail
• ✅ MANIFESTO 5-axis → 6-axis (Alignment quality, evidence = Layer V)
• ✅ plugin.json version 2.50.0 + CHANGELOG entry

Dry-run result: 5 sample closed issues (#7-#11) all V≤3, none triggered Layer V. Expected — these are verify-derived issues with inherent high clarity. Layer V is designed for fresh user-opened issues in quadrant A (small + vague), which don't appear in this repo's history.

Issue stays open until spectra-archive add-vagueness-layer-routing runs and /idd-close #12 confirms closure.

[kiki830621]

Implementation Complete

Spectra change add-vagueness-layer-routing archived to openspec/changes/archive/2026-05-04-add-vagueness-layer-routing/. New main spec at openspec/specs/routing-vagueness-layer/spec.md.

Checklist

Necessary items (Strategy from Diagnosis):

• rules/sdd-integration.md 加 "Layer V: Vagueness Pre-check" 段落 + 5 層 evaluation order + retrospective dry-run table — Spectra change tasks 2.1-2.4
• idd-diagnose SKILL.md 加 Step 3.4 在 Step 3.5 之前 — Spectra change task 3.1
• Step 3.4 Hybrid 3-option AskUserQuestion (clarify / proceed / escalate) 實作 — Spectra change task 3.5
• Diagnosis Report 加 ### Vagueness Pre-check 區段 (V1/V4 score + reasoning + user choice + 結果, trigger / 不 trigger 都寫) — Spectra change task 3.9
• MANIFESTO.md 5-axis → 6-axis,新增 Alignment quality 軸,evidence = Layer V — Spectra change tasks 6.1-6.2

Resolved open questions (via spectra-discuss):

• Approach A vs B vs C — 選 C (Step 3.4 in idd-diagnose,不新增獨立 skill,維持 6-skill plugin surface)
• Heuristic 設計 — Likert 6-point per-axis (V1, V4),無中位,trigger ≥ 4;不用 keyword matching;anchors 在 .claude/rules/attribute-assessment.md
• Layer 1 disqualifier 互動 — Layer 1 命中仍最優先 (narrative / ad-hoc 強制 Simple,vagueness 不推翻);Layer V 在 Layer 1 之後
• Backward compat / --ignore-vagueness flag — 既有 verdict 不回溯重判;不加 flag (option B proceed anyway 已涵蓋)
• 與 IC_R011 sister sweep 邊界 — V3 (vague scope) 推到 sister sweep (idd-diagnose Step 3.6),Layer V 只處理 V1 + V4;在 attribute-assessment.md 內明確註明
• AI 自評 vagueness 可靠性 — 機制是 audit trail (V1/V4 score + reasoning 顯化在 Diagnosis comment 給 user 校準) + retrospective dry-run (5 個 closed issue 跑分驗證 anchors 不 inflation)

Bonus items implemented during apply (not in original Strategy but discovered during work):

• NEW .claude/rules/attribute-assessment.md meta-rule — codify「屬性評分用 Likert,不用 keyword」(scope > Layer V,適用未來 attribute scoring)
• Root CLAUDE.md 加 @.claude/rules/attribute-assessment.md import (session-wide enforcement)
• idd-implement Step 2.5 + idd-all Phase 3 routing parsers strip via X suffix (Plan via Layer V → canonical Plan)
• idd-all unattended mode Layer V handling (auto-apply proceed anyway + audit trail [Layer V: ... clarify-default skipped under unattended mode])
• plugin.json version bump 2.49.0 → 2.50.0 + CHANGELOG v2.50.0 entry

All 34 Spectra tasks complete. Spec file openspec/specs/routing-vagueness-layer/spec.md (9 normative requirements) is the frozen contract.

[kiki830621]

Closing Summary

Problem

idd-diagnose 的 4 層 Complexity routing(rules/sdd-integration.md)只衡量「改動的形狀」(scope / API surface / risk),完全沒衡量「需求清晰度」。結果 quadrant A(scope 小 + 需求模糊,例:「menu 感覺怪怪的,改一下」)一律被判 Simple,AI 直接進 TDD loop → pattern-match 一個方向就動手 → 改完才發現「不是這個意思」。

spectra-discuss 已承認此失敗模式(「AI 常常高估 diagnosis 完整度」),但只在 Spectra path 內處理 — Simple path 完全沒有對應的 alignment gate。

Root Cause

設計 origin 把「routing decision」當成單一維度(scope/risk/contract shape),沒把「issue 本身的清晰度」當成一階信號。Layer P 的 "decision-heavy with multiple valid approaches" 看似相關,但前提是 diagnosis 已經列出 2+ 策略 — 對「issue body 本身就含糊到 diagnose 都做不下去」的情境完全沒覆蓋。

更深層原因:沒有 codify「屬性評分用 Likert,不用 keyword matching」的 meta-rule。第一直覺會想用 hedge 詞清單(「感覺」「之類」「somehow」)做 routing,但中文 hedge 詞 brittle 且文化差異大,deterministic match 在錯誤特徵上隱藏 false positive 比 honest AI judgment 更危險。

Solution

新增 Layer V (Vagueness Pre-check) 為 5 層 evaluation order 中第 2 層(Layer 1 disqualifier 之後、Layer 2 Spectra 之前):

Layer 1 (disqualifier) → Layer V (vagueness) → Layer 2+3 (Spectra) → Layer P (Plan) → Simple (default)

實作為 idd-diagnose Step 3.4:

1. AI 用 Likert 6-point per-axis 評分(無中位,trigger threshold per-axis ≥ 4):
   • V1 (vague WHAT) — 「要做什麼」清晰度
   • V4 (vague ACCEPTANCE) — 「完成定義」清晰度
   • V2 (vague HOW) 已被 Layer P 覆蓋,不重複
   • V3 (vague SCOPE) 由 IC_R011 sister sweep 處理,不重複
2. Hybrid 3-option AskUserQuestion 當 trigger 時跳:clarify now / proceed anyway / escalate to Plan,default 隨 max score 變(V=4 → proceed, V=5 → clarify, V=6 → escalate)
3. Audit trail PATCH 到 Diagnosis comment(trigger / 不 trigger 都寫,V1/V4 score + reasoning + user choice + 結果)
4. Routing parsers in idd-implement Step 2.5 + idd-all Phase 3 strip via X suffix,Plan via Layer V → canonical Plan(backward compat:bare verdicts 不變)

抽出 meta-principle 到獨立 rule .claude/rules/attribute-assessment.md:「屬性評分一律用 Likert 6-point per-axis,不用 keyword matching」。透過 root CLAUDE.md 的 @import 套用 session-wide,scope 超越 Layer V(未來任何 attribute scoring 都遵守同一條 rule)。

MANIFESTO.md 5-axis bug-fix model 擴成 6-axis,新增「Alignment quality」軸(TDD ❌ / SDD ❌ / IDD ✅,evidence = Layer V)。

Verification

• Spectra change add-vagueness-layer-routing 走完 propose → apply → archive 完整 lifecycle,34 個 task 全 done
• Main spec openspec/specs/routing-vagueness-layer/spec.md 含 9 個 normative requirement(SHALL/MUST,scenarios + example tables 完整)
• Retrospective dry-run 對 5 個 closed issue(idd-all Phase 5: PR body heredoc 改 quoted (預防未來 RCE) #7-[SOP] umbrella split flow should mandate commit log scan before filing sub-issues #11)跑 Likert scoring,全 V≤3 不 trigger Layer V — expected,因為 IDD-self-improvement issues 從 verify findings 派生 inherently 高清晰度。Layer V 設計目標是擋 fresh user-opened quadrant A issues,不是 verify-derived issues。anchors 不需 fine-tune
• JSON validity:plugin.json 通過 python3 -c "import json; json.load(...)"
• Spectra validation:spectra validate add-vagueness-layer-routing ✓ valid;spectra analyze 0 Critical / 0 Warning(2 Suggestion 已忽略)
• Spectra archive:成功移到 openspec/changes/archive/2026-05-04-add-vagueness-layer-routing/,新 spec 套到 main(0 added/modified/removed 因為已手動 sync)

Changes

Commit	Description
b2899e6	feat: Layer V Vagueness Pre-check for complexity routing (#12)

Files modified (15 files: 7 modified + 8 new):

• NEW .claude/rules/attribute-assessment.md — meta-rule for attribute scoring
• NEW CLAUDE.md — root project instructions + @.claude/rules/attribute-assessment.md import
• NEW openspec/specs/routing-vagueness-layer/spec.md — frozen contract (9 requirements)
• NEW openspec/changes/archive/2026-05-04-add-vagueness-layer-routing/ — proposal/design/specs/tasks artifacts
• MOD plugins/issue-driven-dev/rules/sdd-integration.md — Layer V section + 5-layer order + retrospective dry-run table
• MOD plugins/issue-driven-dev/skills/idd-diagnose/SKILL.md — Step 3.4 + 5-layer Step 3.5 + Step 0 TaskCreate
• MOD plugins/issue-driven-dev/skills/idd-implement/SKILL.md — Step 2.5 parser strips via X suffix
• MOD plugins/issue-driven-dev/skills/idd-all/SKILL.md — Phase 3 parser + unattended mode handling
• MOD plugins/issue-driven-dev/MANIFESTO.md — 5-axis → 6-axis (Alignment quality)
• MOD plugins/issue-driven-dev/.claude-plugin/plugin.json — version 2.49.0 → 2.50.0
• MOD plugins/issue-driven-dev/CHANGELOG.md — v2.50.0 entry

Backward compatibility

• Pre-v2.50 diagnoses 不回溯重判;既有 Simple / Plan / Spectra / SDD-warranted verdict 全部保留
• 不加 --ignore-vagueness flag(option B proceed anyway 已涵蓋)
• 其他 repo 安裝 plugin 後沒 .claude/rules/attribute-assessment.md,Step 3.4 fallback 用 plugin built-in anchors 並印 warning

Closing Follow-ups Filed (v2.45.0+ #527)

(none — no orphan mentions in closing summary; matched phrases 「之後」/「未來」 are positional/scope descriptors, not deferred work)