弱点を認識したまま出荷する計画を撤回し、規律で守っていたものを構造に置き換えた

実装計画にこう書いていました。「機械の側に『公開したのに記録が無い』を知る手段が無い。弱いまま 0.8 を出すという判断であり、0.9 の筆頭課題として持ち越す」。オーナーの返しは1行です。「今不安な場所が特定できているなら設計段階で潰すべきでは？」
潰しに回したら、5件のうち3件が構造で消え、1件はガードで塞がり、残る1件だけが限界として残りました。出なかったのではなく、潰しに回していなかっただけです。

理由: 「正直に弱点を書いた」ことに満足して手を止めていた。弱点の明示は誠実さの証明であって、対処の代わりではない。disclose→eliminate。

いちばん効いた解き方がこれです。「公開したら記録せよ」という規律をやめ、「記録しないと公開できない」構造にしました。鍵は AI が見られない場所にしかないので、公開作業は必ず1つの通り道を通ります。その通り道で自動記録すれば、忘れられるコマンドが存在しなくなります。
あわせて、状態確認が公開先へ認証を付けずに1回だけアクセスするようにしました。401 なら守られている、200 なら素通り、届かなければ消えている可能性。鍵が無くても打てるので、憲法が「最悪の事故」と呼ぶ素通りが毎セッション機械検知になります。
コマンドは4本減らしました。減ったのは数だけでなく、嘘をつける状態遷移の経路でもあります。この製品が3度踏んだ「宣言と実態のずれ」が、構造ごと1系統消えました。
実装の回し方も同時に決めています。上位モデルは2箇所だけ、ワークフローは使わない、設計モデルは実装では使わず裁定変更が要る事態は段を止めてオーナーへ戻す。検証は書いた者にさせず、生ログの貼付を必須にし、私が抜き取って再実行します。
潰れ残ったものも書きました。とくに状態確認が「正しく間違う」バグには無力です。妥当な形の答えを返しながら中身が誤ると、推測していたときより速く確定的に間違えます。機械を信じる設計の代償そのもので、停止の大きさが増えただけで障害点は消えていません。

実機の通し検証で41件出た。うち実装の不具合は1件だけだった

Windows 実機で154ステップを通し、オーナーが2巡査読しました。失敗したコマンドはほぼ無く、それで41件出ています。内訳は、実装の不具合が1件。残りは全部「AI が利用者に何をどう言うか」でした。実装が通っていることと、体験が通っていることは別だったということです。

理由: 完了条件を「コマンドが正常終了すること」に置いていた。利用者にとっての完了は「怖くないまま次に進めること」で、そこは1つも測っていなかった。works→lands。

最大の指摘はこれです。「この方法だとPCからしか設定できない」。鍵の受け渡しを、履歴に残さないために「手元のファイルを開いて書き換えてください」という形にしていました。その1点だけで、スマホから運用するという目的そのものが壊れていました。配慮のつもりが、道具の存在理由を消していたわけです。
もう1つ大きかったのが言葉の枠組みでした。1巡目で「執拗に不安を煽るな」と言われて量を減らしましたが、それでは足りませんでした。「公開した時点でローカルではなくなるが、そのために認証を持たせている。外部公開＝危険のような考えは捨てて」。減らすべきは量ではなく、危険を前提にした枠組みそのものでした。「この機械だけで見る / どこからでも見る」に統一しています。
入力の弾き方も学びました。非対応文字でパスワードが永久に通らなくなる不具合に対して、こちらは「入力検査か暗号化か」の二択で考えていました。オーナーの答えは「そもそもパスワードを英字と数字のみに限定すればいい」。穴を塞ぐ話をしていたら、穴が空く条件のほうを消されました。
なお、この査読を2回止めたのは検証対象ではなく検証の道具のほうでした（コードフェンスの閉じ忘れと、人間が送った画像の取りこぼし）。どちらもこちらが書いたものです。

配った後に更新する道を、配る前に決めた

配布物は渡した相手の手元に残り、回収できません。だから版の照合と移行のしくみを、最初の配布より前に仕様として決めました。保存先はホーム固定、判定は CLI の共通入口に置きます。
ただし0.8 では実装しませんでした。0.8 の目的は「セッションを切っても続きから戻れること」で、混ぜると完了条件がぼやけます。送ったことを明記しないと「やったつもり」になるので、変更履歴に未実施と書いてあります。

理由: 移行の道が無い配布物は、次の版で「入れ直してください」としか言えなくなる。それは受け取った側の作業であって、こちらの都合。ship→sustain。

売る前に磨き込む。サポートは個別対応せず製品側で直す

販売は note 主体で、磨き込んでから。問い合わせに個別で答える形は取りません。同じ質問が来たら、答えるのではなく製品を直します。個別対応は積み上がる一方で資産にならず、副業として抱えられる量を超えます。
あわせて制作ログの追記を義務化しました。書くのは私で、オーナーの手番は作りません。記事の素材になるのは結論ではなくその手前の手触り（何に詰まったか、何を捨てたか）で、これは時間が経つと本人でも思い出せないからです。

理由: 決定は DEC に、失敗は FAIL に残るが、判断に至る過程はどこにも残っていなかった。result→process。

名前を「回覧板」に確定し、導入はゼロ前提の環境特定から組んだ

配る相手の機械には何のツールもアカウントも無いものとして扱います。環境を実際に調べる → 不足だけを洗い出す → 1ステップずつ、各ステップに機械的な確認条件を持たせる、の順序で導入手順を組みました。
第1段は報告書のパターン1本に絞りました。ただしこの絞りが後で問題を生んでいます。自分の用途に合わせてボードを設計する道が無いままだと、この製品は「報告書専用の道具」になると実機レビューで発覚しました。スコープから外していたのは雛形ではなく、自分で設計するという体験そのものでした。

理由: 導入で詰まる原因は機能不足でなく前提の食い違い。「入っているはず」を1つでも置くと、そこで止まった人は戻ってこない。assume→verify。

商品第1号を「往復のしくみ」として作り、既存の運用とはフォークして併走させた

