onto-mcp 0.3.0 → 0.3.1

package/.onto/processes/review/binding-contract.md

@@ -226,6 +226,14 @@ binding_notes:
 recommendation, explicit token, 주체자 확인 결과를
 최종 값으로 materialize한 결과여야 한다.
 
+단, interpretation/config 단계에서 explicit domain이 없고 configured domain도
+없으면 runtime은 review target의 path/content/intent와 available domain 문서의
+bounded signal을 비교해 `domain_final_selection`을 자동 materialize할 수 있다.
+이 경우 `selection_mode`는 target 기반 자동 선택임을 드러내야 하며,
+왜 해당 domain을 골랐는지는 `binding_notes`에 사용자에게 설명 가능한 문장으로
+남긴다. 충분한 signal이 없어서 `none`으로 가는 경우도 같은 방식으로 이유를
+남긴다.
+
 ---
 
 ## 7. Prompt / MCP / Runtime Effect

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

package/AGENTS.md

@@ -60,8 +60,9 @@ 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. [source-profile-contract.md](/Users/kangmin/cowork/onto-mcp/.onto/processes/reconstruct/source-profile-contract.md)
+4. selected source profile under `.onto/processes/reconstruct/source-profiles/`
 
 ---
 

package/README.md

@@ -43,8 +43,10 @@ providers, validates evidence refs, computes deterministic metrics, and writes
 `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.
+semantic/confirmation post-Seed artifact loop. It implements claim realization,
+confirmation validation, competency-question assessment, failure classification,
+revision proposal, metrics/status projection, and artifact-tethered final
+output; 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 reconstruct post-Seed loop with explicit mock semantic/confirmation realization |
+| `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
@@ -110,8 +113,8 @@ Minimal reconstruct MCP call shape:
 
 `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
+Today this proves the material-aware post-Seed artifact loop, runtime gates, and
+MCP surface. It does not claim live host-LLM semantic authorship or live
 user-mediated confirmation.
 
 Repository-local development harness:
@@ -235,7 +238,7 @@ Primary outputs:
 
 A reconstruct session writes artifacts under `.onto/reconstruct/<session-id>/`.
 
-Implemented happy-path outputs:
+Implemented mock-authored, runtime-gated outputs:
 
 | Artifact | Owner | Purpose |
 |---|---|---|
@@ -246,19 +249,33 @@ Implemented happy-path outputs:
 | `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 |
