onto-mcp 0.3.0 → 0.3.2

package/.onto/processes/review/lens-registry.md

@@ -71,6 +71,22 @@ controlled deliberation은 관점 간 충돌을 제한 맥락에서 정리하며
 - 다른 lens 전체를 요약하지 않는다
 - `New Perspectives` canonical slot을 소유한다 (axiology-exclusive)
 
+`New Perspectives`는 현재 review에서 관찰된 목적상 미커버 관점을 보존하는 슬롯이다.
+이 슬롯은 현재 실행의 active lens set을 변경하지 않는다.
+domain 문서, domain concern tag, CQ, case evidence는 lens 추가를 요구하거나 결정하는
+authority가 아니다. domain은 concern을 lens-usable 원칙, 사례, CQ, 관련 문서 경로로
+표현할 수 있지만, lens 추가/삭제/분할/통합 판단은 review process 차원의 lens governance
+문제다.
+
+`New Perspectives` 제안이 나오면 가능한 처리 경로는 아래 중 하나다.
+
+1. 기존 lens/CQ/domain rule 경로로 흡수한다.
+2. domain 문서의 concern tag 또는 CQ를 보강한다.
+3. 별도 lens-governance follow-up으로 보존한다.
+
+3번은 후속 검토 입력일 뿐이며, 본 review 실행이나 특정 domain 문서가 새 active lens를
+추가했다는 뜻이 아니다.
+
 ### 4.2 `synthesize`
 
 - lens set 전체와 `deliberation.md`를 읽어 final review output을 만든다

package/.onto/processes/review/pre-dispatch-contracts.md

@@ -252,16 +252,32 @@ lifecycle_state: dispatched
 Runtime-generated packet registration preserves `lifecycle_state: dispatched`
 and appends/upserts the generated packet ref before invoking the unit.
 
-### 5.3 Freshness And Resume
+### 5.3 Freshness And Continuation
 
-Current canonical MCP review does not expose an explicit resume tool.
+Current MCP review/status/result can read halted session artifacts. The planned
+explicit continuation surface is `onto.review_continue`; its design lives in
+`docs/architecture/review-continuation-surface.md`.
 
-`review-run-manifest.yaml` records a `resume_token` for audit, idempotency, and
-future operator-controlled resume design only. The token is not a dispatch
-capability and must not be accepted as authorization to restart, skip, or reuse
-worker stages.
+The public concept is review continuation, not subagent management. A
+continuation may re-dispatch failed or missing review execution units while
+reusing completed units from the same session.
 
-A future resumed or reused session must validate:
+Continuation planning should use the shared `PipelineExecutionLedger`
+projection defined in
+`.onto/processes/shared/pipeline-execution-ledger-contract.md`. For
+`review`, the projection derives from the execution plan, run manifest,
+execution result, lens barrier, semantic ledgers, and output seats. The ledger's
+primary purpose is to verify artifact trust boundaries: which outputs were
+produced by completed units, which outputs are untrusted because the producing
+unit failed or upstream work is incomplete, and where execution should continue.
+`finding-ledger.yaml` and `issue-ledger.yaml` remain semantic ledgers; they are
+continuation inputs after they exist, not the full pipeline execution ledger.
+
+`review-run-manifest.yaml` records a `resume_token` for audit and idempotency
+only. The token is not a dispatch capability and must not be accepted as
+authorization to restart, skip, continue, or reuse worker stages.
+
+Any continued or reused session must validate:
 
 - manifest schema version
 - source hash for every required `context_source`
@@ -270,14 +286,19 @@ A future resumed or reused session must validate:
 - consumed context eligibility
 - generated packet refs before invoking issue-artifact, deliberation, or
   synthesize runtime units
+- route consistency against the existing execution plan and actor invocation
+  profiles
+
+Any mismatch stops before continuation dispatch and writes a
+`manifest_lifecycle`, `context_eligibility`, or route-specific failure record.
 
-Any mismatch stops before lens execution and writes a `manifest_lifecycle` or
-`context_eligibility` failure record.
+Continuation must not change inputs, settings, target scope, provider route,
+domain, review mode, selected lens set, or manifest-governed artifacts. If any
+of those must change, the caller must start a new review session.
 