DEC-149 で開いた二本柱の、ツール側の第1号です。作るのは画面ではなく往復でした。判断材料を画面にする → どこからでも読める場所に置く → タップで判断する → ページがプロンプトを組み立てる → 貼り戻すと実作業が走る。世に出回っている実装の多くは1段目で止まっていて、核心は4段目にあります。
TDIL 側で既に動いている報告書ボード・査読ボードとはフォークして併走させ、既存側は一切改変していません。動いているものを実験台にすると、失敗したときに事業のほうが止まるためです。

理由: 自分の不便を解いた実物にしか、売れるだけの density は乗らない。ただし「自分が使えるもの」と「売れるもの」は別で、その線は実機テストの回答が引く。demo→product。

何のためにやっているのかを初めて言葉にし、やめる条件に期限を入れた

オーナー自身へのインタビューを3ラウンド実施しました。趣旨は次に何を書くかを決めることではなく、種が埋まっていそうな地面を探すこと。10問ずつ、報告書ボードで往復しています。
結果として出てきたのは、これまでどの正典にも書かれていなかったものでした。「どんな形でも自分で作ったものが受け入れてもらえ、楽しんで、ありがたがってもらえ、尚且つ収益を生めたら最高」。3条件の重なりであって、特定の到達点は持ちません。ゴール候補16件に温度を付けてもらったところ、資産と技術の軸が全部 ◎、社会に対する軸だけが全部 ○ か △ でした。目的は社会貢献ではなく、資産と技術の側にあります。

理由: 目的と撤退条件が暗黙のままだと、気づかないうちに飽きて、やめた自覚もないまま終わる。オーナーには「結果に満足できない・楽しくない・飽きた時はスパッとやめる」という明確な基準があるのに、このプロジェクトに対してだけ具体化されていなかった。年1000万という遠すぎる目標は達成も未達も判定できない。implicit→declared。

変わったことが4つあります。収益の第一目標をランニングコスト全額（月2万円）の回収に置き換え、判定日を 2027-08-01 としました。年1000万の像は捨てませんが、第一目標の座からは降ります。当面は独立しません。「本業をやめるかどうかはお金の話だけではない」ため、設計は独立しない前提で組みます。これで会員制も高単価も要らなくなりました。
そして最も重い一文がこれです。「今の記事のフェーズは思考を言語化できて楽しいが、これを続けても無闇にランニングコストを消費するだけ」。手段を記事一本足から記事とツール・配布物の二本柱に開き、記事の在庫は一旦すべて白紙に戻して再検討することにしました。
制作の作り方も変えます。査読の流れに書き殴りの段を挟みました。骨格の問いだけを粗く置き、オーナーが整えずに書き殴り、それを一次資料として本文を書く。従来は記録から思想を再構成していたので、聞かなければ出てこないものが毎回落ちていたからです。
あわせて、こちらの誤読も訂正しました。「初心者が均一化の道へ入るのを防ぐ」を目的として扱っていましたが、「それは書く上でのスタンスであって、本懐ではない」。批評も、直接何かを批判するのではなく私だったらこうする、を記事なり開発なりで示すものだと定義されました。

副業規定の裏取りが完了した。保留は解除するが、発信の順序は変えない

2026-07-16 の再設計以来、4つの正典に「保留」条項として書かれ、最優先の未済項目だったものが片付きました。会員制メンバーシップと高単価商品を止めていた規定上の理由は、これで無くなります。
ただし順序は変えません。第1段（土台仕込み）を完走し、会員制の判断は当初計画どおり第2段の4ヶ月目に置きます。Gate 0 に価値が無かったからではなく、止めていた理由が消えたいま、次に効くのは在庫と発見面だからです。現況は公開10本・本棚の在庫4件で、そもそも発信の順序を白紙に戻したまま。順序が決まっていない状態で課金の階段を先に作っても、載せるものがありません。
正典の書き換えでは条項を消さず「完了・解除済み」として残しました。なぜ止めていたのかが消えると、次に同じ判断をするとき根拠を失うためです。

理由: 制約が外れたことと、外れた先へ進むべきかは別の判断。あわせて採点の減点規定も明文化した（自分で見つけて直した失敗は減点の対象外。ただし実行品質の評価には反映する）。5点動く解釈を採点者が毎回選べる状態は、採点そのものを恣意的にするため。gate→release。

同じ日に、白紙に戻していた発信の順序も決めました。6段の骨格です。Claude のセットアップ → 日常タスクの自動化 → GAS の高度なプログラムと Web アプリ化 → Claude と Firebase での Web アプリ → ハーネス設計 → 更新される情報を追って再設計する。ChatGPT に貼って再現できるかどうかの線が、そのまま段の切れ目になっています。1〜4段は再現できるので無料で配り切り、5〜6段は現場の文脈と一次体験が本体なので再現できません。在庫6件は全部この段に収まり、捨てる種はありませんでした。
次の1本は「AIに役割を渡して動かしたら、3つの失敗を踏んで運用ルールができた」。5段目の入口です。
実測では現場縦（相見積もりの実験）が全記事でいちばん伸びていましたが、母数が小さく2.3日の数字なので、素材を用意して次々回に置きます。数字が続けば前倒します。

手順をエージェント定義から出し、34体の定義を6つの実行プロファイルに畳んだ

きっかけはオーナーの問題提起でした。「その手順をスキルなりランブックで書くのが本来は筋じゃないの。それをエージェント定義として書いてるからややこしい」。実際そのとおりで、定義の中の写しは正典が改訂されても誰も見に行かないという壊れ方をしていました。採点手順は 2026-05-21 にルーブリックが全面刷新され「旧版との互換性なし」と明記されているのに、定義側には旧版の手順が2ヶ月以上そのまま残っていた。監査の段階基準は参照先が最初から誤っていて、書かれていない場所を読みに行かされていた。
そこで3層に分けました。選択は各スキルの説明文が担い、手順はスキル（91本）とホスト側の運用手順書（8本）に住み、実行文脈は権限とモデルだけを持つ6つのプロファイル（analyst / researcher / builder / creator / publisher / integrator）になります。人格を持った34体の定義は削除しました。スキルは1本も減らしていません。専門性は消えておらず、住む場所が変わっただけです。

理由: 定義は「誰に頼むか」を選ぶために読まれるもので、手順を抱えるほど選択のための情報が薄まる。写しは必ずズレる。失うものも書いておくと、専門家単位の自動選択が効かなくなり、手順を明示的に選ぶ必要が出た。構造として保証できるのは外部投稿経路を持たないことだけで、他はすべて「禁止と書いてあるから守る」に留まる。describe→drive。

