End-to-end coding_test_fix TaskStream fixture

[devkade]

Summary

Prove the #236 MVP with one end-to-end governed coding TaskStream.

Parent: #236

Fixture

A small intentionally failing test.

Expected flow:

create stream
finalize contract
start run
dispatch to one runtime session
collect evidence
run verification
decide completion by kernel
query status/events

Required evidence

• changed files
• final diff artifact ref
• test command
• exit code 0
• verification result
• completion decision referencing evidence and verification

Acceptance criteria

• E2E test proves one successful coding_test_fix stream.
• Completion is emitted by kernel authority.
• Event log contains compact accountability events.
• Raw logs/diffs remain artifacts.
• README documents how to run the fixture.

[devkade]

AI-understood issue summary

Issue #245 should prove the #236 MVP with one end-to-end governed coding_test_fix TaskStream fixture: create a stream, finalize its contract, start one run, dispatch to one runtime session, collect normalized evidence, run verification, have the kernel emit completion, and then query status/events. The proof must include changed files, final diff artifact ref, test command, exit code 0, verification result, and a completion decision that references both evidence and verification.

Why this issue is needed

• SSOT: Ilchul Agent OS — MCP TaskStream control plane MVP #236 defines the MVP as one human goal → one TaskStream → one Run → one RuntimeSession → evidence → verification → kernel-owned CompletionDecision; End-to-end coding_test_fix TaskStream fixture #245 is the mechanical proof that the architecture works beyond isolated unit tests.
• Parent SSOT: Ilchul Agent OS — MCP TaskStream control plane MVP #236 requires compact accountability events and artifact refs for raw logs/diffs. The current repo has durable workflow artifacts and events, but they are Kapi workflow snapshots, not the required TaskStream event vocabulary (src/application/workflow-service.ts:876, src/application/workflow-service.ts:880, src/application/workflow-service.ts:882, src/application/workflow-service.ts:883).
• The existing repo already has evidence, artifact, worker, and validation patterns that can reduce implementation risk, but there is no in-repo TaskStream/CompletionDecision implementation yet (rg "TaskStream|CompletionDecision|EvidenceRecord|VerificationResult|stream.created|completion.decided|coding_test_fix" found no matches outside the issue text, and no repo Rust source exists except references/oh-my-codex/Cargo.toml).

Why this issue may not be needed

• If the maintainers only need to validate the current TypeScript/Kapi workflow harness, existing tests already cover start/status/evidence/artifact/complete behavior (test/tool-behavior.test.ts:150, test/tool-behavior.test.ts:158, test/tool-behavior.test.ts:176, test/tool-behavior.test.ts:196, test/tool-behavior.test.ts:295).
• If the goal is just supervisor visibility for existing workers, ilchul report/events/doctor already inspect worktree diffs, artifacts, evidence, events.jsonl, and snapshot.json (src/cli/runctl-cli.ts:181, src/cli/runctl-cli.ts:194, src/cli/runctl-cli.ts:571, src/cli/runctl-cli.ts:579, src/cli/runctl-cli.ts:659).
• However, those surfaces do not prove the SSOT: Ilchul Agent OS — MCP TaskStream control plane MVP #236 authority boundary: kernel-owned stream/run/session records, accepted evidence, verification result, and completion.decided with decided_by=ilchul.

Expected Outcome

After approval and implementation, the implementation agent should leave a deterministic fixture/test that can be run locally and documented in README.md. A successful run should mechanically show:

• one coding_test_fix TaskStream and one Run;
• one selected runtime session;
• required compact events, including at least stream.created, run.created, runtime.dispatched, evidence.recorded, verification.finished, and completion.decided;
• artifact refs for raw logs and final diff rather than raw logs/diffs embedded in events;
• evidence containing changed files, final diff artifact ref, test command, and exit code 0;
• a verification result with pass status;
• a kernel completion decision with non-empty evidence/verification references and decided_by=ilchul;
• status/events query coverage.

Evidence-based implementation plan

Feasibility grounded in research

In-repo reusable code/patterns found:

• Existing RunContractView already projects goal, lifecycle, artifacts, evidence, expectations, completion criteria, and completion status; use it as vocabulary inspiration, not as the TaskStream authority source (src/domain/run-contract.ts:49, src/domain/run-contract.ts:58, src/domain/run-contract.ts:69, src/domain/run-contract.ts:70, src/domain/run-contract.ts:71, src/domain/run-contract.ts:72, src/domain/run-contract.ts:73).
• Existing evidence records already include fields directly relevant to End-to-end coding_test_fix TaskStream fixture #245: command, exit code, artifact refs, changed files, acceptance criteria, command refs, worker id, actor, authority, and snapshot hash (src/domain/types.ts:74, src/domain/types.ts:79, src/domain/types.ts:80, src/domain/types.ts:84, src/domain/types.ts:85, src/domain/types.ts:86, src/domain/types.ts:87, src/domain/types.ts:89, src/domain/types.ts:90, src/domain/types.ts:91, src/domain/types.ts:92).
• WorkflowService.startWorkflow, recordEvidence, completeWorkflow, and validateWorkflow show the existing start/evidence/complete/validate flow to mirror at the TaskStream level (src/application/workflow-service.ts:33, src/application/workflow-service.ts:134, src/application/workflow-service.ts:164, src/application/workflow-service.ts:256).
• Current completion already records evidence before completion and validates artifacts before terminal save; preserve that sequencing but move final authority into the TaskStream kernel (src/application/workflow-service.ts:168, src/application/workflow-service.ts:169, src/application/workflow-service.ts:170, src/application/workflow-service.ts:172, src/application/workflow-service.ts:173).
• Existing artifact persistence enforces root confinement and generated-artifact ownership; reuse the safety model for raw logs/diffs/artifact refs (src/adapters/file-store.ts:53, src/adapters/file-store.ts:58, src/adapters/file-store.ts:65, src/application/workflow-service.ts:911, src/application/workflow-service.ts:912).
• events.jsonl/snapshot.json are already tracked generated artifacts for existing modes (src/domain/workflows.ts:5, src/domain/workflows.ts:6, src/domain/workflows.ts:7, src/domain/workflows.ts:8), and initial file contents are scaffolded by the file store (src/adapters/file-store.ts:343, src/adapters/file-store.ts:344, src/adapters/file-store.ts:346, src/adapters/file-store.ts:347). The fixture should add TaskStream-specific artifacts rather than overloading legacy Kapi snapshots.
• Existing worker preparation and dispatch patterns can inform the “one runtime session” fixture (src/application/workflow-service.ts:304, src/application/workflow-service.ts:334, src/application/workflow-service.ts:339, src/application/workflow-service.ts:360, src/application/workflow-service.ts:367, test/worker-list.test.ts:94, test/worker-list.test.ts:103).
• Existing CLI/reporting code already parses events.jsonl, reads evidence from state, inspects worktree diffs, and reports artifacts (src/cli/runctl-cli.ts:603, src/cli/runctl-cli.ts:614, src/cli/runctl-cli.ts:642, src/cli/runctl-cli.ts:651, src/cli/runctl-cli.ts:659, src/cli/runctl-cli.ts:670, src/cli/runctl-cli.ts:672). That provides reusable query/report expectations for status/events coverage.
• Existing tests prove target resolution and generated artifact availability (test/target-resolution.test.ts:9, test/target-resolution.test.ts:13, test/target-resolution.test.ts:26, test/target-resolution.test.ts:27) and compact worker events (test/cli-worker-events.test.ts:18, test/cli-worker-events.test.ts:23, test/cli-worker-events.test.ts:24, test/cli-worker-events.test.ts:35).

External references / libraries found:

• SDKs - Model Context Protocol - https://modelcontextprotocol.io/docs/sdk — official MCP SDK list; the Rust SDK is listed as modelcontextprotocol/rust-sdk and Tier 2.
• GitHub - modelcontextprotocol/rust-sdk - https://github.com/modelcontextprotocol/rust-sdk — official Rust MCP SDK implementation; use only behind the MCP adapter boundary.
• Tools - Model Context Protocol - https://modelcontextprotocol.io/specification/draft/server/tools — MCP tools are the appropriate control-plane primitive, but operations should carry explicit stream/run/session ids instead of relying on hidden transport state.
• rusqlite - Rust - https://docs.rs/rusqlite/ — suitable SQLite adapter for canonical store implementation.
• Using derive · Serde - https://serde.rs/derive.html — suitable for typed JSON artifacts/projections and record serialization.
• Tokio - An asynchronous Rust runtime - https://tokio.rs/ — suitable async runtime for MCP/runtime adapter layers if needed.
• tempfile - Rust - https://docs.rs/tempfile — suitable for isolated fixture workspaces/artifact roots.
• assert_cmd - Rust - https://docs.rs/assert_cmd — suitable for CLI/e2e fixture command assertions if the implementation exposes a Rust CLI harness.
• Test runner | Node.js Documentation - https://nodejs.org/api/test.html — the current repo already uses Node’s built-in test runner via tsx --test test/*.test.ts (package.json scripts.test), so TS compatibility tests should stay on that runner unless the Rust fixture fully replaces them.

Concrete step-by-step plan for the implementation agent

