report

name	report
description	報告書・完了報告を出力する際に発火する。インターロック検証欄を含む報告書を生成する

報告書出力スキル

発火条件

作業完了時・中断時・人間から「報告して」と言われたとき。

報告書の出力先

設計 AI 向け報告書を MD ファイルで出力する。 会話内テキストでの報告は「報告書の出力」に該当しない。

dev log + 正報告書 二段構成:

• 上位文書リポ配下: 正報告書 (judgment 中心、設計判断・反芻・提案)。読者は設計 AI / ユーザー
• 作業リポ配下: dev log (fact 中心、差分・commit 単位)。読者は次セッション CC / 保守者
• 判定迷う場合は両方記載で良い (相互ナビゲーションで整合維持)

図プラン（執筆前・必須）

本文を書き始める前に diagram-craft skill を発火し、図トリガー表で使う図を決め、frontmatter に宣言する:

figures: [da-table, where-map]   # 図種: da-table / where-map / flow / state / arch-svg
# 図を使わない場合（省略理由の明文化義務）:
figures: none
figures_reason: <理由 1 行>

• 黙って図なしは禁止。宣言した図種は本文に実体が必要（--lint が宣言-実体一致を機械検査）
• 読者が最初に見る認知負荷低減の 4 点核: 要判断一覧パネル / 現在地図 (where-map) / DA 表バー / スコープ外台帳。報告書の判断材料はこの 4 点に構造化することを最優先する

本報告書の読者と目的

報告書冒頭 (frontmatter 直後) に以下のセクションを 必ず明示 する:

## 本報告書の読者と目的

- **誰が読む**: <主読者、複数なら優先順>
- **何のために**: <読者が本文書から得るべき情報、なぜ読むべきか>
- **次のアクション**: <読者に期待する次のアクション、読み終わったら何をすべきか>

加えて frontmatter に以下を試行記載 (機械可読、オプション):

audience: [<FILL: 主読者ロールを指定>]  # 例: design-ai, human-user, cc-next, cc-self, public
purpose: <FILL: 1 文で要約>
expected_action: <FILL: 1 文で要約>

「該当なし」で省略禁止。読者が不明確なら設計を見直せ。

結論の概要（必須・読者と目的の直後）

報告書は 読者と目的 → 結論の概要 → （要判断一覧/目次＝レンダラ自動）→ 詳細 の順。読者が結論と「良し悪しの方向」を先頭で掴めるよう、読者と目的の直後に必ず置く（md-render が自動 hoist する）:

## 結論の概要

- **OK** — <結論（検証 PASS の実測あり）>
- **CAVEAT** — <結論（動くが条件付き・残課題）>
- **FAIL** — <結論（実測で破綻・未解決）>
- **INFO** — <結論（中立・対象外）>

• 中身: 1〜5 行の outcome（読者が今 何を信じ/すべきか）。読者と目的の言い換え・決定リストの複製・冗長化を禁止（第 2 の目次にしない）。
• 状態バッジ: 先頭 **OK/FAIL/CAVEAT/INFO** を md-render が色付きピルに変換（OK=teal / FAIL=red / CAVEAT=amber / INFO=slate）。集合に完全一致する太字のみ変換（**OK:**・**OK …** は非変換）。
• ★根拠なきバッジ禁止（誠実基準・最重要）: 各バッジは根拠を併記する。OK＝検証 PASS の実測がある／FAIL＝実測で破綻・未解決／CAVEAT＝動くが条件付き・残課題／INFO＝中立・対象外。根拠なき "OK" を禁止（報告書が "良く見せる" 方向へドリフトする歯止め）。混在時は主たる成果/リスクを映す（中核が失敗なら一部動作でも FAIL。FAIL→CAVEAT 格下げ等のアンチゲーミング禁止）。
• 要判断一覧・目次は手書きしない: 要判断一覧は本文の > [!DECISION] から、目次は見出しから レンダラが自動生成。著者が書くのは 読者と目的・結論の概要・[!DECISION]・詳細・スコープ外(Pending)。結論がアクションを要するなら該当を [!DECISION] へミラーする（結論の概要＝方向／[!DECISION]＝決定・アクション）。
• 免除: 純記述メモ/議事録/参照等は frontmatter conclusion_summary: none ＋ conclusion_summary_reason: <理由> で免除（figures: none と同型・--lint が確認）。