-Until an explicit resume contract is implemented, MCP callers must start a new
-review session after changing inputs, settings, target scope, provider route, or
-manifest-governed artifacts. Runtime status/result tools may read existing
-session artifacts, but they do not resume execution.
+Until `onto.review_continue` is implemented, MCP callers must still start a new
+review session when they need execution to proceed. Runtime status/result tools
+may read existing session artifacts, but they do not resume execution.
 
 ### 5.4 Synthesize Context
 

package/.onto/processes/review/productized-live-path.md

@@ -89,6 +89,8 @@ prompt-backed path에서도 이 단계의 결과는 최종적으로
 - configured domain이 하나면 바로 사용
 - configured domain이 여러 개면 interactive selection을 수행
 - interactive selection이 불가능한 non-interactive 환경이면 fail-fast 하고 explicit domain selection을 요구
+- explicit token과 configured domain이 모두 없으면 review target path/content/intent를 기반으로 available domain 문서 중 하나를 자동 선택하고, 선택 domain과 이유를 start preview, `binding_notes`, opening brief input, final output에 기록한다
+- target 기반 자동 선택에 충분한 signal이 없거나 available domain seat가 없으면 `session_domain=none`으로 진행하며 그 이유를 같은 표면에 기록한다
 - `--domain` 과 `--no-domain` 동시 지정은 parser layer 에서 fail-fast
 
 ### 3.4 호출 고정 (InvocationBinding)
@@ -395,4 +397,4 @@ Target rules:
 남은 follow-up은 live path 자체의 구조 변경이 아니라 운영/확장 품질이다.
 
 1. provider credentials/endpoints가 의도적으로 준비된 환경에서 provider별 live conformance를 수행한다.
-2. replay, stale artifact, partial worker, duplicate-dispatch semantics가 닫힌 뒤 explicit resume command를 설계한다.
+2. `.onto/processes/shared/pipeline-execution-ledger-contract.md`의 shared ledger를 `review`에 먼저 투영하고, `docs/architecture/review-continuation-surface.md`의 설계에 따라 `onto.review_status` continuation plan과 `onto.review_continue`를 구현한다.

package/.onto/processes/shared/pipeline-execution-ledger-contract.md

