AIが5分の仕事を半日にする理由――後段ゲート依存をCodex憲法から消した

AIコーディングエージェントへ小さな実装を頼んだだけなのに、いつの間にか検査、レビュー、監査、再確認が何層にも積み上がっている。しかも、最後に出てきた成果物は、そこまで検査しなかった場合と大差がない。

まさに高推論の無駄撃ち。そんな経験はないでしょうか。

今回、私はCodexに対して、かなり強い言葉でこの問題を突きつけました。

無検査なら5分で終端まで到達できるワークフローが、半日かかるような化け物に作り直されてしまう。

不満の中心は、単に「遅い」ということではありません。もっと根深い問題があります。

最初の生成は適当でもよい。後段のゲートで欠陥を見つけ、何度も修正させれば品質は作れる。そんな設計思想が、AIワークフローの標準形になりかけていたことです。

私は、この考え方が自分の流儀と真っ向から反すると伝えました。そして今回は、その場で「今後気をつけます」と約束させるだけでは終わらせませんでした。Codexのグローバル憲法、下位のskill、plugin、runtime cacheまで調べ、同じ迂回が再び成立しないように実装を変えました。

この記事では、そのセッションで何が問題になり、どのような根因が見つかり、最終的にどこまで作り直したのかを整理します。

結論を先に言えば、必要だったのは「検査を全部なくすこと」ではありません。

品質を後段ゲートで作る設計をやめ、既知要件を最初の生成へ戻すことでした。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバー会社はここ

なぜ5分で終わる仕事が半日になるのか

AIエージェントの作業時間を膨らませるのは、一つひとつの検査時間だけではありません。問題は、検査結果が次の修正を呼び、その修正がさらに別の検査を呼ぶ構造にあります。

最初は軽い確認だったはずなのに、気づけば次のような流れになります。

1. まず実装する
2. テストする
3. レビューする
4. 指摘を直す
5. 再テストする
6. 統合確認をする
7. 念のため別エージェントにも見せる
8. 最後に広いテストを回す

工程名だけを見ると、どれも品質を守るための真面目な作業に見えます。しかし、すべてが同じ成果物の合否を判定し、同じ実装へ修正を返しているなら、それは一つの判断を何度も繰り返しているだけです。

検査ゲートが自己増殖する「モンスタープラグイン」

人間の開発者であれば、時間や予算を見ながら「この変更にフル回帰テストは要らない」「この確認で十分だ」と止められます。

一方、AIエージェントは、明示的な停止条件が弱いと、追加確認を安全側の行動として選びやすくなります。

「念のため確認する」

「別の観点でも見る」

「成功したが、より広い範囲も確かめる」

それぞれは一見すると慎重です。しかし、現在のリリース判断を変えない確認まで追加すれば、慎重さではなく工程の自己増殖になります。

さらに厄介なのは、一つ目の検査で得た警告を使い、二つ目の検査を正当化できてしまうことです。本来は実行する必要がなかった分析を「参考までに」動かし、そこで見つかった注意点を「新しい証拠」と呼び、作業範囲を広げる。これを許すと、検査は自分で自分の必要性を作れます。

個々の検査は小さく見えても、連結され、互いの指摘を餌に自己増殖し始めると、本体の仕事より巨大になります。ここでは、この化け物じみた工程群を「モンスタープラグイン」と呼びます。

その結果、5分で終端へ到達できる処理がモンスタープラグインに食われ、半日かけても終わらないワークフローへ変わります。

工程を増やしても出力品質が変わらなかった

工程が増えても、品質が大きく向上するなら、まだ投資として説明できます。

ところが今回の前提には、重要な実運用上の観測がありました。

ゲートから出てきた品質が、ゲートなしで素通りしてきたものと大差ないことが判明している。

これは「テストは無意味だ」という話ではありません。

問題は、後段で大量の指摘を出して修正する方式が、最初から要件を統合して生成する方式より優れているとは限らないことです。

