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

T-704 implementation and validation ledger

Editorial note (2026-10-10): obsolete state terminology is summarized by purpose below; cited IDs, commits and validation results still describe the original investigation, not new executions.

Base: 6f9621ca (clean detached assigned checkout). Parent created work/t-704-backend-subjektiv-jobs without replacing a branch or discarding changes. Parent owns Backend/Profile/Subject authorization, cutover, documentation and integration. Two direct implementation SubWorkers supplied the common durable Job/store and Worker/Runtime contracts; parent inspected their committed sessions, diffs and test evidence, integrated them and corrected the boundaries below. Independent MR review is separate from implementation delegation.

Implemented contracts

• Caller-selected existing Builtin/project registry Profiles, normal virtual config/prompt bundle resolution and explicit execution-requirement rejection. Chosen instructions/features/model are not replaced with backend-job defaults.
• Immutable Host-authored Job/attempt create/restore binding and result capability, independent of Profile names/instructions/tags. No inherited Workdir, parent or subject-body execution authority.
• Common transactional resource serialization (Workspace schema 81), immutable Subject/candidate batch grants, exact replay vs resource collision, unknown fences and all-old-attempt cleanup fences before retry/followup.
• subjektiv requests its Profile; immutable bounded batches, empty surface-only Jobs, candidate authorization, existing CAS/atomic receipts and dispositions.
• Synchronous bounded clean-context surface generation before result submission. Preparation reports an already-current snapshot to avoid needless conflicting regeneration. Job failure acknowledgements are failed_confirmed only after checking the actual failed marker/reason/then-current store condition and generation provenance. Subject feature migration 6 adds immutable generation Job/attempt provenance, without changing Subject/Memory/candidate content.
• Durable results contain actual candidate dispositions and a separate verified ready/failed surface outcome. Existing terminal cleanup retains results/memory.
• Removed subject direct spawn and Idle resubmission. Persisted legacy ownership plus actual foreground WorkerState and confirmed stop/removal fence the cutover. Busy legacy workers are not interrupted or duplicated; subject bodies and the independent old Workspace Memory feature are not selected for removal.

Final validation (bounded CARGO_BUILD_JOBS=2)

Command/boundary	Result
cargo test -p yoi-workspace-server --lib backend_job	33 passed (before final surface acknowledgement addition; final whole-crate run below covers it)
cargo test -p yoi-workspace-server --lib subjektiv_jobs_tests	5 passed, including project recipe, batch/auth/receipts, actual failed acknowledgement, current surface and legacy cutover
cargo test -p worker --lib memory_surface_lifecycle	16 passed, including publication/failure before result, cancellation, definitive correction, ambiguous exact retry and already-current surface
Root cargo check	Passed; normal TUI/Server/standalone compile closure
cargo test -p worker -p worker-runtime -p manifest -p runtime-api -p server-api -- --test-threads=4	Passed: manifest 185; runtime-api 9; server-api 70; worker 815 lib + 110 integration; runtime 335 lib + 34 binary tests
cargo test -p yoi-workspace-server -- --test-threads=4 (final)	637 lib + 11 binary passed, no skips
cargo test -p server-api --features typescript	77 passed, including generated/OpenAPI/TypeScript contract freshness; existing ts-rs serde-attribute warnings
cargo fmt --all -- --check / git diff --check HEAD	Passed

These are recording-backend/store and scripted-client fixtures, plus real compiler and test binaries. They are not real-provider LLM execution, a live Backend / Runtime deployment, live dogfood consolidation or an environment update. No live Worker/environment was stopped or updated.

Failed checks and fixes (not erased by later passes)

• During integration, new request fields, resource replay metadata and surface validation arguments initially failed compilation; all were corrected before final validation.
• Initial Backend tests exposed the narrower browser builtin candidate allowlist; Host launch now resolves the complete existing registry without widening browser choices or adding a purpose-specific Profile allowlist.
• Initial surface-only test exposed rejection of empty candidate grants; empty batches now retain the subject lock and grant no candidate access (owned store tests 9 + contract tests 9 passed).
• Legacy fixture initially compared catalog compatibility state rather than actual WorkerState. Cutover now requires the actual Idle snapshot, and the test synchronizes on that authoritative observation before asserting behavior.
• First full Server run: 635 passed / 2 failed, both stale migration-history fixtures expecting schema 80. Their explicit retained chain/history is updated to 81; migration filter passed 14 tests and subsequent whole-crate runs passed.
• Exploratory cargo check -p worker-runtime --no-default-features and --no-default-features --features fs-store both failed, with 16 errors from existing unconditional workspace_request / reqwest imports while HTTP is disabled (plus unused-import warnings). The source/gates are present in the original baseline and are recorded in the T-701 ledger. No isolated baseline build was performed here. These remain failed exploratory unsupported configurations, not feature passes or a T-704 feature-gating fix. The default Runtime fs-store/ws-server configuration is fully tested.
• The inherited intermittent Ticket checker failure described in the T-702 ledger and T-701 report was not observed in the final T-704 full Server runs, but is not claimed fixed.

Raw parent logs are under target/t704-validation/ (ignored local artifacts), including server-full-initial-migration-fixtures.log, server-full-final.log, changed-crates.log, root-check.log, worker-surface-final.log, server-subjektiv-final.log, server-api-typescript.log, runtime-no-default.log and runtime-fs-only.log. The durable report records their concrete results; local log paths are not a substitute for the published immutable MR source.

Bounded-result follow-up after interrupted review

The first implementation was published as d12cdc91. Human interruption ended its first pending Reviewer before a verdict. On retry, the parent reread Ticket, MR, clean Workdir and provider source. Before the replacement Reviewer verdict, parent inspection identified a concrete result-budget defect: copying full resolution records for a 100-ID batch could exceed the common 16 KiB result bound, even when candidate decisions and surface generation had actually completed. That pending old-source review was stopped rather than treated as approval.

The follow-up keeps full immutable receipts/reasons/immutable history references/source edges in their existing store and persists only verified {candidate_id, action} summaries in the Job result. Batch selection conservatively budgets the complete result, including JSON-escaped IDs in both claim and outcome, plus a reserved bounded Subject/surface envelope. Candidates beyond that byte-bound stay staged. The common result bound is not enlarged or bypassed.

A new narrow fixture closes a batch of long/escaped IDs with individual receipt reasons larger than 16 KiB, successfully accepts a result within the default bound, verifies exact replay and remaining candidates, and starts a disjoint followup only after cleanup. A maximum escaped-ID budget unit test proves the complete projected result fits, not merely its raw input IDs.

Follow-up evidence (same bounded jobs setting):

• cargo test -p yoi-workspace-server --lib result_budget: 2 passed.
• Root cargo check: passed (fix-root-check.log).
• Full cargo test -p yoi-workspace-server -- --test-threads=4: 639 library + 11 binary passed, no skips (fix-server-full.log).
• Format and git diff --check HEAD: passed.

Only Server logic, Server fixtures and documentation changed in this follow-up; all other changed-crate/generated/Worker/Runtime results above remain applicable. The new commit is published on the same source selector of the existing MR and requires a fresh exact-source review. No target ref, tags or unrelated refs are pushed, and no merge/integration is performed by the Coder.