Roadmap

Note

Project policy: draft. This roadmap is the project’s plan of record. It changes through pull requests, and larger changes go through the RFC process.

How to read this roadmap

• Milestones are defined by capability, not by date. A milestone is finished when its exit criteria are met.
• Each milestone lists what is out of scope, so that “not yet” is an explicit decision.
• Shipping a milestone includes updating the documentation: every page for that milestone changes its banner from “Design intent: not implemented” to the implemented state.
• Versions before 1.0 may contain breaking changes, as described in Versioning and stability.

Overview

M0: Specification

Goal. Settle the design before writing product code.

Scope.

• The documentation set in docs/, including every specification listed in About the specifications.
• JSON Schemas and test vectors that encode the use cases.
• The Cedar spike required by ADR-0014, done: it reproduced every test vector, so ADR-0014 is accepted.

Exit criteria.

• The action request, decision, evaluation, policy model, and adapter contract specifications are accepted. Done on 2026-10-12.
• The threat model has been reviewed by at least one person outside the project. Open: this is the last M0 criterion, and it needs a reviewer who is not the author.
• The core golden use cases have test vectors. The original eight-case corpus has grown to 26 cases, each decidable from its own inputs and checked in continuous integration.
• ADR-0014 is accepted. Done on 2026-10-12.

v0.1: Gate

Goal. A developer using Claude Code on Linux or macOS can enforce a policy and see a record of every decision.

Scope.

• Claude Code hook adapter, running without a daemon.
• Identity at the asserted level, capability, policy, and the secret_path, outside_workspace, bulk_delete, and opaque_command risk signals.
• Built-in protected resources.
• Commands: shiin init, shiin check, shiin explain, shiin policy validate, shiin hook claude-code, shiin log, and shiin doctor.
• Hash-chained audit log.
• pending expressed through Claude Code’s native permission prompt. This is an interim step, not the approval protocol.
• Signed release binaries with a software bill of materials.

Out of scope. Daemon, approval protocol, grants, tasks, receipts, Windows.

Exit criteria.

• All v0.1 test vectors pass.
• The performance budgets for the daemonless hook path are met on Tier 1 platforms.
• A fault-injection test shows that crashes and timeouts in the hook produce deny.

v0.2: Tasks

Goal. Actions can be bound to the task the developer gave, and the same policy works across three hosts.

Scope.

• Task declarations with the closed constraint set, marked experimental. Done: scope, forbidden action types, allowed hosts, counting limits, ask-for, and expiry.
• Counters for task limits. Done.
• Codex CLI and Cursor hook adapters. Done in source; neither has been tested against a running host, which is the remaining v0.2 work.
• shiin task and shiin policy test. Done.
• Unattended mode for CI. Done in v0.1.

Out of scope. Approval protocol, SQL classification.

Exit criteria.

• Intent-binding test vectors pass for all three hosts.
• The intent-binding evaluation plan in Intent binding has produced its first measurements. Done for the nine-case labelled task corpus; independent real-workload evaluation remains open.

v0.3: Approve

Goal. pending decisions go through a real approval protocol instead of host prompts.

Scope.

• shiind, the per-user daemon.
• Approval protocol v1 with the command-line approver.
• Single-use and scoped grants, and revocation.
• Deny-with-ticket for hosts that cannot wait.

Out of scope. Remote approvers, desktop or editor approvers.

Exit criteria.

• Approval state-machine property tests pass.
• Self-approval through an intercepted channel is shown to be impossible by test.

v0.4: Evidence

Goal. Decisions can be proven and re-examined.

Scope.

• Signed checkpoints and receipts.
• shiin verify and shiin replay, including what-if replay against a different policy.
• Key management and rotation.
• Redaction of sensitive values in audit events.
• cargo-deny enforced in CI, as selected in ADR-0038.

Exit criteria.

• Receipts verify offline on every Tier 1 platform. Unit tests and native key-store lifecycle checks pass on hosted Linux, macOS, and Windows runners; independent review and live operator-environment qualification remain open.
• Replay reproduces every decision in the conformance corpus. Done for the 26-case signed/encrypted corpus through the CLI evaluation routine, including capability, session/task, what-if, and grant regression tests.

v0.5: MCP and SDK

Goal. Shiin mediates MCP traffic and can be embedded in custom agents.

Scope.

• MCP proxy for spec revision 2026-07-28, stdio transport first.
• Local API over the daemon.
• shiin-client, the Rust client library.
• Peer-credential identity (attested-local).
• SQL and migration classifiers. Partial classifier primitives exist in source; host integration remains open.

Exit criteria.

• The MCP proxy passes conformance tests against reference MCP servers.
• A custom agent built with shiin-client passes the adapter conformance suite.

v0.6: Reach

Goal. Shiin works in more environments.

Scope.

• Remote approvers through signed webhooks (ADR-0041 must be decided first).
• Streamable-HTTP MCP transport. Downstream HTTP and HTTPS with a provisioned bearer token have process-fixture coverage; the upstream connection remains stdio, and OAuth token acquisition/refresh and external conformance remain open.
• Shell wrapper for hosts without hooks. shiin exec now has a Unix source implementation; live host routing and platform validation remain open.
• Windows promoted toward Tier 1.
• Additional hosts, each with its hook behavior verified and documented.

v1.0: Stable

Goal. Shiin is dependable enough to build on.

Exit criteria.

• The v1 specifications and the policy language are frozen.
• An independent security audit is complete, and its report is published.
• The conformance suite is published.
• All success criteria in the vision are met.

After 1.0

• Team policy server with signed policy bundles and central evidence.
• Desktop and editor approver applications.
• Language bindings (ADR-0042).

Not planned

These are deliberately not on the roadmap. Proposing any of them requires an RFC.

• Machine-learning or language-model decisions.
• Telemetry or any phone-home behavior.
• Dynamic-library plugins for adapters (ADR-0026).
• Compliance certifications.

Changing the roadmap

Small corrections are ordinary pull requests. Adding, removing, or reordering milestone scope requires an RFC.