yoi/docs/report/2026-10-06-t701-validation.md

T-701 validation ledger

This records concrete intermediate failures rather than treating later passes as erasing them. Final source and review evidence are on the repository Merge Request.

Validation approach

Start with Restore/parser/UI/serialization boundary filters, then the eight changed crates and the normal root cargo check compile closure. Cargo jobs are bounded to three; full crate test concurrency is bounded to four. No all-workspace test, --all-targets, Nix/Docker build, deployment, process restart or live Worker repair is part of this validation.

The Web production bundle, svelte-check, normal Deno tests and actual rendered component suites have passed. Those results alone do not prove Backend admission, replay or preparation recovery. Full Rust suites exercise callers, schema migration and dependent inventories that narrow guard filters cannot prove.

Intermediate failures and disposition

1. Early root checks failed because the Runtime request/preparation DTO integration was not yet present. This was an incomplete implementation, not a baseline defect. A subsequent root check passed after the integration.
2. Early Server API full tests reported three stale generated artifacts after the OpenAPI contract changed. Regenerating the affected closure artifacts resolved them; the full default suite passed 70 tests. TypeScript-feature tests were also executed after regeneration.
3. Adding full catalog GETs exposed existing browser fixtures that returned Workdir-only shapes to every endpoint. The fixtures now return the exact /workers contract, and the Workdir-error fixture fails only its intended endpoint. Catalog and transport/Workdir failures have separate alert identities.
4. Parent full cargo test -p yoi-workspace-server -- --test-threads=4 produced 614 passed / 4 failed (618 library tests):
   • hosts::tests::embedded_runtime_registers_routes_input_without_internal_leaks: a broad forbidden-word assertion rejected the newly public observation field's word token. The private credential/token non-leak contract must be preserved while allowing the explicitly public observation token.
   • server::tests::embedded_runtime_api_routes_by_runtime_and_worker_ids_without_leaking_internals: an old {} Restore fixture received 422 because guarded Restore now requires the observed token and request ID. Update the real route fixture, do not restore an unguarded compatibility path.
   • workspace_deletion::tests::explicit_purge_inventory_covers_every_workspace_scoped_table: the new internal Restore intent journal was absent from the explicit purge inventory. Integrate its Workspace deletion lifecycle; do not weaken the exhaustive inventory check.
   • server::tests::ticket_checker_suppresses_stale_and_clean_results_and_diagnoses_invalid_output: the inherited stale-checker execution.take_inputs().is_empty() assertion failed. Earlier T-702 evidence reproduced this named instability on an isolated original baseline; see T-702 validation report. T-701 has not fixed that checker, and this failure is not conflated with the three new integration regressions.

Follow-up disposition and final pre-publication results

The projection fixtures now permit only the explicit restore_observation_token key and validate its UUIDv7 value; private token/credential fields remain forbidden. The HTTP fixture sends the real observed token and request ID. The internal intent table is in the exhaustive Workspace deletion inventory.

The final restart recovery test exposed one obsolete Runtime expectation: an unowned startup/legacy pending operation must be explicitly recoverable, not permanently conflict. Public recovery now binds a receipt to the exact existing lifecycle operation ID, without candidate preparation or a replacement execution. Tests assert a competing request conflicts, recovery preserves the ID, and terminal replay after Stop never launches again. A Tool recovery fixture also used path-shaped IDs rejected by the existing authority-ID validator; it now uses valid authority IDs and proves the two explicit calls send an identical request body.

After those fixes, a full Server run reported 618 passed / 1 failed, solely the inherited stale-checker assertion above. Its isolated test subsequently passed. An additional whole-crate run with the same four-thread configuration and no skips passed 619 library + 11 binary tests. This does not erase the earlier failure or claim to fix the checker race.

Executed command	Final pre-publication evidence
root cargo check	Passed normal default-member compile closure, including TUI and Server
cargo test -p worker-runtime -- --test-threads=4	332 library + 34 binary tests passed
cargo test -p yoi-workspace-server -- --test-threads=4	619 library + 11 binary tests passed in the additional no-skip run; previous flaky failure retained above
cargo test -p worker -- --test-threads=4	804 library + 109 integration tests passed
cargo test -p runtime-api	9 tests passed
cargo test -p server-api / --features typescript	70 / 77 tests passed, including generated artifact freshness
cargo test -p protocol / --features typescript	78 / 83 tests passed
cargo test -p client	52 library + 2 integration tests passed
cargo test -p tui	331 tests passed
Web deno task check	0 errors, 0 warnings
Web deno task test	504 tests passed
Web deno task test:component	249 tests in 25 files passed, including the real paired sidebar/page/store suite
Web deno task build	Production build passed; existing chunk-size warning remains
cargo fmt --all -- --check, git diff --check HEAD	Passed

