arthur0824hao/icd-operator

ICD Operator

description: ICD (Inter-Consciousness Decision) canonical operation guide. Use when creating, reviewing, answering, landing, archiving, or routing ICD / gate ICD / STANDING-ICD.

Canonical source: this skill is the ICD source of truth after Wren-185. note/ICD/README.md is a symlink back here. If this skill and any older memory/doc disagree, this skill wins until Arthur changes it through a new ICD.

ICD 文件流程

Workbench ICD tab 修好前，ICD 暫時走文件流程。

Arthur 2026-05-07 補充：任何需要 Arthur 介入、決策、批准、排序、GPD 提問/回覆的事項，都要進 note/ICD/ 這個 human-facing queue。不要只留在 .tkt/artifacts/、inbox、WPT stage 或終端輸出裡。

Schema (stage-subdir + folder-per-topic, Arthur 2026-05-08 directive)

ICD 跟 GPD 共用 schema：stage 是 subdirectory，topic 是 folder。Arthur 答完之後物理把整個 topic dir 從 queue/ 搬到 answer/unread/；agent 讀後搬到 processing/ 或直接 archive/；WPT 完成後從 processing/ 搬到 archive/。

note/ICD/
├── queue/                         # Wren/Aster 寫進；Arthur 看
│   └── <writer>-<id>-<short-title>/
│       ├── note.md                # 報告主檔（只放報告內容，不放答區）
│       └── answer.md              # Arthur 批改/決策用（Q&A + evidence + 選項 + reviewer/Aster review）
├── unread/                        # Arthur 答完搬整個 dir 進來
│   └── <topic-dir>/
├── processing/                    # agent claim 後搬整個 dir 進來
│   └── <topic-dir>/
└── archive/                       # WPT 完成搬整個 dir 進來；或無工作可做直接搬
    ├── <topic-dir>/
    └── (legacy flat .md 留作 audit trail，不強制 migrate)

<writer> = Wren / Aster 等；<id> 各自序列遞增（Wren-40, Aster-37 etc.）；<short-title> 短描述.

Stage 流程

| stage subdir | 觸發 | 動作者 | |---|---|---| | queue/ | ICD plant | Wren / Aster (writer) | | unread/ | Arthur 答完（inline checkbox / 補文字） | Arthur 物理搬 dir | | processing/ | agent claim 開始消化 | agent (主意識) | | archive/ | WPT 完成 OR 無工作可做（純 FYI / 拒收） | agent (主意識) |

Arthur-facing queue/ topic dir 只允許 note.md + answer.md。允許清單定義在 .bh/config/icd-lifecycle.yaml 的 format_lint.queue_allowed_files，不得在 hook 內硬編。status.md / claim.json / *review*.md 不可出現在 queue topic dir；狀態與 claim 走 WPT、memory、inbox receipt 或 lifecycle log。

unread/ 不是被動倉庫。WAG / Aster heartbeat 必須把 note/ICD/unread/ 當成主循環代謝入口，至少注入 path、count、owner/topic 摘要；Aster-owned unread topic 要被 claim 到 processing/ 或直接 archive/，Wren-owned unread topic 要用 WPT/inbox route 喚醒 Wren，不能只停在 status line 的 icd_unread 計數。

Myelin Loop Phase Gate（Wren-185 2026-05-19 land）

Arthur 是所有 myelin-loop phase transition 的 gatekeeper。Aster/Wren/子意識可以分析、建議、準備 evidence；但不得自行宣告 phase 結束或進入下一階段。

Arthur 2026-05-22 主線 gate 作者規則：主線 paper / model / experiment phase transition 的 gate ICD 預設由 Aster 親自撰寫。Wren、Finch、Lark、Corvus 可以準備 evidence pack、表格、圖、peer review、WPT 子任務，不能代寫最終給 Arthur 勾選的主線 review gate / prepare gate。只有 Arthur 明確針對某一份 gate 指定例外時，其他 cortex 才能寫該 gate；否則其他 cortex 的輸出必須回到 Aster，由 Aster 統整成 queue 內 note.md / answer.md。

Arthur 2026-05-22 重新定義 phase 節律：

adventure state -> review state -> review gate -> prepare state -> prepare gate -> adventure state

adventure state -> review state 沒有 gate。Adventure execution 完成後，agent 應直接進 review state，分析數據、檢討 clean/dirty evidence、解釋結果，並準備 review gate。Review gate 才是請 Arthur 決定下一方向與是否進 prepare state 的 gate。

需要 Arthur gate ICD 的 transition 包含：

• review -> prepare
• prepare -> adventure
• adventure/review/prepare -> close/archive
• 任何 paid resource、policy、scope、dataset surface、model family、paper-facing claim 的階段切換

正確語句：

• ready for Arthur gate
• Aster/Wren recommendation
• 等待 Arthur 在 gate ICD 勾選

禁止語句：

• 方向已決定（除非 Arthur 已在 gate ICD 勾選）
• 進入下一階段（除非 Arthur 已答完 gate ICD）
• 已 close state（除非 gate ICD 已答完且 close work 已 PAT）

Gate ICD 必備內容

Gate ICD 不是 FYI，也不是單題 yes/no。它必須讓 Arthur 與 agent 完全理解本 state 的成果、意義、風險與下一步，並對齊認知後再決定。

