AGENTS.md

Reckn — Autonomous Harness (ETHOnline 2026)

このリポジトリは自律開発ハーネス付きで運用される。founder は gate 判定と停止判断だけを担い、 仕様・実装・レビュー・デモはエージェントが進める。

計画は docs/ethonline-2026/PLAN.md、ETHGlobal への事前開示は同ディレクトリの DISCLOSURE.md。

---

0. これを壊したら全部無意味になるもの

判定する鍵が存在しない。

Reckn の差別化はこの一点しかない。RecknZkEscrow に owner / admin / resolver / pause / upgrade を 一行足した瞬間に、製品は競合と同じものになる。だから約束でなくビルド条件にしてある。

検査は 2026-09-06 に締め直された（task 009、check を足さず・番号も変えず・最終行も変えず）:

• check 2 は「見つけた関数を列挙する」のをやめ、入口の集合を閉じる。 fallback() と receive() は function キーワードを持たないので、任意の funded deal を抜く fallback が 4検査を全部通ることを実測していた。いまは 関数以外の入口キーワードが0であること を要求し、 さらに 継承・第二の contract・using を禁じる（継承したメンバーは contract 行より上に 宣言されるので、それを許すと検査領域そのものが不完全になる。これも実測——排水する base を 継承させた木が全検査を緑のまま通った）
• check 4 は 009 後に空虚になる。 constructor が無くなるので「constructor は msg.sender を 保存しない」は何もマッチせず通る。中身を 4a（領域が literal＝ブロックコメントも文字列も無い）と 4b（constructor も immutable も無い）に差し替えた
• どちらも締め direction の変更だが、no-keys.sh が 0 で抜けることの意味は 009 前と同じでは ない——エスクローは buyer が指名したコードへ dispatch するようになり、ビルド条件はそれを検査 しない。安全にしているのは INV-9（view 型＝STATICCALL）と §4.4 の B-1/B-2/B-3 であって、 no-keys.sh はそのどれも見ていない。列挙された関数面は不変

検査される領域は2ファイルである（2026-09-05 に拡大、task 008 check 5）。 RecknZkEscrow.sol に加え RecknVerdictVerifier.sol —— settleWithProof は後者の verifyVerdict が返す struct に従うので、そこに定数アドレス分岐を差し込めばそれは resolver である。 それまでこのスクリプトは1ファイルしか読んでおらず、その分岐は全検査を緑のまま通過した。 check 5 は禁止語の列挙ではなく6つの性質（許可される内容の全体）で閉じる。

bash scripts/no-keys.sh     # exit 0 = 主張はまだ真

• 全 commit の前に走らせる。 落ちたら commit しない、デモしない、提出しない。
• 列挙された関数面（fund / settleWithProof / refundAfterDeadline）を増やすなら、 主張が変わったということ。同じ commit で本ファイルと scripts/no-keys.sh を更新し、 デモの台本でも明示する。黙って通さない。
• このチェック自体を緩める変更は founder 判断。エージェントは緩めない。

既定の optimistic 経路（RecknEscrow: bonded resolver + challenge window + quorum）は コモディティであり、差別化しない。 デモと物語は zk 経路一本に寄せる。optimistic 経路は 既存資産として維持するだけで、ここでの改善対象ではない。

---

1. エージェント

frame の分割は熟練度でなく枠の厚さによる。

agent	frame	役割	定義
reckn-spec	thin / Claude	変更すべき判断を1つだけ選び、受入条件・不変条件・非目標を固定する。探索の反復を所有しない。	.claude/agents/reckn-spec.md
reckn-codex-review	Codex	Claude が書いた仕様を1回だけ反証する。Codex 自身が書いた diff はレビューしない。	.claude/agents/reckn-codex-review.md
reckn-codex-impl	thick / Codex	固定済み仕様の実装、テスト修正、限定diff調査を行う。	.claude/agents/reckn-codex-impl.md
reckn-review	thin / Claude	Codex が書いた diff を1回だけ独立レビューする。実装も再設計も行わない。	.claude/agents/reckn-review.md
reckn-demo	thin	審査員が最初に見るもの（gauntlet・money-shot・README・3分台本）を所有。	.claude/agents/reckn-demo.md

