# Clavue Autonomous Development Mode - 2026-05-01

## User Need

Modern frontier models such as GPT-5.5 can often choose the best implementation path without repeated human confirmation. For P0-P3 bug fixing, TODO execution, and upgrade work, the user wants Clavue to move like a senior development tool:

- read the codebase,
- choose a reasonable implementation path,
- edit files,
- run focused verification,
- continue through TODOs,
- recover from ordinary failures,
- ask only when there is a real safety, product, credential, or destructive-action boundary,
- leave final inspection and release decisions to the human.

## Product Decision

Add an explicit opt-in high-autonomy lane:

```text
/permissions autonomous
```

Users can also run `/permissions` and choose `Autonomous development` from the picker. `/autonomous` is a direct shortcut for the same preset.

This is not the default for all users. It is a trusted-workspace development preset for users who want Clavue to proceed proactively.

## Behavior Contract

When autonomous development mode is active, Clavue should:

- Treat broad fix/upgrade/TODO/P0-P3 prompts as execute-now prompts unless the user explicitly asks for planning only.
- Choose the best reasonable implementation path without asking the user to pick between routine options.
- Use direct repo tools, edits, tests, and diagnostics before asking follow-up questions.
- Continue from existing task boards, plans, and prior verification state.
- Run focused tests after changes and broader gates when release-relevant.
- Summarize decisions and evidence after the work, not before every step.

Clavue should still ask for:

- publishing,
- package release,
- pushing to remotes,
- destructive filesystem actions,
- infrastructure changes,
- credential entry,
- outside-workspace access,
- ambiguous product decisions with irreversible consequences.

## Implementation

The preset is implemented through the existing permission engine, not by bypassing the engine.

Key properties:

- Uses `bypassPermissions` as the default mode where the existing runtime allows it.
- Keeps explicit ask rules for publish, push, destructive, and infrastructure actions.
- Reuses the existing safety checks that are bypass-immune.
- Does not add `Bash(*)`, `PowerShell(*)`, `Agent(*)`, or `dontAsk`.
- Preserves managed-policy blocking.
- Reports both missing allow rules and missing ask boundaries in `/permissions autonomous-status`.

Related deployment/release option: `permissions.defaultMode = "trustedOps"` is the conservative trusted-operator mode for builds, packaging, releases, deployments, and ops. It auto-approves file edits like `acceptEdits`, but Bash and PowerShell commands still require explicit confirmation. Migrate legacy `"dontAsk"` settings to `"trustedOps"`; `dontAsk` is deprecated and is no longer activated from CLI or settings.

Primary files:

- `src/utils/permissions/zeroConfigPreset.ts`
- `src/commands/permissions/permissions.tsx`
- `src/commands/permissions/index.ts`
- `src/commands/autonomous/index.ts`
- `src/utils/permissions/autonomousRecommendation.ts`
- `src/utils/suggestions/commandSuggestions.ts`
- `tests/legacy-ccjk-command-discovery.test.mjs`
- `tests/permission-authorization-flow.test.mjs`
- `tests/autonomous-interaction.test.mjs`

## Recommended Development Policy

For trusted local development:

1. Run `/permissions autonomous`.
2. Ask Clavue to complete a concrete TODO range or P0-P3 repair set.
3. Let Clavue pick implementation details unless a decision changes product semantics.
4. Require focused verification before completion.
5. Require human final review before release, push, publish, or destructive cleanup.

## Version Upgrade Logic

Use the changelog style from modern AI coding tools: every release should name the user-visible capability, the reliability boundary, and the developer-facing verification. For Clavue autonomy, the sequence should be:

- `v8.9.x`: opt-in autonomous development permissions, explicit safety boundaries, direct status command.
- `v8.10.x`: autonomy profile in settings, status-line visibility, prompt policy that treats P0-P3/TODO prompts as execute-now by default.
- `v8.11.x`: task-board continuation engine, automatic next-TODO selection, stale in-progress repair.
- `v8.12.x`: evaluation harness for permission friction, continuation stalls, and release-boundary correctness.
- `v9.0.x`: stable high-autonomy developer mode with documented guarantees and release-grade regression gates.

Each release note should contain:

- Added: new user capability.
- Changed: interaction or permission behavior.
- Fixed: concrete stall, conflict, or false prompt.
- Safety: boundaries that still require approval.
- Verification: focused commands and full gates used.

## TODO List

- P0: Verify ask-boundary precedence for `git push`, `git reset --hard`, `npm publish`, and `rm -rf` under bypass mode.
- P0: Ensure autonomous status fails closed when ask boundaries are missing.
- P1: Add `/permissions autonomous-status` to help and onboarding surfaces.
- P1: Add `/permissions` picker telemetry for selected mode, cancelled mode, and rules fallback.
- P1: Add an `autonomy.profile` setting separate from permission mode.
- P1: Teach the system prompt/router that TODO/P0-P3 repair prompts should execute without asking routine strategy questions.
- P2: Add task-board invariants for autonomous continuation and stale in-progress cleanup.
- P2: Add friction metrics: prompts per completed local edit/test loop, unnecessary clarification rate, and blocked-boundary accuracy.
- P2: Add release-note template checks so autonomy changes always document safety and verification.
- P3: Add UI affordance showing current autonomy profile and next human boundary.
- P3: Add migration guidance from zero-config setup to autonomous development mode.
- Done: `/permissions` now opens a mode picker instead of dropping users directly into rule editing.
- Done: `/permissions <mode>` typeahead can suggest autonomous, autonomous-status, setup, status, and rules.
- Done: `/autonomous` shortcuts to `/permissions autonomous`.
- Done: development-intent and routine local permission prompts can recommend `/permissions autonomous`.

## Conflict Checks

Current conflicts and mitigations:

- `bypassPermissions` can otherwise auto-allow too much. Mitigation: content-specific ask rules are checked before bypass mode and now have direct regression coverage.
- Existing zero-config includes broad Git rules. Mitigation: autonomous ask rules deliberately override routine Git allow rules at push/reset-hard boundaries.
- Broad shell grants would erase safety. Mitigation: preset refuses dangerous classifier permissions and does not add `Bash(*)`, `PowerShell(*)`, `Agent(*)`, or `dontAsk`.
- Managed policy may prevent user permission writes. Mitigation: preset returns a blocked result and does not silently claim activation.
- Status could previously appear complete while ask boundaries were missing. Mitigation: status now checks missing ask rules separately.
- A mode picker could hide low-level rule controls. Mitigation: `View or edit rules` remains in the picker and `/permissions rules` opens the existing rule manager directly.
- Prompt-side autonomy recommendations could be noisy. Mitigation: recommendations are suppressed when `bypassPermissions` is already active and are limited to development-intent or routine local dev/test/build permission contexts.

## Future Upgrade

The next layer should add an `autonomy profile` separate from permission mode:

- `balanced`: current default behavior.
- `developer`: proactive implementation and test loops.
- `release`: proactive verification but conservative publish/push gates.
- `ops`: explicit infrastructure boundaries.

That profile should affect intent routing, plan-mode bias, permission suggestions, task-board continuation, and status-line messaging as one policy.