@@ -0,0 +1,185 @@
+# Pipeline Execution Ledger Contract
+
+> Status: shared design contract.
+> Purpose: define the artifact trust and provenance ledger that every onto
+> pipeline must expose or derive across `review`, `reconstruct`, and future
+> `evolve`.
+
+## 1. Position
+
+`PipelineExecutionLedger` is a shared runtime concept. It records how a
+pipeline produced its artifacts at the unit level so a caller can determine:
+
+- which artifacts are trustworthy;
+- which artifacts are untrusted because their producing unit failed;
+- which artifacts are blocked because upstream units did not complete;
+- which unit is the first incomplete or failed boundary;
+- where a later continuation or repair action may safely begin.
+
+Continuation is one consumer of the ledger. The primary purpose is execution
+audit, trust boundary inspection, and artifact provenance.
+
+This contract applies to:
+
+- `review`;
+- `reconstruct`;
+- future `evolve`;
+- any later onto pipeline that materializes staged artifacts.
+
+## 2. Ownership
+
+Runtime owns the ledger projection because it observes unit dispatch, validation,
+file writes, hashes, and terminal status.
+
+Host LLMs may read the ledger to explain trust boundaries or propose the next
+action, but they do not author ledger truth.
+
+Semantic ledgers remain separate:
+
+- `review` semantic ledgers include `finding-ledger.yaml` and
+  `issue-ledger.yaml`.
+- `reconstruct` semantic or decision artifacts include Seed, confirmation,
+  question, failure, revision, and stop-decision artifacts.
+- future `evolve` may define design-specification or decision ledgers.
+
+Semantic ledgers explain meaning. The pipeline execution ledger explains whether
+the process that produced each artifact can be trusted.
+
+## 3. Minimum Model
+
+Shared ledger shape:
+
+```ts
+interface PipelineExecutionLedger {
+  schemaVersion: "1";
+  pipeline: "review" | "reconstruct" | "evolve" | string;
+  sessionId: string;
+  sourceRefs: string[];
+  units: PipelineExecutionLedgerUnitEntry[];
+}
+
+interface PipelineExecutionLedgerUnitEntry {
+  unitId: string;
+  unitKind: string;
+  owner: "runtime" | "host_llm" | "user_or_host_mediated";
+  producedArtifactRefs: string[];
+  consumedArtifactRefs: string[];
+  packetRef?: string | null;
+  packetSha256?: string | null;
+  outputRefs: string[];
+  outputHashes: Record<string, string | null>;
+  status:
+    | "planned"
+    | "completed"
+    | "failed"
+    | "missing"
+    | "skipped"
+    | "not_reached";
+  trustStatus: "trusted" | "untrusted" | "blocked_by_upstream";
+  trustReason: string;
+  attemptCount: number;
+  lastFailureMessage: string | null;
+  upstreamUnitIds: string[];
+  downstreamUnitIds: string[];
+}
+```
+
+Rules:
+
+- `trusted` requires the producing unit to complete and all required output
+  artifacts to exist and validate.
+- `untrusted` means the unit ran but failed, produced invalid output, or wrote
+  artifacts that failed validation.
+- `blocked_by_upstream` means this unit's trust cannot be established because an
+  upstream required unit is missing, failed, or untrusted.
+- `skipped` must include a reason and must not be confused with trusted output.
+- A missing optional unit may be `skipped`; a missing required unit is
+  `missing` or `blocked_by_upstream`.
+- The ledger is derived from existing run artifacts unless a pipeline contract
+  explicitly promotes it to a durable artifact.
+
+## 4. Source Inputs
+
+Each pipeline maps its own runtime artifacts into the shared ledger.
+
+| Pipeline | Required derivation sources |
+|---|---|
+| `review` | `execution-plan.yaml`, `review-run-manifest.yaml`, `execution-preparation/review-context-manifest.yaml`, `execution-result.yaml`, `lens-completion-barrier.yaml`, semantic ledgers when present, and output seats |
+| `reconstruct` | `reconstruct-run-manifest.yaml`, `reconstruct-record.yaml`, stage registry, validation artifacts, metrics, stop decision, final output, and output seats |
+| `evolve` | future evolve run manifest, target profile, adapter selection, observation/projection artifacts, design specification validation, final disposition, and output seats |
+
+The pipeline-specific source artifacts remain authority. The ledger is a
+normalized projection over them.
+
+## 5. Pipeline Mapping
+
+### Review
+
+`review` units include:
+
+- lens units;
+- issue artifact units;
+- per-lens deliberation units;
+- controlled deliberation;
+- synthesize;
+- record/final-output assembly where runtime treats them as separate stages.
+
+`finding-ledger.yaml` and `issue-ledger.yaml` remain semantic ledgers. They are
+inputs for downstream trust once they exist, not replacements for the execution
+ledger.
+
+### Reconstruct
+
+`reconstruct` units follow stable `ReconstructStageId` values:
+
+- material profiling;
+- source inventory;
+- source observation;
+- LLM-authored directive production;
+- runtime directive validation;
+- Seed candidate, confirmation, competency-question, assessment,
+  failure-classification, revision, metrics, stop-decision, final-output, and
+  record assembly stages as the contract enables them.
+
+Runtime validation units are the trust gates for LLM-authored artifacts. A
+semantic artifact can exist but remain untrusted until its validation unit
+completes.
+
+### Evolve
+
+Future `evolve` units must begin with:
+
+- target profiling;
+- adapter selection;
+- material-specific observation or projection;
+- design inquiry/specification stages;
+- validation and final disposition stages.
+
+No future evolve adapter may bypass the ledger by writing design artifacts
+without a producing unit and trust status.
+
+## 6. Status And Result Surfaces
+
+Status tools should expose the ledger, or a bounded projection of it, whenever a
+pipeline is prepared, running, halted, or completed.
+
+Result tools should expose enough ledger refs or summary fields for callers to
+audit why final artifacts are trusted.
+
+Continuation tools, where implemented, must derive their frontier from the
+ledger's trust and completion boundary rather than from ad hoc file existence.
+
+## 7. Durable Artifact Policy
+
+First implementation may keep the ledger as a derived status projection.
+
+Promote a durable root artifact such as `pipeline-execution-ledger.yaml`
+only when at least one of these is true:
+
+- external audit needs a stable standalone ledger file;
+- continuation attempts need replayable pre/post trust snapshots;
+- result artifacts need to cite a ledger ref as part of their trust contract.
+
+If promoted, the durable artifact must still be derived from the pipeline's run
+manifest, record, validation artifacts, and output seats. It must not become a
+second execution truth.

