Pre-choice usable artifact execution

Purpose & Output Contractの最小の実成果物をmain contextで作成する。effect別のparse/open・secret・irreversible・corrupt guardだけを実行し、現物path・digest・開き方を提示してからaccept-as-is/light/standard/detailedを記録する。accept-as-isはその場でhandoff完了とし、後続sectionを実行しない。

Post-choice selected improvement execution

以下の既存workflow・goal-seek・評価・修正sectionはlight/standard/detailedが記録されてsemantic_evaluator_startedへ遷移した場合だけ実行する。release/exhaustiveは別の明示eventを必要とする。

run-dev-graph-node

Purpose & Output Contract

• 入力: C24 で containment 検証済みの artifact candidate、既存 graph snapshot、または exact-13 package。
• 出力: C02 単一 writer 経由で atomic 登録された typed node/package と revision/digest receipt。
• 完了条件: kind/path/frontmatter/dependency が schema と一致し、package は P01..P13 exact-set のときだけ applied count 13 となる。

全 graph/content write の単一 writer。通常 artifact は issue/task/specification/architecture/document、macro feature は C14 (run-dev-graph-decompose) が宣言した macro contract だけを add の artifact_kind=feature で features/ に登録する。

Classification and write

1. C24 resolver で全 read/write realpath の containment を検証する。
2. 内容から artifact_kind/domain/project_id、候補 path、confidence/reason/second candidate を preview する。confidence>=0.80 かつ margin>=0.15 は自動確定し、それ以外だけユーザー確認する。保存先は質問しない。
3. template-contract.json から kind template を選ぶ。architecture は subtype 全件、specification は API 変更時だけ api-contract overlay を合成する。
4. frontmatter/body/path と graph node を一時領域で構成し validate-graph-schema.py を通してから atomic replace する。更新は既存本文を全置換せず、変更 field だけを更新する。不足 section は writer が返す readiness_fill[] ({item, via, key}) の via と key をそのまま使って埋める (placeholder のままの見出しは set_sections、見出しが無い section は append_sections、API block が無ければ add_api_contracts、feature の projection は macro_patch の field (key=purpose など) か node_patch.depends_on)。placeholder のままとは、section の全行が template の雛形行か placeholder (placeholder_tokens。< は <...> の範囲を指す) だけの行であることを指し、p95 < 300ms・Bearer <token>・未定だが 30 日を上限にする のような本文と <https://…> の autolink は埋まっている扱い、ラベルと placeholder だけの行 (- メモ: <TBD>、理由の無い N/A: <reason>) は placeholder のまま扱いになる。via=null (手で消された subtype block や leaf) は writer に埋める経路が無いので停止して報告する。readiness の項目名 (api-contract・<subtype>:<leaf>・api:<op>:<leaf>) を見出しキーに渡すと readiness_item_is_not_a_heading で拒否される。物理削除は禁止。

add/update/bind-github/link-github verb は手順 1-4 の実装本体 ../../scripts/build-graph-node.py に委譲する (add|update|bind-github|link-github --repo-root <path> --input <repo 内 JSON> [--dry-run])。skill は R1/R2 の分類結果と section 本文を入力 JSON に整形するだけで、graph・content・receipt を Write/Edit や自作 script で直接書かない。writer は C24 解決、入力の repo 内 containment (相対 --input は repo root 基準)、expected_graph_revision の CAS、register-package と共有する fcntl lock、staging 上の validate-graph-schema.py 再検証、content→graph→immutable receipt の順の atomic commit と失敗時 rollback を一体で持つ。apply では R2 preview の graph_revision_before を expected_graph_revision (整数) に必ず渡す。省略は missing_expected_graph_revision、整数以外は invalid_input、preview 後の変更は graph_revision_conflict で止め、省略できるのは --dry-run だけである。書込み前検証は baseline 差分で判定し、変更した node は finding 0 を要求し、変更していない node の既存 finding は持ち越す。

