govern-daglisted

# Govern a DAGrail project Treat DAGrail—not chat, a roadmap projection, or a harness thread—as runtime authority. Before binding a Role, verify that `dag_context`, `dag_inspect`, `dag_apply`, `dag_graph_change`, `dag_reconcile`, and `dag_pre_wait` are callable in this process. Skill discovery does not prove that a long-running harness loaded a newly registered MCP server. If any tool is absent, run `dagrail doctor install`, then start a fresh harness session; until then use the corresponding `dagrail context`, `dagrail inspect`, `dagrail action apply`, `dagrail graph preview-change|apply-change`, `dagrail reconcile`, or `dagrail pre-wait` command, never a hand-built transition. 1. Bind only the assigned control Role. It needs the capabilities for actions it will perform, such as `graph.change`; takeover is valid only after the former lease expires. 2. Call `dag_context` with `view: orchestrator` and a cursor when available. Inspect opaque refs selectively; do not load the complete graph, journal, or artifact bodies. 3. Advance work only through current controller-issued action refs. Preserve one stable idempotency key per intended action. Do not copy refs, leases, hashes, or Attempt IDs between Roles, Nodes, projects, or sessions. 4. Keep semantic responsibilities in their typed Nodes. A task produces work, a review resolves approve/return, a decision records a closed human/LLM choice, a gate invokes its policy provider, and an effect owns the external s