Operator surface
What you'll find here
The read-only operator surface Craik ships, the formatter contracts behind each view, and the boundary between the CLI-first surface and a complete dashboard.
Craik chose a CLI-first operator surface for v0.7.0.
The shipped entrypoint is craik operator overview: a read-only,
terminal-friendly surface backed by local-store queries and validated
formatter contracts. A complete TUI or dashboard is post-MVP scope.
See Post-MVP Scope.
Why CLI-first
Same terminal
Works where agents and operators already run Craik.
No service required
Inspects local SQLite state without starting a process.
Keeps review simple
Read-only workflows stay lightweight.
Avoids premature complexity
No browser, server, auth, or asset concerns before views are proven.
Future-compatible
Dashboard views can reuse the same formatter contracts.
Boundary
Read-only by default.
The v0.7.0 operator surface displays state from the local store and validated contracts. It must not mutate memory, approve grants, resolve contradictions, delete records, or execute plugins without an explicit future command and policy boundary.
Commands
The shared overview command prints the current project state grouped by operator question.
craik operator overview
craik operator overview --project project_docs
craik operator overview --section inbox
craik operator overview --json
--project scopes records that carry a project id or link to a task in
that project. Global records without project or task scope remain
visible because hiding them would imply a relationship Craik cannot
prove from the persisted record.
The JSON payload is the same read-only snapshot used by the text view:
project_id, read_only, sections, and notes. Every section names
the navigation id, count, status, suggested command, backing contract
kinds, and a short summary.
Navigation
The CLI surface organizes views around operator questions. The first command is an overview; follow-on commands can reuse the same section ids and formatter contracts.
Overview
Project · active tasks · recent handoffs · blocked states.
Work Graph
Graph events · exports · dependencies · verification links.
Handoffs
Summaries · next steps · receipts · evidence · risks.
Receipts
Capability and plugin action records.
Inbox
Contradictions · delegations · context requests.
Evidence
References · assumptions · memory impact previews.
Quality
Quality scores · critic findings · red-team findings · gates.
Instructions
Sources · snapshots · distilled proposals · reviews.
Traps
Known traps · negative knowledge.
Run Deltas
Recovery and continuity changes.
Each view degrades cleanly when records are missing. Missing data is shown as unavailable state — never inferred.
Data sources
The initial surface reads from existing contracts and store helpers.
craik.handoff
craik.capability_receipt
craik.plugin_receipt
craik.work_graph_event
craik.contradiction_report
craik.evidence_reference
craik.assumption
craik.memory_impact_preview
craik.human_delegation_point
craik.context_request
craik.handoff_quality_score
craik.evidence_coverage_score
craik.runtime_critic_finding
craik.red_team_finding
craik.instruction_source
craik.distilled_instruction_proposal
craik.known_trap
craik.negative_knowledge
craik.run_delta
See the schema reference for the persisted field shapes of each contract.
Follow-on surfaces
Future TUI or dashboard work can reuse the overview snapshot and individual formatter contracts behind the same read-only boundary. Each new command or panel should have focused tests for formatting, empty-state behavior, project scoping, and links to the underlying contracts before it is described as operational.