MVP Plan

6 min readFor contributorsUpdated 2026-05-19

What's in this doc

The accepted v0.x.0 MVP scope: the single workflow Craik proves end-to-end, the components that ship, the build order, the non-goals held off until later, and the success criteria the MVP is measured against.

Prove one workflow — not a broad platform shell.

Given a real software repository, Craik should assemble a task-specific project model, guide an agent through governed work, record capability receipts, and produce a durable handoff backed by memory.

Accepted primary demo

The accepted first demo target is Stigmem documentation and state reconciliation. It exercises the problems Craik is designed to solve: stale documentation · public/internal documentation boundaries · immutable ADR constraints · live GitHub state · Stigmem facts · operator and credential identity · multi-agent handoff continuity · verifiable tool use.

1. Connect Craik to a GitHub repository.
2. Register the Stigmem repository as the project.
3. Connect to a local Stigmem node.
4. Authenticate the operator via OIDC and configure a provider credential profile.
5. Ingest repo state, docs, ADRs, issues, PRs, branch status, prior handoffs, and recent Stigmem facts.
6. Ask Craik to review whether documentation matches implementation state.
7. Craik assembles a case file.
8. An agent performs the review with scoped read/write capabilities.
9. Craik records key tool-use receipts.
10. The agent proposes doc updates and facts.
11. Craik surfaces any contradictions or stale assumptions.
12. The user approves changes.
13. Craik creates a structured handoff, updates memory, and exports the work graph.

MVP components

The MVP ships as a CLI-first runtime with real persisted state and typed schemas. A UI waits until the CLI workflow proves the runtime contracts are correct.

CLI

Full command surface: craik home init · craik connect stigmem · craik login · craik logout · craik whoami · craik auth list · craik auth add · craik auth remove · craik auth test · craik auth status · craik auth approve · craik auth grant · craik project add · craik task create · craik case build · craik run execute · craik handoff show · craik handoff create · craik memory propose · craik memory diff · craik receipts list.

Implementation priority order:

1. craik home init
2. craik project add
3. craik login and craik auth add
4. craik task create
5. craik case build
6. craik run execute
7. craik receipts list
8. craik handoff create
9. craik memory diff

Runtime schemas

Required: task request · project profile · case file · capability grant · capability receipt · handoff · memory proposal · contradiction report · verification result.

Memory backends

In-memory

For tests and demos. Resets between calls.

Local file

SQLite-backed development backend. Persists between CLI calls.

Stigmem

Full product behavior. Reference durable substrate.

Authentication

Required: typed credential profiles in auth-profiles.json · credential source kinds (env-var API key · local-CLI OAuth fallback · vendor-CLI bridge · external secret reference · Stigmem-backed credential reference · marker identity for local no-secret providers) · credential pool with rotation, failover, and per-profile health tracking · OIDC operator login with session persistence · workload identity providers (CI · Kubernetes · generic file tokens · env-var tokens) · RFC 8693 token exchange for short-lived federated provider credentials · credential-scoped receipts · operator-scoped receipts · policy-bound operators and credentials · approval-gated first live credential use.

GitHub adapter

Required reads

• Repository metadata
• Branches
• Issues
• Pull requests
• Changed files
• Comments
• CI status

Initial writes

• Create issue
• Create PR
• Comment on issue or PR

Repository adapter

Required: read file tree · read files · inspect branch status · inspect diffs · run configured validation commands · write patches through an explicit grant.

Handoff writer

Required sections: task summary · completed actions · artifacts created · files changed · commands run · tests run · facts learned · facts invalidated · unresolved questions · risks · next steps · links to receipts.

Case file assembler

Required sections: task objective · policy envelope · relevant facts · relevant docs · relevant ADRs · current branch state · open issues and PRs · recent handoffs · stale-risk notes · contradiction notes · verification expectations.

The case file is the most important MVP artifact.

If a future agent cannot use it to understand why the current task is safe, relevant, and bounded, the MVP is not complete.

MVP build order

1. Define schemas and fixtures.
2. Build local project registry.
3. Build case-file assembly from local repo state.
4. Add local receipt and handoff storage.
5. Add policy envelope enforcement for write boundaries.
6. Add Stigmem memory read/propose/write.
7. Add GitHub read-only context.
8. Add guarded GitHub writes.
9. Add work graph export.
10. Add contradiction reports and memory diff.

Non-goals for MVP

Explicitly out of scope. Listed here so they don't sneak back in.

Full UI

CLI proves the runtime contracts first.

Plugin marketplace

Contracts ship; distribution is later.

Multi-tenant SaaS

Single-operator workflows are the proof point.

Autonomous background execution

Operator-initiated runs only.

Broad provider abstraction

OpenAI + Anthropic + OAI-compatible is the bar.

Complex scheduling

Cron-style schedules are gateway territory, not MVP.

Enterprise policy editor

YAML profiles and CI policy tests are enough.

Federated memory

Single Stigmem node is the MVP target.

MVP success criteria

The MVP succeeds if a new agent can:

1. Understand the current state of a repository faster.
2. Avoid repeating already-resolved investigation.
3. Identify stale documentation.
4. Leave a useful handoff.
5. Create memory updates that future agents can use.

The MVP is evaluated on real project workflows, not toy examples.

For the accepted Stigmem docs reconciliation demo, success also requires:

1. The case file clearly identifies ADR constraints and public/internal documentation boundaries.
2. Stale documentation findings include evidence.
3. Proposed updates avoid immutable ADR edits.
4. Receipts capture meaningful file, shell, GitHub, and memory actions.
5. The handoff is useful to a later agent without relying on chat history.
6. Stigmem receives appropriate fact proposals or fact writes.

What's next

Read nextMVP roadmapThe release-readiness work that must land before v0.1 ships.ReadFeaturesPer-feature acceptance criteria that compose into the MVP.ReadImplementation planThe buildable sequence under the chosen stack.