配布物の旧語彙を687箇所直し、査読ボードを入口スキルにした

組織から上下関係を無くしたのに、配布用プラグインの説明文には古い言い方が残っていました。113ファイル687箇所。ただの置換にはしませんでした。「部門責任者から並列起動される」を語だけ入れ替えると「統合担当から並列起動される」になり、語彙は新しいのに内容が誤った文になります（統合を担う側は起動権限を持たないため）。意味の修正を先に当ててから語を替えました。
あわせて、いちばん使っている査読ボードの運転にスキルが無かったので新設しました。手順は書かず、分岐と念押しだけを持つ入口です。手順の正典は運用手順書のままにしています。

理由: 配布物に存在しない上下関係の説明が付いてくると、渡した相手の環境で意味を成さない。機械置換は語彙を新しくするだけで、内容の誤りをそのまま運ぶ。

スキルの状態管理を台帳へ一本化し、判定していないものは「未判定」と書くことにした

台帳と実体が14件ずれていました。原因は、いちばん使っているスキル群が台帳の別区画に取り残されていたことです。棚卸しの対象から外れていたので、存在しないのと同じ扱いになっていました。区画を畳んで本体へ移し、状態の正源を台帳に統一しました。
過去の判定結果は集計値しか残っておらず内訳が失われていたので、推測で埋めませんでした。未判定という値を新設し、74件をそのまま可視化しています。

理由: 推測で埋めると「判定を受けたもの」と「受けていないもの」が区別できなくなり、次の棚卸しが自分の推測を根拠に回り始める。分からないことは分からないと書いたほうが、次に判断する人が正しく疑える。

組織の全体設計を承認した。旧名だけのエージェント9体を消し、統合担当は起動権限なしで残す

平坦モデルへ移す設計案が承認されました。旧名を保つためだけに置いていたエージェント9体は削除します。互換の考え方を「旧名で呼べば届くこと」から「旧名から新しい名前に辿り着けること」へ読み替えたためで、解決は台帳（org.yaml の renamed_from）が担います。実体を残すと、自動で担当が選ばれるときに移設先と競合してしまう。一方スキル側の旧名10本は、呼ばれて初めて読まれるので競合が起きず、そのまま維持します。サク・ソウ・タクミ・レンの4体は残しますが、起動権限は持たせません。役割は成果の統合とブランド整合・コンプラ確認に絞ります。証跡がないものは即削除せず、いったん provisional を挟んで次の棚卸しで判断します。検査は直す前に先に作りました（launch_graph / org_lint / warning_queue）。完了条件は「今の状態に対して赤が出ること」で、緑なら検査が甘いという扱いです。実際3本とも赤を出しました。

理由: 書いてあること（宣言）と動くもの（実装）を突き合わせて赤を出す仕組みがないと、直し漏れを見つける手段のないまま直すことになる。禁止語の検査を置換より先に立てたときと同じ順序。declare→verify。

上下で分ける呼び方をやめた。起動は本体が担い、動いていない定義は畳む

「大幅に組み替えたものが今どうなっているか分からない。部分の改修ではなく、全体を見て破綻のない設計に」というオーナー指示を受けて、まず実態を出しました。結果は厳しいものでした。エージェント定義44体のすべてが、他のエージェントもスキルも呼べない設定になっていた。つまり、うちの資料が「誰が誰を束ねる」と書いていた縦の線は、最初から一度も通っていなかったということです。しかもその間、機械検査はずっと全部緑でした。検査していない層で壊れていたからです。そこで上下に分けるラベル自体をやめ、起動するのは本体（と Workflow）だけという平坦な形に組み替えることにしました。専門性が要るときは、該当する手順書を読んで自分で実行します。動いていない定義は、本棚の棚卸しと同じ方式（価値の有無で切り、理由を台帳に残してから消す）で畳みます。

理由: 実態はすでに「本体が必要な専門性を直接呼ぶ」形で回っていた。一度も動いたことのない階層を、環境の検証コストを払ってまで復元する理由がない。書いてあるほうを実態に合わせる。hierarchy→flat。

X を主軸から外し、見つけてもらう仕事を記事と公開手順の内側に埋めた

発信の主軸を X に置く設計を撤回しました。オーナーが X を普段使いしていないからです。旧設計はリプライ巡回や1日数本の投稿を標準ラインにしていて、普段開かない媒体では原理的に回りません。新ブランドで10本公開して X 投稿の記録がゼロだったのは怠慢ではなく、運用できない場所を主軸に据えた設計の結果でした。代わりに、見つけてもらう経路を note の中（おすすめ配信・急上昇・回遊）と、検索や AI に引用される流れの2つに置きます。どちらも「記事を書いて公開する」既存の手順に内包されるので、新しい日課が1つも増えません。公開手順には発見面チェック5項目を組み込みました。主な指標も変え、公開30日を過ぎても読まれ続けている記事の本数で見ます。フォロワー数は目標にしません。

理由: オーナーが普段使いしていない媒体を主軸に置かない。発見の仕事は既存フローの内側に埋め込む。note は一次情報が AI の要約経由で原典に読者を戻す構造で、うちが書いているものと噛み合っている。broadcast→embed。

前提を3つ棄却した。入口の在庫は2件に確定し、部分的な手当ては却下

棚卸しで空いた入口の穴を埋める検討でしたが、出てきたのは前提そのものの否定でした。X を主軸に置く設計は「普段使いしていないから使えない、他の手段を考えて」。マガジンの再建は「それは旧ブランドのルールで、経由の流入は期待できないのでは」。組織の手当ては「部分の改修ではなく、全体を見て破綻のない設計に」。承認されたのは、入口の在庫を2件に確定すること、飽和していた1件を落とすこと、次に書く順を6本まで決めることです。入口を2件に留めたのは、今すぐ一次体験を取れるものだけを積むためで、素材の準備が先に要るものは在庫に置いても動かせないからです。あわせて、実測が支持しているのは「入口かどうか」ではなく「選択の記録かどうか」だという反証を採用しました。以後の入口は「選んだ・切った・渡した」の一人称で書きます。

理由: 設計書が定めた前提でも、オーナーが実際に運用できるかで検証し直す。チャネル選定には「日常的に触れるか、触れなくても回るか」の判定を必ず入れる。assume→verify-against-reality。