package/.onto/processes/shared/target-material-kind-contract.md

@@ -4,6 +4,12 @@
 > Purpose: define the cross-process goal for material-aware target handling
 > across `review`, `reconstruct`, and future `evolve`.
 
+Related shared contract:
+
+```text
+.onto/processes/shared/pipeline-execution-ledger-contract.md
+```
+
 ## 1. Goal Statement
 
 Establish a material-aware runtime contract so `review`, `reconstruct`, and
@@ -50,7 +56,7 @@ Allowed values:
 | `spreadsheet` | Workbook, sheet, CSV, accounting schedule, formula model, report, or tabular calculation artifact. |
 | `document` | Prose, requirements, policy, guide, report, contract, PDF, DOCX, Markdown, or similar textual artifact. |
 | `database` | Database connection, schema, migration, SQL file, warehouse model, table, view, or query artifact. |
-| `mixed` | Bundle containing more than one material kind. Each member needs its own material classification. |
+| `mixed` | Bundle containing more than one material kind. Each member needs its own material classification; `mixed` itself is not an adapter target. |
 | `unknown` | Runtime cannot classify the material safely. Adapter execution must halt or ask for clarification. |
 
 The axis is separate from:
@@ -71,6 +77,21 @@ The axis is separate from:
 | `reconstruct` | Source profiles, source adapters, source observations, and directive validation must be keyed by `target_material_kind`. |
 | `evolve` | Future adapters must not assume code-product inputs; adapter selection should start from `target_material_kind` as defined in `.onto/processes/evolve/material-kind-adapter-contract.md`. |
 
+### 4.1 Mixed Support Semantics
+
+Because `mixed` is an allowed public value, every process that exposes it must
+also expose one of these support states:
+
+| Support state | Runtime behavior |
+|---|---|
+| `supported_composite` | Classify every member, dispatch only member-specific supported adapters, and preserve cross-material refs as structural refs. |
+| `partial_composite` | Classify every member, observe supported members, record unsupported members and downstream authority impact. |
+| `unsupported` | Halt or ask for clarification before adapter dispatch with a stable unsupported reason. |
+| `reserved_future` | Treat `mixed` as non-executable vocabulary and do not expose it as a runnable path. |
+
+No process may dispatch a single generic `mixed` adapter. Semantic
+cross-material interpretation belongs to the LLM after runtime observation.
+
 ## 5. Artifact Contract Additions
 
 | Artifact | Required change |
@@ -114,7 +135,8 @@ Runtime must validate:
 
 - `target_material_kind` is one of the allowed values
 - `unknown` does not dispatch a material adapter
-- `mixed` records per-member material kinds
+- `mixed` records per-member material kinds and one of the support states in
+  section 4.1 before adapter dispatch
 - unsupported formats halt or degrade explicitly
 - source observations do not claim ontology facts such as entity, relation,
   business rule, aggregate root, or policy meaning

package/.onto/roles/axiology.md

@@ -61,12 +61,17 @@
 
 현재 lens set 에 빠진 purpose-critical 관점을 이 lens 가 발견하면 여기서 직접 제안한다. `synthesize` 는 이 제안을 보존할 수 있으나 독자적으로 발명할 수 없다. 이 slot 은 axiology 만 사용할 수 있는 의도적 canonical asymmetry 이다.
 