必備 section：

1. current state：現在在哪個 phase，為什麼進 gate。
2. adventure/result summary：本階段做了什麼，terminal 結果是什麼。
3. dataset contract：資料集、surface、split、label/eval universe，不可混用的邊界。
4. preprocess / data-flow：資料從 raw 到 payload 到 worker runtime 的路徑。
5. model/spec：模型、recipe、seed、metric、artifact contract。
6. execution / EP path：本機或 RunPod、EP registry、worker、artifact sync/close。
7. clean/dirty evidence：哪些結果可用、哪些 mismatch/missing/blocked。
8. interpretation：這些數據表示什麼，不表示什麼。
9. options：多個下一步方向，例如加資料集、改架構、改 loss、改實驗、送 GPD、停止/hold。每個 Q 必須有「其他/Other」選項；「其他」選項必須附說明欄位（- [ ] D. 其他：），不得只有空白 checkbox。 Arthur 選「其他」時會在 ： 後面直接寫理由。（Arthur 2026-05-21 Aster-95 directive）
10. recommendation：Aster/Wren 可推薦，但必須標成推薦。
11. explicit Arthur gate-pass Q：Arthur 是否同意 close 本 phase / 進下一 phase / 改 scope。
12. PAT / close evidence：已跑的檢查與下一階段 close condition。

Review State Gate

Review state 的目標是解釋 adventure 結果並請 Arthur 決定下一步方向。完整 review-state gate 必須包含：

• adventure 結果與圖表/數據；
• 數據分析與機制解釋；
• clean evidence、dirty evidence、blocked comparator；
• 可選下一步方向與每個方向的風險、成本、預期價值；
• Aster/Wren 推薦；
• Arthur 可勾選的下一方向問題。

如果 review 只總結結果，沒有問 Arthur 下一步方向，review state 尚未完成。

流程

0. Arthur 可先把想要 ICD 的議題寫進 note/ICD/agenda.md。
   • agenda.md 是 ICD intake buffer，不是正式 ICD。
   • Wren/Aster 讀取後先判斷：明確要 ICD、或 reviewer 判定需要 Arthur 決策，才建立 note/ICD/queue/<topic-dir>/ 正式 ICD。
   • FYI、sensor 噪音、或只需要 owner repair 的條目不可自動升 queue；應寫 memory/WPT/inbox 或 archive trail 後清除。
   • 建好 topic dir 或留下 durable handling receipt 後，必須清空或移除 agenda.md 中已處理的對應條目。
1. Aster/Wren 建 queue/<writer>-<id>-<short-title>/note.md + answer.md；其中主線 paper / model / experiment gate ICD 預設只能由 Aster 建，Wren 只能供 evidence / peer review / draft material。
   • 命名固定 <writer-agent>-<id>-<short-title>/，不可省 -<id>-.
   • note.md = 報告/分析（只讀），answer.md = Arthur 批改（可寫）。Arthur 答區不放 note.md。
   • answer.md 每個 Q 必須附 evidence（source code line / DB query / PAT 結果），讓 Arthur 不需自己查就能決策。
   • Arthur 2026-05-15 directive：Arthur 只看 note.md + answer.md。任何 Aster / reviewer review 若是給 Arthur 判斷用，必須直接寫進 answer.md 或 note.md；不得新增 aster-review.md / review.md 等旁支檔。
   • Arthur 2026-05-15 directive：Arthur 注意力最少、決策維度最高，ICD 品質直接影響系統效率。
2. Arthur 在 answer.md 內勾選 [x]、填 :: comment、或補文字 → 物理搬整個 dir 從 queue/ 到 unread/。
3. agent 讀 answer：
   • 有後續工作 → 搬到 processing/，做 Myelin Loop（memory + WPT + behavior + neural）。
   • 無後續工作（純 FYI / 拒收）→ 直接搬到 archive/。
4. WPT 完成後 → 從 processing/ 搬到 archive/。
5. source-stays sidecar deprecated for queue：Arthur-facing queue topic 不放 sidecar。claim / reviewer / archive trail 走 WPT、memory、inbox receipt、或 lifecycle log；archive 前採納/未採納 review 必須已反映在 answer.md 或 owner receipt。

Topic Ownership Boundary

Arthur 2026-05-09 / Aster-42 決議：

• ICD topic dir 採 writer-owned / target-owner lock。Aster-* 由 Aster claim / move / archive；Wren-* 由 Wren claim / move / archive。其他 cortex 預設 read-only。
• writer 目前只允許主意識層級（Aster / Wren）作為正式 ICD 作者；子意識如需 Arthur 決策，透過 WPT + inbox 要求主意識開 ICD。
• 主線 paper / model / experiment gate ICD 是額外限制：即使 Wren 是主意識，也不預設擁有主線 gate 作者權。Aster 是主線 gate final author；Wren 若有分析，交 evidence pack / WPT / inbox 給 Aster 統整。
• 跨 cortex 溝通預設走 WPT + inbox，不搬動對方 ICD topic dir。
• 若內容只面向另一個 agent，寫 inbox；若寫進 ICD，視為 Arthur-facing，Arthur 也會看到。
• 可在對方 ICD 追加 comment，但必須先 memory_store 並留下 memory id；這只用於刻意讓 Arthur 看到的補充，不作日常協調神經。
• emergency exception 是窄門：只有 Arthur 明確指示、owner 長時間死亡/不可用、或 block 變成 Aster sink 時，Aster 才可代管。代管必須先 memory_store，並寫 WPT/inbox receipt 給原 owner。
• WAG / Workbench 必須監測 topic prefix、WPT owner、inbox receipt 的不一致；不一致標成 BH lesion，並建立 WPT/inbox route 給正確 owner。

