Closes Tarquinen#560 ## Problem Compaction can preserve an earlier user approval as if it were the current instruction. The reported case: a question tool asked permission to write a spec, the user answered positively, and after a compaction the summary still carried that approval. A later turn read it, concluded the user had authorised writing the spec, and a **PLAN-mode agent started modifying files** even though the user had since said not to execute. The mode restriction is enforced by the host, not by the model, so a model that believes it was told "go ahead" will act on that belief. There is no second line of defence in front of it. The prompts had `USER INTENT FIDELITY`, which asks the summariser to preserve intent faithfully. That is the wrong instruction for an approval: preserving it faithfully and preserving it *as an active instruction* are different things, and nothing told the model which one to do. ## Change A `TEMPORAL STATUS OF USER MESSAGES` section in both compress prompts (`compress-range` and `compress-message`, in the xml and compact variants): - a summary is history; everything inside it has already happened - approvals, permissions and confirmations must be recorded as a past event, never as a live instruction - write them in past tense with their position in the timeline, and say that the user has not restated the approval since - **never place an approval at the end of a summary**, where it reads as the most recent thing the user said, and never end a summary on an imperative sentence taken from a user message - when a later instruction narrows, overrides or cancels an approval, state both and make the later one operative - an unresolved question stays described as unresolved The two prompts differ in scope: range mode compresses a span and therefore carries the placement rules, while message mode compresses individual messages and only carries the past-tense and precedence rules. ## What this does not do It does not enforce anything. A summary is produced by a model, and a model can still get it wrong. What changes is that the prompt no longer invites the failure and the common cases - an approval at the tail of a summary, a cancelled approval still reading as live - are spelled out. The durable fix is host-side, where mode restrictions are actually enforced, so this is the part a plugin can carry. ## Verification `tests/prompt-approval-status.test.ts`, six cases, all four prompt variants: - every prompt states a summary is history - every prompt forbids replaying an approval as a live instruction - range mode forbids ending a summary on an approval - range mode requires the later instruction to win - unresolved decisions stay unresolved - the existing id and placeholder contracts the tool schema depends on are asserted unchanged All six fail on the current implementation. Full suite 132 passing, `tsc --noEmit` clean, `tsup` builds, `prettier --check` clean.

Commits

Commits on Oct 1, 2026

fix(prompts): a summary is history, not a live instruction