1. Add the narrow E2E fixture at the TaskStream boundary, not as a broad workflow rewrite. Treat End-to-end coding_test_fix TaskStream fixture #245 as the child proof for SSOT: Ilchul Agent OS — MCP TaskStream control plane MVP #236, not as the whole Rust kernel implementation. If prerequisite child issues (Rust workspace scaffold + DDD core skeleton #238-Pi runtime adapter and TS facade boundary #244) are not merged yet, create the minimal missing testkit/core/store/adapter surface needed for this fixture while preserving the SSOT: Ilchul Agent OS — MCP TaskStream control plane MVP #236 boundaries.
2. Define or reuse core TaskStream records needed by the fixture. Ensure the core can represent TaskStream, immutable/finalized contract, Run, RuntimeSession, EvidenceRecord, VerificationResult, and CompletionDecision. Use the existing RunContractView and ValidationEvidence field coverage as migration references (src/domain/run-contract.ts:49, src/domain/types.ts:74) but keep canonical authority in the new kernel.
3. Implement the exact event timeline. The fixture must emit compact events, not raw transcripts. Required minimum: stream.created, stream.contract_finalized, run.created, runtime.session_started, runtime.dispatched, bounded runtime.output_observed, evidence.recorded, verification.started, verification.finished, and completion.decided. This is intentionally different from current workflow.snapshot appends (src/application/workflow-service.ts:876, src/application/workflow-service.ts:882).
4. Create a tiny intentionally failing coding fixture. Put it under an isolated testkit/fixtures area or temp workspace. The task should be mechanically fixable, e.g. a one-function implementation with a failing test. Use tempfile for Rust fixture isolation and, if testing CLI commands, assert_cmd; for current TS test harness coverage, use the existing npm test path shown in package.json and Node’s test runner docs.
5. Dispatch to exactly one runtime session. Use one selected adapter/session only. If using the existing Pi/tmux path, keep tmux/process fields in adapter/session records and out of core domain records, following SSOT: Ilchul Agent OS — MCP TaskStream control plane MVP #236 and the existing adapter separation (src/application/workflow-service.ts:304, src/application/workflow-service.ts:360).
6. Collect normalized evidence after the runtime changes the fixture. Evidence must include changed files, final diff artifact ref, test command, and exit code 0. Existing ValidationEvidence shows the field shape to mirror (src/domain/types.ts:79, src/domain/types.ts:80, src/domain/types.ts:84, src/domain/types.ts:85, src/domain/types.ts:87).
7. Write raw outputs and diff as artifacts. Store full stdout/stderr/test logs/final diff under artifact refs with digests or stable ids. Do not inline them into event payloads. Reuse root confinement/path safety principles from FileWorkflowStore (src/adapters/file-store.ts:53, src/adapters/file-store.ts:58, src/application/workflow-service.ts:911).
8. Run verification through kernel authority. Verification should consume accepted evidence/artifact refs and produce a VerificationResult. It should not trust runtime “done” output as completion. Include a negative test that runtime success text without evidence/verification cannot produce completion.
9. Emit completion from the kernel only. completion.decided must include decided_by=ilchul, non-empty evidence_ids, and a verification result reference. Include negative tests for missing evidence ids, missing verification ref, incorrect decided_by, and runtime/adaptor attempting to mark completion directly.
10. Add status/events query checks. The E2E test should query status/events after completion and assert the event log remains compact and mechanically parseable. Existing CLI parsing/reporting behavior can guide this (src/cli/runctl-cli.ts:181, src/cli/runctl-cli.ts:659, src/cli/runctl-cli.ts:670, src/cli/runctl-cli.ts:672).
11. Document how to run the fixture. Update README.md with the command(s), expected artifacts, and validation checklist because repo instructions require README alignment whenever commands, artifacts, validation gates, or workflow semantics change.

Risks / assumptions surfaced by research

• The repo has reusable TS/Kapi patterns but no existing TaskStream kernel implementation; this fixture may need to depend on Rust workspace scaffold + DDD core skeleton #238-Pi runtime adapter and TS facade boundary #244 or introduce a minimal vertical slice.
• The official Rust MCP SDK is appropriate but Tier 2, so keep MCP usage isolated behind the adapter crate/module.
• Current generated artifacts are guarded from direct writes (src/application/workflow-service.ts:911, src/application/workflow-service.ts:912); the implementation should preserve that ownership model for TaskStream projections.
• Avoid a false pass where events.jsonl contains required event names but raw logs/diffs are embedded inline. Tests should assert payload boundedness and artifact refs.
• Avoid adapter leakage: one Pi/Codex session is allowed, but generic core records should not contain tmux-, Pi-, or Codex-specific fields.

Assumptions / human decisions to resolve asynchronously before /approve

• Assumption: the first fixture runtime should use the same selected runtime path chosen by SSOT: Ilchul Agent OS — MCP TaskStream control plane MVP #236/Pi runtime adapter and TS facade boundary #244; if no choice is recorded, implementation agent should choose the smallest deterministic local adapter that can mutate the fixture and produce evidence.
• Assumption: using rusqlite, serde, tempfile, and optionally assert_cmd is acceptable for the fixture/test surface unless maintainers object before /approve.
• Decision to resolve before or during approval: whether End-to-end coding_test_fix TaskStream fixture #245 should wait for Rust workspace scaffold + DDD core skeleton #238-Pi runtime adapter and TS facade boundary #244 to merge or land as a vertical slice that includes any missing minimal kernel/store/MCP/runtime pieces.

Approval reminder

Implementation starts only after a human comment containing /approve. Until then, this is a planning handoff only; the implementation agent will use the issue body and this GitHub discussion as its complete starting context.

Agent Signature

[devkade]

/approve