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-system-spec

Purpose & Output Contract

• 入力: C24 で caller repo 内に固定した system-spec/、system-spec-harness manifest/entry points、任意の resume state。
• 出力: confirmed specification/architecture node、C02 import report、version/digest/imported_at を含む source lineage。
• 完了条件: system-spec-harness の required 4 entry points、coverage/source-citation/evaluator gate が PASS し、dev-graph 内の同等生成ロジック複製が0である。

本 skill は仕様生成ロジックを持たない。system-spec-harness を起動し、確定成果物の検証と C02 取込だけを担う。

1. C24 で caller repo の system-spec/ を解決し、plugin source/別 repo の content を拒否する。
2. plugins/system-spec-harness/.claude-plugin/plugin.json の name/version が >=0.1.0 <1.0.0、かつ references/package-contract.json#entry_points.skills が run-system-spec-elicit, run-system-spec-doc-fetch, run-system-spec-compile, assign-system-spec-completeness-evaluator を持つことを確認する。公式manifestへharness専用キーを混在させず、不在/不一致は fallback を実装せず停止する。
3. Skill 呼出しで elicit → 必要時 doc-fetch → compile → completeness evaluator を順に委譲する。
4. confirmed 章と evaluator PASS だけを C02 に渡し、source_lineage={origin_kind,plugin,path,version,digest,imported_at}, confirmation evidence, readiness を specification/architecture node に保存する。

出力は import report (system-spec/index.md, imported node ids, lineage, confirmation_status, readiness)。feature は architecture_refs で参照し、内容を複製しない。1 feature→13 task は system-dev-planner の責務であり本 skill は扱わない。

Resume と lineage gate

../../scripts/validate-source-lineage.py --repo-root <DEV_GRAPH_ROOT> [--graph <path>] [--node-id <id> ...] を R0 (resume) と R3 (C02 import の後) の決定論 gate にする。origin_kind=system-spec-harness の node だけを対象に、source_path が repo 内の通常ファイルとして実在し、その生 bytes の sha256 が source_digest と一致するかを副作用なしで検査し、{status, checked, checked_node_ids, violations[]} を返す (exit 0=pass、1=violation、2=usage/入力エラー)。C02 (build-graph-node.py add) も同じ関数で登録前に検査し、解決しない lineage は source_lineage_unverified で拒否される。

• R0 の resume は「取込済み node の lineage が今の system-spec/ に解決するか」の確認である。checked=0 (system-spec 由来の node がまだ無い。system-spec/ 未作成を含む) は再開する対象が無いので、新規作成として手順 3 へ進む。checked>=1 で exit 0 なら、取込済み node を保持したまま続きから再開する。
• exit 1 (取込元の削除・移動・編集で lineage が解決しない) と exit 2 は fail-closed にする。取込元の付け替えや digest の書換えで辻褄を合わせず、診断 JSON (violations[] の node/code/detail) をそのまま提示して停止する。
• この fail-closed は最小成果物を作る前の停止なので、artifact_delivery は初期状態 artifact_created に留まり minimum_guard_pass を発火しない。artifact_presented/user_choice_recorded へ進まず、semantic evaluator・Agent fork も起動しない。利用者が取込元を戻すか再取込を選んだ後に R0 からやり直す。
• R3 の import 後に同じ gate が exit 0 にならなければ、import report を完成扱いにせず、同じく診断を提示して停止する。

ゴールシーク実行

ゴール (Goal)

仕様書・アーキテクチャをplugins/system-spec-harness/の正規フローで構築し、出典・確定状態・上位目的traceを保ったままdev-graphのspecification/architectureノードへ取り込んだ状態になっている

目的・背景 (Why)

system-spec-harnessが既に持つヒアリング、カテゴリ×platform matrix、公式出典、確定章保護、独立完成度評価を複製せず引用し、dev-graphはグラフ登録とlineage維持だけを担うため。本skillが取り込むarchitecture/specificationノードはfeature.architecture_refsから参照されfeatureのアーキテクチャ文脈を成す (複製せずlineage参照のみ・MM-12)

完了チェックリスト

• system_spec content root が caller repo 内で repository_id/common-dir と一致する
• system-spec-harness が version >=0.1.0 <1.0.0 と required 4 entry points を満たす
• elicit/条件付き doc-fetch/compile/evaluator が system-spec-harness Skill 経由だけで実行される
• coverage/source-citation/evaluator gate が全て PASS である
• C02 登録 node の source_lineage/confirmation/evaluator evidence/readiness が欠落0である
• dev-graph 内に同等 elicitation/compile logic の複製が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 write の JSON receipt を得て、repo_root が content_roots.repository の realpath と一致する場合だけ DEV_GRAPH_ROOT=<receipt.repo_root> に固定する。cwd から再解決しない。
• 元のゴールを $DEV_GRAPH_ROOT/eval-log/run-dev-graph-system-spec-goal-spec.json へ、各 checklist の status/evidence を $DEV_GRAPH_ROOT/eval-log/run-dev-graph-system-spec-progress.json へ記録する。
• 未達 responsibility を担当する prompts/<R-id>.md を読み、Agent で分離 context に fork する。ユーザー判断が必要な境界だけ AskUserQuestion を使う。
• 各周回末に $DEV_GRAPH_ROOT/eval-log/run-dev-graph-system-spec-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-system-spec-goal-spec.json" "$DEV_GRAPH_ROOT/eval-log/run-dev-graph-system-spec-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: system-spec-harnessのcoverage/source citation gateとdev-graph schema gateが全てexit0である。
• criteria:OUT1: 確定成果物をsource lineage付きで引用し、同等のelicitation/compileロジックは複製0件、登録はC02経由だけにする。

Gotchas

• system-spec-harness 不在や version/entry-point 不一致時に、簡易 fallback を dev-graph 内へ実装しない。
• plugin source 側や別 repo の system-spec/ を読まず、C24 receipt の caller repo だけを content authority にする。
• evaluator PASS と confirmed の両方が揃わない章を C02 へ登録しない。
• feature に仕様本文を複製せず、architecture_refs と source lineage で参照する。