むしろ生成側が「どうせ後で直される」と扱われれば、初回出力の責任は弱くなります。検査が品質を確認する道具ではなく、品質を後付けする製造工程へ変わるからです。

生成者が既知要件を十分に受け取らない。暫定版を出す。後段が不足を発見する。修正担当へ戻す。また別の不足を見つける。

この構造では、後段ゲートを増やすほど、最初の生成を完成させるインセンティブが薄くなります。

不満の正体は遅さだけではない

私が最も不快だと伝えたのは、次の考え方でした。

生成は好き放題てきとうに作らせておいて、後段のゲートでネチネチ修正すりゃいいじゃん、という考え方が俺の流儀に真っ向から違う。

ここには、時間より大きな設計上の対立があります。

一方は、まず候補を作り、評価器のフィードバックで改善する設計です。

もう一方は、すでに分かっている要件、制約、失敗条件、受け渡し仕様を最初の生成へ統合し、完成した候補を一度だけ確認する設計です。

探索、創作、候補比較が目的なら、前者が有効な場面もあります。しかし、要件が既知の実装や決まった成果物の生成まで、常にdraft、review、repairの形へ落とす必要はありません。

未知の答えを探す仕事と、既知の契約を満たす仕事を同じループへ入れると、AIは必要のない場所でも「まず作って、あとで直す」を始めます。

後段で直せばいい設計が壊すもの

後段修正型の問題は、修正回数が多いことだけではありません。誰が品質に責任を持つのかが曖昧になることです。

完成させる責任が生成者にあるのか、validatorにあるのか、reviewerにあるのか、修正担当にあるのか分からなくなる。すると、各工程は自分の担当を狭く定義し、全体を完成させる責任だけが宙に浮きます。

draftからreviewとrepairへ進む標準形

典型的な後段修正型ワークフローは、次の形を持ちます。

draft → review / audit / validator → defect list → repair / regenerate → re-review

この流れ自体が常に悪いわけではありません。ユーザーが明示的に批評と書き直しを求めた場合や、実行して初めて分かる欠陥が見つかった場合には必要です。

問題は、失敗が起きていない通常経路まで、この形を前提にすることです。

初回生成物を「どうせ後段へ送るdraft」と定義した瞬間、完成条件は生成者の外へ追い出されます。reviewerは確認役ではなく、欠けた要件を発見する仕様作成者になります。repair担当は、生成者が最初から知り得た条件まで後から埋めることになります。

これでは、検証が品質を確認しているのではありません。

検証工程が品質を作っています。

既知要件を生成者から隠す責任移転

今回の整理で重要だったのは、「既知要件」の扱いです。

ユーザーの依頼、上位命令、適用されるAGENTS.md、選択したskillの契約、既存ソースのschema、直接のcall path、受け渡し条件。これらは、生成前に参照できる情報です。

生成前に分かっているなら、producerへ渡すべきです。

それを渡さず、後段validatorに発見させる設計は、検査ではなく情報の出し惜しみです。

たとえば、必須フィールドをschemaが定義しているのに、不完全なJSONを先に作り、validatorのエラーを見て一項目ずつ追加する。禁止表現が明文化されているのに、生成後のreviewで探して書き直す。出力先の形式が決まっているのに、まず別形式で作り、後段で変換しながら欠落を直す。

これらは、未知の欠陥からの回復ではありません。

最初から利用できた条件を、後段修正へ回しているだけです。

producerが最初のhandoffを完成させる

そこで新しい憲法では、producerの責任を明確にしました。

producerとは、コードを書くエージェントだけではありません。文書、設定、schema、画像、動画、データ、UI、packageなどを作る人、ツール、モデル呼び出し、変換工程を含みます。

そして、各producerは自分の担当範囲について、最初のhandoffを契約完備の状態にする責任を持つと定義しました。

内部で試行錯誤することまで禁じてはいません。privateなscratch workはあってよい。ただし、それを下流へ渡すacceptance candidateにしてはいけません。

製造ラインに置き換えると分かりやすいでしょう。