• add: artifacts[] に artifact_kind/slug/title/project_id/domain/tracker_binding/classification と、kind に応じた artifact_subtypes (architecture は 1 件以上、specification は api_contracts があれば api を自動補完) と任意の sections・subtype_sections・api_contracts・depends_on を渡す。形は classification={reason, candidates:[{artifact_kind, confidence}], decision: auto|user_confirmed}、api_contracts=[{operation, sections:{leaf 見出し: 本文}}]、subtype_sections={subtype: {leaf 見出し: 本文}}。id は <kind prefix>-<slug>、path は kind の正規 root 固定で、保存先は入力に含めない。分類は閾値未達なら decision=user_confirmed が無い限り拒否する。C14 が宣言した architecture だけは classification={reason, decision: c14_macro_contract} (candidates 無し) で登録でき、同じ batch の feature の architecture_refs が参照していなければ invalid_classification になる。sections の追加キーは単一行・先頭 # 無し・> 無し・120 字以内・secret 無しの見出しだけを受け付ける (invalid_section_key)。既存 feature へ後から architecture を足すときは、その architecture を通常の classification (candidates 付き) で add してから、feature を update の macro_patch.architecture_refs で参照させる。source_lineage.origin_kind=system-spec-harness を渡した node は、../../scripts/validate-source-lineage.py と同じ関数で source_path の実在と source_digest の一致を登録前に検査し、解決しなければ source_lineage_unverified で拒否する。
• update: updates[] に graph_node_id と set_sections (見出し直下の本文だけ置換、祖先 > 見出し で曖昧さを解消。H1 より下のパスを全部書いたキーは完全一致を優先するので、修飾しない名前は同名の H2 を指す)・append_sections (末尾に H2 で追記、同名の H2 があれば duplicate_section)・add_subtypes (block は subtype の正規順の位置へ挿入)・add_api_contracts・node_patch・macro_patch (feature のみ) を渡す。id/path/kind/template と外部 authority の field は変更できず、非管理 section のバイト列と contract 外の frontmatter キーは保持する (unmanaged_frontmatter_kept)。writer が生成した section (Subtype architecture・API契約) は、本文が旧状態の生成文と一致するときだけ新状態で再生成し (sections_regenerated)、人手で編集済みなら set_sections の同時指定が無い限り generated_section_diverged で拒否する。feature の projection は update のたびに frontmatter から再投影するので、手で編集した本文も手で消した見出しも次の update で戻る (sections_regenerated。消えた見出しは required 順の位置へ挿入する)。status/closed_at 以外の内容変更は evaluation_status=pass を stale に戻す。ただし tracker_binding=github の node では、GitHub と双方向に同期する title/priority/start_date/target_date/iteration の変更も pass を保つ (公開中・active の node は schema 上 pass を外せないので、C03 がこれらを import できるようにする。本文の変更は stale になり、書込み前の検証で拒否される)。graph 上の node に schema/frontmatter の必須キーが欠けていれば、書く前に node_missing_required_keys (findings[].detail が欠けたキー名) で止める。
• feature は add に macro={purpose, goal, scope_in[], scope_out[], acceptance[], architecture_refs[]} を渡したときだけ登録し、classification は受け付けない (decision は c14_macro_contract 固定)。architecture_refs の先は architecture、depends_on の先は feature でなければ invalid_macro_reference。目的・到達状態・スコープ・受入・アーキテクチャ参照・機能間依存は macro の projection なので sections/set_sections/append_sections では書けず (macro_section_is_projection)、変更は macro_patch/node_patch.depends_on で行う。macro が無い feature は feature_requires_c14_macro_contract、parent_feature/feature_package_id/phase_ref は register-package へ回す。拒否時は applied_count=0・write_count=0 を返す。
• tracker_binding は register-package と同じ規則で repo の tracker mode (execution_tracker.mode = beads/github/both) と照合する。none は binding の値で mode ではなく、常に可。beads/github は mode が同じか both のときだけ可 (tracker_binding_not_allowed)、repo-config-default は mode が beads/github ならその値に解決し、both や mode 不明では tracker_binding_unresolved。github に解決された binding は draft node では schema を満たせないため github_binding_requires_confirmed_node で拒否するので、github mode の repo では none で登録し、confirm/pass の後に bind-github で切り替える。
• bind-github: bindings[] に {graph_node_id, publication_mode?} (issue 既定、または issue_and_projects) を渡し、confirmation_status=confirmed・evaluation_status=pass・readiness complete の issue/task を tracker_binding=github (beads_linkage=null、github_publication.mode を issue 系) へ切り替える。frontmatter だけを再生成して本文のバイト列は保持し、evaluation_status=pass は変えない。mode が github/both 以外は tracker_binding_not_allowed、未 confirm/pass は github_binding_requires_confirmed_node、issue/task 以外は bind_github_requires_issue_or_task、beads に link 済みは beads_linkage_present、package member は package_member_requires_register_package で拒否し、既に同じ状態なら noop。GitHub への投影はその後 C12 (run-dev-graph-sync) が行う。
• link-github: links[] に {graph_node_id, issue_linkage?, github_project_linkages?} を渡し、C14 の linkage_proposal と C03 の同期結果 (field_snapshot・sync_state) を tracker_binding=github の node に記録する。issue_linkage は github.issue_repository の Issue だけを受け、別番号への付け替えは issue_linkage_conflict、null は変更なし。project linkage は project_alias ごとに置き換え、field_snapshot はキーごとに重ね、最初の linked_at を保つ。未設定 alias は unknown_project_alias、owner/project_number の食い違いは project_identity_mismatch、別 item への付け替えは project_item_conflict、github 以外の binding は link_github_requires_github_binding で拒否する。linkage は GitHub 側の状態の写しなので、本文・evaluation_status・updated_at を変えず、変化が無ければ noop。C14 は exact-13 package member も投影するので、update/bind-github と違い package member も受ける (linkage は system-dev-planner が持つ本文・binding・package key に触れない)。member は register-package と同じく graph だけに記録し、artifact file と内容 key を求めない (receipt の graph_only)。