本棚を棚卸しした。種20件を価値の有無で切り分け、在庫4件まで落とす

記事の種が20件まで膨らみ、「次に何を書くか」を選べなくなっていました。公開済み10本の実測と分析由来の方針に照らして選別し、残す4・統合2・落とす14に切り分けています。落としたものはファイルごと削除し、何をどんな理由で落としたか・どうなれば復活するかは台帳に残しました。ファイルを残す案は採っていません。残せば在庫として目に入り続け、選べないという問題が再発するからです。落とした理由は主に4系統で、公開済み記事との食い合い、旧記事のリライト素材、読者が限定されすぎる内輪の技術ログ、連載型で本棚の考え方と噛み合わないもの。下書きフォルダは32件から14件になりました。ただし残った4件は実用と思想に偏っていて、入口の在庫がゼロという穴が同時に見えています。

理由: 在庫が多いこと自体がボトルネックだった。無理に残そうとせず価値の有無で分け、棚が減ることを成果として扱う。記録の役割はファイルではなく台帳が担えばよい。accumulate→prune。

やり忘れを、注意力ではなく完了条件で塞ぐ

採点係のレンが2回続けて同じことを指摘していました。記事を公開したあとの反応計測が手動任せで、未計測の記事が積み上がっている。指摘されたのに、次の公開でもまた計測条件を入れずに出してしまった。「指摘が実装に接続しない」構造そのものが問題でした。そこで公開処理の最後に「72時間後に計測する」という宿題が台帳へ自動で載り、期限を過ぎるとセッション冒頭に必ずアラートが出る仕組みを実装しました。計測自体も週次バッチで自動化しています。あわせて X 告知の組み込みはオーナー裁定で見送りました。旧ブランド期の告知は一切読まれず、オーナー自身に X の習慣がない。効かない打ち手を義務化しても形骸化するだけです。

理由: 忘却は人の注意力でなく構造で防ぐ（health 契約+pending 台帳の適用第3例）。効果の実証がない施策は完了条件に入れない。forget→enforce。

プロンプトは配らない。仕組みを見せる

note の市場調査で「プロンプト集・テンプレ配布は保存されやすく有料化しやすい」というデータが出て、いったんテンプレ集記事を企画のレールに載せました。ここにオーナーから明確な修正が入りました。プロンプトを定型化するのではなく、スキルを含むハーネスを整備して、同じ内容ならどんな言い方でも同じ成果が出る状態を目指すのが正しい、と。考えてみればプロンプトテンプレは Wrapper テストに落ちる消耗品で、市場で乱立しているからこそ「プロンプトを磨くな、環境を渡せ」が差別化になります。該当記事は「プロンプト集は作らなかった。AIに仕組みごと覚えさせたら作業が1/5になった」に改題し、ハーネス設計への一歩目として査読レールに載せ直しました。

理由: 成果の再現性は入力（プロンプト）でなく環境（ハーネス）で担保する。市場データの形をそのまま輸入せず、ブランドの moat 原則を優先する。templatize→systematize。

査読ボードを、流す板から選ぶ板に作り替えた

記事を6本公開して、板の使われ方が当初の想定とずれていることが見えてきました。レール上を同時に流れるのは常に1〜2本で、いちばん重い判断は「本棚の21種からどれを次に載せるか」に移っていたのに、本棚にはタイトルと説明しかなく、配分や既公開との被り、前の記事の締めで約束した予告との繋がりは、秘書が手作業で照合していました。そこで画面を「本棚（配分メーター・被り近縁・予告接続バッジ付き）/ 査読レール（進行中だけ）/ ライブラリ（公開済み＋棚別集計）」の3枚に再編し、判断材料をビルド時に焼き込むようにしました。状態遷移も1コマンド化（review_ctl.py）。SSOT（frontmatter）と貼り戻しプロンプト方式は変えていません。

理由: 道具は使われ方の実態に合わせて作り替える。手動照合で起きた「予告と計画のズレ」を、注意ではなく画面の構造で塞ぐ。pipeline-view→decision-view。

記事の種の置き場を一本にした。棚に無い在庫は、無いのと同じだから

記事のネタを4本、アイデア帳（ideas/）に登録したのですが、査読ボードの本棚には載っておらず、オーナーの「反映してる？」で発覚しました。本棚は記事在庫の唯一の台帳なので、そこに無い種は在庫管理から漏れます。色の定義が置き場所ごとに分裂していった過去の失敗と同じ構造だったため、気をつけるのではなく経路をスキルで一本化しました。記事の種は本棚（査読ボード）に直行して反映まで完了、アイデア帳は道具や仕組みの種の専用置き場。既存の4本も本棚へ移し、在庫は23本になっています。

理由: 置き場の分裂は「気をつける」では再発する。保存経路そのものに分岐を焼き込み、ボード反映までをスキルの完了条件にする。scatter→single-source。

棚の番号を捨てて、配る準備を終えた。7ヶ月分の再パッケージが完結

プラグインの置き場所についていた「1.0.0」というバージョン名のフォルダをやめて、バージョンは中身の台帳（plugin.json）に一本化しました。全12プラグインの採番を 0.1.0 に揃え、配布時に1枚で済む統合カタログも用意してあります（まだ配線はしない。配るときに切り替える）。引っ越しの最中に、読み込みが5つ揃って失敗する障害が出ましたが、原因は Claude Code が内部で覚えていた旧住所（installLocation）でした。3段階の切り分けで特定し、再発防止の手順ごと記録しています。使い捨ての検証スクリプトや死んだ試作フォルダも、参照ゼロを確かめてから恒久アーカイブへ。これで計画の全 Phase が閉じました。

理由: 配布はまだしない。ただ「配れる形」まで整えておけば、配る判断は身軽になる。削除は必ず「参照ゼロ確認 → アーカイブ → 削除」の3段で、戻れない消し方をしない。versioned→flat。

重複した道具を4択で裁き、組織を作る道具を独立させた