インターロック検証欄（必須）

報告書に以下のチェックリストを含めること:

## インターロック検証
- rumination: 発火した / 発火していない（理由: ）
- testable-impl: 発火した / 発火していない（理由: ）
- investigation: 発火した / 発火していない（理由: ）
- diagram-craft: 発火した / 発火していない（理由: ）
- md2html --lint: exit 0 / 未実行（理由: ）
- md2html --check: 実行済 / 対象外（理由: _index.md 非更新 等）

「発火していない」に正当な理由がなければ、報告を中止して該当 skill を発火し直すこと。

知見蓄積提案（必須検討）

報告書に以下を含めること。候補を検討した上で不要なら理由を書け。「該当なし」で省略することを禁止する。

## ローカル知見提案
- 候補: （rules/ や skills/ に格納すべき知見はないか）
- 判断: 採用 / 不要（理由: ）

使用構文（8 種に閉じる）

報告書 MD は決定論レンダラ（md-render）の対応構文 8 種のみで書く。 italic・取り消し線・画像・脚注・生 HTML タグは使用しない（使用してもリテラル表示に退化するだけで内容は失われない）。

#	構文	用途
1	YAML frontmatter（scalar + インラインリスト）	doc_id / revision / audience / where / status / figures
2	見出し H1〜H4	文書題 / §N / サブセクション
3	GFM 表	DA 表 / Pending 台帳 / 比較表
4	フェンスコード（info 付き。mermaid / svg は特別扱い）	コード引用 / 図ソース。SVG はレンダラが base64 data URI の img に変換（script 無害化）
5	blockquote + [!DECISION] [!DA] admonition	判断マーカー
6	箇条書き / 番号リスト（ネスト 2 段まで）	列挙
7	水平線 ---	区切り
8	インライン: code span / bold / link	強調・参照

任意のタブ（frontmatter tabs: by-h2）

長い状況報告では frontmatter に tabs: by-h2 を宣言すると、本文のトップレベル H2 セクション群をタブで表示できる（決定論レンダラ拡張・新構文ではない）。該当 H2 が 2 件以上ある時に使う（例: 目的 / 経緯 / 現状 / 次 / 残課題）。読者と目的 / 要判断一覧 / TOC / Pending パネルと lead はタブの外に残り、JS 無効でも全節が読める（fail-soft）。ラベルは H2 見出しテキスト — 番号付きタブにしたいなら見出しに番号を付ける。詳細と CSP 注記は md-render skill 参照。

コメント & 返信プロンプト（報告書は既定 on）

レンダリングする全報告書に、既定で各本文 H2 直下のトピック別コメント欄とワンクリック返信プロンプト生成が付く（ユーザーが読みながらコメント → 生成 → コピー → レビュー担当 / CC へ）。要件・注意:

• frontmatter に安定 report_id（か doc_id）を入れる — コメントはこれをキーに読者の localStorage に保存（MD/HTML に書き戻さない）。安定 id が無いとコメント無効。
• 本文 H2 の見出しは一意にする（同一見出しは sha1 アンカーを共有しコメントが合流。--lint が警告）。
• comments: off で抑止（dev log・非対話文書など）。
• レンダラが作るのは返信プロンプト（固定整形・LLM 不使用）+ コピーボタンまで。返信本文生成は責務外。詳細は md-render skill 参照。

判断マーカー規約

要件	書き方
設計判断箇所	> [!DECISION] <題>（要判断一覧パネルに自動集約される）
DA 推奨	> [!DA] <推奨と理由 1 文>（任意）
現在地 Where	frontmatter where: A > B > C ＋ 必要時 ## 現在地 セクション + where-map 図
スコープ外会計	固定見出し ## スコープ外提案（Pending） ＋ 表

評価軸方向の規約（DA 表）

• 評価軸の方向に裁量がある場合、歪曲なき範囲で「値が高いほどポジティブ」に揃える（例: 「コスト」を自然に「コスト効率」へ言い換えられるなら揃える）。バーの値依存色（高=マゼンタ）と良し悪しが自然に一致し、読み取りが速くなる
• 禁止: 揃えるための歪曲（無理な逆数化・不自然な指標化・データ改変）
• 本質的に「低いほど良い」が自然な軸はそのまま書く（バー色は値の位置のみを示す意味中立。良し悪しは見出しと数値で読む）
• 判断基準: 歪曲なく自然に「高い=良い」にできるか。できる→揃える / できない→そのまま