STANDING-ICD（Wren-86 2026-05-11 land）

STANDING-ICD 是正式 ICD kind，用於會長期累積決策的 recurring topic thread；它不是 paper-only，也可用於 system architecture、BH/EP/FD 長期設計、或其他可複用 meta-process。

命名與使用時機

• 命名固定：STANDING-<writer>-<id>-<topic-slug>-ICD。
• 使用 STANDING：主題會跨週/月累積多輪 Arthur 決策，或屬於長期寫作/架構/流程 contract。
• 使用 regular ICD：一次性 bug forensic、cycle-specific audit、1-2 輪即可關閉的決策。
• 每個 STANDING topic 必須有 completion criterion；沒有 exit condition 的長開 thread 是 BH-CNS lesion。

STANDING subtype（Aster-65 2026-05-16 land）

STANDING-ICD 不新增頂層類型；需要可索引的 state ledger 時，在 note.md frontmatter 區加 standing_subtype。

目前允許 subtype 定義在 .bh/config/icd-lifecycle.yaml：

• prepare-state-ledger：prepare / gate / readiness 期的 lesion ledger。
• adventure-state-ledger：execution / adventure 期的 lesion 與 anomaly ledger。

宣告 subtype 的 state ledger topic 必須只保留 note.md + answer.md，並在 note.md 內維持標準 ledger table： time / agent / surface / symptom / evidence / containment / split_target / state。 檢查神經：.bh/scripts/icd-standing-subtype-lint.py --json <topic-dir>。

.bh/docs/adventure-friction-log.md 只是 scratch/mirror，不是 canonical ICD ledger。Adventure / prepare state 的 source-of-truth 仍是 note/ICD/standing/ 內宣告 subtype 的 STANDING topic；F-items 必須連到 WPT、specific ICD、或 archive_no_action，否則只能由 BH.ICD.AdventureFrictionCanonicalize.Wren 這類可見 migration WPT 暫時承接。 檢查神經：.bh/scripts/adventure-friction-mirror-lint.py --json。

Lifecycle (Wren-124 hybrid + Wren queue-symlink standard 2026-05-13)

standing/STANDING-<writer>-<id>-<topic>-ICD/    # canonical home (real dir)
  ↓ recurring topic, never moved to queue/
processing/STANDING-<writer>-<id>-<topic>-ICD -> standing/...  # active working symlink
  ↓ future sections append to same note.md
queue/STANDING-<writer>-<id>-<topic>-ICD -> standing/...       # Arthur-visibility symlink (ONLY when has pending Arthur Q)
archive/decommissioned-standing/<topic>/  # only after topic decommissioned per STANDING Archive Policy

Standardized queue-symlink rule (per Arthur 2026-05-13T17:52Z directive 「需要 Arthur 答的舊 symlink 到 queue」):

• STANDING dirs live in standing/ (real dir, shared append only after durable memory_store)
• processing/ always has symlink → standing/ (active working pointer)
• queue/ symlink → standing/ ONLY added when STANDING has pending Arthur Q (即 unanswered checkbox)
• Arthur 答完所有 open Q 後 → active seat 移除 queue/ symlink (real STANDING stays in standing/)
• 真實 mv 不發生; symlink 只是 visibility shortcut, 不違 IR-icd-stage-subdir-owner-only

Same pattern for regular ICD with partial-answer follow-up (Wren-128 precedent 2026-05-13):

• ICD lives in processing/ per stage flow (queue→unread→processing)
• 若 Arthur partial-answered + 還有 open Q → add queue/ICDname symlink → processing/ICDname for re-visibility
• Owner agent removes queue/ symlink when all Q answered
• Avoids "bouncing back to queue" anti-pattern (which violates IR-icd-stage-subdir-owner-only)

Owner-write 規則

Arthur 2026-05-16 更新：STANDING 不再按 owner 或 agent 分裂。STANDING 是共享長期 ledger，所有主/子意識都可 append，但每次 append 前必須先 memory_store，entry 內要寫 source / evidence / split_target / state，避免無來源的意見污染長期 surface。

活躍 STANDING canonical set 固定四類，設定來源是 .bh/config/icd-lifecycle.yaml 的 format_lint.standing_canonical_topics：

• ep → STANDING-EP
• bh → STANDING-BH
• paper → STANDING-PAPER
• model → STANDING-MODEL

新增或重複的 EP/BH/Paper/Model STANDING 不應再建立新 topic；應 merge 到上述 canonical ledger。舊 standing dir 的完整原文移到 note/ICD/archive/standing-merged/，canonical note 保留 merge receipt、open item 摘要與 archive path。

活躍 STANDING 使用 note/ICD/standing/；note/ICD/processing/ 保留 symlink 作 active working pointer。queue/ 只在該 standing 有 pending Arthur Q 時建立 symlink。

