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-requirements

Purpose & Output Contract

• 入力: C24/C11 検証済み subgraph、C02 保存済み readiness/evaluation/source digest、system-dev-planner package。
• 出力: requirements document、readiness matrix、snapshot digest に固定した capability-build/task-graph handoff。
• 完了条件: C11/C02/validate-system-plan の三 gate が同一 digest で PASS し、missing section が0、本 skill による実装 code 生成が0である。

実装コードの生成は禁止。graph の5 artifact kind、C19 が取り込んだ system-spec lineage、external system-dev-planner の feature execution package を引用して requirements handoff を作る。

1. 対象 feature/subgraph と handoff target を確定する。
2. 三 gate の照合は validate-readiness-binding.py --repo-root <root> --package-dir <published package> --receipt <C02 receipt> [--system-planner-root PATH] だけが行う。script は C24 (resolve-repo-context.py --mode read) で root を固定し、system-dev-planner の validate-system-plan.py を起動して validated_digest を得る (P01..P13 exact set・13-node DAG・共通 parent_feature/feature_package_id の検証は外部 validator のまま。13 task の生成ロジックは複製しない)。
3. 同じ script が、C02 の registration manifest・promotion receipt・C02 receipt の source_digest と validated_digest の一致、C11 (validate-graph-schema.py の validate) を通した graph の package member の readiness view (status/confirmation_status/evaluation_status/implementation_readiness/source_digest/evaluated_digest) の digest と C02 が保存した同じ view の digest の一致、receipt の graph_revision_after と同じ revision なら graph 全体の digest と graph_digest_after の一致を確かめる。exit 1 なら violations (code と node) をそのまま返して止まる。LLM が digest や readiness を読み比べて代わりに判定しない。
4. handoff 対象の node は guard-requirements-handoff.py --repo-root <root> --node <id> [--node <id>]... --expect-graph-digest <binding の graph.digest> に渡す。script は参照 closure (depends_on/related_nodes/architecture_refs/parent_feature と package member) をたどり、incomplete/unknown/pending/fail/stale/draft/superseded/tombstoned・参照切れ・C11 violation が1件でもあれば exit 1 (status: withheld、handoff_count: 0) で、closure 全件の missing_sections と各 blocked node の remediation.owner を返す。一部の node だけを handoff しない。guard は自分が読んだ graph の graph.digest と graph.graph_revision を binding と同じ定義 (C02 の canonical digest) で返し、--expect-graph-digest と違えば (binding の後に graph が変わった) exit 2 (status: snapshot_mismatch、handoff_count: 0) で止まる。そのときは binding からやり直す。exit 2 には report の無いもの (usage・C24・IO の例外。stdout は空で、stderr に理由が出る) もある。これも handoff 0件で止め、stderr の例外の内容を止まった理由として返す (binding からやり直すのは status: snapshot_mismatch の report があるときだけ)。
5. validate-readiness-binding.py と guard-requirements-handoff.py がともに exit 0 で、binding の graph.digest と guard の graph.digest が一致する (guard の graph.digest_match: true) ときだけ、guard の handoff に並んだ node について requirements document、graph snapshot digest (binding の graph.digest)、package reference、capability-build handoff reference を atomic emit する。

出力は readiness matrix と handoff package。run-system-dev-plan の出力を消費するが dev-graph 自身は task spec を作らない。

ゴールシーク実行

ゴール (Goal)

system-spec-harness確定成果物とsystem development task planを含むグラフ情報から実装要件を導出し、implementation-readiness完了時だけcapability-build/task-graph buildへ実装をhandoffした状態になっている

目的・背景 (Why)

実装コード生成は既存 capability-build/task-graph build へ責務分離するため、本ハーネスはグラフ情報から要件定義を導出するところまでを担う。要件定義が参照する各成果物がテンプレート必須セクションを充足していない (implementation-readiness不足) まま handoff すると後段 build が要件不足のまま着手してしまうため、本 skill が readiness を機械判定し不足セクションを事前に surface する (要件C20)。system development task planはexternal plugin system-dev-plannerのrun-system-dev-planをSkill呼出しで引用する (external_contract_ref: plugin-plans/system-dev-planner/handoff-run-plugin-dev-plan.json)。implementation_readiness/validator (validate-system-plan.py) も同pluginが所有する