+이 slot 은 domain concern 을 active lens 로 승격하는 장치가 아니다. domain 문서의 concern
+tag, CQ, case evidence 는 원칙적으로 기존 lens/CQ/domain-rule 경로로 소비된다.
+New Perspectives 는 "현재 domain 이 새 lens 를 원한다"는 뜻이 아니라, review process
+governance 에서 별도로 검토할 수 있는 목적상 미커버 관찰을 보존하는 출력이다.
+
 New Perspectives 제안 시 최소 필수 필드:
 
 1. **trigger condition** — 제안을 촉발한 증거 (대상 · 관찰 · authority 미커버 영역)
 2. **proposed perspective** — 무엇을 평가할 것인가 (1~2 문장 perspective 요약)
-3. **insufficiency argument** — 기존 9 lens 각각이 이 관점을 왜 커버하지 못하는지 명시
-4. **intended receiving seat** — 제안이 착지해야 할 위치 (현재 review 의 `synthesize` 보존 / 후속 lens governance / axiology 내부 sub-check 등). 착지 seat 미지정 제안은 orphaned 로 간주하여 `synthesize` 가 거부할 수 있다
+3. **insufficiency argument** — 기존 9 lens, CQ, domain rule 경로가 이 관찰을 왜 충분히 커버하지 못하는지 명시
+4. **intended receiving seat** — 제안이 착지해야 할 위치 (현재 review 의 `synthesize` 보존 / 기존 lens·CQ·domain rule 보강 / 후속 lens governance / axiology 내부 sub-check 등). 착지 seat 미지정 제안은 orphaned 로 간주하여 `synthesize` 가 거부할 수 있다
 
 New Perspectives 제안은 현재 리뷰 실행의 active lens set 을 변경하지 않는다. 실제 lens set 확장은 별도 governance 경로를 통한다.
 

package/AGENTS.md

@@ -60,8 +60,10 @@ target material 관련 작업 시 추가로 읽을 문서:
 `reconstruct` 작업 시 추가로 읽을 문서:
 
 1. [reconstruct-boundary-contract.md](/Users/kangmin/cowork/onto-mcp/.onto/processes/reconstruct/reconstruct-boundary-contract.md)
-2. [source-profile-contract.md](/Users/kangmin/cowork/onto-mcp/.onto/processes/reconstruct/source-profile-contract.md)
-3. selected source profile under `.onto/processes/reconstruct/source-profiles/`
+2. [reconstruct-execution-ux-contract.md](/Users/kangmin/cowork/onto-mcp/.onto/processes/reconstruct/reconstruct-execution-ux-contract.md)
+3. [top-level-concept-discovery-contract.md](/Users/kangmin/cowork/onto-mcp/.onto/processes/reconstruct/top-level-concept-discovery-contract.md)
+4. [source-profile-contract.md](/Users/kangmin/cowork/onto-mcp/.onto/processes/reconstruct/source-profile-contract.md)
+5. selected source profile under `.onto/processes/reconstruct/source-profiles/`
 
 ---
 

package/README.md

@@ -36,15 +36,17 @@ cross-process goal contract lives at
 
 `reconstruct` now has a current design contract under
 `.onto/processes/reconstruct/`, material-aware runtime helpers, and a bounded
-happy-path runner. The runner classifies target material, writes source
-observations, accepts pluggable LLM-owned directive authors and confirmation
-providers, validates evidence refs, computes deterministic metrics, and writes
+direct-call integral runner. The runner classifies target material, expands
+directory targets into per-member source observations, writes the initial source
+frontier, runs reconstruct lens judgments and exploration synthesis through a
+configured LLM provider, validates evidence refs, computes deterministic metrics, and writes
 `final-output.md`, `reconstruct-run-manifest.yaml`, and the primary
 `reconstruct-record.yaml`. Code is the first fixture; the runner path is shared
 with spreadsheet/document/database material through source profiles and