Exact-13 package gate

register-package verb はこの gate の実装本体 ../../scripts/register-package.py に委譲する (register-package.py register --package <path> --graph <path> --output <path> --receipt <path> [--tracker-mode <mode>] [--config <path>]、事前検査は register-package.py preflight)。tracker mode は --config (既定 .dev-graph/config.json、--repo-root 基準) の execution_tracker.mode (beads/github/both) を読み、build-graph-node と同じ値で binding を解決する。config ファイルが無い、mode が無いか beads/github/both 以外のときは flag があっても進まず exit 2 で拒否する。--tracker-mode は config と同じ値の明示だけを受け付け、食い違う値も exit 2 で拒否する。拒否時の出力は applied_count=0 を持つ。単一 writer は register-package.py が fcntl ロックと receipt の os.link 一回性で保証し、skill 側は入力整形と結果提示に留める。

system-dev-planner の package は P01..P13 exact set、13 node、共通 parent_feature/feature_package_id、同一 package 内だけの DAG、source digest、tracker binding を commit 前に検証する。12/14件、phase 重複/欠落、mixed parent/package、cross-feature edge は applied_count=0 で拒否する。成功 receipt は status/source_digest/expected_count=13/applied_count=13/graph_revision_before/graph_revision_after/node_ids/registered_at を持ち immutable に保存する (schema: ../../schemas/package-registration-receipt.schema.json)。

--dry-run は local/external write 0。失敗時に一部 node を残さない。

Execution-context consumer

C27 の claim saga は register-package.py execution-context --graph <path> --graph-node-id <id> --context-json <json> を内部 consumer として必ず実行する。この入口も C02 単一 writer の lock・graph-node schema 検証・atomic replace を共有し、同一 worktree_id の context を冪等置換する。C27 が receipt を自作・持込みせず、consumer が返す owner=C02/run-dev-graph-node、operation=project_execution_context、status=applied、node/worktree identity 一致を確認してから claim を確定する。

ゴールシーク実行

ゴール (Goal)

