ロゴ1つから設計言語を抽出して、13プロダクトを揃えた

トーナメントを勝ち抜いた13案を、ロゴ由来の共通デザインシステムで作り直す実験。TDIL ロゴの SVG から、内蔵8色をトークン化し、字形の45°対角カット（面取り）を署名モチーフとして抽出した。これを ds.css（ボタン・メニューバー・カード・フレーム等の共通部品）と ds.js（画面切替の共通フック）の2ファイルに実装し、参照デモ1本を手作りした上で残り12案を並列で再構築。色はすべてトークン経由、レイアウトだけサービス別にした。媒体が LINE・iPhone・iPad・ブラウザ・ウィジェットにまたがるのに、同じ studio から出たプロダクト群に見える。全13案と設計言語のショーケースは /products/lab で俯瞰できる。

理由: 50案では「別プロダクトに見せる」ため固有デザインにした（DEC-105）が、今回はその意図的な反転。共通部品の再利用は実装速度と一貫性に効き、デザインシステム自体がブランド資産になる。per-service→shared-system。記事化価値◎。

50案を AI 同士で戦わせて、13案まで淘汰した

マイクロプロダクト候補50案を、3審査員制のトーナメントで段階淘汰した。Round 1 は同ジャンル優先シードの25試合——各試合をユーザー代弁者・市場の現実主義者・運用の番人という別レンズの審査AIが独立採決し、多数決で25案に。勝者には要件書を書かせ（R1審査講評への対応を必須セクション化）、Round 2 は要件書の質まで判定材料にして再戦（12試合+最強勝利者のバイ1）。結果、Round 1 を 3-0 で勝ち抜いた案が要件の保守設計や配布の現実性で次々に敗れる逆転が起き、ファイナリスト13案が残った。全37試合・111採決の判定理由全文と要件書25本は /products/battle・/products/specs で公開。13案は要件を反映した詳細デモに更新済み。

理由: 1対1×3レンズの強制判定はリスト採点より「なぜ落ちるか」の言語化が濃く、敗者の良かった点まで全試合分残る。勝敗を最も分けたのは保守の軽さ（外部依存ゼロ）と配布の具体性だった。diverge→converge。記事化価値◎。

AI で作る会社が、「生成AIを載せない」と決めた

マイクロプロダクトの選定条件に「生成AI・LLM を機能に組み込まない」を追加した（OS 標準の音声入力・OCR は入力手段としてのみ可）。API ランニングコスト・外部依存・AI機能の飽和による差別化喪失を避け、「保守が AI 組織で回る」原則と揃えるため。このルールで初版20案を篩い分け（4案落選・5案を非AI設計に転換・工房系は純工房1本に再分類）、オーナーの興味領域ではなくユーザー視点の新規34案を加えて候補を50案に拡張。制作は Workflow で機械化し、設計=fable / 実装=sonnet 39体並列 / 検証=自動検査（違反ゼロ）の分業で34本の軽量デモを一括量産した。

理由: 作り手が AI を使うことと、製品が AI を内蔵することは別の話。ジャンルは子育て・介護・推し活・同人・巡礼・釣り・編み物・教師・法事・賃貸まで意図的に散らした（/products v2）。constrain→diversify。記事化価値◎。

新規事業は、市場評価がいちばん低かった案を選んだ

既存3軸と別路線の新規事業計画3案（B2B の AI バックオフィス運用 / B2C の聞き書きギフト / マイクロプロダクト群）を設計し、市場検証・チャネル批評・Red Team を並列で通した。market スコアでは案1が最有力だったが、オーナーは「マイクロプロダクト・ポートフォリオ」を採用。判断軸を収益効率ではなく「思考を巡らせて形にするプロセス」と「多媒体でのスキル獲得」に置いたため。iPhone・watchOS・CarPlay・キーボード拡張・LINE・GAS・Raspberry Pi + 電子ペーパーまで媒体を散らした候補20案を、フロントエンドAI 5体の並列実行で全案デモUI付きカタログ化した（/products・認証付き）。検討と却下の経緯は /ventures に保存。

理由: 各プロダクトが発信素材と技術実験台を兼ねる複利構造（DEC-005 のポートフォリオ並走を事業レイヤーで再適用）。選定4条件（実在の不便 / 検索に頼らない配布 / シンプルな決済 / 月2h以内の保守）+ 同時並走2本ルールをセットで確定。deepen→multiply。記事化価値◎。

AI組織をAIに監査させ、見つかった9つの歪みを12のAIで一括修繕した

4体の監査AIを並列で走らせて組織全体（エージェント定義・スキル・メモリ・自動化）を点検したら、方針転換がエージェントの人格定義まで反映されておらず、AIが繰り返し古い路線を推してくる根本原因が見つかった。ほかにも役割が重なった道具の二重化、使われた形跡ゼロのスキル、参照先が消えた旧名の残骸など計9項目。修繕は計画書に落とし、ファイル競合がないよう10レーンに分けたAI群（sonnet / opus / fable を負荷で使い分け）で一括実行し、別のAIが横断検証する三段構えで完走した。

理由: プロンプトは AI の行動規範そのもので、方針だけ変えて定義を変え忘れると確実に再発する。検出→計画→並列修繕→検証まで AI に分担させ、人間は4つの判断ゲート（文言・削除・経路の選択）だけを握った。implicit→explicit。記事化価値◎。

21日間こっそり死んでいた夜間バッチは、直さずに捨てた

メモ整理の夜間自動実行が、OS の権限制御に阻まれて21日間毎晩失敗し続けていた。健康チェックは別経路の成功を記録していたため、表面上は正常に見えていた。修復（システム設定の変更）もできたが、クラウドストレージ配下＋OSスケジューラの組み合わせはまた壊れる構造なので、実際に毎日動いていたセッション開始時の自動発火を正式な仕様に昇格させ、夜間バッチは登録ごと削除した。

理由: 壊れたものは「直す」より「仕様を実態に合わせる」方が誠実なことがある。動いていない仕組みを健全に見せていた観測の穴も、全フックに健康記録を義務付けて塞いだ。repair→retire。記事化価値○。

「みんなが書いている項目」より「商品ごとに違う項目」を選ぶ、に変えた

自分用の比較ツールで、商品ページから集めた仕様のうちどれを並べるかの選び方を根本から変えた。最初は「多くの商品が記載している項目」を出していたが、多種多様な6カテゴリで試すと破綻した——「保証・原産国・ブランド」のような全部同じで比べようがない定型が居座り、逆に「出力ワット数・タンパク質量・容量」のような本当に比べたい軸ほど、一部の商品しか書かないせいで消えていた。そこで「商品ごとに値が割れている項目ほど比較に効く」という基準に切り替えた。全部同じ値の行は自動で沈み、差のある軸が浮く。

理由: 多カテゴリで AI に並列で検証させたら、頻度で選ぶ方式には構造的な天井があると数字で出た。「差があるかどうか」は商品カテゴリの知識も保守リストも要らずに汎用で効く。あわせて、ある商品ジャンルで仕様が一切取れていなかった取得バグも修正した。AIに作らせ、多様なデータでAIに検証させ、人間が「選定の原理」を決め直した一連が中核。frequency-filter→difference-rank。記事化価値◎。

差し替えは「消してから載せる」——APIの実挙動に手順を合わせた

記事をまとめるマガジンの表紙画像を差し替える処理が、想定の2手順（アップロード→紐付け）では効かないと実機で判明。紐付けの口は「空の状態から初めて設定するとき」だけ効き、既にある表紙の差し替えでは黙って無視されていた。本家の画面自身も差し替え時に「古い表紙を削除」する操作を踏んでいたため、削除→アップロード→紐付けの3段を正規手順として確定した。

理由: 想像で手順を組まず、捨て実験と実適用で実挙動を突き止めて合わせた。反映の判定も、応答をうのみにせず取得し直して確認する方式にした。set-once→replace-with-clear。

記事を公開順の連番で並べ直し、古い情報を一つも残さないクリーンにした

書き直した記事と古い版が混在していたので、フォルダを公開順の連番（01〜15）に作り直し、各記事を「本文・図・サムネ」だけの最小構成に揃えた。途中、棚卸しから漏れていた一番読まれている記事を見つけて同じ基準で作り直し15本に。図のシリーズ番号バッジ・古い言い回し・本文に literal で出ていた壊れたリンク記号まで、本文から図・サムネ・索引・スクリプトの全層を洗い、URL もスキも保ったまま差し替えた。

理由: 「どれが今の正か」で迷わないよう、古い情報を一つも残さないことで現在を正と確定させる。シリーズ名（essay/build/dms の識別子）は意味を失ったので連番に統一し、記事同士のつながりは連番＋関連リンクで別に表す（各記事は単体で完結）。prefixed→sequential。記事化価値○。

公開済みの記事を「中身ごと差し替える」道具を自作した

既存の note 記事を、新しい文章・図・サムネ・タグへURL も既存のスキも保ったまま一括で入れ替える仕組みを作った。note にはそのための公開された方法がないので、ブラウザが「更新」ボタンで実際に送っている中身を一度だけ捕まえ、その正規の形を組み立て直す方式に行き着いた。これで14本の記事を1本ずつ手で貼り直さずに差し替えられた。

理由: タグはスペースやハイフンが1つ混じるだけで全部無効になる、本文は各ブロックに固有IDが要る——「実物を見ないと分からない作法」が肝だった。これを道具側に閉じ込めたことで、今後の記事更新も同じ手順で安全に回せる。draft→publish-api。記事化価値◎（非エンジニアが非公式な仕組みを解析して自分の道具にした制作ログ。規約グレーは淡々と扱う）。

「一度切った別ページ」を、サーバー不要の形で取り戻した

自分用ツールに「複数の候補をまとめて並べて見比べる」画面を足した。以前は重くなるので見送った機能だが、外部サーバーも会員登録も使わずツールの中だけで完結する別画面として作り直した。ボタンひとつで、選んだ商品それぞれのページを裏側で順番に開いてデータを集め、表で横並びに比べられる。AIに実装を任せ、人間は実際に動かして不具合を見抜く側に回った——テストが通っていても、本物のページでしか出ない不具合が3つ見つかり、その場で直した。

理由: 「広い画面で多数を並べたい」という要件は満たしたいが、サーバーや会員登録は自分専用ツールには過剰。"道具の中で完結する別画面"なら身軽に要件を満たせる。見比べの判断自体はAIに要約させず人間がやる（「AIに作業を渡し、人間は考える」と一貫）。cut→revive-bounded。記事化価値◎（#3「道具で面倒を潰す」の中核。痛点→道具→解消と、AIが作り人間が実機で直す過程）。

note を「いまスキを取る場」から「検索で積み上がる記録の場」へ組み替えた

14 本書いてフォロワー 0・最高スキ 7 という停滞を、4 つの並列診断（自分の数字の解剖／伸びている書き手のベンチマーク／note の届く仕組み／ブランドの自己点検）で掘った。結論は明快で、中身が刺さっていないのではなく、届いている人数がほぼゼロだった——届いた読者の反応率はむしろ高い（当たり記事で約 29%）。そこで note の目的を「いまスキを最大化する」から、検索で何ヶ月も後に拾われる"作った記録"を積み上げる（あわよくば収益化）へ置き換えた。

理由: いま最もエネルギーが乗っている実材料は外に出せず、尖った肩書きフックはどれも実態とズレ（実際に作っていないものは看板にしない）、手作業での拡散はしない方針——どれも正しい選択の帰結で、いま note で大きく跳ねるのは構造的に無理。ならば打算に最も誠実なのは複利資産。読者は非エンジニアに定め、媒体は note 単体（UI と間口の広さ）。本当の拡大は将来の別フェーズに置く。spike→compound。記事化価値◎。

月次監査を「並列 × 敵対的検証」の仕組みで回し、見つけた綻びをその場で直した

監査部の 8 人を一斉に走らせ、重要度の高い指摘は別働の検証役が敵対的に裏取りする形で第 5 回の月次監査を完走した。軽微〜中程度の指摘 10 件はその場で自走修正。記憶整理バッチが必須メタの欠落で"静かに詰まる"構造的な原因（ある指摘が 7 日間も残っていた根本）も塞いだ。

理由: 公開済み記事に関わる不可逆な指摘は据え置き、直して安全なものだけ即修正する線引き。監査を一過性のレビューでなく、検知から修復までを仕組みで回す形にした。detect→remediate。記事化価値○。

「狙いと実装のズレ」を実機で見つけ、直すものと送るものを分けた

