[trissim]

Summary

2 commits; 5 files; +134/-2. Selected capture now compares its ordinary readers with their originals before releasing the existing cut. No new installer, hold, callback, schema, ledger, replay, or native-launch permission.

This continues P1086 after #3897 (merge 8c478c35fe2f) installed the selected request/worker path. That source approval did not complete original-data comparison or application acceptance.

Before / after

Before:

SelectedInputsProbe -> PracticeCopy.capture_inputs -> PracticeMeasurement
external comparison helper -> authentic hold already unavailable

After:

SelectedInputsProbe -> PracticeCopy.capture_inputs
  capturing_inputs (existing maintenance / writer / registry / file checks)
    select original rows
    ContextStore.require_retained (same context resolver)
    PracticeCopy.require_inputs (ordinary input + participant readers)
    PracticeMeasurement

A comparison against newer originals after rehearsal cannot prove the captured cut. The comparison now shares the actual capture lifetime, including its disabled source-write claim and final source-integrity checks.

Context ownership

ContextStore.require_retained compares each selected session/path entry group, requires every requested original record/source, resolves every retained request and predecessor through ContextStore.resolve, and compares request/version records without reminting their coordinates. Entry-only selection does not invent a store identity.

Coordinator/readback ownership

PracticeCopy.require_inputs compares the ordinary InputDispositions.unresolved answer, exact native session/path groups, requested participant presence, and all retained participant aggregates through ParticipantStore.read_at. The held original's CoordinationStore.schema_at selects the schema once, and that declaration validates both databases. The selected output has no independent registry or runnable-root authority. Missing originals or a mismatch refuse capture; nothing is rewritten to make the comparison pass.

Deletions and scope

No old product subsystem is being replaced. Two import lines change; no compatibility entry point is added. The prepared external comparison script is not wired into the product or used to claim a same-cut result. Normal complete backups and the empty selected-request default remain unchanged.

Evidence

• Read the complete changed production diff and its source/capture/worker lifetimes.
• git diff --check passes.
• Four changed Python files parsed using installed Python 3.14.8, without importing Core.
• Two additional controls are authored, not executed: omitted native context entries refuse, and the real held selected probe keeps the ordinary unresolved answer. The existing context closure/sequence control also invokes the new readback.
• The initial publication performed no pytest, full suite, local NRA gate, capture, installer, provider, sampler, or physical app run. Later execution epochs follow separately.

Actual build and scratch execution epochs

• Build 01 failed before capture: latest Toad requires CommsConversationPageTool, absent from the older Core base. The failed prefix and log remain intact. No shim was added.
• Rebased onto current main and published 37f8d248ff54a82734d21d9be2c37ee0c0b34811; Git range-diff reported the same comparison patch. Build 02 completed through RuntimeStack.build/complete and the existing host lease, including producer/native/package/runtime-resolution/client-import probes. This built a candidate without publishing it.
• Scratch 01 used the actual ExistingBusInstall.owners_stopped path and candidate TargetStack.probe(SelectedInputsProbe(...)). It FAILED at PracticeCopy.require_inputs: asking the selected output's registry for a schema raised Native runtime has no registry authority. Its source, partial output and log are preserved; no original data was involved.
• Commit 405719243c2742ebb9ffe41bcd3654350f3750c4 fixes that owner error: derive the schema from the held original and validate both connections with it. No registry copy, fallback or weakened schema check. The correction's candidate build03 completed through the supported runtime owner. Scratch02 passed the actual selected target operation, then failed in a duplicate controller-only call to the new method on the older outgoing runtime; that failed epoch remains preserved. Removing that duplicate check required no product change. Fresh scratch03 completed the real installer stop/retarget/give-back, selected target-worker capture and ordinary readback, then the existing schema-current PreparedMigration.capture/carry path: 790,528 selected bytes, 11 identical files, zero rewrites, one thread read back, and source writes admitted again after release. Actual exit0; source/output/JSON/phases retained in pi-publication-carry/shared-board/p1086-scratch-worker-03.*. This root had no historical migrations to apply; it is not original-data, peak, native or physical acceptance.
• Separately, the useful MAIN install of Core 8e165494e704 completed in 59.5 seconds with Textual Add notes on child process supervision and a plan audit #232. Actual build/root/source readback confirms that epoch. It excludes this unmerged PR and proves neither capture nor physical typing acceptance. Errors' fresh typing attempt remains failed and separately owned.

No pytest, full suite, local NRA gate, provider or original-data operation ran in these scratch/build epochs. A schema-current scratch migration/readback will not prove every historical carry or the original native journey.

Still required

Authentic original-data capture; aggregate/peak <=3 GiB including temporary/SQLite companions, handles/RSS/free-space/source integrity; and the original configured-native/isolated-physical read/edit/draft/undo/return/reopen journey. A final PracticeMeasurement is not peak-resource proof.

Assumed: the existing installer owns the retargeted hold; this check runs inside capture_inputs, not as independent freeze authority. Source readers are stable under that already-traced lifetime. No absent relationship or unknown input is synthesized or replayed.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.