# Clavue 9.5+ Platform Roadmap

Date: 2026-05-01

## Target

Clavue should score 9.5+ as an AI development platform by making its core guarantees measurable:

- execution-first coding loop: inspect, edit, run, verify, and deliver from the repo;
- provider control without provider identity drift;
- consistent command reachability across local TUI, headless, remote mode, and Remote Control;
- safe high-autonomy development with explicit release and destructive-action boundaries;
- reproducible source-to-dist shipping;
- offline and live evidence that users can trust before upgrade or release.

## Upgrade Method: Autoresearch Loop

The only acceptable upgrade path is an Autoresearch-style loop: fixed metric, bounded experiment, isolated edit scope, run, keep/discard, log, repeat. Clavue should not upgrade by opinion or one-off feature enthusiasm. Every platform improvement must produce evidence against a named axis and then be kept or discarded.

The first platform loop is exposed as:

```bash
npm run autoresearch:platform -- --dry-run
npm run autoresearch:platform
```

It tracks five core axes:

- `memory-system`: recall precision, stale-memory suppression, and scoped memory usefulness.
- `tool-matching`: when Clavue chooses shell, search, edit, test, browser, MCP, subagents, or planning.
- `context-system`: compaction, continuation, active task state, and project-rule injection.
- `gpt-5-routing`: matching GPT-5.x family/model choices to task type, provider mode, cost, and latency.
- `gpt-5-capability-adaptation`: adapting prompts, tool schemas, effort, images, and Responses behavior to GPT-5.x capabilities.

Default evidence paths:

- `docs/evals/autoresearch/platform-autoresearch-report.json`
- `docs/evals/autoresearch/results.tsv`

The long-term target is a self-improving Clavue loop where each release is the accumulated result of many measured keep/discard experiments across these axes.

## Current Score

Current workspace baseline after the Remote Control `/init` fix: 8.4/10.

Strengths:

- `npm run check` passes the full repo gate.
- `dist/` verification, source rebuild verification, source purity, and release packaging gates are active.
- `/init`, provider routing, `/mao`, permissions/autonomy, default-path smoke, provider matrix, and world-class eval evidence all have focused tests.
- Core product direction is aligned with an execution-first development platform.

Remaining blockers to 9.5+:

- Command reachability was implicit and scattered across docs, help, headless support, remote mode, and bridge allowlists.
- Most world-class evidence is still offline-contract evidence; live route, fresh install, and upgrade evidence must become routine.
- Some primary surfaces are still local-TUI only because they render Ink UI; Remote Control needs text/JSON fallbacks for the highest-value flows.
- Autonomy has good safety direction, but release-grade evidence must prove it does not cross push, publish, destructive, or infrastructure boundaries.

## Scoring Rubric

| Area | Weight | 9.5+ Bar |
|---|---:|---|
| Core coding loop | 20 | Read/edit/test/verify/default-path smoke passes locally and from packaged runtime. |
| Command/platform contract | 15 | Every primary command declares intended reachability for local TUI, headless, remote mode, and Remote Control. Release blocks undocumented drift. |
| Provider/runtime quality | 15 | Native, compatible, degraded, chat-only, and blocked routes are classified with live validation evidence and clear fallback behavior. |
| Release integrity | 15 | Source, dist, npm pack, standalone tarball, fresh install, and version metadata are reproducible and checked before release. |
| Autonomy safety | 15 | High-autonomy mode accelerates normal development while proving release, publish, push, destructive, and infrastructure actions remain gated. |
| Continuity and recovery | 10 | Resume, compaction, task state, `/mao`, `/team`, and `/retro` preserve real work state without stale or inflated claims. |
| Product focus | 10 | New features reinforce execution-first development and do not become detached chat, spectacle, or provider-brand drift. |

## P0: Platform Contract Gate

Goal: prevent another primary command from being documented but unreachable.

Required work:

- Keep `BUILTIN_COMMAND_CLIENT_SURFACES` as the source of truth for built-in command reachability.
- Block releases when a `primary` command lacks explicit client-surface coverage.
- Derive bridge-safe built-ins from the reachability contract, not from an independent mental model.
- Add focused tests any time a command changes type, public classification, headless support, or Remote Control behavior.

Exit evidence:

- `node --test tests/slash-command-surfaces.test.mjs tests/print-bridge-remote-control.test.mjs`
- `npm run verify:dist`
- `npm run check`

## P1: Live Evidence Upgrade

Goal: move from offline-contract confidence to real install/provider confidence.

Required work:

- Add live-but-safe release evidence mode for fresh `npx -y clavue@<version> --version`.
- Record live provider validation for at least one Anthropic-native and one OpenAI-compatible Responses route.
- Record Remote Control command advertisement/execution evidence for bridge-safe primary commands.
- Store release evidence in `docs/evals/world-class/` with explicit keep/discard decision rows.

Exit evidence:

- `npm run eval:world-class -- --mode live --evidence-mode local-live`
- Fresh install version output for the release candidate.
- Provider matrix with live-ready rows for supported routes.

## P2: Remote Control Parity For Highest-Value Flows

Goal: make mobile/web control useful for real development without forcing Ink UI into remote clients.

Required work:

- Add text or JSON fallbacks for high-value local-TUI commands where safe: `/status`, `/provider doctor`, `/tasks`, and selected `/team` checks.
- Keep `/model`, `/permissions`, and other picker-heavy flows blocked until they have explicit non-UI fallbacks.
- Make Remote Control errors explain the unsupported surface and the local command to use.

Exit evidence:

- Bridge system/init advertises only executable commands.
- Remote inbound tests cover both successful bridge-safe commands and intentionally blocked local-TUI commands.

## P3: Autonomy Safety Evidence

Goal: make high-autonomy development a trusted accelerator, not a risk multiplier.

Required work:

- Add regression scenarios for routine edit/test/build work under autonomous mode.
- Add negative scenarios for push, publish, release tagging, destructive cleanup, credential exposure, and infrastructure mutation.
- Ensure recommendations for `/permissions autonomous` appear only in trusted local development contexts.

Exit evidence:

- Focused autonomy tests and full `npm run check`.
- Release report section naming autonomy boundary evidence.

## P4: Product Focus Guardrail

Goal: keep Clavue from drifting into feature accumulation that weakens the platform.

Required work:

- Every new primary surface must state which core loop it improves: inspect, edit, run, verify, deliver, recover, route, or coordinate.
- Features that only add spectacle, detached chat, provider branding, or duplicated UI should remain secondary, plugin, or out of tree.
- Roadmap reviews should score against the rubric above before release.

Exit evidence:

- README and release report name user-visible capability, reliability boundary, and verification.
- No public docs advertise internal, hidden, or unreachable commands.