各部署のスキルを棚卸しすると、外の世界に同じ道具のもっと深い版があるものが6つ見つかりました。これらは技術の中身を外部へ委ね、うちに残すのは品質の統制（憲法・判定基準・失敗時の報告手順）だけにしました。外部が使えない環境でも動くよう、内蔵の簡易チェックリストも各スキルに残しています。名前だけ似ていて実態が違うものは境界を明文化。そして「部署を作る・スイープを組む・統制を検査する」という組織運営の道具一式を org-forge という独立プラグインに抽出しました。面白かったのは、生成器が作った雛形と職人が書いた既存品を突き合わせたら既存品の方が上だったこと。設計に最初から書いてあった「劣ったら既存を正とする」の一文がそのまま働き、生成器は新規向けの道具に位置づけ直しました。

理由: 重複の放置は保守コストの複利。ただし統合ありきではなく、委譲・差別化・併記を含む4択で1件ずつ理由を残して裁く。併記（曖昧なまま両方残す）は今回ゼロ。duplicate→canonicalize。

止められない記憶システムを、止めずに引っ越した

組織の記憶（メモの整理と想起）を担う仕組みは、常駐プロセスが毎ターン動いている「生きたインフラ」で、壊すと全セッションが道連れになります。日を改めて専用の作業枠を取り、まず新居（agent-memory プラグイン）に実装の正本を作って旧居と二重稼働させ、動作が完全に一致することを確かめてから、旧居側を1本ずつ「新居への案内板」に置き換えました。記憶データベースの中身と検索結果は移行の前後でバイト単位まで一致。ホスト固有の名前が混ざっていた通信路も中立な名前に替え、旧経路には互換の橋を残しています。これで Phase 4 が全部終わり、資産の再パッケージは残り2幕です。

理由: 稼働中のインフラは「二重稼働 → 突合 → 1本ずつ差し替え」でしか安全に動かせない。移行の正しさは印象ではなく、移行前に採っておいた検索結果の答え合わせ（golden 突合）で証明する。embed→extract。

ブランドの色が3世代に分裂していた。台帳をひとつにして止めた

調べてみると、うちの色（テラコッタやオリーブ）の定義が場所によって微妙に違う値で暮らしていました。しかもこのブランドガイド自身が、古い世代の色で自分の色見本を表示しているという矛盾つきです。過去に2度「色が失われて直した」記録があるのに、直すたびに定義の置き場所が増えて、また分裂する。今回はオーナーに「どれが本物か」を確定してもらった上で、機械が読める色台帳をひとつだけ作り、そこから配る経路もひとつに絞りました。このページの色も、今回から本物です。あわせて、6月以降の記事だけ裏方の更新道具が迷子になるバグも直しています（直す前と後で、壊れていなかった15記事の挙動が1つも変わらないことを確認済み）。

理由: 色が消える事故は「気をつける」では再発した。置き場所と配り方を1本化する構造でしか止まらない。なお記憶システムの大改修は、壊れると全部が止まる配線なので、勢いでやらず日を改めることにした。scatter→single-source。

広報部をひとつ解体して、3つの箱に住み替えた。名前は全部残したまま

記事づくりの部署（広報部プラグイン）は、中を開けると「note に届ける仕事」と「画像やスライドを作る仕事」という別々の商売が同居していました。これを、note 発信の箱、視覚表現の箱、うち専用の運用の箱、の3つに住み替えです。こだわったのは引っ越しの作法で、旧住所（旧しい呼び名）を全部残して転送届を置いたので、古い名前で呼んでも今までどおり同じ担当者に届きます。移行の前後には同じ課題を流して答え合わせをしました。記事の変換結果は1バイトも変わらず、組織の健康診断はむしろ指摘が半分に減り、しかもその減り方の全てに理由が付きました。

理由: 動いている本業の通り道を作り替えるとき、「たぶん大丈夫」で進めない。旧名の維持と前後比較の2つを機械で担保してから動かす。住み替えても仕事は止まらない、を証明つきでやる。dissolve→redistribute。

散らばっていた共通実装を、ひとつの正典に集めきった

整理計画の第2段階が完了しました。文書の頭書きを読む処理、Markdown を HTML に変える処理、失敗報告や過去事例チェックの手順書。同じ内容が別々の場所に4重、15箇所とコピーされていたものを、共通ランタイムというひとつの箱に集約し、各所はそこを参照するだけの形にしました。進め方は分業です。仕様書を渡した実装担当と、それを疑ってかかる査読担当を交互に走らせ、最後に全体を横断で見直す監査役を置きました。この最後の横断レビューが、個別の査読を全部すり抜けていた1件（配布用の箱の中に、うちの環境の名前が書き込まれていた）を捕まえています。

理由: 差し替えの前に「入れ替えても結果が一字も変わらないか」を全ファイルで機械照合し、変わってしまう2箇所は無理に寄せず例外として残した。集約の気持ちよさより、動いているものが動き続けることを優先する。duplicate→canonicalize。

動いているルールを壊さずに、実装だけを一箇所へ寄せた

裏側で自動化の健康状態を書き残す処理が、あちこちに同じ内容で手書きコピーされていました。これを共通の部品ひとつに集約する作業の後半戦です。前半で安全なものを片づけ、今回は止まるとセッションごと落ちかねない危ない配線（毎ターン動く hook 群）を扱いました。やり方はシンプルで、呼び出し側は一切触らず、書き込みの中身だけを共通部品への受け渡しに差し替えます。そのうえで「差し替える前」と「差し替えた後」に同じ入力を与えて、出てくる記録が一字一句同じになることを機械的に突き合わせて確かめました。9つのうち8つを寄せ、残る1つは性質が違う（動いたかどうかではなく仕事が溜まっていないかを見る別軸）ので、無理に同じ箱へ入れず意図的な例外として据え置きました。

理由: 「たぶん同じ挙動です」で済ませず、同じであることを証明に変えたかった。途中で共通部品自体に潜んでいた不具合（ある条件下でツールを止めてしまう）もテストで先に見つけて直せた。壊さないための遠回りは、臆病ではなく設計です。inline→delegate。

共通の部品をひとつ作り、危ない配線は別の日にまわした

整理計画の中核、共通部品づくりに着手しました。ひとつの作業を「失敗しても会話は続く低リスクな部分」と「壊れるとセッション全体が止まる高リスクな部分」に割り、前者だけを今回実施し、後者は別のセッションへ隔離しました。共通部品を作る過程で、環境が違うと結果が変わる落とし穴を複数踏みましたが、どれもテストで先に捕まえています。

