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

T-708 implementation and validation ledger

Base: clean detached assigned checkout 3c424fd17d1a5e8bb5542de2d0ad88f55338e0ea, also the inspected origin/develop. T-704 was authoritative done with that integrated source. Created work/T-708-standalone-jobs without overwriting an existing branch or discarding changes. T-709's subjektiv consumer is separate. The concrete SQLite placement/schema ownership was recorded in the design before implementation; it uses the existing <state_dir>/<WorkerId> directory layout, not a new workers subdirectory.

Three scoped implementation children supplied the common contract/Backend projection, Worker execution adapter, and local SQLite store. Parent inspected committed sessions, exact source changes and concrete test results, then integrated Host/service ownership, live-resource ceilings, deadline fencing, independent acknowledgement, shared outcome projection, process-loss tests and documentation. Independent published-MR review is separate from these implementation children.

Implemented boundaries

• job: neutral immutable request/limits/result envelope, fingerprint, strict registry selectors, bounded digests and read-only intent/attempt/outcome DTOs. No HTTP, Workspace, Runtime identity, domain grants, runner or workflow DSL.
• Backend reuses validation/result helpers and neutral projections while retaining its exact request wire/fingerprint/envelope, domain grants, persistent states, Runtime authorization, unknown fences, resource serialization and cleanup.
• worker::job: selected registry Profile/instruction/model, explicit requirement rejection, bounded policy, distinct ephemeral Internal Worker, result-only FeatureModule and Host-fenced structured acceptance. No parent filesystem, Workspace, Feature or domain connections; no Profile-name authorization. Ambiguous sink acceptance is Unknown unless the Host's durable result proves success.
• Standalone Host owns schema-1 SQLite intent/attempt/result/ack state and a bounded execution service. It opens and recovers under its Worker lease; shutdown cancels and awaits executions, closes SQLite, then releases the lease after controller confirmation. Old cloned handles are closed. Drop cannot attest cleanup and retains the lease. Busy/unknown/cancelled/terminal work is not blindly replayed.
• Exact immutable request resend differs from explicit bounded new-attempt retry. Results commit before resource release, survive model/notification failure, and are independently acknowledged by the consumer. Waiting does not relinquish Host ownership of cancellation/concurrency. Cancelling unknown intent retains its uncertain attempt evidence and serialization fence.
• Optional builtin:job is a caller-selected compatible policy, not a fixed runner default. Different user registry Profiles are demonstrated in Worker fixtures. Existing builtin:backend-job retains Backend behavior; standalone rejects its unavailable requirements rather than silently stripping or replacing them.
• No production Server/Runtime process, HTTP/WS listener, Worker registry, subprocess Worker, daemon/pool or subjektiv-specific runner is added.

Validation results

Development began with narrow contract/module targets before full changed-crate validation. Final root check covers the normal default-members TUI/Server closure.

Command	Concrete result
cargo test -p job	9 contract tests passed; no unit/doc tests
cargo test -p standalone --lib job_store	19 fixtures passed: transactional replay/conflict, all limits, result fences, retry/old-attempt preservation, cancellation, concurrency races, SQL rollback, schema rejection and reopen recovery
cargo test -p standalone --lib jobs::tests	2 passed: Host capability binding/deadline/replay and success/cancellation/closed-handle lifetime
cargo test -p standalone --test jobs process_loss_recovers_durable_jobs_without_replaying_unknown	Actual test-owned process exit and Host stale-lease/SQLite recovery passed
Final cargo test -p standalone	25 library + 10 existing Host integration + 8 Job integration passed; 1 child-process fixture entry point marked ignored in parent harness, explicitly invoked with --ignored by the passing process-loss test
cargo test -p manifest	All 185 tests passed, including new optional builtin Profile catalogue resolution; no resolver/runtime/schema implementation changed
cargo test -p worker	All 826 library + 110 integration tests passed, including 11 new Job tests and 8 existing Internal Worker substrate tests
cargo test -p yoi-workspace-server --lib backend_job	All 38 passed: neutral adapter/wire/fingerprint, T-704 Profiles/no fallback, structured fences, unknown/recovery, resource serialization and T-690 cleanup
cargo test -p yoi-workspace-server --bins	All 11 binary tests passed
cargo test -p worker-runtime --lib backend_job	All 3 Job binding/dispatch regressions passed
cargo test -p server-api --features typescript	All 77 passed, including checked-in generated/OpenAPI/TypeScript freshness; existing ts-rs serde-attribute warnings
Root cargo check	Passed after integration and again after final local adapter/tests changes
cargo fmt --all -- --check / git diff --check HEAD	Passed
cargo test -p yoi-workspace-server	Failed: 643 passed, 1 failed in library; see retained anomaly below. Binary tests were therefore run separately. This is not a green full Server suite.
cargo test -p yoi-workspace-server -- --test-threads=4	Failed: 643 passed, 1 failed, same unchanged checker assertion; not claimed passed