自分用の小さなツールを作る過程で、ある機能（重複のまとめ表示）が実環境では一度も発火しないことを、実機の自動検証で見つけた。原因は明快で、「同じ商品が複数並ぶ」という狙いに対し、実装は厳密な一致でしか畳んでいなかった——現実の"複数表示"はもっと緩い別物だった。あわせて、追加したボタンが画面の見えない膜にクリックを奪われて押せていなかった不具合も実機検証で発見し、こちらは即修正してエンドツーエンドで動くところまで通した。

理由: 直せる不具合（ボタンのクリック横取り）はその場で直す。一方、緩い名寄せは誤って別物を同一視するリスクとコストが大きく、自分専用ツールには過剰だと判断して将来送りに線引きした（保険として無害な現状実装は残す）。ユニットテストが緑でも、ブラウザ実環境でしか出ない不具合がある——その事実自体が記録に値する。scope-cut。記事化価値○（#3「道具で面倒を潰す」の実体験素材）。

発信の看板を「個人の経歴」から「AI と作る仕組みの記録」へ一本化

受ける記事を再検討する中で、これまで差別化軸に据えていた個人の専門バックグラウンドを、発信の看板にはしないと決めた。経歴は思考の質として滲ませるだけにとどめ、前面の旗は「非エンジニアが AI と仕組みを作り・運営していく記録（AI に記憶を持たせる・作業を渡すワークフローの実践）」に一本化する。あわせてコンプラ・ラインに「専門属性を発信で前面化しない」を明文化した。

理由: 専門経歴は個人のバックボーンであり、大々的に掲げる情報ではないというオーナー判断。これを note の実数字が裏付けた——経歴・両刀性を最も体現した記事は閲覧は集めたが反応はゼロ、一方で「AI に記憶を持たせる／作業を渡す」系の実践記が最も高い反応率を出していた。判断と市場データが同じ方向を指した。diversify→focus。記事化価値△（メタ判断だが、以後の記事ストックを規定する）。

Marp + カスタム CSS のスライド生成を「汎用層 × ブランド層」の2層で新設

登壇・note 補助・営業・思考整理に使うスライドを Marp で作る仕組みを、いきなりブランド込みで書くのではなく2層に分けて設計した。汎用層（構造・寸法・型だけを持つ色なしの"スライドマスター"）と、それを継承して色・フォント・TDIL ロゴを注入するブランド層に分離。実物を3回作って目で確かめながら原則を固め、同じデッキが無彩色版とブランド版で破綻なく出ることを実証した。

理由: 「デザイン完全再現 × ネイティブ編集可能」な PPTX は構造的に両立不可能（敵対的検証で確証）→ 既定は再現重視の PDF+画像PPTX、編集は実験モードに分離。標準スライド設計のベストプラクティス調査で汎用層が持つべき寸法・型を確定。フッタはロゴと番号の高さを実測で1px未満まで揃えた（Marp の隠れた挙動を打ち消す修正込み）。couple→separate。記事化価値◎（AI と実験して"良いスライド"の設計原則を実証ベースで固める過程）。

過去記事を AI が参照できる「記事メモリ」を実装——被り提案を構造的に防ぐ

ある記事の執筆中、AI に次の発信を提案させたら、過去に書き尽くした内容を「新しい最強の路線」として提案する事故が起きた。原因は単純で、AI は渡された情報しか見えず、過去の投稿記事を参照する手段が無かった。記事を書き直すのではなく、その欠落そのものを塞ぐ判断をした。公開済み記事を既存の意味検索 DB（Dream）に取り込み、執筆着手前に「それ、もう書いてないか？」を機械が警告する仕組みを作って本番稼働させた。

理由: これは記事単体の問題ではなく構造的な欠落。新規 DB を作らず既存基盤に type=article で同居させ（公開済み13本を取り込み）、執筆スキルの着手前に類似度で被りを警告する（止めはしない＝最終判断は人間）。実証として、事故を起こしたテーマで検索すると当の既出記事が被り上位に正しく出ることを確認した。「AI が過去記事と被る提案をする事故を、AI 自身の記憶基盤を広げて防ぐ」。isolate→integrate。記事化価値◎。

A発信のテーマ戦略を「内向きの仕組み解説」から「AIに任せ人間は考える／過程を見せる」へ確定（内向き脱却）

DEC-089 の GO 後、既存14記事の実測ベースライン（ビュー平均17・スキ率最強29%）と全記事の棚卸しで、当初案や「記憶設計の続編」など内部の仕組み系は既出かつ内向きと判明。ゼロベースで再考し、発信の幹を「AI に作業を渡し、人間は"考える"。考えた"過程"ごと残し、読者がそこから学べるようにする」に確定した。枝は ①面倒を潰す ②何を作るか判断する ③思考を楽しむ。結果でなく過程を見せ、読者が追体験・再現できる外向きの素材として書く。

理由: 実測で最大の壁はコンテンツの質でなくリーチ構造（到達者不在）と判明。仕組み系は内向きで読者の自分ごと化が弱い。一方 jinc. 固有の特性（効率化への偏執・思考プロセスが報酬・過程を記録する習慣）は、内向きでなく「読者の頭の使い方」という外向きに開ける。建築設計者目線は当面外す（オーナー判断）。当初「実測でこの路線が最強」と短絡しかけたが、数字が刺さった本質は"題材"でなく"具体的な効能"だったと問い直して軌道修正——第1弾はその「AI の提案を人間が見抜いて軌道修正した過程」自体を扱う。inward→outward。記事化価値◎。

事業A「非エンジニア AI 発信」を条件付き GO で採用——建築は主題でなくラベル、流入は当面 note 単体運用

「非エンジニア（特に建築設計者）が AI で自作ツールを作り、その過程を note で発信する」テーマを、調査部長と広報部長を並列起動して多角検証し条件付き GOで採用した。市場ポジショニングは明快で、ニッチを深掘るほど読者が消える強い負の相関——建築×AI 特化の先行者は 7 スキの天井に張り付く一方、「非エンジニアの正直な体験」帯は 276〜516 スキに乗る。そこで戦略を器「非エンジニアの正直な体験」（読者母数）× 中身「設計者がコードを書く両刀性」（模倣困難な固有性）に統合。建築は主題ではなく語り手のラベルに引き、主題は陳腐化しやすい「手法」でなく「思考・意思決定」に置く。

理由: GO 根拠（競合空白／AI カテゴリの市場拡大／体験記の希少性は売れる実績／両刀性は模倣困難）と NO-GO 根拠（ニッチ天井／流入導線の構造欠陥／技術陳腐化の速さ／継続率の壁／副業リスク）を対置。流入導線と陳腐化はテーマを変えても残る構造問題でテーマ選択の減点材料にならず、NO-GO にする理由はない。一方その構造が未解決のためフル GO にもできない＝条件付き GO。流入動線はオーナー判断で当面 note 単体運用（複数媒体に分散して消耗するより、続けることを前提に一媒体へ集中＝マイペース原則と整合）。質の発信（エッセイ・設計記録・思考）は即着手可、量産・課金は就業規則の裏取り後ゲート。本業および特定の非公開案件は題材化しない。撤退トリガーは実測（ビュー平均17）を踏まえスキ率ベースに改定（効能/体験型のスキ率が3本連続10%未満→器・切り口を再設計／6本or3か月でビュー横ばい→導線再考）。旧「中央値スキ20未満」はビュー実態に対し到達不能のため廃止。記事化価値◎。

Dynamic Workflows を採用——研究品質を Workflow で機械保証する research-sweep を新設

Opus 4.8 の Dynamic Workflows（決定論的オーケストレーション）を初導入。第1号として research-sweep を新設した。調査部の品質規格（視点スペクトラム 推進/慎重/撤退/反対/領域外 各≥3・Red Team 必須・サンプル下限）を「ルール（守られない前提）」から「Workflow による構造強制」へ格上げするもの。実体は名前付き Workflow（部員を並列起動→フロアを満たすまで loop→Red Team を必須ステージ化→部長が統合）。パイロット実走で 91 ソース・「慎重/撤退/反対多数」の偏りなき分布を機械的に確保し、リサーチが自組織寄りに偏る既知の弱点を構造的に潰せることを実証した。

理由: これは行動規約を hook で機械強制した過去の判断（DEC-071）のオーケストレーション版＝convention→enforced の適用先拡張（hook → モデル階層 → workflow）。生成は廉価モデルの部員、統合は上位モデルの部長、というモデル階層化（DEC-086/087）とも噛み合う。分離原則は維持——ホスト固有のオーケストレーション（部員合成＋ブランドフィルタ）はホスト側に置き、調査部プラグインは汎用のまま、ブランドフィルタは統合ステージに隔離。opt-in 必須・トークン消費大（パイロット約408kトークン）なので通常の単発調査は調査部スキル直呼び、包括性・品質保証が要るときだけ本スキル。次の Workflow 化候補は監査ループ（loop-until-target）・連載企画（pipeline）。記事化価値◎（AIエージェント組織で研究品質を Workflow 機械保証する、は A発信の中核・公開可）。

モデル階層配置を2モデルブラインド実測で検証・確定（DEC-086 follow-up 完遂）

DEC-086 のモデル階層配置（Opus9 / Haiku3 / 他Sonnet）を経験的に検証。3カテゴリ（アーキ判断 / セキュ・法務 / 外部公開コピー）× 3アーム（sonnet / sonnet+ultrathink / opus）を同一プロンプトで生成し、別系統 codex(gpt-5.2) が匿名ブラインドで品質判定（自己評価バイアス排除）。結果、アーキ判断・セキュ/法務では opus が明確に勝利（→Opus化が妥当）、外部公開コピーでは opus が最下位（150–200字制約を超過）で上位モデルの価値なし（→Sonnet維持が正解）。配置は据え置き確定。あわせて follow-up #1（create-department v1.5＝再生成での巻き戻り防止）・#2（scorer 出力設計ガードレール＝証拠トレース/判定先行/キャリブレーション、RUBRIC v2.1）も完遂。#3（公開/デプロイのゲート化）は自走度向上段階まで保留。

理由: 「Opus に払う価値があるか」を主観でなくデータで決めるため、生成（Opus/Sonnet）と判定（別系統 codex）を分離し、ラベルを伏せて「差は実質的か無視できるか」を問うた。実測は DEC-086 の3判断をいずれも裏付けた。追加の学び2点: (1) 外部に出る定型コピーでは上位モデルがむしろ制約（字数）を破る＝「定型は Sonnet 維持」の妥当性を実証。(2)「Sonnet+高effort（ultrathink）」は Opus の信頼できる代替にならない——アーキでは過剰設計に走り最下位で、深い判断では effort が不安定。固定 Opus の判断を支持する。限界: 各カテゴリ n=1、継続観測推奨。記事化価値◎（別系統モデルのブラインド評価でモデル階層を実証／高effortは深い判断の代替にならない、は A発信の中核・公開可）。

サブエージェント30体を一律 sonnet 固定から役割別モデル階層へ＋破壊的操作の hook 機械強制

配下サブエージェント30体が全員 model: sonnet 固定だったのを、役割の「推論の深さ要求 × 失敗時のコスト × 検証しにくさ」に基づき再配置。Opus 化 9 体（tdil-engineer / tdil-researcher / tdil-auditor / architect / security / reviewer / legal / driller / devil）、Haiku 化 3 体（evidence-gatherer / delta-tracker / visualizer）、残り 18 体は意図的に Sonnet 維持。とりわけ publisher は当初 Haiku 化候補だったが「外部露出・不可逆のゲート役」として撤回、community・scorer も「炎上検知は人間承認の手前で起きる」「採点はモデルより手続き」を理由に Sonnet 維持。あわせて PreToolUse hook をモデル不問の構造防御に拡張し、破壊的 Bash（rm -rf 危険ターゲット / git reset --hard / push --force / clean -fd）と秘密ファイル書き込み（秘密鍵 / .pem / service-account / .ssh / 認証情報）をブロック（27 ケースのテスト合格・誤爆なし）。