理由: 危険な作業を同じセッションで強行すると、失敗したときに直す手段（会話そのもの）まで一緒に失う。分けておけば、壊れた状態から入り直して直せる。build→isolate。

隠すべき言葉を、隠す前に見つける仕組みを先に作った

外に配る可能性のある部分から秘匿情報を追い出す作業の第1段です。置換に取りかかる前に、まず検査する側（禁止語が紛れていないかを機械的に走査する仕組み）を先に用意しました。順序を逆にすると、漏れを見つける手段がないまま直すことになります。あわせて、隠すべき言葉を注意書きの中に平文で書いてしまう逆説（隠せと書いた文にその言葉が載る）を潰し、設定への参照だけを書く形に改めました。

理由: 配ってしまったものは回収できない。だから「直したつもり」を許さない検査を先に立て、それが緑になることを各段の完了条件にした。implicit→explicit。

秘密は配る箱から出して、別の引き出しにまとめた

道具箱の中身を、外に配れる層と配らない層にはっきり分け、実名や鍵といった秘匿情報を配らない側の一箇所へ集約しました。配る側に置いてよいのは、中身そのものではなく「あっちを見て」という参照だけ、という線を引いています。整理の起点として、まず境界を確定させた段です。

理由: どこに何を置いてよいかの線が曖昧なままだと、秘密は少しずつにじみ出す。にじみを防ぐには、まず箱の仕切りを先に決めるしかない。scatter→centralize。

整理計画を承認した。ただし「残す」と「見直さない」は別だと線を引いた

道具箱の整理計画を承認し、まず「今できること」を全部書き出して固定する段から始めることにした。この段では何も動かさない。台帳がないまま構造を触ると、あとで不具合が出たときに「元からできなかった」のか「壊した」のかを判別できなくなるからだ。部署ごとのまとまりは解体せず維持する判断も承認したが、維持することと、重なりを放置することは別だという条件を付けた。重なっている機能は一つずつ「片方に寄せる／担当を分ける／外部に任せる／両方残して違いを明記する」の4択から選び、理由を残す。「両方残す」は既定ではなく最終手段とする。

理由: 引き直す必要のない境界を引き直さないのは正しいが、それは重なりを放置してよいという意味ではない。維持と改善は別の軸で、混ぜると「維持」がただの現状追認になる。approved→execute。

道具箱を、売り物ではなく構造として整理することにした

プラグイン・スキル・スクリプト・明文ルールを全て棚卸しし、汎用の道具とブランド固有の運用を分ける方針を確定した。将来これを資産として配る可能性は視野に入れつつ、今回は値付けや売り方の判断を完全に切り離し、純粋な構造整理として進める。第一目的は二つに絞った。重複をなくして責務を一つにすること、そして整理の前後で振る舞いが変わらないこと。棚卸しで分かったのは、分離の原則そのものは壊れていないということだった。壊れているのは実装の一貫性で、パスの直書き・ブランド語の本文埋め込み・禁止語のベタ書きが全域で繰り返されていた。重複も、一つの部署の中より部署をまたいだところで深刻だった（同じ契約の書き込みが12箇所、同じ判定が5箇所など）。

理由: 売り方を判断基準に混ぜると、構造として正しい境界と売りやすい境界が競合して前者が歪む。実際、当初案では「無料で配って集客する」ための分割が複数あったが、目的を構造整理一本に絞った途端どれも根拠を失い、より単純な形に戻った。「呼び出し元が変わるのは構わないが、できることが減ったり結果が変わったりするのは駄目」という線を、機械で検証できる受け入れ条件に落とし込んだ。sellable→structural。

判断を仰ぐときは、チャットではなくボードに載せる

オーナーの判断が要る報告の既定経路を、チャットへの直接報告から報告書ボードへの掲載に変えた。長い前置き・複数の判断項目・詳細な背景をチャットに流すのをやめ、統一フォーマットのページに載せて、承認・棄却・保留と詳細をその場で入力してもらう。確認項目が軽ければ従来の簡易確認でよく、どちらを使うかの振り分けは軽量モデルに任せて毎回聞かない。あわせて申し送り3件も決裁した。

理由: 判断材料が会話に流れると、後から何をどう決めたのか辿れなくなる。ボードに載せれば、判断が構造として残り、処理済みは消える。ad-hoc→standardized。

監査の宿題を、まとめて片付けた

第006回監査で残っていたオーナー判断4件を、新しくできた報告書ボード経由で決裁した。公開ページのサーバ側認証は棄却（構造を複雑にする割に得るものが薄い）、連載企画のスキルは退役（本棚方式への移行で役目を終えた）、文体統一を手順書全体へ反映、公開後レビューの記録漏れを補填。

理由: 監査で挙がった指摘を宙に浮かせたままにすると、次の監査で同じものがまた挙がる。決めるものは決め、やめるものはやめる。resolve→close。

報告書のやりとりに、専用のページを作った

報告と「判断してほしいこと」を、統一フォーマットのページに載せて渡す仕組みを作った。一覧から報告書を開くと、確認事項ごとに承認・棄却・保留と詳細を入力でき、そのまま指示文としてコピーして返せる。受け取った側は照合して作業し、済んだ報告書はページから消える。ページ本体は報告の中身を一切知らない汎用の表示器として作り、データ操作は専用スクリプト経由に限定した。

理由: 報告のたびに書式がぶれ、判断がどこまで進んだか分からなくなっていた。書式を固定して、未処理のものだけが残る形にした。chat-report→structured-board。

内部ガイドと外部発信の線を、ルールに引いた

月次監査（第006回）で、内部ブランドガイドの扱いが宙に浮いていることが見つかった。そこで compliance.md に §6「内部ドキュメントと外部発信の切り分け」を新設した。内部ガイドは検索から外した（noindex）うえで、サービス固有名などの内輪の記載を許容する。ただし個人実名は例外なく全経路で伏せるという線は動かさない。あわせて、DEC-110 の再設計で取り残されていた各部門の判断フィルタから旧い事業軸の表現を一掃し、構造の棚卸し（不要ファイルの削除・古い参照の付け替え）まで通した。監査で挙がった残りの重い判断（公開構造の作り替え等）はオーナー預かりとして分けた。

連載をやめ、記事を「本棚」に置くことにした

