Post-MVP scope
What you'll find here
The surfaces intentionally outside Craik's first robust MVP. Each section names a surface, what ships pre-MVP, and what crosses into post-MVP territory. Use this when triaging scope creep.
0.x.0 is not a 1.0.0 promise.
MVP scope is limited to the accepted documentation reconciliation workflow, deterministic OpenAI and Anthropic provider paths, local state, policy-gated side effects, memory proposals, receipts, handoffs, work graphs, package release workflows, and Docusaurus documentation.
Gateway Daemon
v0.8.0 ships a foreground local gateway daemon with /health,
pid-file locking, persisted runtime state, webhook validation, channel
contracts, scheduled automation helpers, and gateway receipts.
Post-MVP gateway work is the broader production service: hosted/public
deployment, TLS termination, always-on scheduler supervision, broad
third-party adapters, inbound messaging loops, webhook dispatchers, and
production dispatch orchestration. Those surfaces must not be
documented as operational support until they have policy checks,
receipts, supervision, security review, and CI coverage.
Operator UI
Formatter contracts and read-only operator view helpers can support local inspection. A complete TUI, web dashboard, mutation-capable console, and hosted operator service are post-MVP.
Additional Live Runners
OpenAI and Anthropic are the MVP provider targets. Fixture and prompt-handoff adapters can remain documented for local testing and preview workflows, but additional live runner adapters are post-MVP until they meet the same certification, budget, retry, redaction, receipt, and side-effect boundaries.
Companion And Visual Surfaces
Desktop companion, mobile companion, voice, browser, visual workspace, multimodal, and adjacent runtime surfaces are posture and contract work before MVP. Product applications, always-on actions, remote action queues, credential storage, and direct mutation through those surfaces are post-MVP.
Marketplace And Community Ecosystem
Community skill, plugin, marketplace, index, probation, and reference integration docs describe future contribution mechanics. They do not imply a supported public marketplace, automatic trust, or runtime authority in the MVP.
Documentation posture
Every doc that covers a deferred surface uses one of three postures.
implementedpreviewpost-MVPDon't describe deferred surfaces as operational.
Unless the same page names the proof workflow, required policy boundary, receipts, and validation command, a deferred surface must not be described as operational.