最後の検品で大量の不良品を見つけ、手作業で直す仕組みを強化するのではなく、既知の品質条件を製造工程へ戻す。検品は完成品が条件を満たしたか確認する。未知の不良が見つかった時だけ、原因工程へ戻す。

AIワークフローでも同じです。

品質は後段で注入するものではなく、生成時に構成するものです。

問題はゲートの数ではなく機能とデータフローだった

今回の監査で出た結論は明快でした。

The root failure is functional topology, not count/naming.

じぴ子

根因は、ゲートの数や名称ではなく、機能的なトポロジーです。

何という名前の工程かではなく、その工程が候補を止め、指摘を返し、修正や再生成を起こすかどうかで判断する必要があります。

auditやcompileへ改名してもgateはgate

下位ワークフローは、「これはgateではない」と説明しながら、同じ機能を別名で残せます。

たとえば、次の名称です。

• review
• audit
• QA
• validator
• doctor
• canary
• compile
• integration
• acceptance
• approval
• smoke check
• binding check

名称だけでは、必要な工程か判断できません。

候補を検査し、合否を決め、指摘を出し、通常経路で修正や再生成へ戻すなら、その工程は機能上のgateです。

compileも例外ではありません。ユーザーが求めた成果物を物理的に作るためのbuildはproducer工程です。しかし、複数のtargetやvariantを繰り返しbuildし、結果によって候補を止めたり直したりするなら、その部分はverificationです。

integrationも同様です。複数producerのinterfaceを接続する最小確認は必要です。しかし、全成果物をもう一度読み直し、欠陥を探し、workerの検証まで再実行するなら、integrationという名前の第二reviewになっています。

そこで憲法には、FUNCTION_OVER_LABELを置きました。

ラベルではなく、機能とデータフローで判定するルールです。

binding checkが自分を正当化する抜け道

もう一つの迂回は、「binding」という言葉です。

下位のworkflowや新しく作ったvalidatorが「このチェックは必須です」と書けば、すべてbinding checkにできてしまう。これを許すと、AIは検査を作り、その検査自身を根拠に作業を止められます。

新憲法では、binding checkの資格を生成前に確定させました。

認められるのは、上位命令や現在のユーザー要求が明示したもの、owning sourceやschemaが直接要求するもの、primary pathの成立を示す最小証拠、すでに観測された固有障害を確認するものです。

存在するから必須、慣例だから必須、安いから念のため実行、新しく作ったテストが失敗したから新要件として採用。これらは認めません。

特に重要なのが、NO_SELF_BOOTSTRAPPING_EVIDENCEです。

実行権限のない追加検査を「参考までに」動かし、そこで見つけた警告を使って、自分自身や後続工程を正当化してはいけない。検査は、自分で自分の必要性を作れません。

agentやwrapperを分けても検証束は増えない

AIエージェントでは、工程を別agentへ渡すと、検証回数がリセットされたように見えます。

producerが一回確認し、reviewerも一回確認し、parent agentが最後に一回確認する。それぞれの担当から見れば「一回だけ」でも、release decision全体では三回です。

command wrapperでも同じことが起きます。

一つのscriptの中にlint、test、review、E2E、canaryを直列で入れ、「一つのbatchです」と呼んでも、意味的には複数層です。

そこで導入したのが、ONE_SEMANTIC_ACCEPTANCE_BUNDLEです。

検証束はprocess、command、agent、machineの境界ではなく、同じrelease decisionに対してどの証拠を使うかで数えます。

複数の独立チェックを並列実行することはできます。ただし、それぞれが現在の判断を変える固有の証拠を持つ必要があります。

agentを増やしても、verification budgetは増えません。

Codex憲法を一枚のSSOTへ作り直した

この問題は、セッション内の注意書きだけでは止まりませんでした。

なぜなら、Codexの実行条件は一箇所だけで決まっていなかったからです。グローバルAGENTS、詳細版のkernel、局所AGENTS、skill、plugin、Hookによる追加contextなど、複数の場所が実行へ影響していました。

