[Legacy refresh] 77e6af7be1d527 — Zero-Trust Completionを「完成と言い切る条件」の実運用比較へ #137

Short-context handoff

Goal

• legacy記事 77e6af7be1d527 をZero-Trust Completionの抽象論から、toolのsuccessと利用者が見るfinal stateの差を実例で検証する記事へ置き換えるか判断する。

Read first

1. pipeline/contracts/article.md
2. parent Legacy Zenn 10記事の置換・退役トラッカー #126
3. https://zenn.dev/kafka2306/articles/77e6af7be1d527

Change only

• この1記事のcross-domain case収集・comparison・replacement candidate。

Start here

1. code / CI / deploy / content / asset等から異なる3domainのfalse completion caseを集める。
2. 各caseを claimed done / observable outcome / missing verifier / receipt で整理する。
3. completion contract導入後に止められたfalse completionを追う。

Do not

• human verificationを無条件に増やさない。
• deterministic oracleだけで完結する処理へ外部verificationを強制しない。
• #138の「runnerとacceptance policyの分離」と混同しない。

Done when

• 3domain以上のfirst-hand caseがある。
• claimed successとobservable final stateの差から独自の判断ruleを導ける。
• replacement / MERGE / RETIREが確定する。

Article contract

• generalizable_insight: completionは実行主体のsuccess signalではなく、利用者が観測できるoutcomeと独立verifierを結び付けて判定する。claimed done -> observable outcome -> independent verifier -> receipt を分けるとfalse completionを減らせる。
• transfer_conditions: build / CI / deploy / publication / asset generation等、内部successとfinal stateが別layerのworkflow。
• non_transfer_conditions: same-process deterministic oracleで完成を完全判定できる処理。
• first-hand fixture: 3domain以上のfalse completion case + verifier導入後receipt。
• reusable exit: completion checklist + 内部oracleだけで十分なstop condition。

#138との差: #137は claimed completion vs observable final state、#138は execution mechanism vs acceptance policy。

Candidate question: 「成功」と表示されたのに、なぜ終わっていなかったのか？