Oko/Docs

Operations

Release qualification

Real session, wait-register and task-graph journeys required before an Oko release.

Behavioral release qualification#

Oko's Darwin release quality gate runs real product journeys, not a compile-only check. The manifest .wisent-release.json invokes cargo test --locked --manifest-path rust/Cargo.toml for the measured OMP session start, shared Stado wait registration and task goal graph. Each target selects its ignored, dependency-bearing journey with --ignored --exact --nocapture; a missing account, goal, Brama refusal or broker route fails the release gate rather than silently skipping it.

The measured session journey starts a real OMP terminal through oko sessions start --harness omp, observes the selected provider and model in oko sessions agents, exercises the raw executable path and direct API-key account, and records Brama's refusal and the resulting unleased selection. The shared-wait journey runs a real OMP agent, observes its live czekam line in Stado's wait directory and verifies that the completed wait disappears. The graph journey writes tasks and a defect in an isolated signed-in organization, checks the native API and oko tasks map, then inspects persisted relations and unlinked debt. Reports retain source identity, executable digest, commands, exit status and responses under the checkout's .build/; on a release worker, the native and wait reports are also retained in WISENT_TEST_EVIDENCE_DIR.

On a Stado release worker, WISENT_SOURCE_DIR, WISENT_SOURCE_COMMIT and WISENT_SOURCE_SHA256 identify its immutable archive. In a normal checkout, the same test fixture records git rev-parse HEAD and a source patch. The archive contains no .git; neither mode may claim the other's source identity. The release worker must have actual signed-in OMP accounts and a Brama route that makes the lease refusal observable. Graph qualification additionally requires OKO_TEST_GRAPH_HOME, OKO_TEST_GRAPH_GOAL, OKO_TEST_GRAPH_GOAL_TEXT and OKO_TEST_GRAPH_MODEL for a separately signed-in test organization. Its HOME must be inside that source's .build/, never the operator's account. The account and its goal are real dependencies, not canned fixtures.

To run a target directly in a checkout with those dependencies, use:

sh
cargo test --locked --manifest-path rust/Cargo.toml --test sessions-model unleased::a_measured_omp_session_starts_without_a_brama_lease -- --ignored --exact --nocapture
cargo test --locked --manifest-path rust/Cargo.toml --test shared-wait a_real_oko_wait_is_registered_and_removed_when_the_harness_answers -- --ignored --exact --nocapture
cargo test --locked --manifest-path rust/Cargo.toml --test tasks-graph recorded_work_has_a_goal_root_and_quoted_relation -- --ignored --exact --nocapture

Task handoff qualification uses the real resident native API and Stado's real change queue with a dedicated task and session. Declare OKO_SESSION_PATH, OKO_TEST_SOURCE_REVISION, OKO_TEST_HANDOFF_TASK, OKO_TEST_FIXTURE_SESSION, OKO_TEST_HANDOFF_SOURCE, OKO_TEST_HANDOFF_COMMIT, and OKO_TEST_STADO_HOME. The Stado home must contain its real CLI and live below this checkout's .build/. The journey publishes the declared source commit to a temporary bare Git origin there and permits only local file transport for its child commands. It never changes the source checkout's origin or sends a handoff to the operator's queue. A missing source commit must be refused without changing the task proof or isolated queue; an accepted commit must appear in both. The report retains the Git receipts, native responses, source revision, executable digest, and observed queue and proof.

Executor continuation qualification uses a real broker terminal and a stopped executor with open work. Declare OKO_TEST_SOURCE_REVISION, OKO_TEST_STOPPED_EXECUTOR, OKO_TEST_EXECUTOR_HOME, and OKO_TEST_EXECUTOR_REGISTER; the signed-in home must be dedicated under the checkout's .build/, and its real register must reside inside that home. Both the resident service and CLI use that home and register. A policy pass must name the work and type it into the broker terminal; the agents catalogue must then show typed, the decision must remain readable, and a second pass must not send again. A missing or non-isolated fixture is a refusal, not a qualification pass.

A written journey, a healthy process and an archive digest are not evidence that the provider answered. Qualification succeeds only when those commands exit successfully and their retained reports show the observed external state. A failed gate names its missing real dependency or failed operation; repair the dependency or product rather than removing the gate.

Migrated from src/content/docs/releases/qualification.md