完了チェックリスト

• scope 内 node の feature/package/system-spec lineage closure が欠落0である
• validate-readiness-binding.py が exit 0 で violations 0件、readiness_digest.c11 と readiness_digest.c02 が一致する
• guard-requirements-handoff.py の missing_sections と blocked[].remediation が全件表示され、exit 1 のとき handoff が0件である
• 全 gate PASS で、binding の graph.digest と guard の graph.digest が一致する場合だけ、requirements と capability-build handoff が同一 snapshot digest で生成される
• 本 skill が生成した実装 code file が0件である

ゴールシークループ

frontmatter の goal_seek.engine: inline / fork: subagent / max_loops: 5 を実行契約とする。固定手順は使わず、未達 checklist と担当 prompts/*.md からその周回の操作を都度生成する。各周回で inner criterion を検証し、完了後は outer criterion の live trial/content review を最大 feedback_contract.max_iterations=3 周で評価する。

ゴールシーク配線

• 開始時に C24 resolve-repo-context.py --mode read の JSON receipt を得て、repo_root が content_roots.repository の realpath と一致する場合だけ DEV_GRAPH_ROOT=<receipt.repo_root> に固定する。cwd から再解決しない。
• 元のゴールを $DEV_GRAPH_ROOT/eval-log/run-dev-graph-requirements-goal-spec.json へ、各 checklist の status/evidence を $DEV_GRAPH_ROOT/eval-log/run-dev-graph-requirements-progress.json へ記録する。
• 未達 responsibility を担当する prompts/<R-id>.md を読み、Agent で分離 context に fork する。ユーザー判断が必要な境界だけ AskUserQuestion を使う。
• 各周回末に $DEV_GRAPH_ROOT/eval-log/run-dev-graph-requirements-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 を必須入力にする。
• 5周到達時に未達が残れば完了扱いせず、progress と blocker を親へ handoff する。全 checklist と feedback_contract.criteria が PASS のときだけ完了する。

ゴールシーク検証

各周回後に次の検査を実行し、中間成果物の欠落・goal drift・hash 不一致を fail-closed にする。

python3 - "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-requirements-goal-spec.json" "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-requirements-intermediate.jsonl" <<'PY'
import hashlib, json, 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()]
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
PY

Criteria acceptance

• criteria:IN1: validate-readiness-binding.pyが、C11のreadiness validation digestとC02保存済みimplementation_readiness/evaluation_status/source_digestの一致、system-dev-plannerのvalidate-system-plan.pyのvalidated_digest(P01..P13 exact 13・共通parent_feature/feature_package_id・機能内前方dependencyの検証結果)との一致を照合し、exit 0で必須キー欠落が0件、stale digestが0件になる。gh-bridge.py 由来のissue contextは補助入力に留め、この三gateの代替にしない。
• criteria:OUT1: requirementsをcapability-build/task-graphへhandoffし、本skill自身は実装コードを生成しない。
• criteria:OUT2: guard-requirements-handoff.pyが、implementation_readiness=incompleteの参照ノードが1件でもあればclosure全件のmissing_sectionsとremediation ownerを返し、handoff_count: 0で該当handoffを保留する。R3はこのscriptのexit 0のときだけhandoffする。

Gotchas

• node 内の readiness 値だけを信頼せず、C11 report、C02 saved state、source digest の照合は validate-readiness-binding.py に任せる。sync などで graph の revision が登録より進んだ場合は graph 全体の digest ではなく readiness view の digest で照合される (graph.relation: later_revision)。登録より古い graph は拒否される。
• validate-system-plan.py の exact-13 検証を独自ロジックで代替しない。
• incomplete/pending/fail/stale を一部 handoff で回避せず、guard-requirements-handoff.py の missing_sections を全件返す。schedule-graph.py の ready set は依存の準備だけを見るので、handoff の可否には使わない。
• 実装は capability-build/task-graph に引き渡し、本 skill 内で code を生成しない。