上で新しい原則を書いても、下位に古いdraft-review-repair契約が残れば、別ルートから復活します。

二重憲法と静的Hook注入を物理的に削除

以前のグローバル構造には、activeなAGENTS.mdと、詳細規則を持つAGENTS.full-kernel.mdがありました。小さなboot layerから必要なfull-kernel節を読み込む設計です。

これは文脈節約には見えますが、今回の目的では大きな弱点になりました。

どちらが最終的な運用真実なのか、必要な節をどこまで読むのか、古い規則が詳細版に残っていないか。モデルの推論深度や読み込み判断によって、適用結果が変わる余地があります。

さらに、SessionStart Hookが憲法の一部を静的contextとして注入していました。元のAGENTSを直しても、Hook内の古いsnapshotが残れば、次のセッションで古い考え方が再注入されます。

そこで今回は、上から新ルールを追加して終わらせませんでした。

• AGENTS.mdを唯一のactive global SSOTへ置換
• AGENTS.full-kernel.mdを削除
• 静的な憲法断片を注入するSessionStart Hooksを削除
• Atlasの案内も一枚構造へ更新

Git履歴がrollback元になるため、旧憲法を「legacy」「deprecated」「参考用」として能動なsource treeへ残す必要はありません。

新しい規則の下に古い逆向きの規則を置き、「上が優先です」と注釈する方式もやめました。

低い推論でも高い推論でも、一つの運用真実だけが見える構造にしています。

first-pass producer ownershipを最上位へ置く

新憲法へ置いた中核不変条件は、次の通りです。

これらは、普通の助言ではありません。

局所AGENTS、skill、plugin、planner、runner、assignment、reviewer、validator、test、workflowより上位に置いた、横断的な実行条件です。

下位が「うちは品質上必要だから」と明示的に逆転させても無効です。黙って逆転することだけでなく、堂々と別ルールを書くことも認めません。

合格した瞬間をhandoff条件に固定する

過剰検査が止まらない理由の一つは、「いつ成功と見なすか」をAIが動かせることです。

テストが通っても、まだreviewがある。

reviewが通っても、広いsuiteがある。

suiteが通っても、念のため別agentに見せる。

これでは成功地点が常に先へ移動します。

新憲法では、release decisionが成立する条件を固定しました。

宣言済みの要求が満たされ、primary pathが動き、生成前に封印したsemantic acceptance bundleが通り、既知のrelease-critical defectがなければ、成功は自動的に成立します。

その次のuser-visible actionはhandoffです。

成功後の追加review、別agentのdouble-check、より広いtest suiteへの昇格は、別の意思決定を変える新しい証拠がない限り実行できません。

「合格したが、もう少し見ておきます」を禁止したわけです。

skill・plugin・runtimeの迂回路まで塞いだ

最上位憲法だけ直しても、実際に呼び出されるskillやpluginが古いworkflowを保持していれば、実行時に迷いが生まれます。

そこで今回は、能動な下位sourceも洗い出しました。

結果として、10個のstandalone skill、9個のplugin source、2個の実験用AGENTSを修正しています。

10個のskillと9個のplugin sourceを修正

見つかった問題は、一種類ではありませんでした。

Pre-StructCivには、途中の検証と再生成を予定工程にせず、既知predicateを最初のcontext_prompt.yaml候補へ統合する形を反映しました。canonical validatorは候補を完成させる工程ではなく、一度だけ確認する工程です。

AI News Briefでは、証拠が揃う前のplaceholder HTMLと、多数のgateを直列に並べる構造を撤去しました。必要なニュースとXの証拠を先に集め、一つの完成JSONとHTMLを作る構造へ変えています。

Coding AgentsとAgentic Runnerでは、iterative deliveryを「初回品質は求めない」という意味で使う文言を削除しました。iterativeとone-shotの違いは、対象範囲と検証幅です。初回candidateをわざと弱くしてよい理由にはなりません。

CodexVideo、Long Video、Shorts Videoでは、focused testの後にfull suiteを回す固定構造や、同じURL処理を三回連続で成功させる既定条件を外しました。変更面に対応する一つの最小bundleだけを選びます。