author independence: reckn-codex-impl が書いたコードを Codex にレビューさせない。 その場合は自分で仕様の不変条件に照らして行単位で裁定する。Codex は「最も自信の無い2点」への セカンドオピニオンとしてのみ呼び、Codex が対象を書いた事実を payload に明記する。 自分の宿題に自分で丸を付けたレビューは、綺麗な verdict と直っていないバグを生む。

---

2. サイクル

task → reckn-spec (Claude, 判断を1つ固定) → reckn-codex-review(stage=spec, 1回) →
       spec を凍結 → reckn-codex-impl (Codex, 実装+テスト) →
       reckn-review (Claude, diff の独立レビュー1回) → fix+実テスト → commit → push

• Claude は判断とCodex diffへの独立レビューだけに使う。リポジトリ探索、定型実装、テスト失敗の 修正、既知factの照合は Codex が行う。
• 各レビューは1回。修正後の再レビューは、中心主張を破る新しい再現可能な BLOCKERが出た場合に founder が許可したときだけ行える。通常の CHANGES は同じ実装者が直し、テストで閉じる。
• brief は対象パス・判断・受入条件・実行コマンドだけに絞り、過去レビューや資料を全文貼り付けない。
• レビューは重大度順の最大3 finding。同根の指摘は統合する。
• レビュー記録は docs/reviews/NNN-<stage>-r<M>.md、末尾は VERDICT: APPROVE か VERDICT: CHANGES の一行。

---

3. タスク（ETHOnline の当日作業）

依存順。各タスクは緑のテストで終わる単位に割る。

#	タスク	主眼
001	keyless timeout	✅ 2026-09-06 着地（founder 裁定でこの一項目だけ実施。003 の鍵ガントレットは §7 の停止のまま）。refundAfterDeadline が 30 日後に buyer へ返す。誰でも呼べて、呼んだ人には何も入らない。待機期間はプロトコル固定——期限を選ぶ者はパラメータを握る。AGENTS.md §0 の列挙面に元からある関数なので主張は広がっていない。RecknTimeout.t.sol 6本
002	実 ERC-20 ワークロード	in-guest 再実行を単一 SSTORE fixture から実トークン入金述語へ。cycles を実測して記録
003	key gauntlet	全当事者の秘密鍵を公開し、あらゆる窃取経路が revert することをテスト行列と UI で実証
004	live adversarial input	seller の納品主張を自由入力に。観客が LLM 判事を説得でき、再実行は説得されない
005	Arc / USDC	Arc の USDC で escrow を決済する。2026-09-06 founder 裁定により唯一のスポンサー統合。契約変更は不要（deal がトークンを指名する）——要るのは USDC の単位と意味論での正しさの証拠
006	Hedera / x402	2026-09-06 founder 裁定によりスコープ外。 x402 有料サービス / Blocky402 / 消費 agent / Hedera デプロイ / 関連文書は作らない
007	World AgentKit	「誰が紛争を開けるか」のゲート。「誰が判定するか」には触れない（触れたら 0. 違反）
009	cross-VM settlement	Solana の proof で EVM の escrow を決済する。 今日 SVM の verdict は同じ汎用 verifier でオンチェーン検証されるが、settleWithProof に届いているのは EVM の proof だけ。EVM に預けた資金を、Solana 上で行われた作業についての proof が解錠する——resolver なし、bridge なし、adjudication 経路に light client なし
008	verdict domain soundness	guest の delta が U256 の limb 0 で取られており、pre=2^64 / post=2^64−1（減少）が最大入金として Reproduced になる＝偽の解放。off-chain は U256。加えて guest は chain_id しか設定せず spec/block env が off-chain と一致しない