通常5 artifactを自動分類し、C14由来featureとsystem-dev-planner由来exact 13 phase tasksをそれぞれの専用契約で正規pathへatomic追加・更新し、graph/frontmatter/body/path/package整合を保つ

目的・背景 (Why)

成果物を単一graphで保持する専用writer。feature由来task batchはsystem-dev-plannerのfeature package契約に従い、P01..P13 exact 13 node、共通parent_feature/feature_package_id、同一package内dependencyを事前検証してall-or-none commitする。tracker bindingも同じtransactionで解決する

完了チェックリスト

• 全 read/write realpath が resolved repo root 内で repository_id が一致する
• classification decision が閾値による自動確定または明示 user confirmation の証跡を持つ
• 通常 artifact の frontmatter/body/path/template metadata が schema と一致する
• package は P01..P13 exact 13、共通 parent/package、内部 DAG を満たし、違反時 applied_count が0である
• 成功 receipt の graph_revision_after と node_ids が commit 後 graph と一致する

progress.json の checklist は、上の5項目を順に id containment・classification・schema・package・receipt で持ち、各項目の status を achieved・not_achieved・not_applicable のどれかにする。not_applicable にしてよいのは次の場合だけで、その項目の evidence に代わりに確かめたものを書く。これ以外の未到達は not_achieved とする。

• containment と schema は not_applicable にしない。graph だけに書く起動 (register-package と、package member への link-github。receipt の graph_only) と noop の起動の schema は、対象の node が validate-graph-schema.py の report で finding 0 であることを evidence にして判定する。
• classification: 通常 artifact の add をしない起動 (update・bind-github・link-github・register-package) と、C14 の macro contract による add (feature と、decision: c14_macro_contract の architecture) では分類をしない。evidence には起動した verb と decision を書く。
• package: register-package をしない起動。evidence には起動した verb を書く。
• receipt: receipt を書かない起動。--dry-run では、preview の graph_revision_after・node_ids・write_count: 0 と、graph の canonical digest が preview の前後で変わらないことを書く。noop (bind-github が同じ状態、link-github が変化なし) では、その返り値を書く。register-package の再実行 (前の receipt を idempotent: true で返す) では、前の receipt の path・graph_revision_after と、その node_ids が今の graph にあることを書く。

pre-choice で commit した run では、checklist はその commit も含めて判定する。pre-choice の receipt は writer_receipts に足さない (下のゴールシーク配線) ので、その receipt で判定する項目 (receipt、register-package の package、分類した add の classification) は not_applicable にせず、evidence に receipt の path を書く。receipt の evidence には、さらに次を書く。

• 最後の pre-choice の receipt の graph_revision_after・graph_digest_after が graph_baseline と一致すること。
• pre-choice が2回以上 commit したときは、すべての receipt の path と、receipt どうしが鎖になっていること (次の receipt の graph_revision_before が前の receipt の graph_revision_after と一致する)。

鎖が切れるのは、pre-choice の commit どうしの間に、run の外で revision が進んだときである。最後の receipt が baseline と一致しないのは、最後の commit と post-choice の開始の間に、run の外で graph が変わったときである。どちらのときも receipt を not_achieved にし、下の配線と同じく baseline を取り直さず、progress.json の overall を blocked にして親へ handoff する。この照合は、最初の pre-choice の commit より前の graph の変化と、commit どうしの間で revision を進めない書き換えを見ない (receipt は書く前の digest を持たないので、鎖は revision だけを見る。下の配線の post-choice の鎖と同じ限界)。

ゴールシークループ