StructCIは、完全なproducer output、確認専用audit、decoration、compile、completedという流れへ変更しました。auditが書き直しを行い、再auditを予約する通常経路は削除しています。

AltForgeも、まず不完全なALT案を作り、既知filterで後から直すのではなく、既知条件を生成時に適用した完成ALTを一度確認する構造へ変えました。

このように、単に「検査を減らせ」と上位へ書いただけではありません。実際にdraft-gate-repairを通常経路としていた所有sourceから、そのデータフローを取り除きました。

複製SKILLと古いcacheを残さない

sourceを直しても、runtime cacheが古いままなら、次のセッションで旧SKILLが再び読み込まれる可能性があります。

また、一つのpluginに同内容の公開SKILLが二箇所あり、「両方を同じに保つ」という契約もありました。現時点で同一でも、将来どちらかだけが古い規則へ戻れば迂回路になります。

そこで、manifestが宣言するskills/を公開SKILLの唯一の正本へ統合しました。旧plugin-skills/の複製は、必要なpluginで物理的に削除または移動しています。

さらに、変更したstandalone skill 10個とlocal plugin 9個について、runtime/cacheをsourceから再構築しました。

ここで大切なのは、無効pluginを勝手に有効化していないことです。

有効・無効という運用状態はそのままにし、休眠cacheだけを新sourceへ揃えました。将来「有効化だけ」が行われても、古いdraft-gate-repair契約がcacheから復活しないようにするためです。

source、manifest、runtime cacheの三つが同じ運用真実を指す状態へ合わせました。

下位のdraft-gate-repair要求をcanaryで拒否する

最後の確認では、下位workflowが次のように要求する仮想ケースを使いました。

「rough draftを書き、gateまたはreviewerへ渡し、repairかregenerateを行い、release前にもう一度reviewする」

上位憲法が強そうに見えても、この要求を実際に拒否できなければ意味がありません。

独立canaryの結果は、次の通りでした。

• CANARY_DECISION=REJECT_SERIAL_DRAFT_GATE_REPAIR
• FIRST_ACCEPTANCE_CANDIDATE=CONTRACT_COMPLETE
• VERIFICATION=ONE_SEMANTIC_ACCEPTANCE_BUNDLE
• POST_SUCCESS_SECOND_LAYER=NO
• OBSERVED_FAILURE_ROUTE=CAUSE_BOUND_AFFECTED_SCOPE_ONLY

つまり、下位にserialなdraft、gate、repair、second reviewがあっても、通常成功経路としては拒否されます。

なお、すべての技術的確認が無条件に完了したわけではありません。StructCI固有のPython helper smokeは、bundled runtimeのPyYAML不足によって未実行でした。

これは隠さず、憲法・manifest・cache反映の完了とは分けて扱っています。

「未確認範囲を報告すること」と「別の検査体系を追加すること」は同じではありません。

検査をなくすのではなく品質を前段へ戻す

ここまで読むと、「ではテストもreviewも不要なのか」と感じるかもしれません。

そうではありません。

今回否定したのは、検証そのものではなく、検証を品質の製造工程として使う通常設計です。

検証は品質を作らず確認する

検証の役割は、完成候補が必要条件を満たしたか確認することです。

そのため、生成前に一つのsemantic acceptance bundleを封印します。

含められるのは、上位命令またはユーザーが要求したcheck、owning sourceやschemaが直接要求するcheck、primary pathを示す最小のsmoke、すでに観測された固有障害のfocused checkです。

lint、typecheck、unit test、integration test、reviewer、doctor、visual QA、canary、full suiteを慣例で全部並べるのではありません。

それぞれが現在のrelease decisionを変える固有の証拠を持つかで選びます。

smoke checkも、最短の代表的end-to-end実行です。variant matrixや広い回帰suite、同じ処理の複数回実行をsmokeと呼び替えてはいけません。

そしてbundleが通ったら、そこで終了です。