スポンサー統合（founder 裁定 2026-09-06）

Arc だけをやる。Hedera はやらない。 賞金一覧が公開され、Arc は実在（$10,000、うち Continuity で出せるのは Best DeFi or Agentic Application と Launch on Arc Testnet & Push to Mainnet の2本）。両方とも "working frontend and backend + architecture diagram" を要求する。

• Arc は支払いレールであって、裁定機構を置き換えない。デモは Arc 上の1つの明確な取引に集中する
• RecknZkEscrow に payable 経路を足さない。関数面が増えるのは §0 の中心主張の変更にあたる
• mainnet デプロイは禁止（§8）。賞の要件は "deployed or deployment-ready" なので後者を取る

実行順（founder 裁定 2026-09-04）

008 → 009 → 003 → 004 → 002 の順で進める。001 は独立タスクとして起こさず、003 の テスト行列の一項目として同時に落とす。

2026-09-06 更新: 008 と 009 は着地。005（Arc / USDC）を先に入れた（founder 裁定、 スポンサー統合は Arc 一本）。001 の timeout だけを単独で落とした——003 の鍵ガントレットは §7 の停止のままで、再開していない。001 を切り出した理由は、Arc の USDC テストが 「blacklist された seller で決済が revert し、timeout が無いので資金が留まる」ことを自分で 実演してしまい、決済レールの賞に「永久に固まりうるエスクロー」を出すことになるから。

008 が先頭なのは、これが 003 より深い破れ方だから。 003 は「鍵が無い」ことを実証するが、 008 が開いている限り鍵を使わずに proof 自身が誤って資金を解放できる。「proof が自分で 権限を持つ」が製品の全部である以上、その proof の健全性が先に立たないと 003 の実証は 空虚になる。002（実 ERC-20）は 18 decimals で ~18.45 トークンを超えた時点でこの領域に入るため、 008 を閉じずに 002 へ進むことはできない。

理由: Continuity で審査されるのは当日の差分であり、001（数十行の期限後返金）は 物語上必要だが差分としては弱い。審査員に効くのは 003 key gauntlet と 004 live adversarial input。001 は 003 が実証する「あらゆる窃取経路が revert する」 行列の中で、「proof が来ないまま期限を過ぎた場合」の行として自然に入る。

これは依存順の変更であって、001 の中身の放棄ではない。003 の受入条件は 001 の受入条件（任意アドレスが期限後に呼べる / 期限前は誰も呼べない / settleWithProof 後は返金経路が死んでいる / 逆順でも二重に出ない）を含まなければならない。

---

4. Continuity 規律（違反すると失格・賞剥奪・BAN）

• 境界は日付で定義する。当日作業とは、日付が 2026-09-04 以降の commit のみ。 ハッシュで「終端」を書くと、それを書いた commit 自身が終端の後に来て必ずずれる （実際に一度ずれた）。ハッシュは事前に書けるものではなく、開始時に確定する。
• イベント開始時（9/4 最初の作業の前）に git rev-parse HEAD を記録し、 STATUS.md の EVENT_START に書く。 それ以前は全て事前作業。
• 参考: 製品の事前作業は a122b448887eb71b11f87c7d9cdf65afdc25fe69（2026-08-02）で一旦終わり、 以降 9/3 までの commit はハーネスと計画（tooling / planning、製品機能ではない）。 いずれも DISCLOSURE.md に事前作業として記載済み。
• 当日の作業はイベント期間内の日付で連続的に commit する。単一の大 commit は既定で失格扱い。 事前に書いて当日1発 push は不可。
• 各 commit は当日作業のパスに限定し、基準コミットからの差分として説明できる状態を保つ。
• 新規部分は恒久的に open source。提出時に psyto/reckn 全体を public にする（2026-09-03 決定）。
• DISCLOSURE.md を書き換えたら、送付済みの内容との差分を STATUS.md に記録する。

---

5. 主張の規律