理由: 同一モデルの盲点を避けるため Opus 4.8 の 6 ペルソナ円卓 → 別系統 codex(gpt-5.2) のクロスモデル独立レビューの 2 モデル合議で決定。codex がリポジトリを実読し「リスクの主因はモデル階層でなく権限×ガードレール」「実測より構造安全(hook)を先に」「30 体最適化は ROI 悪・ゲート役数体に絞れ」と指摘、最善策に反映した。破壊的操作の防御は engineering-dept 憲法§B.4 の行動規約を、忘れられる前提で hook に機械強制（convention→enforced、DEC-071 と同骨格）。固定モデルは grep 可能・監査可能でガバナンス上有利なため、起動時に監査ログが残らない override 方式は採らない。follow-up: create-department テンプレ {{MEMBER_MODEL}} の巻き戻り回避・scorer 出力設計ガード・公開/デプロイのゲート化。記事化価値◎（AIエージェント自走組織のモデル階層設計・2モデル合議・行動規約 vs hook 機械強制は A 発信の中核トピック、本件は wedpass 無関係で公開可）。

wedpass 主催者管理画面に全ゲスト情報の CSV 帳票出力機能を追加

管理画面の一覧 UI でしか見られなかった全ゲスト情報を、Excel/スプレッドシートで扱える CSV 帳票として一括エクスポートできるように。ゲスト一覧タブに「CSV出力」ボタンを追加し、全項目（PII 含む）30 列（氏名・カナ・チケット番号・テーブル・出欠・メッセージ・チェックイン/受付確認・登録日時・お車代封筒/金額・スタッフメモ・規約同意 ＋ メール/電話/郵便番号/住所/アレルギー/特別配慮 ＋ 同伴者の続柄/氏名/カナ/子供プレート/アレルギー）を出力。同伴者も各1行に展開（種別=本人/同伴者・代表者列で紐付け・行数＝総人数）し、席次・お礼状・配膳の集計をしやすくした。CSV 生成は純粋関数 buildGuestCsv() に切り出し。

理由: 席次表作成・お礼状送付・アレルギー対応など主催者の実務は表計算上で回す必要があり、画面内閲覧だけでは足りない（in-app-only→exportable）。主催者本人が自分の式のデータを落とす用途なので PII を含めて完備に。UTF-8 BOM 付きで Excel の日本語文字化けを防ぎ、RFC4180 エスケープで氏名・住所・メモにカンマ/改行/引用符が含まれても列がズレない——帳票機能で最も多い事故を構造的に回避。AuthGuard 配下の admin 画面でのみ動作し新たな Firestore 露出はない。tsc 緑 / vitest 1302 緑（CSV に +34 テスト）。本番 Hosting デプロイ済。記事化価値○だが wedpass 全面非公開のため公開は事業B Phase 2 以降。

wedpass ゲスト偽テンプレ表示バグ修正＋式当日リスク監査で fail-safe 設計を全面適用

オーナーが実機4Gで遭遇した「招待状を開くとテーマは出るがデータが偽プレースホルダ（Name & Name / ---- / (-)）になる時がある」重大バグを修正。根因は InvitationPage が event ?? EVENT_DATA で、Firestore 取得が一過性失敗した瞬間に新規作成用テンプレをゲストに描画していたこと。ゲスト経路から偽テンプレ fallback を撤廃し、null の間は実データを描かず loading / エラー画面を出す fail-safe 設計へ。useEventConfig / useGuest に transient（一過性）/ permanent を区別したリトライ猶予を導入し、弱電波の一瞬の揺らぎでは前回値を保持→自動復帰、本当に繋がらない時のみエラー表示にした。あわせて「招待状一斉送付・式当日（8/22）の集中アクセス」を3視点（負荷スケール／整合性並行性／クライアント堅牢性）で予防監査し、必要対策を全実装：guest-lookup の DoS 封鎖、受付係 update のフィールド限定、staffPin の機密化（公開ドキュメントから除去しサーバ照合化）、二重採番防止、もぎり書き込み失敗の握り潰し解消、テーマ chunk ロードのリトライ等。本番デプロイ完了（hosting+functions+rules / tsc -b 緑 / vitest 1261 + functions 76 緑）。

理由: 結婚式は一度きり。実在ゲストに偽の名前が見える・チケットが消える・白画面で固まるのは事業B（実証実験を兼ねた SaaS β1）の信頼を直接損なう。同じ「失敗時に偽データを見せる」構造が event だけでなく guest にも潜んでいたため、単発修正でなく unsafe-fallback→fail-safe を設計原則として横断適用した。当日は時間が戻せないため、発火確率が低くても影響が致命的なもの（DoS・自己もぎり・採番重複）は招待状URL公開前の今こそ潰す判断。過剰対策は避け、100〜150人規模で無料枠内に収まる項目は「現状で堅牢」と明示し、コールドスタート・一斉送付集中は当日運用でカバー。リスク台帳は docs/risk-audit-2026-05-30.md。記事化価値◎だが wedpass 全面非公開のため公開は事業B Phase 2 以降。

wedpass 全22チケットを「もぎり=招待状デザイン + 半券リビール体験」に統一

もぎり画面と招待状のチケットデザインが別物（＝同一レイアウトの二重管理）だった問題を全14テーマ・22バリアントで解消。基盤として①招待状を正本とする SSOT 化（{Theme}TicketShared。招待状ともぎりが同一コンポーザを通る）、②破れホスト化（StaffOverlay はジェスチャ/チェックイン/演出のホストに徹し、OverlayTicket に加算追加した tearRenderer? / renderPerf? / renderDone? で各テーマが破り方・ミシン目・完了演出を opt-in 注入）を確立。その上で 半券リッチ化（現実の半券のように情報を載せる・SSOT で招待状にも反映）と 席リビール（もぎる前は席を非表示→もぎった後に手元の半券へ席番号が現れるデジタルチケットの仕掛け）を全テーマに導入。もぎり前は招待状と「SWIPE UP」ヒットのみ差。横展開仕様は ADR-001 に集約。artdeco のみ元が横長劇場チケットのため招待状を縦に作り替え（意匠は保持・承認）。23コミット + 本番デプロイ完了（tsc -b 緑 / vitest 1113 緑、各テーマ実機目視 + 実もぎり確認）。

理由: 二重管理は片方修正が伝播せず不整合の温床（DEC-023 / DEC-068 と同骨格 duplicate→consolidate）。正本 SSOT 化で 1 箇所修正→両方反映。破れ機構を opt-in 拡張にしたことで StaffOverlay は formal の 1 回拡張のみ・以降ホスト不変＝後方互換を構造的に担保（未移行テーマは従来 WELCOME にフォールバック）。兄弟バリアントは家族 Shared をパレット引数化して再利用し代表を不変に保ったまま低コスト展開。起点はオーナー指摘「もぎりと招待状のデザインが違うのが気に食わない」。記事化価値◎だが wedpass 全面非公開のため公開は事業B Phase 2 以降。

wedpass 14テーマ多様化 + チケット/もぎり独自化 + TABLE・メッセージのチェックイン後 reveal

wedpass のテーマが「4群×色違いvariant＝実質似た見た目」だったのを、各々独立した世界観を持つ 14 テーマに拡張。既存 4（festival/blanc/noir/petal）に新 10（editorial/polaroid/kinetic/cinematic/celebration/formal/wa/artdeco/botanical/mono）を追加し、独立世界観・想定イベント・パレット・レイアウトで実装。チケットレイアウトを全 14 テーマで構造から作り分け（Mono=IDカード / Wa=縦組み短冊 / Polaroid=写真プリント / Cinematic=フィルムストリップ / Editorial=プレスパス 等）。もぎり画面は StaffOverlay を OverlayTicket descriptor 対応にリファクタしテーマ別意匠と一致。TABLE と個人メッセージはチェックイン後に初めて表示する reveal 制御を導入。偽 QR（FakeBarcode）を全チケットから除去。全 14 テーマ + テーマ別チケット + テーマ別もぎり + reveal 制御を wedpass.tdil.dev に本番反映。tsc -b 0 / build 緑 / vitest 1113 維持。

理由: テーマが似通っていると「選ぶ価値」が出ない。独立世界観でユーザーの選択肢としての多様性を最大化。チケット・もぎりはテーマの世界観を最も象徴する体験要素で共通テンプレでは個性が死ぬ（DEC-037 の拡張）。偽 QR はスキャンできそうで出来ず受付係を惑わせるため除去。席・メッセージは「受付でもぎった瞬間に初めて知る」リビールが招待状体験として価値が高い（オーナー指定 UX）。並列実行は基盤先行→各テーマ自フォルダのみ並列の throttle 運用（FAIL-017 教訓）。関連: DEC-037 StaffOverlayConfig テーマ注入型の前身 / DEC-062 unify→diversify 同骨格 / FAIL-017 並列 quota 枯渇。

DMS Phase 5 完結 — recall.py の draft 除外フィルタを DB 側で実装し設計意図と実装の乖離を構造解消

recall.py:58-63 のコメントに「pattern_draft: true の pattern は recall --skeleton 対象外」と設計意図が記載されていたが、実装は全 pattern を検索対象にしていた。本セッションの skeleton 検索手触り評価中、DB 直接クエリで pattern_embedding 非 NULL = 77 件と判明 → 設計意図と実装の乖離を発見。タクミ（engineering-dept 部長）に委譲し 1 セッション内で 3 ステップ実装完走: ①db.py に pattern_draft INTEGER DEFAULT 0 列追加 + マイグレーション + upsert 拡張 + load_all_pattern_embeddings() の SQL に WHERE pattern_draft = 0 追加 / ②sleep.py の process_memo() で frontmatter → DB に同期（extract.py が既に読んでいたため最小変更）/ ③recall.py コメント更新。テスト 5 本追加、既存 71 件パス、合計 76 件全パス。skeleton 検索で DEC-049 が pattern_sim:0.81 でヒット確認。

理由: 設計意図を実装に整合させる方が品質ゲートとして機能する（選択肢 B 採用、コメント書き換えで妥協する A や ファイル側都度読みの C を退ける）。DB 列追加は DEFAULT 0 で後方互換、既存挙動を破壊しない。将来の構造的保証: 新規 DEC は最初 pattern_draft: true で投入される（Haiku 粗抽出値・未承認）→ オーナー or レンが目視確認して false に flip して初めて検索対象になる ＝ 品質ゲートが構造的に機能する。副産物として memory/skill-candidates.md に「コメント・実装乖離検出スキル」を追記（audit-dept:coherence-checker 組み込み候補）。本 DEC で DMS シリーズ DEC-053→079→080→081 が完結。記事化価値○（DMS シリーズ第 4 弾 / AI が書いたコメントと実装の乖離を AI 自身が発見・解消するメタテーマ）。

DMS 骨格メタデータ Phase 1-4 完走 — 76 件全件適用 + analogical transfer の最小実証（δ 段階的方式確立）

DEC-079 で採用した骨格メタデータ設計（ADR 469 行）を 1 セッション内で Phase 1〜4 まで完走。①Phase 1: pattern / structure_summary / pattern_embedding フィールドを extract.py / db.py / sleep.py / recall.py + ALTER TABLE に追加 / ②Phase 2: skeleton_entry_search() + --skeleton フラグ + parallel track 方式（閾値 0.70 / 上位 3 件）/ ③Phase 3: 節目スキル 7 本（record-dec / add-component / create-department / design-decision / library-select / platform-onboard / series-plan）に「同型候補」セクション追加 / ④Phase 4: backfill_patterns + サニタイズ層（先頭行 / コードフェンス / バッククォート除去 / → 必須）を実装、重要 4 件（DEC-053 / DEC-063 / DEC-077 / DEC-079）を手動確定 + 残 72 件を Haiku 粗抽出 + draft マーク → 76 件全件 pattern_embedding が DB 登録。実証: クエリ「新しい部署や機能を独立プラグインとして分離する設計」で DEC-053 (consolidate→distribute) + DEC-063 (consolidate→distribute) が同型ヒット = ADR §Context の本来問題（「DEC-053 と DEC-063 が同型と気づけなかった」）が構造的に解決。

理由: δ（既存 76 DEC への適用方針）として A 全件一括バッチ / B 段階的（pattern_draft マーカー） / C オンデマンド の 3 案から B を採用。A は即時 76 件レビュー負担、C は analogical transfer の発動が不定期で、B は重要 DEC で即動作開始 + 残りは将来の編集機会で順次確定可能。pattern_draft 含みでも recall は十分機能することを実証。サニタイズ層は Haiku 出力の揺れ（バッククォート / コードフェンス / 説明文混入）を吸収する必須レイヤとして確立。DEC-053 の pattern を当初の limit→relate から consolidate→distribute（DEC-063 と一致）に再確定したのは、ADR §Context の本来意図に合わせて recall --skeleton で互いにヒットする構造を作るため。記事化価値◎（DMS 連載の本当の完結エピソード。実装完走 + 実証 + 段階的方式の妥当性を build 系記事として書ける / essay-05 と並走可能）。