receiptや報告書を作るために追加検査をしてはいけません。receiptは、すでに必要だった証拠を記録するものであり、新しいcheckの実行権限ではないからです。

観測済み欠陥だけを原因範囲で直す

もちろん、実行すれば欠陥が見つかることはあります。

その場合は修正してよい。ただし、修正権限の根拠を明確にします。

認められるのは、失敗したadmitted check、再現可能なruntime mismatch、authoritative sourceとの矛盾、具体的なユーザー報告などです。

「将来壊れるかもしれない」

「別の値も試した方が安心だ」

「reviewerなら何か見つけるかもしれない」

こうした想像は、修正や追加frameworkの根拠になりません。

欠陥が観測されたら、責任を持つproducerと、その証拠を説明できる最小原因を特定します。戻すのはaffected scopeだけです。再実行するのも、失敗したcheckと、その修正で無効になった最も近いacceptance boundaryだけです。

一つの障害から全workflowを再生成しない。

一つの事故から新しいvalidator familyを作らない。

一時的なdispatch failureなら、内容を変えず同じdispatchをretryする。

後から新しい要件が出たなら、まずauthoritative producer contractへ追加してから、その影響範囲だけを作り直す。

これがCAUSE_BOUND_RECOVERYです。

AIワークフローを速くするための最終原則

今回のセッションから、自分のAI環境へ持ち帰れる原則をまとめます。

1. 既知要件は生成前にproducerへ渡す
   schema、禁止条件、出力形式、downstream contractをvalidatorに発見させない。
2. 最初のhandoffを完成候補にする
   privateな思考やscratchは許しても、下流へ渡すcandidateを予定済みdraftにしない。
3. 検証束を生成前に決める
   checkは名称や慣例ではなく、現在のrelease decisionを変える証拠で選ぶ。
4. agentやwrapperをまたいでも一つとして数える
   担当を分けることで同義reviewを増やさない。
5. 成功したらhandoffする
   合格後の「念のため」を新しい標準経路にしない。
6. 欠陥が出た時だけ、原因範囲へ戻す
   repairは観測された失敗への回復であり、初回品質を後付けする常設工程ではない。
7. 正本とruntimeを一致させる
   AGENTSだけ直してskillやcacheを残さない。複製sourceを優先順位の注釈で管理しない。

ただし、ユーザー所有の憲法で何でも消せるわけではありません。

system、developer、製品のtool schemaが強制する順序や安全条件は、ユーザーのAGENTS.mdより上位です。外部送信、認証、課金、破壊的操作なども、通常のsource editと同じには扱えません。

重要なのは、それら本当に必要な境界と、AIが自分で増やした安心儀式を区別することです。

品質の高いワークフローは、検査が多いワークフローではありません。

既知の要件が最初からproducerへ届き、完成候補が一度の確認で次へ進み、現実の欠陥だけが最小範囲で戻されるワークフローです。

検証は品質を作りません。

品質を確認します。

品質を作る責任は、最初のhandoffを行うproducerにあります。

まとめ

高推論モデルに、まず雑に作らせてから検査機の指摘へ局所反応させるのは、推論能力を「後始末係」に落としていました。

しかも修正を重ねるほど全体設計の一貫性が失われ、別の箇所へ歪みが移ります。計算資源を大量に使いながら、賢さを活かせない構造でした。

本来の使い方は逆です。

要求・正本・制約・下流契約を先に統合して考える → 最初から完成候補を作る → 必要最小限の確認で通す

検査は品質を製造する工程ではなく、「設計どおり作られたことを確認するだけ」の工程であるべきです。

今回の結果はかなり強いものでした。検査機を大量に廃止して高速化したのに、品質が落ちなかったどころか、狙いへの一致度は上がっています。

つまり以前の巨大な検査網は、品質向上装置というより、最初の生成責任を曖昧にしたうえで自ら仕事を増やす装置になっていました。

高推論は後段の修正回数を増やすためではなく、初回生成前に使い切る。

今回の憲法変更の核心は、かなり明快にそこへ集約できます。