Active STANDING Index

| topic | ledger access | path | processing link | status | last append | idle days | completion criterion | |---|---|---|---|---|---|---|---| | EP — RunPod / order / worker execution | shared | note/ICD/standing/STANDING-EP/note.md | note/ICD/processing/STANDING-EP (→ standing/) | standing | 2026-05-16 | 0 | EP 支援 durable order file/table，能從本機 preprocess → S3 sync → live GPU availability refresh → Aster paid gate launch → worker run → artifact sync-back → pod auto-close，並通過 fake-provider E2E 與一次 paid smoke。 | | BH — WAG/WPT/Workbench/ICD/runtime governance | shared | note/ICD/standing/STANDING-BH/note.md | note/ICD/processing/STANDING-BH (→ standing/) | standing | 2026-05-16 | 0 | BH 不再需要 permanent adventure-state ledger，或所有 open items 都已遷移到 successor standing ledger。 | | Paper — APSIPA writing / presentation / reviewer-safe framing | shared | note/ICD/standing/STANDING-PAPER/note.md | note/ICD/processing/STANDING-PAPER (→ standing/) | standing | 2026-05-16 | 0 | APSIPA 2026 paper 投稿完成（EDAS submit + Arthur approval），paper writing strategy / professor-presentation decisions 全部落地並通過 reviewer-safe audit。 | | Model — D6v3 / ESUN prepare and model-analysis ledger | shared | note/ICD/standing/STANDING-MODEL/note.md | note/ICD/processing/STANDING-MODEL (→ standing/) | standing | 2026-05-16 | 0 | D6v3 × ESUN prepare gate 通過或被 supersede；所有 prepare lesions 已分裂成 WPT、specific ICD、或 archive_no_action。 |

Index auto-maintained by BH.cron.standing-icd-index (Finch, per Wren-98 Q2). Manual edits get overwritten on next run.

STANDING Archive Policy (Wren-98 Q3 landed 2026-05-13)

STANDING-ICD 設計上是 recurring topic，預設不 archive。但當 topic 死亡時走以下 archive trigger：

• (a) Owner explicit decommission: STANDING owner 寫 inbox-write.sh <self> directive normal "decommission STANDING-<id>" OR 在 STANDING note.md 加 decommissioned: <ISO date> frontmatter。
• (b) 90-day no-append auto-warn: BH.cron.standing-icd-index 同時掃 mtime；超 90 day 無 append → emit antigen + inbox owner blocker normal「STANDING-<id> 90 day idle，confirm-or-extend」。owner 回 ack→延長 OR 確認 decommission。

Archived STANDING 走 note/ICD/archive/decommissioned-standing/ (跟 regular archive 分開)，保留 completion criterion + decommission rationale。Active STANDING 是 shared ledger；archive / append 前仍需 durable memory receipt。

Myelin Loop

• 夠清楚：寫回 memory、WPT、behavior、Neural Wiring Registry，必要時 action/dispatch；topic dir 從 processing/ 搬到 archive/。
• 不夠清楚：在 queue/ 建續問 ICD topic dir（v2 / v3）；舊 dir 在 archive/ 標 state=superseded。

Arthur intervention queue

• note/ICD/queue/ 是需要 Arthur 看、選、批准、補充的唯一主入口。
• 需要 Arthur operator approval 的 blocker 也要建成 ICD queue 檔；WPT stage 可以引用該 ICD，但不能取代它。
• agent 若只在 inbox/WPT 說 Arthur needed: yes，Aster 主循環要補一份正式 queue 檔。
• 可由 Aster 自行決定且已有協議的事項，不要污染 queue。

GPD

Arthur 2026-05-07 directive (Aster-25 answer)：GPD canonical 唯一路徑為 /datas/store162/arthur0824hao/Work/note/GPD/，不是 note/ICD/GPD/。note/ICD/GPD/ 是過時設計，不要再用。

GPD 跟 ICD 共用 stage-subdir + folder-per-topic schema (Arthur 2026-05-08 directive)：

note/GPD/
├── queue/<topic-dir>/         # 待送 GPT Pro 的 prompt
│   ├── prompt.md              # 送 GPT Pro Deep Research 用
│   ├── answer.md              # placeholder（pending）
│   └── status.md
├── unread/<topic-dir>/        # GPT Pro answer 回來，Arthur 貼到 answer.md 後搬整個 dir 進來
├── processing/<topic-dir>/    # agent (主或子意識) claim 消化中
└── archive/<topic-dir>/       # 消化完

.tkt/artifacts/gpt-pro/prompts/ Arthur 已 directive 停用；過去檔可保留作 raw artifact / compatibility 但不再是 Arthur-facing surface，亦不可被 Workbench/WAG 當作 pending truth。

Wren-CC 修 (2026-05-07)：本 section 原寫 note/ICD/GPD/ 路徑跟 Aster-25 Arthur answer 衝突 — 已對齊 canonical。 Wren 修 (2026-05-08T15:00Z)：對齊 stage-subdir + folder-per-topic schema。

填答格式