zk-verdict/README.md の "Honest scope" を上書きしない。以下は当日の作業で解消しない限り真であり、 デモ・README・提出文で解消したかのように書かない:

• c-kzg / ecrecover precompile は in-guest でも動く（revm-precompile は native feature を 切ると k256 / arkworks の純 Rust 実装へ落ちる）。真の限界はもっと狭く、もっと悪い: guest と off-chain engine は同じ precompile の別実装を走らせており、等価性は未検証
• 1 CALL + 1 delta check。フルブロック / 任意コントラクト集合は more cycles, same architecture
• state_root ↔ ブロックヘッダの束縛は off-chain の reexec-evm::header 層に残る
• predicate は floor であり、floor が 0 なら「何もしない」で満たされる（minDelta = 0）

008 で解消したもの（「まだ真」の側に置いたままにしない）:

• verdict 値は uint256。旧 u64 マップは制限ではなく健全性バグだった —— limb 0 をまたぐ 減少が「最大の credit」として証明され、seller へ払われた。in-guest と off-chain が同じ committed bytes の同じ関数になり、14 vector が両側で判定して一致を要求する
• guest は committed hardfork と block environment で実行する。engine identity は仮定でなく検定 （13 vector）で、その各フィールドは dealBinding に入る（18 vector）

さらに:

