v0.3.0 milestone

Status: active architecture milestone; no WRITE capability is authorized.

Immutable production baseline

v0.2.2 is the immutable published READ platform. Its tag, artifacts, public contract, acceptance evidence, and release interpretation must not change.

• Auditor: 41 READ tools, 0 WRITE tools.
• Engineer: 0 tools.
• Active WRITE capabilities: 0.
• WRITE endpoint allow-list entries: 0.
• Production mutation transport reachability: 0.

v0.2.3 is reserved for READ-platform bug fixes and security hotfixes. Feature development targets v0.3.0.

v0.3.0 objective

Make the Tier 1 safety architecture implementation-ready while keeping every mutation path unreachable. A first capability may enter v0.3.0 only after a separate owner approval names its tool, capability, exact endpoint and method, typed field scope, disposable lab, rollback semantics, and acceptance plan.

Architecture sprint deliverables

1. A closed Recovery Contract model with deterministic, domain-separated bindings for capability, endpoint, method, target, fingerprint, intent, snapshot, confirmation, idempotency, rollback version, expiry, and state.
2. A complete state machine with atomic compare-and-set persistence, target reservations, integrity checks, restart reconciliation, and no blind retry.
3. Exact policy primitives whose production instance is empty.
4. Value-free audit event and durable transition metadata.
5. Adversarial/fault tests covering replay, stale state, corruption, crashes, ambiguous outcomes, concurrency, rollback conflicts, and isolation.
6. A complete writable-endpoint risk inventory and first-capability study.
7. A disposable integration-lab plan.

Subsystem review

Subsystem	Baseline weakness/debt	v0.3.0 direction
Capabilities	WRITE enum placeholders exist but are intentionally unsupported	Keep build/profile sets unchanged; future activation requires an exact rule plus profile approval
Tool registration	Empty register_all_write() is safe but has no future manifest	Retain isolation; design a capability-specific registration record only with the approved first tool
Endpoints	WriteEndpoints is empty; broad upstream CRUD routes combine safe and unsafe fields	Keep empty; future rule names one endpoint, method, response, field projection, and API version
Transport	Tier 0 write client lacks typed body/status/outcome semantics	Do not extend until a capability is approved; future executor sends once and distinguishes proven failure from ambiguity
Recovery	Tier 0 OPEN/COMMITTED in-memory model cannot survive crashes	New isolated Tier 1 package supplies digest-bound records, state machine, protected artifacts and atomic durable store
Audit	Tier 0 decorator is value-minimized but not transition-atomic	Tier 1 store records state metadata atomically; separate event model excludes values/messages
OpenAPI	Endpoint existence is not safe-operation evidence	Pin source discovery and compare exact disposable-lab OpenAPI plus behavior before proposal
MCP surface	READ public contract is stable	No Tier 1 import or tool; future schema exposes IDs/digests and typed intent, never authoritative contract state
Tests	Tier 0 happy-path mocks overstate readiness	Add exhaustive state, binding, persistence, corruption, isolation and fault tests before transport work
Package layout	Dormant Tier 0 and future safety logic could become coupled	New pfsense_mcp.tier1 depends inward on pure types and remains absent from bootstrap imports

Candidate recommendation

The preferred first study is a firewall-alias description-only PATCH, not a generic alias update. The fallback study is a system-tunable description-only PATCH. Neither is authorized. See the complete risk matrix.

Owner decisions still required

Resolved since this milestone was first written, kept here only as a correction so this section doesn't misstate already-closed decisions: the protected-artifact encryption/key-provider design (ADR-009/010, implemented), the confirmation and reconciliation authorities (ADR-012/013, implemented), rate/blast-radius containment (ADR-015, mechanism implemented; numeric defaults remain provisional pending lab evidence), the sealed executor interface (ADR-014, implemented), and disposable-lab research authorization for the alias candidate specifically (ADR-016, accepted — research only, not production activation).

Still genuinely open:

• The anti-rollback anchor's concrete backend (TPM2 vs. remote witness) — ADR-011, pending confirmation of production host TPM availability. The backend-agnostic protocol and store wiring are already implemented.
• Select or reject the first candidate and its exact field projection — ADR-016 authorizes researching the alias candidate in a disposable lab, not selecting or implementing it.
• Approve an upstream least-privilege identity and disposable lab environment for a live lab run (the offline harness itself is implemented and tested; running it against a real VM is separately gated).
• Approve the capability, endpoint/method allow-list entry, tool schema, production construction, and live acceptance as separate gates — none of the above authorizes any of these.

Proposed v0.3.0 acceptance criteria

• The v0.2.2 READ contract remains unchanged and all READ gates pass.
• Auditor remains 41 READ / 0 WRITE until a separately approved activation.
• Engineer remains 0 until activation approval.
• Every Recovery Contract binding and legal/illegal transition is tested.
• Store corruption, stale versions, duplicate operations, target conflicts, restart states, and ambiguous outcomes fail closed without transport calls.
• Protected values never enter logs, errors, schemas, fixtures, reports, or distribution artifacts.
• A selected capability passes disposable-lab prepare/execute/verify/rollback and crash reconciliation before any production profile can expose it.