v0.8.67 Setup support: runtime posture card with constitution boundary

[Hmbown]

Constitution boundary update (2026-06-29)

This issue owns the runtime security posture that the constitution creator must not silently change.

The trust/approval/sandbox step should expose a small explicit posture selector such as ask-first / normal agent / high-trust local, then show the actual config effects: default_mode, approval_policy, sandbox/network/trust behavior, and any warnings.

The constitution creator (#3793) may collect an autonomy preference and may recommend one of these runtime postures, but applying the posture must be a separate explicit action owned here. This prevents a user-global constitution from becoming a hidden permissions file.

Acceptance additions:

• A constitution autonomy preference does not directly mutate runtime mode/approval/sandbox/trust.
• Applying a runtime posture from setup shows a visible config diff and confirmation.
• Doctor/setup report can show both: constitution preference and effective runtime posture, side by side.

---

Product shape

This step turns "how much can CodeWhale do on its own?" into a small, legible choice — like a difficulty/mode selector, not a policy document. The user picks one of a few named postures (ask-first / normal agent / high-trust local) and sees, in plain language, what each allows and protects. Advanced users can drill into approval policy, sandbox, network, and privacy individually; first-run users take the recommended preset and move on. The effective policy — and where it comes from (default / user / project / CLI / env) — is always visible.

Non-goals

• Not inventing a new policy engine; reuse the existing workspace-trust, approval-policy, sandbox, and network-policy runtime.
• Not forcing power users through a simplified preset — advanced controls remain reachable.
• Not changing project-level overlay precedence semantics; only surfacing and warning about overrides.

Safe fallback

• Skipping the step leaves current/default trust + approval + sandbox intact (status inherited/optional).
• A risky combination (e.g. high-trust + untrusted workspace + open network) surfaces a clear warning but remains a permitted explicit choice; setup never silently overrides a deliberate user pick.
• Summaries redact any secret-bearing policy detail.

Problem

The setup wizard should help users understand and configure safety boundaries before they start running agents. Workspace trust, approval policy, sandbox behavior, network access, telemetry/privacy, hooks, and secret handling are currently scattered across docs, config, onboarding, and runtime prompts.

Scope

• Reuse or replace the current workspace trust onboarding screen with a richer setup step.
• Explain and configure approval policy, sandbox mode, workspace trust, network policy, and optional telemetry/privacy settings where supported.
• Surface risky configuration clearly without fearmongering or hiding the escape hatches power users need.
• Show the current effective policy and where it comes from: defaults, user config, project config, CLI flags, or environment.
• Ensure setup summaries redact secrets and avoid logging sensitive policy details unnecessarily.
• Add tests for trust choice, approval policy choice, sandbox choice, skipped setup, project override warning, and redacted summary behavior.

Definition of done

• Users can see and configure the safety posture before first real agent work.
• Existing users can rerun setup to inspect current trust/approval/sandbox/network state.
• Policy changes go through comment-preserving config persistence or explicitly require a restart when needed.
• Docs and setup copy agree with actual runtime behavior.

Localization / UX

• Posture names, descriptions, warnings, and the "effective policy from: <source>" line use localization IDs; non-English coverage or documented fallback is required (precedent: v0.8.68: Localize Hotbar setup wizard chrome and add non-English coverage #3759).

Doctor / docs expectations

• codewhale doctor reports the effective trust/approval/sandbox/network posture and its source, matching this step's output.
• Docs (v0.8.67 Docs: constitution-first setup, localization, screenshots, and copy #3412) and setup copy agree with actual runtime behavior.

Acceptance criteria

• Users can choose a safety posture before first real agent work; advanced controls are reachable but not forced.
• Effective policy and its source (default/user/project/CLI/env) is displayed.
• Existing users can rerun /setup to inspect current trust/approval/sandbox/network state.
• Policy changes persist through comment-preserving config writes (v0.8.67 Setup: config persistence, migration, secret handling, and rollback #3410) or clearly require a restart.
• A risky-but-deliberate combination warns without silently overriding.
• Summaries redact secrets; tests cover trust choice, approval policy, sandbox, skipped setup, project-override warning, and redaction.

Related

• Epic: v0.8.67 EPIC: Constitution-first setup wizard and user-global constitution #3402 · State model: v0.8.67 Setup: audit current setup/onboarding surfaces and define the unified setup state model #3403 · Wizard shell: v0.8.67 Setup: implement the setup wizard shell, navigation, resume, and /setup entry point #3404 · Persistence: v0.8.67 Setup: config persistence, migration, secret handling, and rollback #3410 · Verification: v0.8.67 Setup: verification, doctor integration, setup report, and release QA matrix #3411 · Docs: v0.8.67 Docs: constitution-first setup, localization, screenshots, and copy #3412
• Permission profiles work: v0.8.61: Add first-class permission profiles and nonblocking execution defaults #3211