The Claude policy layer.

Claude attempts too much in one context, then leaves half-built work when the window ends. Each round does exactly one feature:

• Require a failing feature flag before implementation starts
• Baseline end-to-end proof of the current state
• Implementation, then proof again before advancing
• No second feature starts until the first is controller-accepted

A planned five-agent run reportedly grew to 361+ background agents. Recursion is a first-class hazard:

• Child agents cannot spawn children — depth 1 by default
• Hard caps on total and concurrent agents
• Budgets are cumulative across parent and children: turns, tokens, spend, wall time, tool calls, repair rounds
• A subagent is never a fresh allowance

Claude improves beyond the ask. After plan approval, every new file, dependency, feature, or requirement must map to a frozen requirement or consume a visible scope-change budget. A scope checksum detects drift; commentary has a separate output ceiling so verbosity can't spend the build budget.

Claude is trained to ask when ambiguity changes outcomes, but free-text questions raise round-trip and parsing cost. At most two consequential questions per decision point, with fixed options plus a recommendation; otherwise log the assumption and proceed.

Prompt rules are not enough for rare risky actions. Pre-tool hooks, network and file boundaries, and approval classes must execute in code — not in the prompt. Default-deny; every allowed action is explicitly granted.

The shell sandbox does not by itself bound the Read tool. Add explicit filesystem denies, credential-path denies, environment filtering, and a strict network allowlist. Reading secrets is an action, not a passive default.

Prefer a clean next session plus git, progress file, hashes, and feature JSON over repeated compaction — compaction does not reliably preserve instructions. The long-running pattern is initializer plus incremental coding sessions.

Don't fight context limits with prompt tricks alone. Use the platform's own answers:

• Prompt caching for stable instruction blocks
• Tool-result clearing / context editing to shed bulk without losing directives
• The memory tool for durable state across compactions

Effort and thinking budgets are a metered resource alongside tokens, turns, and spend. Cap extended thinking per round; a run that needs unbounded deliberation is a run whose scope wasn't actually frozen.

Use cheaper models for leaf workers and the stronger model for planning and review. Model tiering is a major budget lever — and it keeps the judgment layer economically separate from the build layer.

Skills and CLAUDE.md files disclose instructions progressively as tools and directories are touched, instead of loading one giant prompt into every context. The profile's rules live in the right layer: code for enforcement, skills for procedure, prompt for intent.

Models sometimes edit or special-case tests to pass. Frozen checks cover part of this; the profile makes it explicit:

• Test directories are read-only to the builder
• Any test change needs a diff audit and a change record
• A test edited to make a failing build pass is itself a failure

If the reviewer is also Claude, correlated blind spots are possible. For key checks, use a different model or deterministic-only gates (hash comparisons, schema validation, budget arithmetic) that don't depend on any model's judgment at all.

Profiles drift as models update — Opus 4.6 behavior is not 5.x behavior. Pin the model version per profile release and run regression evals on profile updates. A profile is versioned against the model it was validated on.

The profile covers the API layer too: rate-limit handling with backoff, bounded retries, failure recovery that preserves partial evidence, and tracing/observability so a run can be reconstructed after the fact. An unobservable run is an unverifiable run.