DMS に骨格メタデータ追加 — AI 出力が人間の違和感を誘発する協働設計へ

DMS（Dream Memory System v3）は「メモを持たせる → 引く」までは達成したが、「過去原則を別ドメインの未知の問題に先回りで当てる能力（analogical transfer）」が未達。DEC-053「1メモ1ファイル」（5/14・メモリ設計の文脈）が、DEC-063 調査部立ち上げ（5/18・組織設計の文脈）で AI に想起されず、AI は統合案を提示し、オーナーが過去原則を抽象化して棄却した事例が発端。設計目標を「AI に違和感を持たせる」（達成困難・重い・過剰思考リスク）から「AI 出力が人間の違和感を誘発しやすい形」（軽量・責任明確）に転換。仕組み: ①骨格メタデータ（DEC frontmatter に pattern + structure_summary を追加）/ ②骨格類似検索（recall を意味類似 + 骨格類似の 2 軸に拡張、parallel track 方式）/ ③節目（skill 名ベース判定）で結論 + 過去の同型候補を併記する出力規約。

理由: オーナーとナギの長期対話（リサーチ・反証・諦め検討を経た 8 ラウンド）で、選択肢 X（AI 違和感再現ワークフロー）が Self-Verification Dilemma（過剰思考）に陥るリスクを認識、選択肢 Y（諦める）は人間負担増を回避できないため、中間道の選択肢 3 を採用。研究的根拠: RPMS（arxiv 2603.17831, +14.9pp）/ Self-Verification Dilemma（arxiv 2602.03485）/ Patterns over Principles（arxiv 2502.16169）/ Evidence for Limited Metacognition（arxiv 2509.21545）。本 DEC 自身が骨格メタデータ実証第1号（pattern: autonomous→assisted）。engineering-dept:architect が ADR 起草完了（469 行）、タクミが Phase 1 実装 + Phase 4 SSOT 判断を進行中。対話そのものが解こうとした問題の縮図になっていたことに気づき、記事化（essay-05）も plan 起草済み。記事化価値◎。

自走度ルーブリック v2.0 刷新 — 野心×実行×幾何平均型（旧 v1.2 廃止）

v1.2 はインフラ整備完了後に 100 点になる設計上の欠陥があった（#013 = 100点）。v2.0 は D_score = Ambition × Execution、Total = 100 × ⁴√(D1×D2×D3×D4) − 減点 で再設計。フィギュアスケート（難度係数×実行品質）× HDI（幾何平均）モデルを採用。4ドメイン: D1インフラ自律性 / D2発信自律性 / D3外部影響自律性 / D4事業自律性。幾何平均により弱いドメインが全体を強く引き下げるため、一点突破では高得点にならない。

理由: v1.2 では「hookが動いているか」「セッション内介入がなかったか」を加算していたため、インフラ整備だけで満点近くに達してしまった。v2.0 は「どのレベルの自律を試みているか（野心）」と「それをどれだけ実現できているか（実行）」を乗算で評価。初回 v2.0 スコア #014 = 13.47点（D3外部影響 = 0.020 が全体を引き下げる構造を正確に反映）。記事化価値◎（「AIが自分を採点するシステム設計」「満点が意味しない理由」）。

sleep.py スキップ分岐に archive 移動を追加 — DB 登録済み inbox 残留ファイルの自動クリーンアップ

session-start hook と手動 dream 実行の競合により、DB 登録済みのメモが inbox に取り残されるケースが発生（7件残留を手動対処）。sleep.py のスキップ分岐は「DB 登録済み = 変更なし = スキップ → archive 不実行」だったため、競合後に再実行しても archive されない構造的バグが根本原因。修正: スキップ分岐に source_path.exists() チェックを追加し、inbox に残留していれば archive_memo() を実行する 3 行を追加。以後は次回の dream 実行で自動クリーンアップされる。

理由: session-start hook の dream 擬似発火（DEC-075 採用）を維持しつつ、競合耐性を高める最小変更。代替案として hook 廃止・手動のみ運用も検討したが、DB 最新化のメリットを失うため棄却。記事化価値△（DMS 内部改善・技術メモレベル）。

note 発信戦略確定 — ブランド維持 + ニッチ集中ルート（X 縮小 + note 内動線強化 + マガジン整備即実行）

note アクセス状況の実数値分析（フォロワー0 / View 22 上限 / X click 累計 1 / 最高スキ率 46%）と類型サンプリング 27 件（A 同型×伸 8 / B 同型×不伸 8 / C 煽り型×伸 5 / D 属性近似 6）から、4 論点を AskUserQuestion で確定。①「伸びる」の定義 = ブランド維持 + ニッチタグ上位の維持（数字を主目的にしない、既存の局所優位 #メモリ設計 1 位 / #記憶設計 4 位 / #ドキュメント設計 7 位を維持・拡張）、②著者ラベル = 現状維持（属性は控えめ）、③媒体動線 = X 縮小（思想断片アーカイブに再定義）+ note 内動線強化、④即実行施策 3 本 = マガジン 4 本作成 + DMS 連載クロスリンク補修 + タグ最適化（13 記事一括）。Devil 3 反論仮説検証で「X 流入ゼロが本質的課題」が最も根拠厚いと確定したが、X 本気運用は性格的・Phase 整合的に困難として棄却。Phase 1（2026-08-23〜）で Zenn 投入を再検討。

理由: 類型C（煽り型）はブランド憲法「マイペース・煽らない・情報密度高・エッセイ型」と完全に相反、性格的に持続困難。類型A（同型×伸）との最大ギャップ「外部流入経路」「著者ラベル」のうち、ラベル側は匿名性最大を優先し控えめ運用を採用。同属性 KOBATAKA（建築×AI）も 7 スキ止まりという事実から、属性単独では伸びないことが確認できた。jinc. が局所的に勝っている事実（メモは溜める〜が 13V/スキ 6 = 46% / #メモリ設計 1 位）を中核に据える方が、Phase 0（〜2026-08-22）の B 軸と並走可能。フォロワー数の目標化は禁止、対句メソッド型タイトルの意識的試行は継続（因果未確定だが相関強）。記事化価値◎（「数字を追わない発信戦略の実証」「ニッチ領土確保による持続可能性」連載候補）。

dream 自動発火の運用方針確定 — launchd cron は当面放置 / session-start 擬似発火を主軸（C 採用）

DEC-074 で Stop hook を治した後、dream の launchd cron（毎日 03:00 JST）も **実は 7 連敗していた**（5/14〜5/20 全て Operation not permitted）と判明。真因は **launchd プロセスへの Full Disk Access 未付与 → Google Drive 配下のスクリプト実行不可**。ターミナル単独で FDA 付与は macOS の TCC（SIP 保護下）で原理的に不可能と確認（tccutil は削除のみ・sqlite3 直接 INSERT も SIP でブロック）。判断: **C を採用**（session-start hook 擬似発火を主軸として運用継続）+ 周辺の observability 整理。具体的には: ①dream-cron.sh を FDA 未付与時 silent exit + 1 日 1 マーカーのみ書き込みに改修（ログ膨張防止 / FDA 付与後はそのまま通常ルートで動く設計）、②session-start hook の dream-errors 集計から .resolved/ 配下を除外、③旧失敗ログ 3 件を memory/.dream-errors/.resolved/ に退避（履歴保持）、④FAIL-017/018 の frontmatter を新形式に変換（extract 失敗解消）、⑤Task #19「launchd cron 復活: /bin/bash に FDA 付与」を将来対応として登録（GUI 5 分作業）。全 health クリーン達成（dream-sleep / post-tool-use / stop-hook 全て ok 連敗 0）。

理由: PC sleep 中の launchd 不発火は macOS 標準仕様で回避不能。session-start 擬似発火は「PC を起こした瞬間に inbox が消化される」という現実的な代替で、inbox 溜まりすぎず（5/20 時点 7 件・健全範囲）。「困っていないなら無理に直さない」が現実解。dream-cron.sh の silent exit 化は K8s readinessProbe 的な発想 = 「動けないなら静かに諦める / 復帰可能な状態を保つ」。FDA 付与は 1 回 5 分の GUI 作業で完璧解だが、付与しなくても observability を汚さない設計に移行した時点で緊急度は低下。記事化価値○（「macOS のセキュリティ思想と自動化の現実解」「諦める設計の有用性」「session-start hook が ReadinessProbe を兼ねる」連載候補）。

Stop hook 連敗 18 回の真因再特定 — FAIL-022 修正で自動発火 2 連続成功 / A 軸復活見込み

DEC-070（FAIL-016 修正）で「真因は CLAUDECODE 継承」と判断していたが、実際は Stop hook 経由で 5/15 〜 5/20 全 SESS-* が fallback（claude_exit=1 / output_len=0 / stderr_dump 空）が継続。手動 bash stop.sh 一発で真因判明: DEC-070 修正時に 2>"$STDERR_FILE" を (cd $TMPDIR && unset CLAUDECODE && claude --print) の subshell 内に入れた際、STDERR_FILE が相対パス（${LOG_DIR}/...）のままだったため、subshell 内 cd 後に TMPDIR 基準で展開 → No such file or directory → bash がリダイレクト失敗 → claude が起動すらできず exit 1。修正は STDERR_FILE="$(pwd)/${LOG_DIR}/..." の 1 行絶対パス化のみ（FAIL-022）。検証: 23:42 修正前失敗 → 23:43 手動成功（output_len=3242）→ 23:45 / 23:46 Claude Code 自動発火 2 連続成功。health.json: degraded(18 連敗) → ok(0 連敗)。

理由: 「dream-sleep（haiku.py 経由）は ok」「stop-hook（stop.sh）は fail」という非対称が決定的ヒント。claude CLI 自体は問題なく、bash のリダイレクト失敗で claude が起動できていなかった。手動再現でエラーが見えれば一瞬。観測機構（DEC-071 健全性契約）が今回の再特定を可能にした。A 軸 14/20 → 20/20 復活見込み、次回 lp-build 採点で 94→100 域到達可能。記事化価値◎（FAIL-016/022 + 観測機構整備の 3 連載候補。「subshell 内 cd 後の相対パスは全て壊れる」「stderr_dump 空 = リダイレクト失敗の兆候」「修正の影響範囲を狭く保つ」の 3 教訓）。

tdil-skills 7 スキル移管完了 + create-department v1.4（汎用は部署 / 固有は runbook の二段構成 SSOT 化）