-material-specific observers. The current public run path is an explicit mock
-semantic/confirmation happy path; domain context selection, failure
-classification, and revision proposal are recorded as deferred scope.
+material-specific observers. The current public run path defaults to
+`direct_call` semantic authoring and host-mediated confirmation. It fails loud
+when provider/model/credentials, LLM-authored artifact shape, or runtime gates
+are invalid; domain context selection remains deferred.
 `evolve` has a future material-kind adapter contract at
 `.onto/processes/evolve/material-kind-adapter-contract.md`, but no active
 runtime or MCP tool. `learn` and `govern` remain separate design slices.
@@ -77,6 +79,7 @@ Available MCP tools:
 |---|---|
 | `onto.review` | Run the full review path and return artifact refs plus summary |
 | `onto.prepare_review` | Prepare a review session and prompt packets |
+| `onto.review_continue` | Continue a prepared or halted review from the ledger frontier |
 | `onto.review_status` | Read structured status and artifact refs |
 | `onto.review_result` | Read `review-record.yaml` and final output |
 | `onto.list_lenses` | List canonical lens sets |
@@ -84,9 +87,9 @@ Available MCP tools:
 | `onto.list_source_profiles` | List reconstruct source profiles |
 | `onto.observe_source` | Materialize reconstruct material profile, inventory, source observations, and initial record |
 | `onto.validate_reconstruct_directive` | Validate LLM-authored reconstruct directive files |
-| `onto.reconstruct` | Run the material-aware reconstruct happy path with explicit mock semantic/confirmation realization |
-| `onto.reconstruct_status` | Read reconstruct session status and artifact refs |
-| `onto.reconstruct_result` | Read `reconstruct-record.yaml`, run manifest, and final output |
+| `onto.reconstruct` | Run the material-aware direct-call reconstruct path with runtime validation gates |
+| `onto.reconstruct_status` | Read reconstruct session status, progress, counts, and artifact refs |
+| `onto.reconstruct_result` | Read `reconstruct-record.yaml`, run manifest, progress projection, and final output |
 
 MCP results include `llmPresentation` prompts. The runtime supplies bounded
 facts; the host LLM should use those prompts to explain the opening brief and
@@ -101,18 +104,15 @@ Minimal reconstruct MCP call shape:
     "projectRoot": "/path/to/project",
     "targetRefs": ["src/example.ts"],
     "intent": "Create a bounded reconstruct Seed from this target.",