Additional exploratory Runtime feature checks did not pass: --no-default-features test/check cannot resolve existing unconditional workspace_request / reqwest imports; the test target additionally references disabled fs_store. HTTP-only check also lacks the existing retention and futures dependencies. Inspection of original HEAD confirms those imports/gates already exist; no isolated baseline build was performed for these configurations. These are recorded as failed exploratory checks, not semantic passes or newly supported configurations. The default Runtime configuration, which contains fs-store and ws-server, is exercised in full above. This Ticket does not redesign unrelated Runtime feature gating.

Raw session validation logs are retained under ignored target/t701-validation/, not shipped as product source. Immutable published source, independent verdict and any subsequent fix/review evidence belong to the explicit repository Merge Request.

Independent review and caller recovery fixes

The independent Reviewer recorded request_changes on MR 01a11064-502b-7222-9494-b1952fbcb1d5, source fdce12a47bdd408e6e1a0275dfb218951f1a2f1f, for two concrete omitted recovery scenarios. These are implementation defects, not baseline failures:

• restore_tui_loses_recovery_identity: The existing TUI Resume/Restore flow exited on unknown/pending result and discarded the tuple. It now retains the request throughout that flow, refreshes Session observation without treating GET as settlement, and offers explicit same-tuple recovery confirmation. Each additional POST requires user confirmation. Conflict and terminal rejection do not offer same-intent recovery; cancellation makes no additional POST and reports the original identity. No new Restore entrance, new execution operation, input or automatic retry loop is introduced. New TUI tests use the real Runtime, with only execution and lost transport acknowledgements faked, to assert identical target/request and unchanged lifecycle operation ID across transport and reconciliation-required recovery. Runtime is a test-only TUI dependency.
• restore_internal_conflict_never_retires_intent: A definitive stale conflict now settles only its pinned client intent before returning the original conflict; unknown/pending delivery remains pinned. A later deliberate generic orchestrator/subject invocation can use fresh observation. Fresh generic requests use a new UUID identity, including when two rejected invocations see the same generation, without changing unsettled retry identity. Tests cover both generic domains, ABA between pin and admission, journal restart, no automatic retry, immutable historical identity, repeated same-generation conflict, and preservation/reconciliation of a different admitted pending operation.

The first compile of the new TUI fixture omitted last_finished_submission_request_id in two WorkerState snapshots and failed; the fixtures were corrected before the passing focused/full tests below.

Post-fix validation:

Command	Evidence
root cargo check	Passed
TUI focused backend_worker_picker::tests::resume_	5 passed, including 3 new real-Runtime recovery tests
Server focused restore_guard_internal_	3 passed, including both new conflict retirement tests and existing unknown/restart recovery
cargo test -p tui -- --test-threads=4	334 passed
cargo test -p worker-runtime -- --test-threads=4	332 library + 34 binary tests passed
First post-fix full Server run	620 passed / 1 failed: the same inherited stale-checker assertion
Post-fix isolated checker	Failed the same assertion; not hidden or treated as a pass
Additional post-fix full Server run, same four threads and no skips	621 library + 11 binary tests passed
Formatting / diff whitespace checks	Passed

The Web/API/Worker/client source is unchanged by this fix; its initial published-source validation above remains applicable. The additional full Server pass does not resolve or erase either post-fix checker failure. Raw fix logs are target/t701-validation/{tui-recovery-fix-target,server-intent-fix-target,fix-root-check,fix-full-tui,fix-full-worker-runtime,fix-full-yoi-workspace-server,fix-checker-isolated,fix-server-additional}.log.

Review tooling boundary encountered

A first builtin Reviewer spawn with read-only delegation was rejected with Merge Request Reviewer SubWorkers must include writable delegated scope, despite the read-only source-review role. The accepted configuration kept product source read-only and delegated write/command authority only to isolated ignored target/t701-review-validation scratch. The Reviewer did not implement changes or delegate implementation. A clearer API distinction between read-only review source and writable validation scratch would avoid this misleading setup failure.