• ICD 是 Arthur-facing 文件，除 code identifiers、路徑、正式專名、paper title 外，一律用繁體中文。不要把標題、問題、選項、建議寫成英文句子。
• 每題用 checkbox 選項，Arthur 填答時把 [ ] 改成 [x]；允許多選。
• 每題最後一個選項固定是 Other:，Arthur 可直接補文字。
• Aster / Wren / 其他主意識的預設建議必須內嵌在每一題的選項文字中，例如 **B. ...（Aster 預設）**；不可集中放在文末，也不可只在題外寫一段「預設組合」。
• 每一題都必須至少有一個明確標記的預設選項；如果沒有預設，該題要明寫 本題無預設，需 Arthur 判斷。
• 若某題不想現在決定，勾 defer 或直接寫 defer。
• 作者不要只寫 Arthur answer: 空白框；要提供可勾選選項。
• 長篇審查意見應拆到各題的可勾選選項或題內說明；預設建議仍要在選項文字內標記，不要集中成一整塊結尾評論。
• 不要使用「候選：1」這種要 Arthur 自己對照上下文的格式；每個可選項都必須是可直接勾選的完整句子。
• 禁止在文末另列「Aster 預設組合」取代逐題標記；這會迫使 Arthur 來回對照，視為 ICD 格式 lesion。

Agenda intake

note/ICD/agenda.md 建議格式：

## 未處理議題

## topic title
Context:
- ...

Need ICD:
- ...

Wren/Aster 處理規則：

• 每個 agenda topic 先 review intent；只有明確 ICD 或主意識判定需要 Arthur 決策時，才轉成一個或多個 queue ICD。
• queue ICD 內要保留原始 context、決策問題、預設選項、PAT/close gate 問題。
• 已轉 queue 或已 durable 處理的 agenda 條目必須刪除；不夠清楚的條目保留，並在旁邊寫 needs-clarification。
• 若 agenda 本身是系統性 lesion，例如 BH-CNS / WAG / memory / EP 神經問題，Wren/Aster 先開 ICD，不直接實作。
• 若 agenda 是 FYI 或 WAG sensor candidate，Wren/Aster 可以拒收、轉 WPT/inbox、或 archive trail；不可因 private wake 自動生成 queue。

處理紀錄落點（Wren-41 2026-05-08 land）

• agenda.md 不留處理紀錄段 — Arthur directive: 「本文檔不應該有 ## 議題處理紀錄 這個應該放到 archive 或乾脆不用紀錄」
• 處理過程必落 memory_store（type=procedural / category=icd-workflow）
• 歷史 audit trail 寫入 note/ICD/archive/agenda-log-YYYY-MM.md（per-month rollup）
• 不需保留 audit trail 的條目（如 sensor 噪音拒收）也可只 memory_store 不寫 archive log

Wren 第一步永遠寫 ICD（2026-05-08 Arthur directive land）

• Wren 看到 Arthur 問題 / agenda 議題的第一動作 = 開 ICD（不是 inline pane 答覆）
• ICD 允許純 FYI 不需作答 — Wren 把調查結果 / 答案 / 計畫寫進 ICD，Arthur 自看不需勾選
• Wren 對 Arthur 的回報語式 = 「請 Arthur 看 ICD」 — 不再說「推薦下一步」/ 「你要我做 X 嗎」
• 詳見 memory16468 (procedural)

目前來源