-    "sessionRoot": ".onto/reconstruct/example-run",
-    "semanticAuthorRealization": "mock",
-    "confirmationProviderRealization": "mock"
+    "sessionRoot": ".onto/reconstruct/example-run"
   }
 }
 ```
 
-`semanticAuthorRealization` and `confirmationProviderRealization` are required
-so completed reconstruct runs are explicit about their current mock semantics.
-Today this proves the material-aware happy path, artifact gates, and MCP
-surface. It does not claim live host-LLM semantic authorship or live
-user-mediated confirmation.
+`semanticAuthorRealization` and `confirmationProviderRealization` default to
+`direct_call`. Configure `.onto/settings.json` or user `~/.onto/settings.json`
+with an `llm` provider/model before running. Test-only mock helpers are not
+product completion evidence.
 
 Repository-local development harness:
 
@@ -235,30 +235,53 @@ Primary outputs:
 
 A reconstruct session writes artifacts under `.onto/reconstruct/<session-id>/`.
 
-Implemented happy-path outputs:
+Implemented direct-call, runtime-gated outputs:
 
 | Artifact | Owner | Purpose |
 |---|---|---|
 | `target-material-profile.yaml` | runtime | detected `target_material_kind`, support status, and selected source profiles |
 | `source-inventory.yaml` | runtime | material-specific inventory units and scan boundary |
+| `initial-source-frontier.yaml` | runtime | first observation frontier derived from inventory |
 | `source-observations.yaml` | runtime | structural observations with stable evidence ids |
-| `source-observation-directive.yaml` | mock/host author | selected observations for evidence use |
+| `source-observation-directive.yaml` | host LLM author | selected observations for evidence use |
 | `source-observation-directive-validation.yaml` | runtime | validation of selected observation refs |
-| `seed-candidate.yaml` | mock/host author | evidence-backed Seed candidate |
-| `seed-candidate-validation.yaml` | runtime | Seed claim and evidence-ref validation |
-| `seed-confirmation.yaml` | mock/host/user mediated | accepted, rejected, or partial Seed confirmation |
-| `competency-questions.yaml` | mock/host author | questions linked to confirmed claims |
-| `reconstruct-metrics.yaml` | runtime | deterministic counts, unresolved count, and pass rate |
-| `stop-decision.yaml` | mock/host author | stop, continue, or ask-user decision based on metrics |
-| `final-output.md` | mock/host author | user-facing result grounded in artifacts |
+| `rounds/<round-id>/lens-judgments/*.yaml` | host LLM author | reconstruct lens judgments over trusted observations |
+| `rounds/<round-id>/exploration-synthesis.yaml` | host LLM author | integrated gaps and next-source needs |
+| `rounds/<round-id>/source-frontier.yaml` | host LLM author | requested next source refs or no-next-frontier rationale |
+| `rounds/<round-id>/source-frontier-validation.yaml` | runtime | boundary, duplicate, and inventory validation for the frontier |
+| `seed-candidate.yaml` | host LLM author | evidence-backed Seed candidate with separate `claim_id` and user-facing `name` |
+| `seed-candidate-validation.yaml` | runtime | Seed claim name, shape, and evidence-ref validation |
+| `claim-realization-map.yaml` | host LLM author | claim-level evidence stance |
+| `claim-realization-map-validation.yaml` | runtime | claim id, stance enum, and evidence linkage validation |
+| `seed-confirmation.yaml` | host/user mediated | accepted, rejected, partial, or deferred Seed confirmation |
+| `seed-confirmation-validation.yaml` | runtime | confirmation transition validation and derived claim sets |
+| `competency-questions.yaml` | host LLM author | questions linked to confirmed claims |
+| `competency-questions-validation.yaml` | runtime | CQ id, eligible-claim coverage, claim-link, and evidence validation |
+| `competency-question-assessment.yaml` | host LLM author | answer status for every authoritative CQ |
+| `competency-question-assessment-validation.yaml` | runtime | exactly-once CQ assessment validation |
+| `failure-classification.yaml` | host LLM author | material failure and gap classification |
+| `failure-classification-validation.yaml` | runtime | failure enum, linkage, and materiality validation |
+| `revision-proposal.yaml` | host LLM author | bounded revision/deferral proposals |
+| `revision-proposal-validation.yaml` | runtime | proposal id, target, action, and regression guard validation |
+| `reconstruct-metrics.yaml` | runtime | deterministic counts, unresolved/deferred counts, and pass rate |
+| `stop-decision.yaml` | host LLM author | stop, continue, or ask-user decision based on metrics |
+| `final-output.md` | host LLM author | user-facing result grounded in artifacts and provenance-checked by runtime |
 | `reconstruct-run-manifest.yaml` | runtime | step refs, `performed_by` provenance, execution profile, and happy-path scope |
 | `reconstruct-record.yaml` | runtime | primary structured reconstruct artifact |
 
 Current deferred reconstruct artifacts are recorded in
 `reconstruct-run-manifest.yaml` under `happy_path_scope.deferred_artifacts`:
-`domain_context_selection`, `failure_classification`, and `revision_proposal`.
-Those require additional host/user semantic decisions and are outside the
-current mock happy path.
+`domain_context_selection` and `domain_context_selection_validation`. Those
+require additional domain selection semantics and are outside the current
+direct-call path.
+
+The reconstruct design contract also defines validation artifacts for those
+stages, stable reconstruct stage ids, cross-artifact id authority, and progress
+UX expectations in `.onto/processes/reconstruct/reconstruct-execution-ux-contract.md`.
+Seed discovery is further constrained by
+`.onto/processes/reconstruct/top-level-concept-discovery-contract.md`, which
+defines the Seed as a purpose-relative top-level concept discovery artifact
+rather than a full ontology or broad claim ledger.
 
 ## Repository Map