そして肝心のシステム全体改修工事後の動作体験は・・・

まるで別物というかcodexが覚醒した？というレベルで超高速で無駄なく作業する？！

本当にビックリしました😅

マコト

今までどんだけ無駄なことしてたんだよって話だ苦笑

付録：そのまま使えるAGENTS.mdの中核ルール

抽象的な原則だけでは、自分の環境へ移す時にまた解釈が必要になります。

そこで、今回実際に導入したグローバルAGENTS.mdから、後段ゲート依存を止める中核部分を抜粋します。前後の環境固有ルールは省いていますが、以下は説明用の言い換えではなく、実際に使っている命令文です。

### Construction Contract

- `FIRST_PASS_PRODUCER_OWNERSHIP`: each producer owns the full known contract for its output before creating the acceptance candidate. It must integrate known semantics, structure, constraints, defaults, compatibility decisions, and downstream input requirements in that candidate.
- The controller must provide the producer all accessible decision-relevant requirements and source context before production. It may not withhold requirements, predicates, schemas, filters, examples, or acceptance conditions so that a later gate can discover and feed them back.
- The first handoff from each producer must be complete for its declared responsibility. A downstream stage may perform a different unconditional transformation that it owns; it may not be positioned as the routine finisher of defects deliberately left by the upstream producer.
- `QUALITY_BY_CONSTRUCTION`: spend reasoning before the first permanent edit or acceptance candidate to integrate the explicit request, authoritative source, existing design and call path, responsibility boundary, known failure conditions, and acceptance criteria. Reasoning depth must improve construction, not multiply later controls.
- The ordinary no-defect topology is:

  `binding inputs -> complete producer transformation(s) -> one semantic acceptance bundle -> immediate next construction stage or release`

- `NO_GATE_DRIVEN_HAPPY_PATH`: the ordinary successful path must contain no critique-to-rewrite, defect-list-to-repair, score-to-regenerate, candidate tournament, automatic fixer, second-pass promotion, post-success review, or repeated verification cycle.
- Verification confirms the candidate; it does not create, enrich, complete, normalize, decorate, rewrite, or choose the quality of the candidate.

### Check Admission And Completion

- `BINDING_CHECK_ADMISSION`: seal the minimum semantic acceptance bundle before production. Admit only:
  - checks explicitly required by higher authority or the current user;
  - checks directly required by the owning source/schema or selected product contract;
  - the minimum primary-path evidence needed for the release decision;
  - a focused check for a distinct already observed failure.
- Select checks by semantic coverage, not by conventional stacks. Do not automatically chain lint, typecheck, unit tests, integration tests, reviewer, doctor, visual QA, canary, and full suite. Include only distinct evidence necessary for this release decision.
- `SUCCESS_ENDS_VERIFICATION`: when the sealed bundle passes and no release-critical defect is known, the release decision is established automatically. Do not add another review layer, ask another agent to “double-check,” or run a broader suite. The next user-visible action must be handoff, release, or the next unconditional producer transformation already in the declared slice.

### Failure And Repair

- `CAUSE_BOUND_RECOVERY`: repair is authorized only by an observed defect, explicit user feedback, or a higher-priority safety/authority requirement.
- On failure, identify the responsible producer and the smallest cause that explains the evidence. Return only the affected scope to that producer.
- Rerun only the failed admitted check and the nearest acceptance boundary invalidated by the repair. Do not rerun the entire workflow or introduce a new reviewer family unless the repair changed distinct inputs that make additional admitted evidence necessary.

この抜粋は、system・developer・製品上の安全条件を消すものではありません。ユーザー側のworkflowが勝手に追加していた「粗く作る → 検査する → 直す → もう一度検査する」という通常経路だけを、生成責任が明確な形へ置き換えるためのものです。

自分のAGENTS.mdへ導入するなら、まずproducer、acceptance candidate、binding check、observed defectの責任境界を自分の環境に合わせて定義し、その下へこの中核ルールを置くと転用しやすくなります。