• 受入条件は「名前」でなく「本体」を検定する。 2026-09-04、003 / 004 / 008 の3本が 独立に同じ誤りを犯した: テストの件数を数え、テストを改名し、禁止語を列挙するが、 テスト本体を一度も開かない。結果、assert!(true) だけの stub が全 AC を通り、 .transfer( を数える検査は approve 1行で破れ、mutation の結果は「手で走らせて報告書に貼る」 自己申告だった。AC を書いたら必ず問え: これを満たしつつ何も検定していない実装は作れるか。 作れるなら、その実装を仕様に名指しで書き、それを落とす AC を足すまで終わりでない。
• 走らせていないものを passing と書かない。 実出力か、さもなくば起きていない。
• 主張は tier を超えない。 local anvil の成功は testnet を意味せず、testnet は mainnet を意味しない。
• ★スパイクが通ることは、プロダクトとして成立することではない（founder、2026-09-14。 別レーンで「事前スパイクが通ったこと」を重く見すぎ、実現可能性の調査で失格になった案を 賞の文言に合うという理由で出しかけた、という実例から）。想定フローがテストで通ることと、 それが誰かの業務として成立することは別の主張であり、後者は前者からは出てこない。 賞の文言に適合することは、この判定に一切寄与しない。 → 012 はこの罠の射程内にある: §2.2 の実測（実 Uniswap swap を無改造 guest で再実行、 13,006,200 cycles、Groth16 497.40 s）は通ったスパイクであって、 「誰のどの業務か」の答えではない。
• 数字が製品に都合よく転んだときこそ疑う。 過去のラボで誤りは常に「案を通す方向」に出た。
• 前の round の数字を引用しない。ハーネスが変わったなら再実行し、変わっていないならそう明記する。

---

6. git 規律

• reckn-codex-impl だけが git を所有する。 他のエージェントは commit も push もしない。 Codex は workspace-write でも .git に書けない。この分担は固定。
• git add -A を使わない。 パスを名指しで stage する（作業ツリーを他のエージェントと共有するため）。
• commit 前に毎回: bash scripts/no-keys.sh、git status、git diff --check、staged 一覧、 そして .env / keypair / 秘密鍵 / target/ / node_modules / 生成物が含まれないことを確認。
• origin を新規作成・削除・置換・URL 変更しない。remote URL をログや報告にそのまま書かない。
• 提出前に repo を public にしない。 public 化は提出時、founder の合図で行う。

---

7. 停止条件

以下に該当したら回避策を実装せず停止して founder に返す。

• scripts/no-keys.sh が落ちた
• 仕様が本当に曖昧（2つの読みとその推奨を書いて止まる。Codex に推測させない）
• レビューが round 6 に到達
• 当日作業と事前作業の境界が曖昧になった
• 0. の中心主張を弱める必要が出た
• 仕様レビューの時刻上限（founder 裁定 2026-09-05）: round 上限（§2 の round 6）だけでは足りない。 9/4–9/5 に12 ラウンド回して APPROVE はゼロ、実装コードもゼロ。上限は機能した（003 は止まった）が、 「6ラウンド分は仕様が膨らむ」ことは防げない（003 は 931 → 5064 行）。以後は時刻で切る:
  • 008 は 2026-09-06 終わりまでに APPROVE。 届かなければその時点の仕様で実装に入り、 開いた項目は開示する（round を追加しない）。
  • 009 は 2026-09-07 終わりまで。 同じ扱い。
  • 003 は再開しない。 §7 hard stop の差し戻し状態を維持する。9/9 ゲートから外れており、 凍結までに 008 / 009 / 004 が入る。9/8 以降に余力があれば founder が再開を判断する。 レビューが見つけてきたものは空回りではない（偽の解放・テストゼロで緑になる AC・結果によらず 緑のデモ・決済権限を持つ未検査ファイル）。切るのは質でなく時間である。
• 9/9 のチェックポイント【2026-09-07 に達成。ac009.sh --all → 13/13 rows passed、 AC-12 が both-green: 2 sibling gate(s) discovered, 2/2 exit 0＝ac005.sh --all と ac008.sh --all を同一走行内で完走。撤退判定は発動しない】: 008 と 009 が緑でなければ、撤退可否を founder に返す。2026-09-04 の応募提出に合わせて 003 から 009 へ差し替えた——応募文が 当日作業の目玉として提示したのは 009（Solana の proof で EVM の escrow を決済）であり、 そこが緑にならないなら物語の中心が無い。003（001 の受入条件を含む）は撤退判定の対象では なくなったが、9/12 の凍結までに着地させる対象であることは変わらない。 9/13–15 は R[3]sidency に明け渡すため、ここで撤退できる形を保つ。 旧文言「001 と 002 が緑」「008 と 003 が緑」は使わない — 001 は独立タスクとして存在せず、 003 は撤退判定から外れたので、どちらもそのままでは判定できない。

8. 禁止

• mainnet デプロイ、実資金の投入、外部ユーザーへの連絡、外部サービス契約
  • 【2026-09-12 founder 裁定 / 2026-09-14 に範囲を書き直した例外2つ】 旧: 「CWF レーンに限る」 → Reckn はその大会に参加しないことになった （docs/cwf-2026/RETRACTED-2026-09-14.md）ので、 範囲を大会でなく計器で切り直す: 解除は下の2つの traction 計器に限る。 どちらも Reckn 自身の成果物についての依頼であり、大会が無くても成立する。 「外部ユーザーへの連絡」を 次の2つに限って解除する。①公開済みのコマンドを走らせて出力を報告してもらう依頼 ②誰でも送れる transaction を1人に送ってもらう依頼（permissionless な refundAfterDeadline）。詳細・依頼文・台帳は docs/cwf-2026/TRACTION.md。 連絡するのは founder であって、エージェントは誰にも連絡しない（この repo に メッセージを送る経路は無い）。mainnet / 実資金 / 外部サービス契約は解除されていない。 @reckn/partner-kit の npm 公開は裁定の対象外なので、依然禁止 （ほぼ不可逆で、かつ scripts/no-unpublished-cli.sh の現在の PASS は 「これらの名前が解決しない」という記述に依存している）。
• docs/ethonline-2026/PLAN.md と DISCLOSURE.md のエージェントによる書き換え（founder の文書）
• 既存の optimistic 経路の"改善"（差別化に寄与せず、当日作業の境界を濁す）
• scope の拡大。迷ったら広げず docs/specs/ の OPEN QUESTION に書いて進む