Profile fixtures use two different existing user registry entries with distinct instructions and budgets, plus optional builtin:job. They prove only SubmitJobResult is exposed, selected instructions/policy are retained, scopes and Backend/domain tools are absent, malformed/oversized/forged results are rejected, uncertain sink submission permits only identical replay, final prose is not success, provider failure/cancellation/turn limits do not manufacture success, and accepted results survive later provider failure.

Host Job integration additionally proves explicit known-model-failure retry, request replay, live concurrency while a consumer waits, cancellation, timeout, shutdown, pending resume, consumer acknowledgement and unsupported Profile rejection without model calls. Direct-store fixtures prove persisted facts and rollback/reopen behavior, not live model or process behavior.

Actual process verification versus fixtures

process_loss_recovers_durable_jobs_without_replaying_unknown starts only a test-owned copy of the integration test executable, using scripted model clients. The child owns a real StandaloneHost/SQLite connection/Worker lease, persists a reserved request, a cancelled request and an accepted result, then exits with code 23 while a separate Internal Worker is executing. It deliberately skips destructors and graceful shutdown. The parent verifies that exit and restores the Host through the real stale-process lease path: accepted result retained/unacknowledged, cancelled work never resumed, reserved work explicitly resumable and interrupted work Unknown/no automatic retry. The helper's ignored annotation is an entry-point selector, not skipped semantic coverage.

These are real Rust test/compiler processes plus scripted in-process model executions and SQLite fixtures. They are not live-provider LLM calls, a live standalone CLI/TUI session, a Backend/Runtime deployment or dogfood environment update. No operating Yoi Worker or live dogfood process was stopped or updated. Production Jobs do not create the subprocess used solely by that crash test.

Retained failures and evidence limits

Initial integrated compilation exposed get snapshot/Option disagreement between concurrently authored store/service; signatures were aligned and the subsequent store/Host/full standalone runs passed. A private tool-type import during child integration was corrected before focused/full Worker validation. No passing result is attributed to those initial failing builds.

Both full Server runs and one isolated run of server::tests::ticket_checker_suppresses_stale_and_clean_results_and_diagnoses_invalid_output failed the unchanged post-stale-result assert!(execution.take_inputs().is_empty()) at server.rs:44748. All 38 Job-filter tests pass, including unchanged Backend envelope/fingerprint compatibility and late-result/cleanup fences. The same checker assertion/race was independently reproduced on the earlier original base in the T-702 ledger, and explicitly retained as unfixed in the T-704 ledger. No new isolated build of this Ticket's exact base was run, and its root cause is not claimed proven or fixed here. The checker implementation/test was neither changed nor skipped to manufacture a green suite. This validation anomaly remains visible for Reviewer/Orchestrator attention.

No whole-workspace tests, E2E, Nix/Docker builds or live-provider validation were claimed. Backend generated contracts were regression checked despite no wire change. Result-only Jobs reject unsupported Feature/authority requirements; subjektiv consumer capabilities/postprocessing are T-709 work, not inferred grants.

Publication must use only the clean committed Ticket work branch by normal non-force push, verified with exact provider source ref. No target/tags/unrelated refs, replacement MR, integration branch, merge or Ticket completion is performed by this Coder. Final immutable source/MR/review identities belong in the MR thread and approved Ticket handoff rather than being guessed in this ledger.