発信の設計を「連載（難易度を1本道で登る）」から「本棚（棚＝ジャンル × 段＝深さ の在庫に、単発の記事を置く）」へ再設計した。棚は横に増やせ（ジャンル追加）、段は需要に応じて縦に深められる。1本ずつ単体で完結する evergreen にし、連載の物語仕立てはやめる（声＝寄り添いは維持）。記事の種は本棚に在庫として溜め、オーナーが選んだものだけ査読ボードのレールに載せる。時間割・締切は持たない。旧プラン19本は種（在庫）に戻し、査読ボードには着手中のものだけが並ぶ状態にした。本棚はサク（需要・種ネタ）とソウ（型・価格・配分）で肉付けした。

理由: GAS×AI入口シリーズ5本を完走して、連載は「登るほど入口ネタが尽き、後半は高度なことしか書けなくなる」構造的欠陥が露呈した。本棚なら新ツールレビュー棚を入口の永久機関にでき、当たった棚だけ需要で深掘りでき、新ジャンルは棚ごと足せる。尽きず・詰まらず・広げられる。serialize→stock。

公開ボタンの前に、実機で見る段を挟んだ

記事査読の流れに「レイアウト確認」という段を新設し、4段から5段にした。本文・サムネ・タグの確認が終わったら、いきなり公開せず、まずnoteに下書きとして入稿する。そこで実際のnote画面の見え方（図のはみ出し・コードの崩れ・サムネの出方）を確かめてから、はじめて公開する。下書き入稿（非破壊）と公開を、はっきり別の段に分けた。

理由: ローカルの査読ボードとnoteの実際の描画は別物で、公開後に「図が崩れていた」に気づくのを防ぎたい。公開は不可逆に近いので、下書きで一度実機を見る段を正式化し、うっかり公開しない安全も構造にした。blind-publish→layout-verified。

公開したら終わり、にしない。記事の管理を一本のSSOTに束ねた

記事の状態を、置き場所やインデックスの手作業でなく記事ファイルの frontmatter 一つ（唯一のSSOT）に集約した。査読ボード・記事一覧・被りチェックDBは、すべてそこから機械生成される派生物にして、二重管理をなくした。公開しても記事フォルダは動かさず、公開後の処理（連番付け・記事DBへの再取り込み・一覧再生成）は finalize_publish.py の一コマンドで完結する。この設計は fable モデルのサブエージェントに委譲し、その場しのぎでなく最適運用を描かせた。

理由: 新しい査読ボード運用と旧来のフォルダ規約が噛み合わず、「公開済みなのに被りチェックDBに載らない」宙ぶらりが起きていた。設計の過程で、放置すれば旧記事の記憶を消しかねない潜伏バグを4件掘り当て、まとめて構造解消。旧16本は凍結アーカイブとしてDBに保持しつつ隔離。dual-manage→single-source。

記事の声を「寄り添い」1本に統一し、規範例で縛った

記事本文の文体を「寄り添い」の声1本に統一した。従来の「2モード運用（実用モード／思索モード特権枠）」と「常体を基調にする」既定を廃止・撤回。全記事を、自己紹介記事①の温かい伴走体（です・ます主体で、読者の情景描写だけ常体）で書く。さらに、抽象ルールだけでは声が再現できないと分かったため、記事①の実文を○（合わせる）／×（戻った書き方）で並べた規範例を docs/strategy/article-voice.md として新設し、文体イメージの唯一の正とした。書き手は執筆前に必ず記事①を音読して声を合わせる。

理由: AIに書かせると、放置すれば冷たいエッセイ・箴言・記録宣言という"それらしい"旧ブランドの声に戻る。ある記事の初稿がまさにそれで差し戻しになった。ルールを覚えさせるより、良い一本を規範例として音読させる方が速く確実。2モードは「これは思索寄り」という自己正当化の隙になっていたので1本に閉じた。split→unify。

記事を「量産して、査読して、GOで出す」カンバンを作った

オーナーの状況に関わらず記事の生成から公開までを回すため、2段カンバンの査読ボードを実装して本番稼働させた（内部ツール・非公開）。①プラン査読（タイトル・ディスクリプション・タグを見て、GOが出たら本文執筆を開始）→ ②本文執筆中 → ③本文査読（全文を見て、GOが出たら即公開）→ ④公開済み、の4列。査読状態の唯一の正は記事ファイルの frontmatter（review_status）に置き、ページは表示専用にして二重管理をなくした。査読メモとGOは整形テキストとしてコピーでき、オーナーがそれを渡すとナギが実行する。コンテンツ計画23本もこのボードに載せ、各ディスクリプションにGOを出すことが計画の確定になる設計にした。

理由: 完全無人化の律速は保存の仕組みではなく note のセッション認証にあるため、重いバックエンドを先に作っても無人にはならない。まず frontmatter を台帳にする静的な最小構成で一周させ、将来の全自動化（Firestore）には作った部品をそのまま使える。全文表示は「低機密でよい」というオーナー判断に合わせ、目次だけ見せる複雑さを捨てた。workflow→infra。

タイトルの作り方を、競合を全部調べて決めた

記事タイトルの設計を恒久SSOT（タイトル設計プレイブック）として確立した。競合分析設計書に載る全対象（直接競合11者・参考・敵対・現場縦）から実タイトルを収集し、12型に分類してから最後にブランドフィルタを通す手順で選別。TDILが採る5型（意外性×権威ギャップ／問いかけ・逆説／期間×成果／つまずき共有／静かな思索）と、捨てる5型（誇大革命語・記号乱打・権威マウント・恐怖訴求・金額露出）を確定した。実データでも釣り見出しは反応を約1/4失い、おすすめ露出も下げる。あわせて、AI生成文の癖に見えるダッシュ表記を全媒体で禁止にした。

理由: 一般に伸びる型と、TDILが採れる型は一致しない。静か・偉ぶらない・寄り添いを壊す煽りは、短期の反応より長期の信用を毀損する。フィルタを恒久ルール化して属人性を排す。記事①のタイトルはプレイブック1位で確定。viral→brand-fit。

ロゴを、コードのカーソルと大工の墨で描き直した