HTML 派生とレンダラ手順

正本は MD。HTML は派生（HTML ⊆ MD）であり、報告義務は MD で完結する。

1. MD 保存後、レンダラで HTML を生成する: node ~/.claude/skills/md-render/md2html.cjs <報告書.md> <報告書.html>（md-render 未配備環境では HTML 生成を省略してよい — 正本 MD のみで完結）
2. --lint <報告書.md> を実行し exit 0 を確認（figures 宣言-実体一致の双方向機械検査: 宣言→実体と実体→宣言。exit 1 なら修正して再実行）
3. --verify <報告書.md> で双方向検証（捏造・欠落ゼロ）
4. _index.md を更新した場合は _index.html も再生成し、--check <_index.md> <_index.html> で鮮度を確認
5. HTML の提示方法は次節「提示規約」に従う

提示規約（在席ノード判定 + 提供方法）

原則: 在席ノードの権威シグナルは存在しない。機械判定を主とし、判定不能時は必ず安全既定（自動起動しない）へ倒す。既定ノードへの倒し込みは禁止（記入漏れ・判定不能が誤配になる構造の排除）。

在席ノード判定（上から順に評価、最初に成立した段を採用）

段	条件（全て AND）	結果
1. ローカル直接実行	SSH_CONNECTION/SSH_CLIENT/SSH_TTY 全て unset ＋ TMUX/STY unset ＋ 実行ノードが物理着席可能ノード	在席 = 実行ノード
2. SSH tailnet	SSH_CONNECTION あり ＋ TMUX/STY unset ＋ client IP の tailscale whois が物理着席可能ノードに解決	在席 = 解決ノード
3. 状態ファイル	~/.ccpit/operator-node の 1 行目が物理着席可能ノード名 ＋ mtime が 2 時間以内	在席 = 記載ノード
4. 安全既定	上記全て不成立	在席不明 → 自動起動せず URL ＋ パス提示のみ

• 実行ノード = ~/.ccpit/app-config.json の currentProfile（権威シグナル）
• 物理着席可能ノード集合は運用環境で定義する（ヘッドレスサーバ・スマホは含めない）。集合外への解決は全て判定不能扱い
• tmux/screen 内の SSH_CONNECTION は陳腐化し得るため在席確定に使わない
• 指示書 frontmatter での在席ノード指定は廃止。任意の allow_autolaunch: false（配信ポリシー）のみ受理し、在席確定時でも自動起動を抑止できる。無記入でも安全
• 状態ファイルは人間が例外時のみ書く明示オーバーライド（常時記入は要求しない。期限切れは無効＝忘れは安全側に減衰）
• 判定・配信のコマンド雛形: templates/present.md（実測済みコマンドのみ収録）

提供方法

判定結果	提供
在席 = 実行ノード	直接起動可（Windows Start-Process / macOS open / Linux デスクトップ xdg-open）。自動起動は最終成果物のみ、中間報告は file:// 提示に留める
在席 ≠ 実行ノード（確定）	Tailscale 配信: staging ディレクトリへ当該 HTML をコピー → 127.0.0.1 限定 bind のローカル HTTP サーバ → tailscale serve --bg --http=80 <port> → http://<実行ノードの tailnet 名>.ts.net/<file> を提示（後片付け手順を併記）。確認後は 3 点後片付け（tailscale serve reset・配信サーバ停止・staging 削除）を必ず行う — proxy 停止だけでは staging 残置分が次回 serve 時に再露出する
在席不明（安全既定）	自動起動なし。Tailscale URL と file:// パスの両方を提示

• tailscale funnel は絶対禁止（公開インターネット露出）。serve は tailnet 内限定であることを status 出力で確認する
• リポジトリを直接 serve しない（staging に当該ファイルのみコピー）

既存報告書への移行措置（grandfather）

• figures 宣言規約と --lint の figures 検査は、本改定後に新規作成する報告書にのみ適用する
• 既存報告書（本改定前に作成された MD）への遡及 lint・frontmatter 追補は行わない（一括 lint 適用は禁止）
• 既存報告書を HTML 再生成する場合も figures 追補は任意