AI との iOS 開発で、デザイン案の探索に構造を義務づけるゲート。1画面 × 1意図に対してエージェントが案を 3〜10 並列で作り切り、1枚の展示物にまとめて依頼した人に渡す — その「コンペ」のループのうち、締めるのは3点だけ。
- 受付: 観点・操作・第2段・賭け・効かないとき・ユーザーストーリー・出所付きの着想が揃わない案は、記録として生まれない
- 展示判定: 内側の claude-gate の合格 + 比較の条件（同じベース・同じ固定データ・同じ端末条件）に合う実物（スクリーンショット、動きの案は録画）が無ければ展示に並ばない。決定論・LLM なし
- 承認: 展示物（画像・録画を埋め込んだ1枚の HTML）の内容で問題ないことを、依頼した人が引き受ける。承認された展示物は共有できる状態になる（Slack へ貼る等の共有そのものはこの仕組みの外）
採用（どの案を実装に進めるか）は共有のあと人が決めることなので、この仕組みでは規定しない。デザインの良し悪しは言語の外。
制作そのもの（発想・実装・調整・動作確認）は縛らない。動作確認は claude-gate をそのまま内側で使う。
案は「この画面はこうあるべきだ」という主張で、主張には支えが要る。観点が決めるのは支えの種類であり、種類が違うから書くべき内容も違う。
各観点は外部の体系に錨を下ろしている。 ここが自由文だった間、項目は設計者の散文で「それらしく」書けてしまった。閉じた語彙（定石10・場面8・並べ方5）や定まった手続き（引き算の順序・制約の対・実例2件）に結び直したので、何を書くべきかは観点が決め、書けたかどうかは機械が見る。
| 観点 | 支え | 操作 | 第2段 | 錨 |
|---|---|---|---|---|
| 前提 | 人 | 疑った前提 | それが外れていたと分かる観測 | Lean UX の仮説の型 |
| 場面 | 人 | 効かせる場面（8から選ぶ） | 望む結果（最小化/最大化 + 何を） | Ulwick の Job Map と ODI |
| 使い勝手 | 知 | 破っている定石（10から選ぶ）+ 重大度0–4 | 守るとどう変わるか | Nielsen 1994 |
| 法則 | 知 | 当てた法則（Fitts / Hick / Miller / 群化） | 予測される差 | Fitts 1954（ISO 9241） |
| 並べ方 | 知 | 変更後の並べ方（5から選ぶ） | 何が速くなり何が遅くなるか | Wurman の LATCH 1989 |
| 引き算 | 手続き | 消した必須の部品 | 残った形が誰の何に向くか | SIT の Subtraction |
| 制約 | 手続き | 塞いだ答えと、向かわせた先（対） | その制約下で捨てたもの | Stokes の制約の対 |
| 実例 | 手続き | 2つの実例から取った具体 | 2つに共通するもの | Gick & Holyoak |
| 端末の機能 | 端末 | 使う機能と、それが見える形 | その機能が無いときの体験 | Norman の signifier / 段階的向上 |
第2段を飛ばせないのが肝。挑発しただけ・実例を拾っただけ・定石を唱えただけでは使えない出力が出る（de Bono / Blackwell / Cooper / SIT が別々に同じことを言っている）。
支えが偏ると案の失敗の仕方まで揃う。 1コンペで使うのは 3〜6 で（5-6 で多様性はピーク・Yilmaz et al. 2012）、支えが2種類以下だと受付が警告する（拒否はしない）。
意図・使いどころ・腐り方・出典・通った例は claude-proto lenses / claude-proto lens <観点> が返す。文書に写しを持たない（SSOT は src/design/words.ts の LENS_GUIDE）。
対象リポジトリに proto.yaml を置く（画面契約・固定データ・端末条件・許可するアイデアソースの宣言）。あとは proto-loop スキルが進行を刻む。
npm install && npm run build && npm link
claude-proto install # launchd に常駐(見る画面と MCP を 7360 で配る)
claude-proto doctor # 常駐・操作面・内側の claude-gate・プラグイン導入を一括点検Claude Code へは marketplace 経由で入れる。このリポジトリ自体が marketplace（.claude-plugin/marketplace.json）なので、登録してから入れる。プラグインが .mcp.json を持っているので、導入するとエージェント側にツールが生える。
claude plugin marketplace add <このリポジトリのクローン先パス or no-problem-dev/claude-proto>
claude plugin install claude-proto@claude-protoエージェントの面 = MCP。ping / lenses / lens / search_ideas / open_source / open_contest / revise_lenses / accept / start_making / attach_evidence / sync_gate / judge / exhibit / abandon / html / share / show の17。share は渡せる形を返すだけで送らない（送るのはコネクタ経由・最後に押すのは人間）。
人間の面 = CLI と見る画面。同じ操作に加えて approve がここにだけある — 承認は依頼した人だけの操作なので、エージェントの語彙には入れない（規約ではなく、呼べるものが無いことで守る。設計は docs/plugin-surface.md）。
claude-proto share --worksite <repo> --contest <id> --as file # 添付するファイルの場所(本筋・無損失)
claude-proto share --worksite <repo> --contest <id> --as slack # 拾い読み用の文字列(送らない・絵は落ちる)
claude-proto show --worksite <repo> # コンペと案の一覧
claude-proto approve --worksite <repo> --contest <id> # 依頼した人だけの操作
claude-proto serve --port 7360 # 前面で動かす(常駐させないとき)CLI の全コマンドは claude-proto を引数なしで叩くと出る。
読んで判断する流れと、見て判断する流れを別に持つ。読む前の判断と読んだ後の判断は別物なので混ぜない。
/→/contests/…→/proposals/…— オブジェクトを選んでから操作を選ぶ。コレクションは見分けがつく最小限、単体で全部の中身。承認はコンペの画面にだけ置く/contests/…/compare— 見比べ。説明を一切出さず、全案の絵を同じ物差しで並べる。名前を隠せる（観点や作業名は先入観になる）、録画は既定で再生される、クリックで実寸に開いて ←→ で案を切り替えると同じ位置・同じ倍率で入れ替わる/model— モデルの全体図。語彙の SSOT にある概念の台帳と関係を、そのまま描く。設計はdocs/view-design.md
共有する1枚（展示物）も同じ2つの見方を持つ（自己完結 HTML のまま・外部依存なし）。
コア + 記録の置き場 + 操作面2つ(CLI と MCP) + スキル + 常駐 + 一覧サーバまで。実プロダクト（stock-radar のホーム画面）で end-to-end の実走を3周まで到達している（docs/s3-real-notes.md）。
常駐と MCP 化は、承認をエージェントの語彙から外すために入れた（同型の実害が claude-gate で出ている＝docs/domain.md の K13）。見る画面の React 化は正当化する事故が無いので入れない — 自己完結 HTML のままにする。
src/design/
words.ts 語彙の SSOT(対訳・観点と手引き・閉じた集合・状態機械・概念の台帳)。最重要
defaults.ts 展示の下限(表現の種類 → 証拠の種類・観点ごとの上乗せ)・コンペの構成の範囲
ids.ts 決定的 ID(べき等の土台)
proto_yaml.ts リポジトリ内 proto.yaml(画面契約・固定データ・端末条件・許可ソースの宣言)
source.ts アイデアソースの契約(search で探し、open で実体を開き、引用の実在を確かめる)
accept_core.ts 受付のコア(コンペを開く / 観点を見直す / 案を受け付ける)
judge_core.ts 展示判定のコア(ゴールデンテストで固定)
approve_core.ts 承認のコア(最新の展示物だけ承認できる)
derive.ts コンペの進行・共有できるかの導出(保存しない)
html.ts 展示物の1枚(自己完結 HTML・見比べの切り替え付き)
ops.ts 操作の実体。CLI と MCP の両方がここを呼ぶ(承認は人間の面からだけ)
share.ts 宛先ごとの変換(純関数)。file=無損失の添付が本筋、他は導線。送る能力は持たない
media.ts 観測の種類の表。**ここが唯一**(組み立て側と配信側で別々に持たない)
src/kernel/
store.ts 記録の置き場(~/.claude-proto)・監査・不変コピー
api.ts 見る画面のための読み取りモデル(進行・共有できるかの導出。日本語を運ばない)
server.ts 1プロセスが2つの口を配る(/ = 見る画面 / /mcp = エージェント)
mcp.ts エージェントの操作面(承認はここに無い)
src/cli.ts 人間の操作面(+ install / doctor)
dashboard/ 見る画面(React 19 + Vite + HeroUI v3 + Tailwind v4)
ラベルは words.ts を直接 import する(写しを持たない)
/model = 概念の台帳と関係の全体図(@xyflow/react + elkjs)
scripts/ 配布の検査(スキルを変えたら版を上げる)・開発用の見本データ
skills/proto-loop 発散 → 編成 → 並列制作 → 検証 → 展示 の進め方
docs/domain.md 事故台帳(仮説)・決定の記録・設計原則・ゲートの外・実装の段階
docs/plugin-surface.md 届け方と操作面(配布の事故台帳・人間の面とエージェントの面の分割)
docs/view-design.md 見る画面(責務・語彙の規則・表現基盤)
docs/sharing.md 共有(添付が本筋・変換は導線・運べないものの宣言・事故台帳)
docs/s*-notes.md 各段階の実走メモ(当時の記録なので後から書き換えない)
test/ vitest(状態機械の整合・受付/判定/承認のゴールデン・退役語の台帳)
- 語彙・観点・状態・概念の関係 →
src/design/words.ts（claude-proto serveの/modelが同じものを図にする） - なぜこの決まりがあるか →
docs/domain.mdの事故台帳と決定の記録 - どう配り、誰がどの操作を持つか →
docs/plugin-surface.md - 見る画面の責務・語彙の規則・表現基盤 →
docs/view-design.md - 承認された展示物を人に渡す →
docs/sharing.md（添付が本筋。変換は開いてもらうための導線）
npm install
npm test # vitest
npm run typecheck # サーバと見る画面の両方
npm run build # tsc + 見る画面の組み立て(dashboard/dist)
# 見る画面だけを触るとき: 見本データを作って、前面のデーモンに当てる
CLAUDE_PROTO_HOME=/tmp/proto-dev npx tsx scripts/dev-fixture.ts
CLAUDE_PROTO_HOME=/tmp/proto-dev node dist/cli.js serve --port 7361
PROTO_PORT=7361 npm run dev:dashboard # 別の窓で。/api の転送先を見本のほうへ向ける見本データは見る画面を作るためだけのもので、受付も展示判定も通っていない。既定の置き場には書けないようにしてある。