+| `claim-realization-map.yaml` | mock/host author | claim-level evidence stance |
+| `claim-realization-map-validation.yaml` | runtime | claim id, stance enum, and evidence linkage validation |
+| `seed-confirmation.yaml` | mock/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` | mock/host author | questions linked to confirmed claims |
-| `reconstruct-metrics.yaml` | runtime | deterministic counts, unresolved count, and pass rate |
+| `competency-questions-validation.yaml` | runtime | CQ id, claim-link, and evidence validation |
+| `competency-question-assessment.yaml` | mock/host author | answer status for every authoritative CQ |
+| `competency-question-assessment-validation.yaml` | runtime | exactly-once CQ assessment validation |
+| `failure-classification.yaml` | mock/host author | material failure and gap classification |
+| `failure-classification-validation.yaml` | runtime | failure enum, linkage, and materiality validation |
+| `revision-proposal.yaml` | mock/host 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` | mock/host author | stop, continue, or ask-user decision based on metrics |
-| `final-output.md` | mock/host author | user-facing result grounded in artifacts |
+| `final-output.md` | mock/host 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 mock
+path.
+
+The post-Seed 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`.
 
 ## Repository Map
 

package/dist/core-api/reconstruct-api.js

@@ -2,12 +2,14 @@ import crypto from "node:crypto";
 import fs from "node:fs/promises";
 import path from "node:path";
 import { parse as parseYaml } from "yaml";
+import { RECONSTRUCT_STAGE_IDS, } from "../core-runtime/reconstruct/artifact-types.js";
 import { materializeReconstructPreparationArtifacts, } from "../core-runtime/reconstruct/materialize-preparation.js";
 import { assembleReconstructRecord, } from "../core-runtime/reconstruct/record.js";
 import { createAutoAcceptReconstructConfirmationProvider, createMockReconstructDirectiveAuthor, runReconstruct, } from "../core-runtime/reconstruct/run.js";
 import { writeSeedCandidateValidationArtifact, } from "../core-runtime/reconstruct/seed-candidate-validation.js";
 import { writeSourceObservationDirectiveValidationArtifact, } from "../core-runtime/reconstruct/directive-validation.js";
 import { loadReconstructSourceProfiles, } from "../core-runtime/reconstruct/source-profiles.js";
+import { buildReconstructPipelineExecutionLedger, } from "../core-runtime/reconstruct/pipeline-execution-ledger.js";
 async function directoryExists(directoryPath) {
     try {
         const stat = await fs.stat(directoryPath);
@@ -75,6 +77,58 @@ async function readTextIfPresent(filePath) {
         return null;
     }
 }
+function deriveReconstructProgress(args) {
+    const stepById = new Map(args.runManifest?.steps.map((step) => [step.step_id, step]) ?? []);
+    const stages = RECONSTRUCT_STAGE_IDS.map((stageId) => {
+        const step = stepById.get(stageId);
+        return {
+            stageId,
+            state: step?.status === "completed"
+                ? "completed"
+                : step?.status === "skipped"
+                    ? "skipped"
+                    : step?.status === "failed"
+                        ? "halted"
+                        : "pending",
+            owner: step?.owner ?? null,
+            artifactRefs: step?.artifact_refs ?? [],
+        };
+    });
+    const lastReachedStage = [...stages].reverse().find((stage) => stage.state !== "pending") ??
+        stages[0];
+    return {
+        currentStageId: lastReachedStage.stageId,
+        stageCount: RECONSTRUCT_STAGE_IDS.length,
+        liveness: {
+            state: args.record.record_stage === "completed"
+                ? "completed"
+                : "halted_or_partial",
+            recommendedPollIntervalMs: args.record.record_stage === "completed" ? null : 1000,
+        },
+        countSummary: {
+            sourceObservationCount: args.metrics?.source_observation_count ?? null,
+            selectedObservationCount: args.metrics?.selected_observation_count ?? null,
+            semanticClaimCount: args.metrics?.semantic_claim_count ??
+                args.record.validation_summary.semantic_claim_count,
+            confirmedClaimCount: args.metrics?.confirmed_claim_count ??
+                args.record.validation_summary.confirmed_claim_count,
+            partialClaimCount: args.metrics?.partial_claim_count ??
+                args.record.validation_summary.partial_claim_count,
+            deferredClaimCount: args.metrics?.deferred_claim_count ??
+                args.record.validation_summary.deferred_claim_count,
+            competencyQuestionCount: args.metrics?.competency_question_count ??
+                args.record.validation_summary.competency_question_count,
+            assessmentCount: args.metrics?.competency_question_assessment_count ??
+                args.record.validation_summary.competency_question_assessment_count,
+            failureCount: args.record.validation_summary.failure_count,
+            revisionProposalCount: args.record.validation_summary.revision_proposal_count,
+            unresolvedCount: args.metrics?.unresolved_question_count ??
+                args.record.validation_summary.unresolved_count,
+            passRate: args.metrics?.pass_rate ?? args.record.validation_summary.pass_rate,
+        },
+        stages,
+    };
+}
 function recordArtifactRefsFromPreparation(refs) {
     return {
         target_material_profile: refs.target_material_profile,
@@ -198,11 +252,27 @@ export function createOntoReconstructCoreApi(options = {}) {
         async getRunStatus(sessionRoot) {
             const resolvedSessionRoot = path.resolve(sessionRoot);
             const reconstructRecord = await readYamlArtifact(path.join(resolvedSessionRoot, "reconstruct-record.yaml"));
+            const reconstructRunManifest = await readYamlArtifactIfPresent(reconstructRecord.artifact_refs.reconstruct_run_manifest);
+            const reconstructMetrics = await readYamlArtifactIfPresent(reconstructRecord.artifact_refs.reconstruct_metrics);
+            const reconstructRecordRef = path.join(resolvedSessionRoot, "reconstruct-record.yaml");
+            const pipelineExecutionLedger = await buildReconstructPipelineExecutionLedger({
+                sessionRoot: resolvedSessionRoot,
+                reconstructRecord,
+                reconstructRecordRef,
+                reconstructRunManifest,
+                reconstructRunManifestRef: reconstructRecord.artifact_refs.reconstruct_run_manifest,
+            });
             return {
                 sessionId: path.basename(resolvedSessionRoot),
                 sessionRoot: resolvedSessionRoot,
                 status: reconstructRecord.record_stage,
                 artifactRefs: reconstructRecord.artifact_refs,
+                progress: deriveReconstructProgress({
+                    record: reconstructRecord,
+                    runManifest: reconstructRunManifest,
+                    metrics: reconstructMetrics,
+                }),
+                pipelineExecutionLedger,
                 reconstructRecord,
             };
         },