frontmatter の goal_seek.engine: inline / fork: subagent / max_loops: 5 を実行契約とする。固定手順は使わず、未達 checklist と担当 prompts/*.md からその周回の操作を都度生成する。各周回で inner criterion を検証する。outer criterion (loop_scope: outer) は skill の外 (live trial・受入テスト・content review) が最大 feedback_contract.max_iterations=3 周で評価するもので、この run の中では判定しない。

engine と fork は別の軸である。engine: inline は、周回の駆動 (未達 checklist の選択・停止判定・intermediate の記録) を main context がこの本文に沿って行うことを指す。fork: subagent は、各周回の responsibility の実行と独立検証を Agent で分離 context に出すことを指す。

ゴールシーク配線

• 開始時に C24 resolve-repo-context.py --mode write の JSON receipt を得て、repo_root が content_roots.repository の realpath と一致する場合だけ DEV_GRAPH_ROOT=<receipt.repo_root>・DEV_GRAPH_GRAPH=<receipt.local_state_paths.graph> に固定する。cwd から再解決しない。
• 元のゴールを $DEV_GRAPH_ROOT/eval-log/run-dev-graph-node-goal-spec.json へ、各 checklist の status/evidence を $DEV_GRAPH_ROOT/eval-log/run-dev-graph-node-progress.json へ記録する。
• 未達 responsibility を担当する prompts/<R-id>.md を読み、Agent で分離 context に fork する (fork: subagent。周回の駆動は main context のまま)。ユーザー判断が必要な境界だけ AskUserQuestion を使う。
• 必須の独立 verifier は dev-graph-integrity-auditor (../../agents/dev-graph-integrity-auditor.md。plugin 経由の名前は dev-graph:dev-graph-integrity-auditor) である。light/standard/detailed を記録して semantic_evaluator_started へ進んだ run では、各周回の writer receipt・commit 後の graph snapshot・validate-graph-schema.py の report を Agent で read-only の fork context に渡し、writer の推論や期待 verdict は渡さない。返った verdict は progress.json の independent_verifier に {agent, verdict, graph_digest} として写す。graph_digest は verifier が返した値をそのまま写し、main context が計算した値で置き換えない。verifier は、渡された graph の canonical digest を、writer receipt の graph_digest_after と同じ計算 (sha256: に、json.dumps(graph, ensure_ascii=False, sort_keys=True, separators=(',', ':')) の UTF-8 の sha256 を続ける) で返す。verifier の後に graph が進んだら、verifier をもう一度起こす。schema・DAG・orphan・path containment・feature/package 境界の verdict が PASS でない周回は完了扱いにしない。
• progress.json の feedback_criteria には、frontmatter の4つ (IN1・OUT1-OUT3) を1回ずつ書く。IN1 には各周回の検証結果を status に書く。OUT1-OUT3 は status: external_pending と判定する場所 (live trial・受入テスト) を書き、writer は PASS などの判定値を書かない。
• progress.json の graph_baseline に、post-choice の開始時の graph の {graph_revision, graph_digest} (digest は上と同じ canonical digest) を書く。writer が commit するたびに、その receipt の path を $DEV_GRAPH_ROOT からの相対で writer_receipts の末尾に足す (build-graph-node は <graph の dir>/receipts/ に書き、register-package は --receipt に渡した path に書く)。noop・register-package の再実行・--dry-run・pre-choice の commit は足さない (pre-choice の commit は baseline より前に済んでいて、baseline の graph に含まれる)。receipt は鎖になる。最初の receipt の graph_revision_before は baseline の graph_revision と、次の receipt の graph_revision_before は前の receipt の graph_revision_after と一致する。今の graph は、最後の receipt の graph_revision_after・graph_digest_after と一致し、receipt が無ければ graph_baseline と一致する。baseline は post-choice の開始時の graph をそのまま起点にするもので、それより前の graph の変化は、この照合では見ない。baseline は、post-choice の開始時 (C24 の receipt を得た直後、post-choice の最初の writer を起こす前) に1回だけ書き、後から書き直さない。鎖の照合は revision だけを見る (receipt は書く前の digest を持たない) ので、revision を進めずに graph を書き換えると、baseline と最初の receipt の間、receipt と receipt の間では止まらない。最後の receipt の後の書き換えは、今の graph の digest の照合で止まる。run の外で graph が進んだとき (C27 の execution-context は receipt を書かずに revision を進める) は、baseline を取り直さず、blocked にして親へ handoff する。
• 各周回末に $DEV_GRAPH_ROOT/eval-log/run-dev-graph-node-intermediate.jsonl へ original_goal、original_goal_hash、current_goal_snapshot、delta_from_original、merged_directive_for_next、drift_signal を append-only で記録する。次周回は直前の merged_directive_for_next を必須入力にする。
• progress.json の overall は、周回の途中は in_progress にする。5周到達時に未達が残れば完了扱いせず、blocked にして progress と blocker を親へ handoff する。PASS にしてよいのは、全 checklist が achieved か上の規則の not_applicable (containment・schema は必ず achieved)、IN1 が PASS、独立 verifier の verdict が PASS のときだけである。skill の完了は、そのうえで外ループの outer criterion (OUT1-OUT3) が PASS になったときとする。

ゴールシーク検証

各周回後に次の検査を実行し、中間成果物の欠落・goal drift・hash 不一致・独立 verifier の欠落・verifier が今の graph を監査していないこと・writer receipt の鎖の切れ目 (最初の receipt が baseline から始まらない、receipt の間で revision が飛ぶ)・最後の writer receipt (receipt が無ければ post-choice の開始時) の後の graph の変化・outer criterion の自己採点・checklist の規則に合わない not_applicable・条件を満たさない完了の宣言を fail-closed にする。not_applicable で機械が止めるのは、containment・schema の not_applicable、evidence の無い not_applicable、writer receipt と食い違う not_applicable (receipt を書いた run の receipt、register-package の receipt がある run の package、分類した add の receipt (decision が c14_macro_contract でない artifact を持つ) がある run の classification) である。writer_receipts に残らない起動 (--dry-run・noop・register-package の再実行・pre-choice の commit) の not_applicable が規則に合うかは、evidence を読んで判断する。

python3 - "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-node-goal-spec.json" "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-node-intermediate.jsonl" "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-node-progress.json" "$DEV_GRAPH_GRAPH" "$DEV_GRAPH_ROOT" <<'PY'
import hashlib, json, os, sys
goal = json.load(open(sys.argv[1], encoding='utf-8'))
rows = [json.loads(line) for line in open(sys.argv[2], encoding='utf-8') if line.strip()]
progress = json.load(open(sys.argv[3], encoding='utf-8'))
graph = json.load(open(sys.argv[4], encoding='utf-8'))
required_keys = {'original_goal','original_goal_hash','current_goal_snapshot','delta_from_original','merged_directive_for_next','drift_signal'}
expected = hashlib.sha256(goal['original_goal'].encode('utf-8')).hexdigest()
assert rows, 'intermediate.jsonl is empty'
for row in rows:
    assert required_keys <= row.keys(), required_keys - row.keys()
    assert row['original_goal'] == goal['original_goal']
    assert row['original_goal_hash'] == expected
digest = 'sha256:' + hashlib.sha256(json.dumps(graph, ensure_ascii=False, sort_keys=True, separators=(',', ':')).encode('utf-8')).hexdigest()
receipts = [json.load(open(os.path.join(sys.argv[5], p), encoding='utf-8')) for p in progress.get('writer_receipts') or []]
baseline = progress.get('graph_baseline') or {}
revisions = [baseline.get('graph_revision')] + [r.get('graph_revision_after') for r in receipts]
assert all(r.get('graph_revision_before') == before for r, before in zip(receipts, revisions)), f'writer receipts do not chain from the baseline: {[(r.get("graph_revision_before"), r.get("graph_revision_after")) for r in receipts]}'
last = (receipts[-1].get('graph_revision_after'), receipts[-1].get('graph_digest_after')) if receipts else (baseline.get('graph_revision'), baseline.get('graph_digest'))
assert last == (graph.get('graph_revision'), digest), f'graph changed after the last writer receipt or the graph baseline: {last}'
verifier = progress.get('independent_verifier') or {}
assert verifier.get('agent') in {'dev-graph-integrity-auditor', 'dev-graph:dev-graph-integrity-auditor'}, 'independent verifier not run'
assert verifier.get('verdict') in {'PASS', 'FAIL'}, verifier
assert verifier.get('graph_digest') == digest, f'verifier audited {verifier.get("graph_digest")}, not the current graph {digest}'
def entries(value):
    pairs = list(value.items() if isinstance(value, dict) else ((c.get('id'), c) for c in value))
    out = {cid: (c if isinstance(c, dict) else {'status': c}) for cid, c in pairs}
    assert len(out) == len(pairs), f'duplicate ids: {sorted(map(str, out))}'
    return out
status = {cid: c.get('status') for cid, c in entries(progress.get('feedback_criteria') or {}).items()}
assert set(status) == {'IN1', 'OUT1', 'OUT2', 'OUT3'}, sorted(map(str, status))
outer = {cid: s for cid, s in status.items() if cid != 'IN1'}
assert set(outer.values()) == {'external_pending'}, f'outer criteria are judged outside this run: {outer}'
checklist = entries(progress.get('checklist') or {})
assert set(checklist) == {'containment', 'classification', 'schema', 'package', 'receipt'}, sorted(map(str, checklist))
assert all(c.get('status') in {'achieved', 'not_achieved', 'not_applicable'} for c in checklist.values()), checklist
assert checklist['containment'].get('status') != 'not_applicable' and checklist['schema'].get('status') != 'not_applicable', 'containment and schema are never not_applicable'
assert all(str(c.get('evidence') or '').strip() for c in checklist.values() if c.get('status') == 'not_applicable'), 'not_applicable needs evidence'
na = {cid for cid, c in checklist.items() if c.get('status') == 'not_applicable'}
classified = any(r.get('operation') == 'add' and any((a.get('classification') or {}).get('decision') != 'c14_macro_contract' for a in r.get('artifacts') or []) for r in receipts)
required = {'receipt'} if receipts else set()
required |= {'package'} if any('feature_package_id' in r for r in receipts) else set()
required |= {'classification'} if classified else set()
assert not (na & required), f'not_applicable contradicts the writer receipts: {sorted(na & required)}'
assert progress.get('overall') in {'in_progress', 'blocked', 'PASS'}, progress.get('overall')
if progress['overall'] == 'PASS':
    assert verifier['verdict'] == 'PASS' and status['IN1'] == 'PASS' and all(c['status'] != 'not_achieved' for c in checklist.values()), (verifier['verdict'], status['IN1'], checklist)
PY

Criteria acceptance

• criteria:IN1: validate-graph-schema.py の書込み前検証で必須キー欠落が0件である。
• criteria:OUT1: 通常5 artifactをroutingし、featureはC14 macro contractからのみ登録し、連続更新後もfrontmatter/path整合を保つ。
• criteria:OUT2: architecture subtypeとspecificationのapi-contract条件を含むkind別必須セクションを欠落0件で適用する。
• criteria:OUT3: 12/14 task、phase欠落/重複、mixed package、cross-feature edgeはapplied_count=0、正常時はexpected_count=applied_count=13、P01..P13/node exact-set、graph_revision付きreceiptになる。

Gotchas

• graph/content を直接書かず、preview と apply のどちらも C02 単一 writer を通す。
• progress.json の graph_baseline を後から書き直さない。検証は baseline を起点に receipt の鎖をたどるので、書き直すと run の中の graph の変化が素通りする。
• feature は C14 の macro contract から受け取り、通常 artifact routing で新規生成しない。
• P01..P13 の欠落、重複、混在、cross-feature edge のいずれかがあれば部分登録しない。
• execution context の repository/worktree identity 不一致を上書きで吸収しない。
• rollback_incomplete (exit 2、write_count=null) は一部 path が書かれたまま残った状態である。findings[] の各 path を detail (restore sha256 … または remove created file) どおり手で戻し、validate-graph-schema.py が通ってから再実行する。
• content commit 後・graph commit 前の crash で本文だけが残ると、再実行は artifact_path_exists で止まる。graph に node が無い孤児本文であることを確かめて退避してから再実行する。graph を過去 revision へ戻したときの immutable_receipt_exists は、既存 receipt を消さず graph を最新 revision へ進めてから書く。