casefile

name	casefile
description	Use to start or resume substantial repository work that needs traceable investigation, human decisions, reviewed tickets, implementation, and evidence.

Casefile

The request-receiving root remains the orchestrator with the model and effort through which the human invoked it. Root is an authority binding, not a model profile. Read repository authority and current state, bound the work, resolve the configured planning store, and validate its project-to-source mapping. Write every durable Casefile artifact directly in that resolved store; never clone or mirror the planning store in task scratch. Use the session's .agent-workspace only for disposable, non-authoritative previews, content-hash backups, isolated output, and command logs. Never infer a source path or replace the root.

Establish read context hierarchically through Provider protocol v2: call casefile_snapshot, use its catalogue to resolve the exact project and complete investigation scope, then request that scope's record_index. Request record_detail only for the exact identities necessary for the current step. Never request unscoped or bulk records, infer an investigation path by concatenation, or combine snapshot, index, detail, board, or transition results carrying different revisions.

Route the current phase to casefile-investigate, casefile-review, casefile-implement, or casefile-close. Every governed phase requires an explicit compatible strategy. Present compatible choices and a recommendation, then wait for human selection.

Review the Provider's compact preview envelope. Request confirmation only when approval_required = true, then apply its preview_id in the same MCP session.

When starting a new Casefile, activate the new investigation root, then call casefile_preview_default_delivery_board, review its envelope, and apply its preview_id. The request to start the Casefile authorizes this canonical board setup but not a ticket-progress transition. Stop before delegation if provisioning fails; never replace a differing board.

Do not offer, select, preview, or persist an implementation-writer binding during startup, investigation, or review. A binding is implementation-phase state: its selection requires an accepted dependency-safe plan, the human's explicit implementation-strategy choice, and the exact selected implementation matrix to be persisted and valid. Route binding selection through casefile-implement; never pre-create a matrix to satisfy the binding Provider.

Keep investigation source access read-only. The root alone arbitrates duplicate findings, reserves ticket IDs and paths, records decisions, and disposes tickets. Reviewers write evidence only. Implementation begins only from accepted tickets and an approved dependency-safe plan. Preserve rejected rationale, contention, verification, and unresolved risk through closeout.