DEC-068（部署プラグイン統合）の積み残しを完了。旧 tdil-skills:{deploy, write-article, note-publish, post-publish-review, plan-series, add-platform, audit-cycle} の 7 スキルを、汎用ロジック=部署スキル / TDIL 固有運用=memory/specs/*-runbook.md / 横断スキル=tdil-skills の 三層分離に完全移管。同パターンを create-department v1.4 で標準フロー化（Step 1-4 = 移管対象特定、Step 3-3.5 = 旧スキル削除・runbook 化・参照更新・残存スキャン）。ルート全体の整合性スキャンで構造的バグ 2 件（LP更新トリガールール・lp-build 本体が部署プラグイン非走査）+ 死参照 4 件を発見・修正。これで 4 部署 + 30 部員 + 42 部署スキル + 11 横断スキル + 7 runbook 体制が完成し、本 lp-build から構造可視化に初反映される。

理由: 部署プラグインを「ホスト組織非依存・転用可能」として設計（DEC-068）したのに、tdil-skills 側に旧スキルが残ると入口二重化・分離原則崩壊・形骸化を生む。「汎用部分は部署スキル、固有部分は runbook」の二段構成は他組織への転用可能性とホスト組織固有運用の両立を構造的に担保する設計憲法。記事化価値◯（部署化と分離原則の実証 + メタ作業の自動化）。

部署プラグイン第 4 号 audit-dept 立ち上げ（部員 8 体・スキル 11 個）+ create-department v1.2

research-dept・engineering-dept・pr-dept に続く Department 規約第 4 号として audit-dept プラグインを新設。部員 8 体（coherence-checker / compliance-auditor / formalization-detector / scorer / visualizer / evidence-gatherer / delta-tracker / workflow-spotter、全員 sonnet）+ 業務型スキル 11 個（full-audit / coherence-check / compliance-scan / formalization-detect / rubric-score / structure-visualize / evidence-gather / delta-report / workflow-detect / skill-propose / audit-cycle-execute）+ レン部長拡張（ブランド整合 6 項目・運用周期付与含む）+ 部署固有の品質担保憲法 11 項目。workflow-spotter が反復ワークフロー検知 → スキル化候補を提案する仕組みを専門役職化（オーナー指示）。create-department v1.2 試運転で Step 2-4.5 クロスプラグイン重複チェック効果を確認。試運転教訓は v1.3 改修候補に持ち越し（settings.json は Claude Code 再起動でのみ取り込まれる）。スモークテスト 4/4 合格・分離原則完全遵守。

理由: レン単体では月次監査+構造可視化+採点+画像プロンプト出力の 4 モードを同時に持つ過剰責務だった。監査ドメインも部署として独立させ、TDIL ブランドフィルタはレン部長段階で適用する分離設計。workflow-spotter はオーナーの「汎用タスクや複数回行われるワークフローはスキル化することを提案するような役割を入れたい」要望を専門役職化したもの。記事化価値○（部署設計パターン第 4 例・自走組織の自己監査構造の例として）。

自動化健全性契約の確立 — add-automation skill 新設で機能追加時にも観測が自動機能する構造

DEC-070 で FAIL-016 真因解決後、オーナーから「なぜ 32 回も失敗していたのに途中で報告や改善提案がなかったのか？」「機能変更・追加時にも同様に機能する設計か？」と本質的指摘。第一案（A〜E 個別パッチ）が場当たり対応であることが露呈 → 契約 + 集約観測で再設計。新スキル tdil-skills:add-automation を新設し、全自動化に .context/health/{name}.json 書き込み契約を強制。集約観測 .context/hooks/health-check.py を SessionStart hook の最優先位置に組み込み。既存 3 自動化（stop.sh / post-tool-use.py / sleep.py）に migrate 適用済み。新規追加時にも契約遵守だけで自動的に観測対象に組み込まれる構造。

理由: 個別パッチを 5 つ並べた瞬間に「場当たり対応」を疑うべき。観測対象が name を知らずに集約できる契約 = 拡張に対する開放性。K8s liveness/readiness probe / systemd unit status / Prometheus exporter と同じ成熟した観測パターンを AI エージェント自走組織に適用。スキル化が「Rule 明文化」より勝るのは、create-department / add-component / add-platform の TDIL 既存流儀（追加時の整合性を構造で担保）と整合。記事化価値◎（連載候補）。

FAIL-016 根本解決 — CLAUDECODE=1 env 継承で Stop hook + Dream Haiku が即死していた

5/15 〜 5/18 のログ集計で Stop hook の claude --print が 32 回連続失敗（成功ゼロ）と判明。手動シェル実行は成功するのに hook 経由が全部 exit 1 / 出力空。リサーチで真因確定: 親 Claude Code が CLAUDECODE=1 を子プロセスに継承 → 子の claude --print が「nested session 検知」で即拒否。Anthropic SDK 既知バグ claude-agent-sdk-python Issue #573 と同型。stop.sh と haiku.py に公式回避策（unset CLAUDECODE / env={"CLAUDECODE": ""}）を適用 → 親環境内手動実行で 9.8s で 'PONG' 応答確認、Bash 同等経路でも exit 0 確認。FAIL-016 を partially-resolved → resolved。

理由: 「観測を先に整える」（5/15 の Step 1 で fallback + ログ可視化）が 4 日後の真因特定を可能にした。「32 連敗」が見えた瞬間に rate/timeout/認証揺らぎ仮説を捨てて構造バグに切替。公式 hooks doc に「hook 内で claude CLI 起動」記述ゼロでも、同じ穴を踏んだ SDK が Issue に残していた。記事化価値◎（「Claude Code hook から claude CLI を呼ぶ罠と公式回避策」は同じ穴を踏む人が必ず出る）。

部署プラグイン第 3 号 pr-dept 立ち上げ（部員 9 体・スキル 10 個）

research-dept（第 1 号）・engineering-dept（第 2 号）に続く Department 規約第 3 号として pr-dept プラグインを新設。部員 9 体（writer / copywriter / publisher / post-reviewer / analytics / thumbnail-designer / community / tone-curator / planner、全員 sonnet）+ 業務型スキル 10 個（series-plan / write-post / short-copy / publish-post / post-review / engagement-analyze / thumbnail-design / platform-onboard / launch-campaign / tone-tune）+ ソウ部長拡張（部長フィルタ・部員指揮テーブル）+ 部署固有の品質担保憲法 11 項目。スモークテスト 9/9 合格。試運転教訓 2 件（agent name 重複・段階的 reload）は create-department v1.2 改修候補へ持ち越し。

理由: ソウ単体ではスケールしないし、執筆 / コピー / 投稿実行 / 公開後分析 / 分析 / サムネ設計 / コミュニティ / トーン管理 / 編集計画を一人に詰めると専門性が落ちる。発信ドメインも部署として独立させ、TDIL ブランドフィルタはソウ部長段階で適用する分離設計。記事化価値○（部署設計パターンの第 3 例、命名規約の安定確認）。

ネイティブ subagent 7 体廃止・部署プラグイン部員に統合（部署側 SSOT 確立）

レンの構造可視化（lp-build #008）で検知した 3 件の整合性違反——(1) implementer 同名重複（ネイティブと engineering-dept 部員）、(2) publisher 役割重複（tdil-publisher と pr-dept:publisher）、(3) dept_head_of frontmatter 未記載（タクミ・ソウ・サクの 3 部長）——を 1 DEC でまとめて整理。「*-dept プラグイン部員を SSOT」とするオーナー方針に従い、ネイティブ subagent 7 体（tdil-writer / tdil-publisher / tdil-reviewer / implementer / frontend-dev / code-reviewer / playwright-dev）を一括廃止し、それぞれ pr-dept / engineering-dept 部員に統合。3 部長に dept_head_of frontmatter 追記。3 skill（write-article / note-publish / post-publish-review）+ 3 部長 agent + ルート CLAUDE.md + OPERATION.md + tdil-skills CLAUDE.md の参照書き換え + 7 ファイル削除を実施。

理由: 部署プラグイン立ち上げ（DEC-063 / DEC-065）でホスト組織との二重管理が発生していた構造的負債を解消。「ベア名 implementer 呼び出しが事故る」「どちらの SSOT を見るべきか不明」という連鎖リスクを根本から塞ぐ。部署プラグインは「TDIL 文脈ゼロの汎用部員」+「部長が並列起動・ブランドフィルタを適用」という構造で拡張性と再利用性で勝る（命名規約 <name>-dept の本旨）。記事化価値◎（部署プラグイン化の終盤・SSOT 一元化の事例として連載候補）。

サブエージェント間起動は Agent tool に統一（FAIL-021 恒久対応）

post-publish-review 実行中、ソウが tdil-reviewer を Bash 経由 claude --agent で起動して stdin 待機で空応答に終わった（FAIL-021）。シェル直起動は claude CLI が stdin から入力を待つため無限ブロックする構造的欠陥。**Agent tool（subagent_type 指定）でのみサブエージェント起動可**を全体規約として明文化。.claude/agents/tdil-pr.md に「サブエージェント起動の絶対ルール」セクション新設、post-publish-review/SKILL.md Step 5 を Agent tool 呼び出し形＋ stdin 経由禁止＋ prompt self-contained 化で書き換え。

理由: 「サブエージェント呼び出しは Agent tool」原則は元々暗黙的だったが、ソウのフォールバック実行（自分で差分分析）が規約違反をカモフラージュして見えにくかった。tdil-writer / tdil-publisher にも連鎖しうるため、ソウ全体の規約として書き出す必要があった。記事化価値△（内部規約・読者への伝達性は低い）。

create-department スキル v1.1 改修（公式仕様遵守の規約明文化）

engineering-dept 立ち上げ試運転で 4 バグ発見: (1) plugin.json 二重定義、(2) .claude-plugin/marketplace.json 生成漏れ、(3) settings.json 登録漏れ、(4) agent frontmatter name 規約違反（path 形式書き）。スキル本体（SKILL.md Phase 2-1 〜 2-5）とテンプレ群（templates/*.md）に反映し再発防止。Claude Code 公式 doc 確認を毎回必須化する習慣も組み込み。

理由: 試運転で動かなかったバグは「次の部署作るとき必ず同じ場所で踏む」種類のもの。スキルは SSOT なので、ここを直さない限り 3 度目以降も再発する。記事化価値△（プラットフォーム固有の細かい話だが、SSOT 直し方の例として軽い参考にはなる）。

部署プラグイン第 2 号 engineering-dept 立ち上げ（部員 9 体・スキル 12 個）

research-dept に続く Department 規約第 2 号として engineering-dept プラグインを新設。部員 9 体（architect / implementer / frontend / reviewer / tester / ux-reviewer / security / legal / devops、全員 sonnet）+ 業務型スキル 12 個（design-decision / library-select / tdd-implement / ui-build / code-review / refactor / e2e-test / ux-review / security-audit / legal-check / deploy / pre-deploy-check）+ タクミ部長拡張（部長フィルタ・部員指揮テーブル）+ 部署固有の品質担保憲法 11 項目（6 カテゴリ）。スモークテスト 9 / 9 合格、分離原則完全遵守を確認。

理由: タクミ単体ではスケールしないし、レビュー / テスト / セキュリティ / 法務 / DevOps を一人に詰めると専門性が落ちる。部署として独立させ、TDIL ブランドフィルタはタクミ部長段階で適用する分離設計を engineering ドメインにも展開。create-department スキルの試運転を兼ねた実証（その結果が DEC-066 になった）。記事化価値○（部署設計パターンの第 2 例）。

wedpass Phase 0 構造的負債解消 4 タスクを一気に実装・本番反映

2026-05-17〜18 で 4 タスク（cancelDeadline 動的化 / 利用規約・プライバシーポリシー実装 / EventConfig.plan + 機能フラグ土台 / オンボーディングフロー追加） + 二次対応（AdminPage ダッシュボード戻り動線 / 規約モーダル化 / 規約 TSX 5項目修正）を本番 wedpass.tdil.dev に反映。Hosting / Functions / Rules 全反映、バンドル grep 検証 6 項目クリア。FAIL-017 / FAIL-018 インシデント記録（規約 markdown と TSX の二重管理問題、Phase 1 で react-markdown 直 import 統一予定）。

理由: service-overview.md §9.1 に「SaaS 化前提の構造的負債解消」が Phase 0 タスクとして明記。jinc. の式の挙動を壊さないフェイルセーフ設計が可能で、当日 2026-08-22（β1 ライブ検証）までに「マルチテナント前提でも正しく動くコード」を整える。記事化価値◎（A 発信ネタとして「マルチテナント SaaS の Rules ハードコード解消」「個人情報保護を前提とした SaaS オンボーディング設計」「規約・ポリシー二重管理問題と markdown 直 import 統一」が抽象化形で連載化候補）。

research-dept プラグイン新設・汎用 Department プラグイン規約確立

リサーチが TDIL ブランド寄りに偏る構造問題（サンプル不足・批判視点欠如）を解消。汎用プラグイン research-dept を新設し命名規約 <department-name>-dept（Department 規約第 1 号）を確立。4 部員（Devil 批判 / Mapper 俯瞰 / Driller 深掘り / Sampler 大量サンプル）+ 9 業務型スキル（landscape-scan / deep-dive / competitive-matrix / tone-reference / devil-advocate / outsider-voices / pain-mining / theme-feasibility / url-batch-analyze）+ 質の規格（サンプル下限・スペクトラム必須・対義テーマ並列・Red Team 必須・多様性メトリクス）を機械的に強制。サクは「調査部の部長」として 4 部員を並列起動・統合・評価フェーズで TDIL 強み視点 + コンプラ確認を適用。

理由: 1 エージェントに全機能を詰め込むとモード揺れが起きる + サクのプロンプト常駐の「TDIL 強み優先」が調査本体にブランドフィルタを混入させていた。調査本体と評価フェーズを完全分離、ブランドフィルタは評価フェーズ専任に。TDIL 文脈ゼロの汎用プラグイン化で他プロジェクト・他人にも使える独自価値に。記事化価値◎（汎用 Department プラグイン規約・批判的調査の構造化）。

generate-figure skill を内容駆動化 — テンプレ使い回しを禁止、カスタム HTML+SVG を主流に

DMS-02〜05 で 14 枚の figure を既存 3 テンプレで生成したところ「ぜんぶデザインが微妙、フォーマットに引っ張られている」とオーナー指摘。テンプレ駆動 → 内容駆動へ全面シフト。デザイン原則 6 → 8 に拡張（原則 7「内容駆動の視覚形式」/ 原則 8「抽象化と可読性のバランス」）、外周パディングを 24-32px → 16-24px に厳格化、失敗パターン 3 つ追加。Step 3b を Path 1（カスタム HTML+SVG・推奨）/ Path 2（既存テンプレ・限定）に再構成。思考プロセス 5 ステップを明文化。

理由: テンプレ駆動は「楽だが本質を伝えない」失敗パターン。1 figure ごとに「何を見せるか」を考える時間投資が必要だが、図解の質は劇的に上がる。note 記事の差別化はサムネ + 図解の質に大きく依存（DEC-050 流入導線整備の延長）。

plan-series skill 新規 + post-publish-review に _index.md 自動更新追加

連載記事の並行作成を構造化する tdil-skills:plan-series を新設。Step 1〜9（シリーズ核心 → 各記事仕様一括 → 動線計画 plan.md → 🚪 G1 動線計画ゲート → Phase A 並列執筆 → B クロスレビュー → C 修正反映 → D ナギ統合レビュー → 🚪 G2 統合レビューゲート → 図解・サムネ並列生成 → 完了報告）。2 ゲート構造 + plan.md 中心設計で writer 全員とナギが単一ソースを参照。あわせて post-publish-review に Step 6.5（articles/_index.md 自動更新）+ Step 6.6（article.md frontmatter 更新）を追加し DEC-060 の運用維持を自動化。

理由: DMS-02〜05 を手動オーケストレーションした体験から、連載並行作成は今後増える見込み（A 軸の dms / build 系続編・将来の事業 B 発信解禁時）。skill 化で Phase A〜C 自動連続実行、オーナーは 2 ゲートだけ確認すればよくなる。

公開済み記事インデックス参照の構造化 — writer が過去記事を毎回認識する仕組み

writer が記事執筆時に「過去の公開記事を忘れる」構造問題を解消。articles/_index.md 改訂（slug 列付き再整理 + §note 公開済み記事 description セクション新設 / 9 本すべての description を frontmatter から転記）。write-article skill / tdil-writer.md / platforms/note.md の必須読込ファイルに _index.md §description を追加。writer は記事執筆前に description を全件読み、テーマが響く既存記事 1〜2 本を冒頭・本文中・末尾に流入リンクとして配置する設計に。

理由: 個別タスクの指示で過去記事を逐次渡すと writer が見落とす / 渡し漏れる確率が高い。writer が自律的に過去記事インデックスを参照する設計に変えれば「忘れる」現象が構造的に消える。description で判断するのが「テーマが響くか」を最速で読み取れる方法。

note 関連記事リンク運用のスキル明文化 + 未公開記事プレースホルダー記法

DEC-050 で確定済みだった「次の記事への橋」「関連既存記事リンク」のスキル明文化が漏れていた問題を正式にルール化。各記事末尾に「次の記事への橋」必須化、冒頭 or 本文中に既存記事への流入リンク 1〜2 本必須化、未公開記事プレースホルダー記法 [LINK:slug] を新規追加（公開時に実 URL に置換 → note 埋め込みカード化）。DMS-02〜05 への適用結果として連載内相互リンク + build-04 への参照などを実装。

理由: DEC-050 で深度戦略は確定していたが運用ルールとしてスキルファイルに反映されていなかった。結果 DMS-02〜05 を書いた時点で writer がルールを認識できず、リンク漏れが発生した。フォロワー薄期の note アカウントにとって関連記事流入経路の整備は最も効く打ち手の一つ。

note 段落ルールの確定 — 意味的まとまり=1段落 / 段落内は単発 br / 最大 7 行目安

note 記事の段落構造ルールを 6 項目に確定: ①段落単位は意味的まとまり ②段落内改行は <br> 単発のみ（連続禁止）③読点改行は段落内 br 単発 ④最大 7 行目安 ⑤1 行段落は強い独立のみ ⑥典型 3-6 行 / 1 行は強い独立 / 7 行超は要レビュー。note 投稿パイプラインを Playwright CDP 方式から非公式 API（cookie 認証）方式に置換。2-step 下書き / S3 presigned 画像 / HTML 正規化（<b> 不可・<pre class="p-textNoteCode"> 必須）/ POST /v1/embed 埋め込み等を実装。

理由: 当初の機械分割は「意味のまとまりを分断する」誤動作を起こした → 撤退。<br><br> 連続が「段落内の空行」として描画される現象を発見し、markdown.py の改行結合方式と正規化を修正。Playwright CDP 方式は H2 drop 等で不安定だった経験を踏まえ、note 非公式 API 方式に乗り換え。

wedpass はサービス公開まで外部発信全面非公開（コンプラ強化）

事業 B（wedpass / 結婚式 Web 招待状 SaaS）の事業内容・存在自体を、サービス公開（Phase 2 一般公開・課金開始）まで note・X・外部発信に一切出さない ことを構造的に保証する。.claude/rules/compliance.md に第 4 項として追記。具体禁止対象: 「招待状サービスを作っている」事実の言及 / 「結婚式」「ウェディング」「wedpass」等の固有語 / 開発過程・実装ログでの間接言及 / 図解・スクショ・URL。LP（内部ブランドガイド）は対象外、社内記録は通常通り。

理由: オーナーがこの方針を何度も伝えているにも関わらず dms-01 ドラフトで「招待状サービスの開発ログ」と書いてしまった（コンプラ違反）。「サービス公開まで競合に手の内を見せない」「自分の式当日までの仕上げを邪魔されない」「移譲容易構造を確保するため jinc. 個人と紐づきを薄く保つ」の 3 つの理由が合致。既存コンプラ 3 項目（Lib Work / 3DP / 社内重複）と同じレベルの絶対遵守として位置づけた。記事化価値× （このルール自体は発信しない）。

wedpass Phase 0 完了宣言 = Phase 1 移行ゲート通過

事業 B「実証実験を兼ねた仕上げ」のうち、guest-auth (Phase 10) を含む構造的負債解消が完了。Phase 1（マルチテナント UI 着手・知人試験運用準備）へ移行可能なゲートを通過したと宣言。完了の 3 要素：①4.9 本番動作確認 8項目 PASS（オーナー手動確認 / 新規登録・既存読み取り・不正アクセス拒否・再ログイン・FIFO・受付係・アクセスログ・リボーク）。②firestore.rules フォールバック削除（移行期の ownerUid 経由 read 許可を撤去 → guestUids のみで判定する最終形へ。全 Guest doc 付与済み 1/1 件）。③DEC-052 残課題 3 件解消（Cloud Functions sanitize = functions/src/shared/geo.ts で geoip-lite による IP/Geo サーバー側取得 / AnimatePresence 最適化 / PRESETS lazy ロード = src/landing/presets-full.ts 動的 import 化）。

理由: DEC-052 で「Phase 0 残課題」と定義していた 3 件 + DEC-055 で採用したゲスト認証強化が全て本番稼働し、事業 B が「自分の式の実証実験 + SaaS β1」両軸で稼働できる基盤に到達。個別 DEC を分散させるよりマイルストーンとして 1 点で記録するほうが「Phase 0 → Phase 1 の切り替え点」を後から引きやすい（recall 時のエントリポイントとして強い）。当日 2026-08-22 まで残り約 3 ヶ月。これ以降は自分の式の最終仕上げ（写真・実データ・運用テスト・当日リハ）とPhase 1 準備（マルチテナント UI / 課金骨組み / wedpass-precheck skill 化 / lint hook 配線）に主軸を移す。記事化価値◎（「個人の式 × SaaS β1 両軸完走」のストーリー / DEC-055 と合わせて Firestore セキュリティ設計テンプレ記事に発展可）。

wedpass ゲスト認証強化 — 匿名 Auth + guestUids 配列 + Cloud Functions sanitize + 監査ログ

DEC-052 残課題 (3) として残っていた firestore.rules の致命脆弱性 allow get: if true を構造的に解消。案 E（匿名 Auth + guestUid 配列、端末上限 3 FIFO） + 案 P（鍵増殖モデル + 主催者リボーク） + 選択肢 Y（Cloud Functions サーバー側で IP/Geo 監査ログ取得） + 受付係をメール+姓名 + isReceptionStaff トグル + joinReceptionSession Function 経由 に再設計。Cloud Functions 4 本（registerNewGuest/joinGuestSession/joinReceptionSession/revokeGuestSessions、asia-northeast1、512MiB）+ Firestore Rules 最終形 + sessions サブコレクション + reception-sessions コレクション + 移行スクリプト + 管理画面アクセスログ UI + リボーク機能を 4 Step で完走。Playwright E2E 5 件全 PASS + ユニットテスト 125 件全通過。当日リハで受付係 update 権限漏れ + セッション失効 UX バグ 2 件を追加発見・即修正。検討・実装・デバッグ・リハで発覚した 7 つの落とし穴（匿名認証 Provider 有効化 / Hosting デプロイ漏れ / geoip-lite で 512MiB 必須 / Cloud Run IAM 残留時の delete+recreate / Firestore トランザクション内コレクションクエリ禁止 / 受付係を update 権限に通し忘れる罠 / 匿名 Auth セッション失効時の UI フォールバック未実装）は今後別 SaaS でも再利用可能な汎用チェックリストとして DEC-055 §運用前提に整理した。

理由: allow get: if true は guestId 列挙攻撃でゲスト全員の機微情報（電話/住所/アレルギー/同伴者/申し送りメモ）が抜ける致命設計だった。Phase 1（知人試験運用）入りに耐えるためには Phase 0 中に塞ぐしかないタイミングだった。設計検討で 5 軸 × 計 11 案を比較（データ保護方式 5 案 / 第二要素 4 案 / 監査ログ 2 案 / 受付係認証 2 案）し、結婚式の使い勝手と SaaS 化堅牢性のバランスから案 E + P + Y を採用。記事化価値◎◎（A 発信ネタとして連載化候補：「個人情報を扱う SaaS の Firestore + Cloud Functions セキュリティ設計テンプレ」「匿名 Auth + guestUid で本人特定する構造」「合言葉 / メールリンク / 個別URL / 匿名 Auth の比較検討プロセス」「FIFO + 監査ログ + リボークの三位一体」）。今後の SaaS 開発（C 軸フィジカル商材で発生する顧客情報管理など）でも同パターンを再利用可能。

Dream 運用パターン確定 — recall は「点」、Bash + 直接 Read は「線」

DEC-053 で導入した Dream Memory System v3 を実地3タスク（他己紹介・wedpass 経緯まとめ・記憶取り出し比較）で検証し、ナギの運用パターンを確定。意味的な関連検索は recall.py（活性化拡散で点を見つける）、時系列の流れ・特定 ID の全文展開は Bash grep + 直接 Read（線で繋ぐ）、恒久プロファイル（profile.md など Dream 対象外）は直接 Read という3分担を標準化。「recall で水先案内 → Bash で詰める」の組み合わせで、旧 BRIEF 方式では原理的に不可能だった「2週間の事業経緯まとめ」が ~8,500tok で完結（旧方式想定 ~30,000tok の約1/3〜1/4）。

理由: 実地検証で「recall 単独だと活性度順しか返らず時系列にならない」「直接 Read 単独だと関連の見立てがつかない」両方の限界が見えた。一方を捨てず両方を併走させる方が現実的に強い。これは LLM RAG の典型課題（ベクトル検索だけでは時系列・網羅性に弱い）への現実解で、A 発信ネタになりうる（記事化価値◎）。次回 recall スキル SKILL.md にこの使い分け原則を追記予定。

Dream Memory System v3 導入 — 活性化拡散ベースの意味検索メモリ

DEC-051 の軽量メモリ（BRIEF.md 1枚集約）が複数文脈並走で文脈が薄まる + 並列セッション競合の問題を抱えていたため、Zettelkasten × RAG の発想で再設計。①1メモ1ファイル: frontmatter (id/type/date/title/tags/status) + 本文、memory/inbox/*.md 投入→memory/archive/YYYY/MM/*.md 整理済み保管。②意味検索 DB: SQLite (memory/.dream-db.sqlite)、multilingual-e5-base (768次元) で embedding、numpy brute force（macOS システム Python の sqlite-vec 拡張制約への対処）。notes + edges (cited_in / related) の二層。③夜間バッチ「sleep」: Haiku で summary 生成 + 関連判定（並列） + 正規表現で DEC-XXX 抽出 + archive 移動 + エラーは .dream-errors/ 隔離。④想起「recall」: 入口は cos sim 閾値（Top-K 廃止）、グラフを活性化拡散で辿り、token_budget 内で content/summary/title を自動切替してツリー出力。⑤擬似自動化: session-start.sh が inbox ≥3 件で nohup 起動。launchd plist 登録済み（macOS Full Disk Access 付与で完全自動化）。実装規模 11ファイル / 65テスト全パス / 既存 74メモを移行（DEC×49 / FAIL×15 / SESS×5 / AUDIT×4 / IDEA×1）/ edges 98本。

理由: オーナーの「Top-K で切る発想は意味がない。リレーションを活用して必要情報を漏れなく取りたい」「セッション単位の文脈分離が必要」「人間が夢で記憶を整理する感覚」という3つの問いから設計が大きく進化。階層を静的に切らず活性度の動的伝播に置き換えたことで、「もっと潜る」判断がエージェント自律になった。記事化価値◎（「ベクトル検索だけでは足りない RAG 運用」「macOS launchd と Drive 配下実行制限」「ローカル完結のセマンティックメモリ」）。

wedpass LP 大改修後の品質仕上げ — モバイル UX + コードレビュー 20 項目一括対応

DEC-049（wedpass LP 大改修）リリース後、実機スマホ録画と多角コードレビューを実施し、20 項目（モバイル UX 6 + コードレビュー警告 9 + Info 6）を 8 タスクに束ねて一括修正。①モバイル UX: ヘッダ不透明度 92% → 97%（背景透過によるオーバーラップ解消）、レスポンシブヘッダ高さ（56px/48px）、Hero 上パディング縮小、Hero 副 CTA を「もぎってみる ↓」+ section スクロールに変更（重複 CTA 解消）、MogiriDemo チケット視認性向上（半透明白 + ボーダー + シャドウ）、ReceptionFlow 矢印モバイル非表示。②コード品質: useTicketDrag stale closure 対策（onTear/onResetRef パターン）、StaffOverlay + MogiriDemo setTimeout cleanup（unmount 後の状態更新警告解消）、onAuthStateChanged 10 秒タイムアウト、sampleData.ts の Firestore Timestamp 型統一（as any 排除）。③セキュリティ: Firestore Rules を匿名認証必須化（guests/guest-lookup/counter の create は request.auth != null）、guests:get 一般公開の Cloud Functions sanitize 移行計画をコメント明記。④個人情報整理: EventConfigForm プレースホルダから個人名（西田/仁誠/大坪/由依）を一掃し汎用例（山田/太郎/佐藤/花子）に置換。service-overview.md festival 由来コピーから個人語彙削除。⑤未対応の Phase 1 タスクを handoff Next に明記（getSampleProps any 排除・Timestamp 型統一の徹底・guests:get sanitize・AnimatePresence DOM 最適化・PRESETS lazy 評価）。

理由: DEC-049 で機能・世界観は揃ったが、実機モバイルでは小さな違和感（CTA 重複・チケット視認性・矢印の縦並び崩れ）が体験を削っていた。同時に code-reviewer が「stale closure」「setTimeout cleanup なし」「Firestore Rules が認証チェックなし」など Phase 1 移行前に必須レベルの構造的指摘を出した。Phase 0 中なら影響を受けるユーザーは自分のみ、つまり「Phase 1 で他人を招く前に直す最後のチャンス」として 20 項目を 8 タスクに圧縮して一気に解消。Phase 1 開始の品質保証を、自分が最初のユーザーとして使い切るタイミングで完了させた。残課題（型整理・guests sanitize・AnimatePresence DOM）は handoff Next に明記し Phase 1 入り前の前提タスクとして可視化。

軽量メモリシステム導入 — PostToolUse + Stop フック + BRIEF.md + session-log.md

セッション引き継ぎコストの根本削減。①PostToolUse フック（Python）が Edit/Write/Bash/Agent/WebFetch/WebSearch をキャプチャし .context/obs/{session_id}.jsonl に追記。②Stop フック（bash → Haiku-4.5 呼び出し）が JSONL を読み .context/BRIEF.md（300トークン・5セクション: 現在地/前回/次/判断/地雷）を上書き更新 + memory/session-log.md（直近10件保持）に1サマリ追記。③session-start.sh 再構築: BRIEF.md 内容を additionalContext に直接注入（～4,750tok → ～300tok、94% 削減）。④ handoff-main.md スリム化（90行 → 35行、Decisions / Status セクション廃止）。⑤ session-log.md に「判断依頼はあったか」「訂正はあったか」フィールドを追加し RUBRIC.md B/D 軸の主証拠を機械化。⑥ 実装は TDD（7ユニットテスト全パス）で品質担保。

理由: セッション開始ごとに handoff.md + decisions.md を全件読む方式はコンテキスト逼迫の主因（最大 5,000tok 超）。Haiku が「前回作業をサマリして 300tok に圧縮 → 次回 Claude がそれを受け取る」という非同期メモリパイプラインを設計することで、コンテキスト効率とセッション連続性を同時に解決。B/D 軸が「推定」から「実測」に変わることで RUBRIC の信頼性も向上。記事化価値◎（「Claude Code のフックシステムを使ったメモリ自動化」「Haiku で安価なサマリパイプライン」が A 発信ネタになりうる）。

note 伸び悩み構造対策パッケージ — 流入導線整備 + プロフィール確定 + Zenn 準備

note 8本連続 PV 二桁〜100未満の構造原因（フォロワー薄期 + ニッチテーマ + X 告知のみで「初動スキの種火」が物理的にゼロ）をサク（外部リサーチ）+ ソウ（内部診断）並列で究明。即日打ち手: (1) memory/x-strategy.md §6 改訂（画像添付必須・URL リプライ運用・夜20-21時固定・1日1本）/ (2) write-article SKILL.md に問いかけ型タイトル必須化（完了形 NG）/ (3) note プロフィール案D'確定「考えながら作るのが好きで、不便があれば道具にしてしまう人。」/ (4) 既存8本の「次の記事への橋」テンプレ作成（essay→build循環構造／フォロワー薄期は深度戦略）。中期: Zenn 仕様調査完了（canonical 不可 → Zenn 一次公開推奨、jinc-tdil ハンドル先取り急務、build はタイトル+冒頭2点改修で転載可）、来週以降 add-platform で追加予定。

理由: サク（外部）とソウ（内部）が独立に「コンテンツ品質ではなく届ける構造が機能不全」という同じ結論を出した。プロフィール3案目で「建築設計者という職業ラベル」「招待状などの具体物」を排除し思考様式・行動原理だけで描く方針を確立（ブランディング憲法「中の人を出さない・TDIL は意匠としてのみ見せる」の延長）。記事化価値◎（「8本連続で伸びなかった構造診断」「note プロフィールから職業ラベルを外す判断」「Zenn クロス投稿の canonical 方針」が note 連載になりうる）。

wedpass LP 全面再設計（v4）— サービス全容ドキュメント基準のゼロベース再構築

v3 LP の魅力欠如を受け、表層のコピー磨き込みではなく サービス全容を上位ドキュメントとして起草 → 訴求軸を再定義 → worktree でゼロベース再設計 という構造的アプローチを採用。サクの競合リサーチを踏まえ、比較対象を「Web 招待状はあるが当日の受付はアナログのまま」という現状運用に再定位。`docs/service-overview.md`（10章/約5000字）が LP・機能拡張・Phase 移行のすべての上位資料。`git worktree add` で隔離環境を作り、Firebase Hosting の preview channel で実機検証してから本番デプロイ。10セクション構成（Hero→MogiriDemo→Philosophy→ReceptionFlow→ThemeShowcase→Customization→GuestJourney→AlsoIncluded→HowItWorks→FinalCTA）。Hero に PreviewCard + ScaleToFit による 4 テーマ実 UI auto-rotate。コピーは「初見の主催カップル」目線で再洗練（ジャーゴン排除・問題提起型ヘッドライン・主体明示）。

理由: v3 は機能訴求が競合と被り独自性が伝わらなかった。オーナー指摘「内輪言語・俯瞰視点でないと伝わらない構造」を受け、サービス全容を再認識した上でゼロベース再構築が必要だった。worktree + preview channel の組み合わせ（DEC-048 /deploy スキルの応用）により本番を汚さずに大規模再設計を試行できた。記事化価値◎（A 発信ネタとして「LP 再設計の判断プロセス」「サービス全容を上位ドキュメント化する手法」「worktree + preview 隔離検証」「初見ユーザー目線でのコピー再洗練」が note 連載になりうる）。

/deploy スキル新設 — デプロイ漏れ・検証漏れ・記録漏れの機械的防止

/insights レポート（24セッション分析）から繰り返し発生していた3つの摩擦パターンを解消。CLAUDE.md 追記・Hook といった「Claudeが覚えていれば有効」な受動的対策ではなく、スキル一本化（オーナー提案）で能動的強制力を持たせた。7ステップ構成: (1)実装チェック（ボタン削除なし・カラー・日本語テキストをオーナーと対話確認）→ (2)npm run build → (3)firebase deploy --only firestore:rules（差分不問・毎回必須）→ (4)firebase deploy --only hosting → (5)Claude Preview MCP でスクリーンショット検証 → (6)record-dec・failures.md 記録チェック → (7)完了報告。

理由: スキルは明示的に呼ぶため「ルールの形骸化」が起きない。オーナーがすでに record-dec・note-publish 等のスキルを日常使用しており採用摩擦ゼロ。7ステップで合計4摩擦パターンを1コマンドでカバー。

wedpass DesignEditor もぎり体験タブ統合 + UI/UX 改善 + リファクタ

結婚式 SaaS（Business B）のデザインエディタを磨き込み。フルスクリーンの MogiriModal を廃止し、もぎり体験を previewMode タブと並列の4つ目タブとして統合。StaffOverlay を preview area 内にレンダリングし、transform: translate(0, 0) で fixed positioning を containment（ヘッダー・ボトムパネル維持）。独自ダークバー廃止＝パーティクル選択を通常パネルに統合。dryRun prop で Firestore 書込スキップ。UI/UX レビュー 8件（HIGH 2 / MED 3 / LOW 3） 対応に加え、リファクタ 13点（死コード撤去・setTimeout 集約管理・useEffect 依存最適化・getPalette 重複統一・pointerEvents 一貫化・disabled 属性活用）。Chrome CDP 経由 Playwright で 11項目 E2E 検証パス。

理由: フルスクリーン Modal は編集中の文脈（パレット・レイアウト操作行）を消し、デザイン作業との往復コストが高かった。Firestore 実書込リスク（preview-guest ID で fail はするが eventId は本物だった）も解消が必須。死コード・メモリリーク・型ロンダリング（Object.fromEntries(Object.entries(...)) ×3）が累積していたためまとめて整理。752行 → 719行。

RUBRIC v1.2 初回採点実施 + スキル・エージェント定義を v1.2 に更新

failures.md 全15エントリに「解決区分」フィールドを追記し、C軸（障害自己完結率）を測定可能な状態に整備。RUBRIC v1.2 で初回正式採点を実施: 62/100（A14/B8/C25/D15）。C軸満点（93.3% 自己解決）、B軸最弱点（非介在率 15〜25%推定）。lp-build/SKILL.md Step 4.5e・tdil-auditor.md §採点モード・tdil-skills/CLAUDE.md の旧軸記述（v1.0/v1.1）を v1.2 形式に全面刷新。

理由: failures.md に解決区分がなければ証拠主義ルールにより C軸が永久に 0点。スキル定義が旧軸のまま放置すると次回 lp-build でレンが v1.0/v1.1 方式で採点するリスクがあった。整備 → 即採点 → 定義更新までを1セッションで完結。

採点ルーブリック v1.2 — 全軸を実率計測に刷新

v1.1 はカウント・累積ベースで「継続するだけで点が増える」設計欠陥があった。また採点軸が「自走度」ではなく「存在量・進捗」を測っていた根本的誤りをオーナーが指摘。全軸を評価期間内の割合（%）に刷新: A=自動発火率(20点) / B=非介在セッション率(35点) / C=障害自己完結率(25点) / D=コンテキスト継続精度(20点)。D軸マイルストーン廃止（進捗指標と自走度指標を分離）。評価期間は前回監査以降のみ。証拠なし推定は最低ランク適用。

理由: 「そもそもその採点軸は正しいのか？」というオーナーの根本的問い返しに対し、現行軸が「存在量・累積」を測るものに過ぎなかったことを認め、全面設計し直した。自走度の本質は「オーナー不在で動ける率」であり、B軸（非介在率）を最大ウェイト35点に置いた。

add-component スキル新設 + 採点ルーブリック v1.1 改訂（チェックリストのスキル化）

DEC-043 のチェックリスト拡充は管理ファイル肥大化リスクを孕んでいた。Claude Code のスキル設計（進歩的開示）と整合させるため、tdil-skills:add-component 統合スキル（skill / agent / extend / memory の4モード）を新設し、OPERATION.md のチェックリストを 約30行 → 5行 に圧縮。RUBRIC.md を v1.1 に改訂し、A軸スキル数の個別上限を撤廃（青天井） + C軸に管理ファイル肥大化指標 4点を新規追加（OPERATION.md と CLAUDE.md 群の行数で減点）。スキル化と管理ファイル肥大化を逆方向のインセンティブとして設計。

理由: スキルは進歩的開示で呼ばれた時のみ展開される。一方で管理ファイル（OPERATION.md / CLAUDE.md）はエージェントが毎セッション読む常時コンテキストに乗る。RUBRIC v1.0 の「スキル数上限15」はこの本質を見落としていた。月初の不整合を月末監査まで放置するのは現実的でない → lp-build の都度採点で C軸を即時検出する設計が正解。

スキル/エージェント追加・拡張時の整合性チェックリスト明文化

DEC-040〜042 で立て続けに発生した「スキル追加 → 4箇所反映漏れ」を受けて、OPERATION.md §変更操作別チェックリスト を拡充。既存「新しいスキル/エージェント追加」を強化し、新規に 「既存エージェントの責務を拡張するとき」（tdil-auditor の4モード化のような責務拡張パターン）と 「新しい memory ファイル/ディレクトリを追加するとき」（scoring/ のようなディレクトリ追加）の2チェックリストを追加。

理由: 第1回監査 M-02（OPERATION.md に tdil-reviewer 未記載）と同型の漏れが3つの DEC で連続再発した = チェックリストの網羅性が不足していた。漏れたまま放置するとレン採点で C軸（構造健全性）が下がる。柱6（構造指示前提確認）の予防的拡張として位置づけ。

図の codex MCP 画像化 + 自走度採点システム導入（ルーブリック v1.0）

DEC-041 の Mermaid 描画を codex MCP の images2 で静的画像化（ブランドトーン統一・レンダリング揺れ解消）。同時に「TDIL の自走度」を計測する 採点システムを導入。100点 = 完全自走（オーナー介在ゼロ）= 実質不可能。100点を目指すものではなく、1点1点積み上げる長期スコアという思想。4軸構成（A 自動化30 + B 記録25 + C 構造20 + D マイルストーン25）。レンに「採点モード」と「画像プロンプト出力モード」を追加し、lp-build スキルが Step 4.5d/e として呼び出す。初回採点 88/100（A28 / B17 / C18 / D25 / マイルストーン14/14達成）。

理由: Mermaid CDN は環境差・バージョン揺れがあり、ブランドガイドとして安定しない。codex MCP images2 なら generate-figure と同じスタックで保守一元化。採点は「100点を目指す競争」ではなく、いま何が機械化されていて何が人手に残っているかの物差し。LP に Score セクションを置くことで、毎回の lp-build で自然に振り返りループが回る。

Orchestration 可視化セクションを LP に追加（ハイブリッド設計）

仮想組織の構造（エージェント12 / スキル11 / hook フロー / 直近7日メトリクス）を lp/index.html の Orchestration セクションとして可視化。自然言語解釈 = レン（agents/*.md と SKILL.md を読解 → Mermaid 生成）、構造化データ集計 = スクリプト（settings.json から hook フロー / JSONL transcript から呼び出し回数 / トークン消費 / ツール使用）の役割分担。レンに Write/Edit 権限と「構造可視化モード」を追加。lp-build スキルに Step 4.5a/b/c を追加し、source mtime 比較によるキャッシュ機構を組み込み（変更時のみレン起動）。

理由: 「文章を読み解くもの = エージェント / 構造化データ集計 = スクリプト」の境界で分けるとメンテ性・精度・コストの三軸でバランスがよい。エージェント追加時はファイルを置いて lp-build を回すだけで自動的に図に出現する（ハードコードゼロ）。

audit-cycle スキル作成（監査改善ループのワークフロー化）

DEC-038 / DEC-039 で実証した「レン監査 → ナギ修正 → 再監査ループ → 100% 達成 → 最終報告書 → DEC 記録 → LP 反映」のワークフローを tdil-skills:audit-cycle として定義。8ステップ構成で月次自動監査・adhoc 監査の標準ワークフローに格上げ。最大ラウンド数 6（無限ループ防止）。自走ルールと例外（ブランド方針 / コンプラ / 指揮系統変更 / 公開発信内容のみオーナー判断必須）を明文化。Step 7 で record-dec スキルを呼び出すため、DEC 記録 → LP 反映までが自動連携する。

理由: DEC-038 / DEC-039 で動いたパターンを再現可能化することで、月次監査の運用コストを下げる。判断ルールを明文化することでナギの自走範囲を拡大し、オーナーへの確認負荷を最小化する。

監査改善ループ第1サイクル完走（4ラウンド / 100%達成）

レン第1回監査の 12件指摘を、追加で見つかった課題も含めて 100% 解決するまで「監査 → 修正 → 再監査」ループを反復。第1回 12件 → 第2回 5件（83%）→ 第3回 1件（92%）→ 第4回 0件（100%）の改善曲線で全指摘を解消。第2回で発覚した DEC-035/036/037 消失を handoff-main.md から復元（多重記録の有効性実証）。自己観察ルールを「タスク完了時の必須チェック」として明示化。最終報告書 memory/audits/REPORT_2026-05-08-09_full-cycle.md 作成。

理由: 監査は「見つけて報告して終わり」ではなく、修正 → 検証までで完結する。100% 達成という明確な完了条件を設けることで「やり残し感」を排除。Stage 3 移行条件「改善ループからの DEC 2件以上」を本サイクルで達成（DEC-038 + DEC-039）。残るは連続運用2ヶ月（2026-07-01以降）のみ。

レン第1回月次監査実施 + 監査ディレクトリ設計 + 12件一括修正

レン (tdil-auditor) が DEC-027 Phase 3 で予定されていた初回月次監査を実施。HIGH 3件・MED 5件・LOW 4件の計 12 件を指摘し、翌日に一括修正を完了。同時に memory/audits/ ディレクトリを新設し、各回独立ファイル + サマリインデックス分離方式に再設計。各レポートは「前回比較」セクション必須化（解決済み / 未解決 / 新規発生）で改善追跡可能に。種別タグ initial / post-fix / monthly / adhoc を運用。3回連続持ち越しは escalate 対象。

理由: 監査を1ファイル時系列追記で運用すると改善の追跡（解決率・持ち越し管理）が困難。各回独立ファイル化により「第N回 vs 第N-1回」の比較構造を作れる。第1回ではナギステージを Stage 2（定着） と判定（DEC 36件 / 連続運用7日 / 全6領域カバー）。

note-publish Playwright スクリプト技術確立（5記事テスト完了）

note.com エディタへの自動投稿スクリプトを安定動作させた。主要修正3件: (1) TOC 挿入の <br> 混入 → SelectionAPI + clipboard paste に変更、(2) 旧形式図マーカー <figure-N.png:cap> 未認識 → 正規表現を両形式対応に修正、(3) 非H2テキストの前要素結合 → last_empty チェック + h2_mode='new_p' で空P確保。5記事（essay-01/02, build-01/02/03）すべてで H2/figure/TOC 数がソースと一致することを DOM 検証で確認。

理由: ProseMirror は座標ベースの操作に敏感で、スクロール量によってカーソル位置がずれる。SelectionAPI による確定的なカーソル配置が唯一信頼できる方法。

tdil-publisher サブエージェント新設・note-publish 呼び出しフロー確定

note-publish skill の実行主体をソウ専属サブエージェント tdil-publisher として確定。フロー: オーナー → ナギ（slug 整理）→ ソウ（媒体判断）→ tdil-publisher（前提確認・投稿実行・DOM 検証・結果返却）→ ソウ → ナギ → オーナー。将来の X 等他媒体対応も同体制で拡張。

理由: タクミはエンジニアリング（スクリプト作成）担当であり運用実行は別担当が自然。発信実務はソウ管轄のため、ソウ部下の専任エージェントとして切り出した。

record-dec スキル作成

DEC 記録作業（decisions.md / handoff-main.md / agent-metrics.md への追記 + lp-build 実行）を record-dec スキルとして定義。「記録して」トリガーで 6 ステップを一括実行。

理由: 手動記録では抜け漏れが発生していた。スキル化により記録 → LP 同期 → デプロイの一貫性を保証する。

LP ブランドコンテンツ精査・修正

データソース（brand.md / character.json / tdil-project-memo.md）との照合で 10 項目を修正: Grey Mid #767676 統一・note ハンドル jinc_tdil・X ハンドル @jinc_tdil・フォント方針（見出し=Sans JP / 本文=Serif JP）・Business 優先順位表記削除・Business A フェーズ表記削除・opacity 廃止・Seed 枠追加・ポーズ名 Wink 修正・Tilt L/R 統一。

理由: LP をブランドガイドとして機能させるにはデータソースとの整合が必須。フォント方針（本文=Serif）は「エッセイ/解説型」ブランドトーンに直結。

LP インフラ・ワークフロー再設計

engineer/lp-dev/ を廃止し lp/ を Firebase Hosting 公開ディレクトリに一本化。アセット（logo/character）は TDIL ルートに据え置き、シンボリックリンクで参照。lp-build スキルに deploy ステップを追加し、データ更新 → lp-build 呼び出し一回で deploy まで完了する設計に変更。

理由: 二重ディレクトリによるメンテナンスコストと同期忘れリスクを解消。memory/ を唯一のデータ SSOT として維持しつつ、LP はそのレンダリング結果として機能させる。

tdil.dev カスタムドメイン公開

Spaceship DNS に A レコード（199.36.158.100）と TXT レコード（hosting-site=tdil-lp）を設定。Firebase Auth 承認済みドメインに tdil.dev を追加。Google Auth（jin93.tdil@gmail.com のみ許可）付きで https://tdil.dev が稼働。

理由: 内部ブランドガイドを TDIL 組織ドメインで管理することで URL の一貫性を確保。

ライターのコウ人格剥奪 → tdil-writer 匿名サブエージェント化

コウ（ライター）の名前・人格・ペルソナを全て剥奪。write-article skill 専用の匿名サブエージェント（tdil-writer）として再定義。戦略はソウが担い、tdil-writer は文章生成のみに特化する。

理由: 人格があるとサブエージェントが自律的に判断しすぎる懸念。write-article skill の枠外で動く必要がない。

7柱の組織再設計プラン採用 — Phase 1+2 実装完了

2層部門構造・横断レビュー（柱2）・監査役レン（柱3）・判断材料蓄積（柱4）・Decision Log必須化（柱5）・構造指示前提確認（柱6）・LP自動同期（柱7）の7本柱を採用。ナギステージを3段階から6段階に細分化。

理由: 旧ADR形式ではDEC連番管理ができず、監査・ステージ判定に不足。7柱を先に制度化し、実運用で育てる方針。

仮想TDIL.inc 4エージェント構成の確定

秘書 → (リサーチャー+広報) → エンジニアの段階的構築。メモリは TDIL/memory/ に集約。リサーチャー×広報は並列起動原則。エンジニアには孫サブエージェント起動（PM化）を許可。

理由: メモリ基盤が育つ前に全エージェントを投入しても精度が出ない。秘書を先行させることでコンテキストの質が上がる。

TDILフェーズ設計 — 時軸なし・フェーズ駆動

Phase 0（仕込み）→ Phase 1（最初の声・試験提供）→ Phase 2（事業稼働・課金）→ Phase 3（振り返り・次の柱）。時軸は固定しない。

理由: ゴールは変わりゆくもの。「次はこれ」と言える状態を維持することが重要。やりたいことをやる姿勢が前提で、収益はその結果。

A + B 地続き発信戦略

招待状アプリ（B）の開発過程を「建築設計者がAI駆動で作った」文脈でA発信の実例として活用。AとBを地続きにする。「個人イベント用に作った」事実は出してよい、式の詳細は伏せる。

通販検討サービス: ブラウザ拡張アーキテクチャ

Chrome Extension（Manifest V3 + CRXJS Vite）+ Webアプリの二部構成。スポンサー非表示 + ピック→比較が差別化。サブスク課金のみ（アフィリエイト排除）。

秘書ペルソナ: フラット → やわらかく引き出すスタイルに変更

会話テンポを優先。情報収集より思考の深掘りを優先する引き出し方に変更。