旧・幾何ワードマーク（技術思索ブランド期の産物・暗背景でロゴが消える反転版なしの実バグ持ち）を刷新。TDIL の4文字を等幅スタイルで自前ドロー（フォント非依存ベクター）し、末尾に朱のカーソル（実装中の点滅）、左端に朱の墨壺点と墨線（大工が最初に打つ基準線）を置いた。「コードを書くカーソル」と「大工が最初に打つ墨」が、"基準を引いて、その上に作る"という同じ所作で重なる。横長バナー主用途・テラコッタ単アクセント・寒色不使用・明暗の反転版とfavicon一式を完備した。

理由: 鉋屑や曲尺など大工道具でTDILを置き換える案は、思想が道具に乗っ取られるとして却下。文字（TDIL）と思想（使う人から作る人へ）を根に残し、造形だけを新ブランドへ寄せた。大工・建築は主題ではなく背景の香り。geometric→tool-fusion。

サムネもキャラも、「図面」の言葉で描き直すことにした

新ブランド（元大工×設計×寄り添い）に視覚言語を追従させる刷新。「現場の図面」言語を採用した。方眼のトレーシングペーパー地に二重の図面枠、Before→After を測る寸法線と通り芯、そしてテラコッタの強調をすべて「現場の朱入れ（朱書き）」として意味づける。サムネは旧・全文要約インフォグラフィック（X のタイムラインでは縮小されて読めない）を廃止し、「1メッセージ＋図面枠」型へ。右下の図面タイトルブロック（図名・種別・約束）が、入口/実用/思想・現場縦の3層の棚ラベルを兼ねる。公開順に SHEET 001, 002…と連番が積み上がる。マスコットも粘菌の Tidil から、鉋屑の精霊「かんなくず」へ刷新（コンセプト2案生成・選定中）。初出は記事①のサムネ（SHEET 001）で、note 下書きのアイキャッチも API で差し替え済み。

理由: 「図面」は元大工×設計者の看板を、言葉で名乗らずに視覚で証明する装置になる。情報を詰める（旧）から意味を持たせる（新）へ。レイアウトのゼロ設計原則は不変で、共通化したのは線種と朱の使い方という"作法"だけ。densify→signify。

16本の公開記事を、消さずに全部しまった

新ブランド立ち上げにあたり、旧戦略で書いた note 記事16本（有料1本含む）を全て「下書きに戻す」完全クリーン移行を決定。削除ではなく可逆な倉庫化で、スキと記事データは保持され、再公開すれば同一URLで復活する。アカウントとハンドル（jinc_tdil）は維持し、X の旧ポストも削除して、プロフ刷新＋自己紹介記事①からタイムラインを再出発する。検討した代替案は「全部残して棚整理」と「代表2〜3本だけ残す」だったが、旧記事群と新ブランドの戦略差が大きく、16本が顔を占めたままでは一貫性が壊れる・16本目に自己紹介が出るのは物語として不自然、というオーナー判断で完全クリーンを採用。損失の実査では X ほぼ未投稿・有料購入者ゼロ・検索流入も実測ほぼゼロで、リセットで失う実資産は極小だった。しまった記事は軌道後に「設計の記録」アーカイブ棚として選別復活するか、現場縦記事の改稿素材にする。

理由: アカウント作り直しだけは棄却（ID再取得の不保証・アカウント年齢喪失＝リプ運用の凍結リスク増）。「器は維持、中身は倉庫へ」が、ブランド一貫性と資産保全を両立する唯一の解。実施は手動（有料記事の pay_body を非公式APIで消すリスクを回避）。retain→shelve。

隠していた「元大工」を、いちばん前に出すことにした

ブランドと発信戦略をゼロベースで再設計した。外部の壁打ちで作った3つの設計書（全体設計書・競合分析設計書・導入経路設計書）を上位憲法として採用。競合分析の結論は明快で、汎用「非エンジニア×AIの使い方」市場は競合過密＋価値の重力（使い方解説はモデル進化で無価値化する構造）で溶けていく。唯一の非対称優位は、これまでコンプラ上隠してきた「元大工 × 旧帝大建築卒 × 商品開発リード × 実装」の現場縦だった。ポジションを2層に組み替え（汎用=入口・集客 / 現場縦=moat・資産）、売り物は Wrapperテストで切り（AIで再現できる使い方=無料 / 再現できない現場文脈・設計判断・一次体験=有料）、収益主柱を会員制メンバーシップに置く。X を主軸チャネルに昇格し、期待値は分布で持つ（1年目=経路確立・1000万は2〜3年の上振れ）。コンプラは全面改定：過去形経歴の看板化と「自分の結婚式で使うゲスト管理アプリ」の一般名詞言及を解禁し、現職の中身・3DP・役職・地域・社名は禁止続行。旧P/C軸は主業に従属化。

理由: 旧方針（DEC-090/093 の属性隠し）の「空看板」批判は、建築を名乗るのに建築の話を書かない不一致への批判だった。現場縦を書くなら看板と中身が一致し、批判の前提が消える。DEC-096 の実測診断「届けば刺さる・主因はリーチ不在」は X 主軸化の根拠としてそのまま継承。Gate 0（副業規定の裏取り）完了までは課金拡大を保留する。hide→leverage。記事化価値◎（この転換自体が第3層のネタ）。

記憶も、異常検知も、定期業務も、「求めたら動く」から「勝手に動いて差し出す」へ

ハーネスの根本進化パッケージを採用。不随意想起（関連する過去メモをフックが会話に勝手に差し込む）、夜勤（health-check が SessionStart 冒頭で自動化の異常・監査期限超過をアラート）、週次経営会議（SESS 3指標を集計し改善提案を自動起票 → 適用はオーナー決裁）、月次運営レポート素材（DEC/FAIL/SESS を事業記事素材に自動変換）、組織定義の IaC 化 v1（org.yaml を単一正源に、org_build.py --check がドリフトを機械検査）。

理由: pull（人が思い出して呼ぶ）に依存する仕組みは、忙しくなった瞬間に使われなくなる。push（勝手に動いて差し出す）に転換すれば、忘れることが構造的にできなくなる。pull→push。

ロゴ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 項目（勤務先名 / 現職の固有ノウハウ / 社内重複）と同じレベルの絶対遵守として位置づけた。記事化価値× （このルール自体は発信しない）。

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（オーナーのアカウントのみ許可）付きで 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アプリの二部構成。スポンサー非表示 + ピック→比較が差別化。サブスク課金のみ（アフィリエイト排除）。

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

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