• .tkt/sentinel-state/aster-icd-queue.tsv
• .tkt/sentinel-state/aster-icd-pages/*.md
• memory: 15696, 15698, 15796, 15848, 15865, 15870, 15878

Myelin Loop

• WPT：把決議變成可見、可分派、可審查的工作。
• behavior：外顯神經承諾，說明這條神經對 Arthur、agent、其他程式會如何表現。
• Neural Wiring Registry：內部實際神經接線表，記錄 owner、gates、sensors、pathways、runtime surfaces、close gates。
• 面向 Arthur 的 EP 溝通要以實驗名為主；row id 只放在括號或 evidence 欄。

ICD format canonical rules (Wren-57 ICD answer 2026-05-10, Arthur 直接 answer)

(Arthur 答 Wren-57: Q1=A 嚴格 inline + 「正則檢測 不符規範就打回重寫」, Q2=C mixed, Q3=B 1+3+5 must-have, Q4=A 全繁中, Q5=C discipline+hook 雙保險 + 「hook一個正則檢查腳本」, Q6=E 4-tier injection)

Wren strawman 必須 inline 每 Q

每個 Q section 結尾必須有一行：

**Wren strawman (Q1)**: <選項> — <短理由>

禁止獨立 ## Wren strawman section 堆檔尾。違反由 .bh/hooks/icd-format-lint.sh 檢測, 不符即 fail.

答區 (decision block) — Arthur 回應習慣適配 (2026-05-15 land)

Arthur 實際回應方式：在選項列的 [ ] 改成 [x]，或在「其他」選項裡寫自由文字。因此：

• 不再使用 → **答區 Qx**: ☐ A / ☐ B / ☐ C 格式 — Arthur 不用這行，直接在選項列勾選
• 選項列統一用 - [ ] A — ... 格式（Arthur 用 [x] 勾選）
• 「其他」選項固定為 - [ ] 其他 — 後面留空讓 Arthur 寫

禁止問 Arthur self-check 型問題 (2026-05-15 Arthur feedback)

Arthur verbatim：「有沒有遺漏不是Arthur應該檢查的」。以下類型的 Q 不得出現在 answer.md：

• 「本報告是否有遺漏？」
• 「本報告是否完整？」
• 「是否有其他組件沒覆蓋到？」

這類 self-check 是 agent 自己的責任，不消耗 Arthur 注意力。

Arthur 反問 = evidence 不足

Arthur 不選選項而是反問（如「decisions.md 被誰在什麼情況下用?」）= agent 的 evidence 不夠充分。answer.md 的背景描述必須預先回答 Arthur 可能的「為什麼」和「誰在用」，否則 Arthur 無法決策。

answer.md Q-block schema (2026-05-15 Arthur directive)

answer.md 是多個 Q section 的結構化決策面。每個 Q 由多個 block 組成：

### Q1: <問題>

**背景:** ...                 # optional block
**Evidence (Q1):** ...          # optional block; use labels allowed by .bh/config/icd-lifecycle.yaml

- [ ] A — ...                 # required options block
- [ ] B — ...
- [ ] 其他 —

**Wren strawman (Q1):** ...    # optional suggestion block
**Aster review (Q1):** ...     # optional review block

Required block:

• options：每題必須有 checkbox options；目前 config 要求每題至少 2 個 - [ ] / - [x] option line，且包含 Other 或 其他。

Optional blocks:

• source / evidence / background：Source、來源、Evidence、證據、背景 等。若要同時寫 source + evidence，使用 Evidence (Qn)；不要寫未在 config 中允許的 Source / Evidence label。
• suggestion：Wren strawman、建議、推薦、Suggestion 等。
• review：Aster review、Reviewer review、審查 等。

Block 名稱、Q heading pattern、option pattern、Other option pattern、禁止的 top-level review heading 全部由 .bh/config/icd-lifecycle.yaml 的 format_lint 定義；hook 只讀 config，不硬編 schema。

Reviewer / Aster review 必須直接寫進 note.md / answer.md (2026-05-15 Arthur directive)

Arthur-facing review 不可存在 aster-review.md、review.md、inbox、終端、或 WPT stage。

Rule:

• note.md 仍只放報告/分析，不放答區。
• answer.md 是唯一 Arthur-facing 決策與 review surface。
• reviewer / Aster 補充若是決策建議，必須直接加到對應 Q section 內，例如 **Aster review (Q1):** ...，放在該題 Wren strawman 後或選項前後最容易閱讀的位置。
• reviewer / Aster 補充若是背景、evidence、或數據更正，直接加到 note.md 對應段落。
• 不得在 answer.md 檔尾集中新增 ## Aster review / ## Reviewer review / ## 審查。Arthur 讀每題時必須就地看到該題 review。
• queue/ topic dir 的檔案允許清單由 .bh/config/icd-lifecycle.yaml 控制；目前只允許 note.md 與 answer.md。

Reason: Arthur 明確說只看 note.md 和 answer.md；review 放旁支檔會造成假完成。

Must-have sections (1+3+5)

• 1. front-matter (writer / created / parent / type)
• 3. Q1...QN（每 Q 遵守 Q-block schema：必填 options，可選 source/suggestion/review；不要另加答區行）
• 5. Memory pointers
• (Background / 證據 / 數據 / review 可選，但若要給 Arthur 看，必須在相關 Q section 就地出現)
• 每個 Q 的背景或 source 應預先回答：這東西誰在用？什麼場景觸發？不改會怎樣？改了影響誰？

全繁體中文 default

保留 code identifier / file path / variable / log 原文; reviewer 引用原文 ok. 純 Wren/Aster 對 Arthur 說的話必繁中.

Enforcement (hook + discipline 雙保險)

• hook: .bh/hooks/icd-format-lint.sh <icd-md-path> — 寫到 note/ICD/queue/Wren-* 或 Aster-* 觸發, fail 即 block plant
• discipline: 寫 ICD 前 self-check Q-strawman-答區 三者數量一致 + 全繁中

4-tier injection (per Q6=E)

規範同步寫進:

• (A) 本 README.md (you are here)
• (B) plugins/bh-cns/skills/skill-system-bh-cns/registry/behavior/icd.behavior.yaml operation icd-format-arthur-facing
• (C) .tkt/personalities/wren-tick-discipline.md G-pattern
• (D) auto-memory feedback_wren_view_inline_per_q.md 升級 IR/CS layer

ICD archive 規則 — 不落實不 archive (Wren-63 Q1 其它 Arthur 答 2026-05-10T16:30+08)

Arthur verbatim: 「既然沒落實為什麼會被移到 archive? 就讓他呆在 processing」

Rule: ICD answer 後若含 actionable design (即使 strawman / framing / FYI 只要含具體 plant-able item), 必先 plant 對應 WPT 給 owner cortex 才 archive. 否則 stay note/ICD/processing/ 直到 actionable WPT 也 land.

Anti-pattern (memory16832/16874):

• Wren-40 RunPod-prebake-netdisk-fast-start ICD archive 但 prebake 沒 plant 實作 WPT → Lark 半年後仍踩 prebake 8min waste
• Wren-G06 GPT Pro answer 含 architecture fix + 5 references + experiment plan, archive 後 sub-WPTs (Implement / Scout / Backup / Paper Integrate) 才慢慢 plant — 應該 archive 前一次 plant 全部

Implement:

• ICD owner archive 前 self-check: Q answer / strawman / FYI 內所有 actionable item 都 plant WPT (給 owner cortex) 了嗎?
• 若否, 留 processing
• Wren-57 ICD format hook lint 加 archive-time gate: ICD note.md + status.md 須含 landed_wpts: [WPT.id, ...] 列表, count >= actionable item count, 否則 archive 不通過

Cross-ref:

• Wren-61 Q1=A+C+D BH 神經誤操作 root cause — 此規則修 D 維度 (self-check 缺失)
• Wren-63 Q3=F 立刻 land EP optimization

---

name: skill-system-review description: "Bridge between OMO Prometheus and TKT ticket lifecycle. Generates structured review context for Prometheus after bundle close, converts Prometheus plans into TKT bundle commands, writes review feedback into the Review Agent Inbox, and provides a structured question protocol for gathering information efficiently. Load this skill when you need to: (1) generate a review prompt for a completed ticket/bundle, (2) convert a Prometheus plan.md into TKT worker tickets, (3) write review feedback back into the ticket system, (4) ask structured questions using the question tool across all scenarios (requirements, decisions, review, planning)." license: MIT metadata: os: windows, linux, macos version: "1.0.0"

skill-system-review

Bridge between OMO Prometheus and the TKT ticket lifecycle.

Two directions:

1. Review — After bundle closes, assemble structured review context for Prometheus to evaluate
2. Plan→TKT — Convert Prometheus plans into TKT roadmap bundles and worker tickets

Operations

generate-review-prompt

Generate a structured review context from a completed/active ticket for Prometheus review.

python3 "<this-skill-dir>/scripts/review_prompt.py" generate-review-prompt --ticket-id <TKT-XXX>

Input: --ticket-id (required) — the ticket to build review context for Output: JSON with review_context, prometheus_prompt, expected_output_format

Reads:

• Bundle review.yaml (stub generated by tkt.sh close)
• All completed ticket results in the bundle
• Audit ticket (TKT-A00) findings
• Current roadmap.yaml state

generate-startup-review-prompt

Generate a review overview prompt for Prometheus at session startup (no active ticket context).

python3 "<this-skill-dir>/scripts/review_prompt.py" generate-startup-review-prompt

Output: JSON with roadmap_summary, bundles, prometheus_prompt

generate-startup-review

Generate a compact startup context summary for the next session.

python3 "<this-skill-dir>/scripts/review_prompt.py" generate-startup-review

Output: JSON with context_summary, roadmap_summary, bundles

• includes carryover_bundles[] when reviewed bundles still have carryover work

suggest-roadmap-update

Suggest roadmap changes from findings/issues without mutating roadmap.yaml.

python3 "<this-skill-dir>/scripts/review_prompt.py" suggest-roadmap-update --input findings.json

Output: JSON suggestions[] with {phase, section, change_type, description, rationale}

plan-to-bundle

Convert a Prometheus plan file (.sisyphus/drafts/*.md) into TKT bundle creation commands.

python3 "<this-skill-dir>/scripts/review_prompt.py" plan-to-bundle --plan-file <path>

Input: --plan-file (required) — path to Prometheus plan markdown Output: JSON with route, goal, tickets[], tkt_commands[] (ready-to-execute shell commands)

Parsing rules:

• ## or ### headings with TODO/task keywords → ticket titles
• - [ ] checkboxes → individual worker tickets
• Dependency markers (depends on, after, blocks) → depends_on fields
• Effort estimates → ticket description metadata
• Categories (visual-engineering, deep, quick, etc.) → ticket category
• ### WAVE N headings → ticket wave metadata for following tasks
• Structured ticket metadata lines (category, effort, acceptance, source metadata, skills, QA scenarios) → preserved into ticket objects and generated TKT commands
• Tiny plans can route to express without filename mentions when they stay within the no-dependency, no-effort fast path

write-review-inbox

Write Prometheus review feedback into the Review Agent Inbox format for refresh_review_inbox() ingestion.

python3 "<this-skill-dir>/scripts/review_prompt.py" write-review-inbox --input <json-file>

Input: JSON file with discussion_points[], next_actions[], batch_id Output: Appends ## Review Agent Inbox + # TICKET_BATCH section to note/note_tasks.md

generate-dispatch

Generate a worker dispatch view from bundle ticket state.

python3 "<this-skill-dir>/scripts/review_prompt.py" generate-dispatch --bundle B-001 [--tickets TKT-001,TKT-002]
python3 "<this-skill-dir>/scripts/review_prompt.py" generate-dispatch --auto

Input: --bundle (required), optional --tickets comma list Output: human-readable wave summary plus last-line JSON containing grouped dispatch waves

Rules:

• without --tickets, emit currently open worker tickets only
• preserve bundle dependency order into dispatch_wave
• include one-line summary and effort estimate for each ticket
• --auto creates the suggested next bundle from suggest-next-bundle and immediately emits dispatch for it

suggest-next-bundle

Suggest the next bundle goal and seed tickets from roadmap/open work/carryover.

python3 "<this-skill-dir>/scripts/review_prompt.py" suggest-next-bundle

Output: JSON with goal, suggested_tickets[], open_issues[]

Integration with OMO Prometheus

Prometheus as Review Agent

When a TKT bundle closes:

1. tkt.sh close generates review.yaml stub
2. PM Agent calls generate-review-prompt to assemble review context
3. Prometheus receives the structured context and produces:
   • summary — what was accomplished
   • discussion_points[] — trade-offs, concerns, questions for user
   • next_actions[] — follow-up work items
   • quality_assessment — structured quality evaluation
4. write-review-inbox converts Prometheus output into TKT-ingestible tickets
5. refresh_review_inbox() picks up new tickets automatically

Prometheus as Roadmap Planner

When a user makes a new request through Prometheus:

1. Prometheus conducts structured interview (OMO default behavior)
2. Prometheus writes plan to .sisyphus/drafts/
3. plan-to-bundle reads the plan and generates TKT commands
4. PM Agent executes the commands to create roadmap goal + bundle + worker tickets
5. OMO dispatches agents to claim and execute tickets

Prompt Reference

• prompts/prometheus-tkt-integration.md — Instructions for Prometheus on how to use TKT roadmap/bundle system
• prompts/question-protocol.md — Structured questioning guide for all scenarios (requirements, branch decisions, review discussion, roadmap planning). Implements the question_tool_first policy from config/tkt.yaml.

Compatibility

• tickets.py alignment: review_prompt.py path matches the hardcoded reference at tickets.py:2468-2470
• Review Inbox format: Output matches parse_review_agent_inbox() expected format (## Review Agent Inbox + # TICKET_BATCH)
• Scope rules: Referenced in 14+ ticket scope allowed_prefixes entries in tickets.py

{
  "schema_version": "2.0",
  "id": "skill-system-review",
  "version": "1.0.0",
  "capabilities": [
    "review-generate",
    "review-startup",
    "review-startup-summary",
    "review-roadmap-suggestion",
    "review-plan-to-bundle",
    "review-generate-dispatch",
    "review-suggest-next-bundle",
    "review-write-inbox"
  ],
  "effects": ["fs.read", "fs.write"],
  "operations": {
    "generate-review-prompt": {
      "description": "Assemble structured review context from completed ticket/bundle for Prometheus",
      "input": { "ticket_id": { "type": "string", "required": true } },
      "output": { "description": "Review context JSON", "fields": { "review_context": "object", "prometheus_prompt": "string" } },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "generate-review-prompt", "--ticket-id", "{ticket_id}"]
      }
    },
    "generate-startup-review-prompt": {
      "description": "Generate Prometheus review overview at session startup",
      "input": {},
      "output": { "description": "Startup review context JSON", "fields": { "roadmap_summary": "object", "bundles": "array", "prometheus_prompt": "string" } },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "generate-startup-review-prompt"]
      }
    },
    "generate-startup-review": {
      "description": "Generate compact startup context summary from roadmap and recent bundle reviews",
      "input": {},
      "output": { "description": "Startup summary JSON", "fields": { "context_summary": "string", "roadmap_summary": "object", "bundles": "array" } },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "generate-startup-review"]
      }
    },
    "suggest-roadmap-update": {
      "description": "Suggest roadmap updates from findings/issues without mutating roadmap.yaml",
      "input": {
        "input": { "type": "string", "required": false }
      },
      "output": {
        "description": "Roadmap suggestion payload",
        "fields": { "suggestions": "array" }
      },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "suggest-roadmap-update"]
      }
    },
    "plan-to-bundle": {
      "description": "Convert Prometheus plan markdown into TKT bundle or express creation commands with metadata preservation",
      "input": { "plan_file": { "type": "string", "required": true } },
      "output": { "description": "Bundle or express creation commands", "fields": { "route": "string", "goal": "string", "tickets": "array", "tkt_commands": "array" } },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "plan-to-bundle", "--plan-file", "{plan_file}"]
      }
    },
    "generate-dispatch": {
      "description": "Generate a human-readable + JSON dispatch prompt from bundle ticket state",
      "input": {
        "bundle": { "type": "string", "required": false },
        "tickets": { "type": "string", "required": false },
        "auto": { "type": "boolean", "required": false }
      },
      "output": {
        "description": "Dispatch payload grouped by waves",
        "fields": { "bundle": "string", "tickets": "array", "waves": "array" }
      },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "generate-dispatch", "--bundle", "{bundle}"]
      }
    },
    "suggest-next-bundle": {
      "description": "Suggest the next bundle goal and seed tickets from roadmap/open work/carryover",
      "input": {},
      "output": {
        "description": "Suggested next bundle payload",
        "fields": { "goal": "string", "suggested_tickets": "array", "open_issues": "array" }
      },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "suggest-next-bundle"]
      }
    },
    "write-review-inbox": {
      "description": "Write Prometheus review feedback into Review Agent Inbox for ticket ingestion",
      "input": { "input_file": { "type": "string", "required": true } },
      "output": { "description": "Inbox write confirmation", "fields": { "inbox_path": "string", "tickets_written": "integer" } },
      "entrypoints": {
        "unix": ["python3", "{skill_dir}/scripts/review_prompt.py", "write-review-inbox", "--input", "{input_file}"]
      }
    }
  },
  "stdout_contract": {
    "last_line_json": true
  }
}