[Issacboy123]

Summary

When evolution activates a harness revision, regular root sessions automatically adopt the workspace-selected revision at the next safe boundary: session construction or resumption, idle prompt admission, a successful idle reload, or successful manual compaction with no queued continuation. Users do not need to select it manually. Already admitted or queued work remains pinned to its existing revision.

This PR depends on #259.

Reasoning

Automatic activation must update a session only between units of work, never while one is admitted, running, or queued. Reusing the existing activation path keeps evolved memory, skills, system prompt, and subagent state in sync. Reload and compaction refresh only when safe; a post-commit compaction refresh failure is reported without undoing the completed compaction.

Changes

• Reconciled the selected harness before regular root-session construction, with built-in-harness fallback for selection-read failures and exclusions for fixed or explicitly pinned sessions.
• Reused one reconciliation path for idle prompt admission, idle reload, and manual compaction without a queued continuation.
• Rejected reload before mutation while session work, compaction, bash commands, or harness switching is active.
• Reported post-commit manual-compaction refresh failures through the existing compaction error field without rolling back the completed compaction.
• Updated harness-evolution and evolved-skills documentation, the coding-agent changelog, and focused lifecycle coverage.

Testing

• node ../../node_modules/vitest/dist/cli.js --run test/suite/agent-session-harness-version.test.ts
• node ../../node_modules/vitest/dist/cli.js --run test/suite/agent-session-runtime.test.ts
• node ../../node_modules/vitest/dist/cli.js --run test/suite/agent-session-compaction.test.ts
• npm run check

[Pepps233]

Once an evolution finishes, the system prompt is changed; changing the system prompt invalidates cached input.

Prefix caching can reuse only content before the first changed token:

• An unchanged opening portion of the system prompt may still hit.
• The changed memory/skill section and everything after it, including unchanged conversation history, cannot reuse the old prefix cache.

A good rule of thumb is to keep fixed, static information on the top of the cache while keeping dynamic information on the bottom of the cache. Since evolution changes system prompts, it'll invalidate all of the later cached inputs and thus increase cost. Our goal is to increase input cache hit % as much as possible.

Here's my suggestion: once evolution finishes, don't switch to the new harness version immediately. Instead, switch to the new harness version after a compaction takes place or if the user uses /clear in the same project directory. This is because compaction will rebuild the entire conversation history, and the input cache will be invalidated anyway, so you can freely modify the system prompt and just attach the compacted history right below it. Similar idea with clear, since it is clearing all previously stored input cache for the session, you can just freely modify the system prompt as it will not affect later cached inputs.

Once an evolution finishes, let the user know that it'll automatically update once context compacts or manually update through using /clear.

Let me know if you have any questions.