Musketeer v0.3.0: Now SMALL-Native

Musketeer v0.3.0 is released.

This is not a feature release. It is an architectural transition.

Musketeer is now fully SMALL-native. SMALL Protocol owns canonical workspace state. Musketeer owns trio execution artifacts. The boundary between them is explicit, enforced, and documented.

What changed

Before v0.3.0, Musketeer defined its own versions of intent, constraints, plan, progress, and handoff. Those names overlapped with SMALL Protocol's canonical artifact set. The schemas were similar but different. The responsibilities were adjacent but not separated.

That created real problems:

  • Same artifact names, different schemas
  • Ambiguous ownership of replay identity
  • Grep confusion across repositories
  • Agent misinterpretation of schema shape
  • Documentation that required caveats to explain the overlap

The fix was architectural, not editorial.

The new model

Musketeer v0.3.0 introduces a clean two-namespace workspace:

.small/ contains canonical state owned by SMALL Protocol:

  • workspace.small.yml
  • intent.small.yml
  • constraints.small.yml
  • plan.small.yml
  • progress.small.yml
  • handoff.small.yml

.musketeer/ contains execution-layer state owned by Musketeer:

  • musketeer.yml (config)
  • packets/ (role packets)
  • verdicts/ (examiner and auditor verdicts)
  • runs/ (execution logs and run metadata)

Musketeer reads from .small/ but never writes to it. All Musketeer-generated artifacts land in .musketeer/.

Why this matters

SMALL Protocol positions itself as a durable state protocol. It governs state, not execution. That makes Musketeer a natural execution-layer complement rather than a competing protocol.

The relationship is now explicit:

  • SMALL governs canonical project state
  • Musketeer executes originator, examiner, and executor workflows against that state
  • musketeer-bridge exposes the integration layer

No more "compatible with SMALL." No more "optional SMALL support." No more "same concepts, different schemas."

One control plane. One execution layer. One story.

What shipped

The migration was implemented in six phases across three repositories:

  1. Architecture declaration and drift freeze
  2. SMALL workspace detection and Musketeer namespace creation
  3. Read-path convergence: all control-plane reads from .small/
  4. Write-path convergence: all Musketeer writes to .musketeer/ with regression guards
  5. Migration tooling: musketeer migrate with archive-first conversion
  6. Documentation sweep across CLI, bridge, and docs site

Verdict separation

The first concrete boundary fix was moving verdict output out of handoff.yml and into its own Musketeer-namespaced artifact at .musketeer/verdicts/REPLAY_ID.verdict.yml. Verdicts are now first-class Musketeer artifacts with their own schema:

kind: musketeer_verdict
musketeer_version: "0.3.0"
replay_id: abc123
status: approve
gate: auditor
reason: "constraints met, artifacts verified"

Execution logging

Progress tracking split cleanly. SMALL owns canonical progress in .small/progress.small.yml. Musketeer writes its own execution log to .musketeer/runs/REPLAY_ID/execution-log.yml. No more shadow writes to the same file with different schemas.

Migration tooling

musketeer migrate converts legacy workspaces to the SMALL-native model:

  • Archives the entire legacy artifact tree before any conversion
  • Maps canonical state into .small/ artifacts
  • Extracts verdicts into .musketeer/verdicts/
  • Reports ambiguous fields that require manual review
  • Supports --dry-run for planning without side effects
  • Verifies the workspace detects as SMALL-native after migration

No silent lossy conversion. Archive first. Report everything.

The operational result

After v0.3.0, Musketeer can explain itself in one sentence without caveats:

Musketeer is the trio execution harness for SMALL-governed workspaces.

SMALL defines canonical execution state. Musketeer runs role-separated originator, examiner, and executor workflows against that state, adding packets, verdicts, and execution receipts without redefining the base contract.

That is the clean version.

What is next

Musketeer v0.3.0 establishes the architectural foundation. The next priorities are:

  • Bridge integration hardening for real runtime environments
  • Adapter development for model-specific originator, examiner, and executor seats
  • Deeper SMALL CLI interop for workspace bootstrapping
  • Community feedback on the migration path

The hard part was getting the boundary right. Now the work is building on top of it.

Start here

Musketeer v0.3.0 is released. The architecture is clean. The migration path exists. The docs tell the same story as the code.