Finish long-running agent parity

PLAN.md

@@ -23,106 +23,36 @@ execution targets one self-contained Mac.
   continuation, malformed DSML recovery, transient prefix-aware KV reuse,
   disconnect/queue cancellation, and shared model scheduling. The full
   automated C/Rust differential corpus remains open.
-- Local sessions persist user, assistant, reasoning, and tool roles. The agent
-  executes the complete `ds4_agent.c` starting tool set and reinjects the same
-  model-specific tool contract when sessions are opened or continued.
-- The remaining baseline gaps are long-running agent behavior and tool safety.
-  SSD streaming, speculative decoding, steering, GLM 5.2 execution, and
-  DeepSeek V4 Pro execution are not implemented in the Rust executor. Some
-  related catalog, validation, and preference plumbing already exists but must
-  not be treated as runtime support.
+- Local sessions now match the long-running `ds4_agent.c` baseline: the full
+  starting tool set, unlimited tool rounds, queued user guidance between tool
+  rounds, session date/time context, periodic tool-contract reminders,
+  cooperative Stop, and explicit activity/failure states are implemented.
+- Context compaction uses the reference soft and exact token-counted hard
+  triggers, private live-model summaries, bounded summary and tool-result
+  retries, a recent verbatim tail, running-job observations, and compatible KV
+  checkpoints. Every summary is a visible durable history marker carrying its
+  tail boundary; the full chat remains scrollable, while missing or
+  incompatible KV state rebuilds from the last marker, its tail, and later
+  messages. Manual compact is available after new chat following the latest
+  marker, alongside a checkpoint-discard/rebuild action.
+- Focused coverage exercises triggers, summary bounds and sanitizing, tail
+  selection, queued guidance, checkpoint identity, running jobs, durable
+  compaction markers, relaunch, and continued tool work after rebuild.
+- The next baseline gap is tool hardening and safety. SSD streaming,
+  speculative decoding, steering, GLM 5.2 execution, and DeepSeek V4 Pro
+  execution are not implemented in the Rust executor. Related catalog,
+  validation, and preference plumbing must not be treated as runtime support.
 
 ## Delivery order
 
-1. **Next:** long-running agent stability and remaining `ds4_agent.c` parity.
-2. Tool hardening, approvals, and productive tool presentation.
-3. Remaining DS4 execution technology, starting with SSD streaming, then
+1. **Next:** tool hardening, approvals, and productive tool presentation.
+2. Remaining DS4 execution technology, starting with SSD streaming, then
    speculative decoding and the other Metal/runtime parity work.
-4. Additional model execution: GLM 5.2 and DeepSeek V4 Pro.
-5. Product completion, exhaustive parity verification, and distribution.
-6. Optional extensions: Dev Brain and A2UI.
+3. Additional model execution: GLM 5.2 and DeepSeek V4 Pro.
+4. Product completion, exhaustive parity verification, and distribution.
+5. Optional extensions: Dev Brain and A2UI.
 
-## 1. Next — long-running agent stability and `ds4_agent.c` parity
-
-Goal: a local agent session must be able to run long read/edit/test loops,
-cross the context limit repeatedly, survive interruption or relaunch, and
-continue with the same durable task state as `ds4-agent`.
-
-### Context compaction
-
-- Port the reference soft trigger: compact before a user turn or tool
-  continuation at 85% context use, or when at most 8192 tokens remain, with the
-  free-token threshold capped to one eighth of small contexts.
-- Port the hard trigger: before appending a tool result that would leave
-  insufficient answer room, compact once and retry. If it still does not fit,
-  return a bounded tool error that tells the model to request less output.
-- Use the live model to generate an internal durable task-state summary. The
-  prompt and generated summary are private compaction work, never ordinary
-  user/assistant messages, and may not execute tools or retain thinking/DSML
-  control markup.
-- Preserve goals, constraints, files touched, commands and important results,
-  decisions, known failures, and next steps. Prefer reloadable paths, ranges,
-  and commands over copying bulky data into the summary.
-- Rebuild the model context exactly as the reference does: current system/tool
-  contract, durable summary, then a recent verbatim tail. Keep up to 10% of the
-  configured context as the tail, capped at 50000 tokens, and align it to a
-  user-turn boundary when possible.
-- Generate at most the reference summary budget, stop at model control or tool
-  markers, and never let the private compaction exchange become the reusable
-  session prefix.
-
-### Durable transition and recovery
-
-- Treat transcript replacement and the new KV checkpoint as one logical
-  transition. Persist the compacted semantic transcript and checkpoint
-  metadata only after the rebuilt prefix is valid.
-- On cancellation, summary failure, prefill failure, or application exit, keep
-  the previous durable transcript, invalidate any KV state contaminated by the
-  private compaction prompt, and make the next turn rebuild safely.
-- Reopen a compacted session with the same summary and recent verbatim turns.
-  If its checkpoint is absent or incompatible, rebuild it from persisted
-  messages without changing the visible conversation.
-- Preserve relevant live tool state across compaction. In particular, append a
-  compact observation for running shell jobs so the model can still inspect or
-  stop them after the context rebuild.
-- Add a user-visible action equivalent to `/compact`, plus the reference
-  strip/rebuild behavior: discard a session KV payload without discarding its
-  transcript, then rebuild on the next use.
-- Bind checkpoint compatibility to the model identity, quantization, context,
-  rendered transcript, and payload ABI. A model/configuration change must
-  rebuild rather than reuse an invalid prefix.
-
-### Long-turn behavior
-
-- Accept user input while an assistant/tool loop is active. Queue it visibly
-  and inject it after the current tool result, before the next assistant
-  continuation, matching `ds4_agent.c` instead of starting a competing turn.
-- Preserve the reference rule that there is no arbitrary maximum tool-round
-  count. Completion, Stop, context pressure, or a real error ends the loop.
-- Match the reference date/time context injection and periodic system/tool
-  prompt reminder so long or reopened sessions do not drift away from the tool
-  contract.
-- Keep Stop cooperative across summarization, compacted-prefix prefill,
-  generation, and active tool work. A stop must always leave a transcript that
-  can be reopened.
-
-### Presentation and verification
-
-- Show explicit `Compacting`, rebuilding/prefill, queued-input, stopped, and
-  failed states without blocking the Iced event loop. Keep the compacted
-  summary inspectable without presenting the private prompt as user history.
-- Add focused tests for soft and hard triggers, tail selection, tool-result
-  retry, cancellation rollback, checkpoint invalidation, queued input between
-  tool rounds, running-job preservation, and reopen after compaction.
-- Add a reference fixture that runs a long tool loop through compaction, saves,
-  relaunches, and continues without losing the active task.
-
-Exit criterion: repeat the reference `ds4-agent` long-context scenarios,
-including compaction forced by a large tool result, stop during compaction, and
-restart after a successful compaction. The same task state, recent turns, tool
-contract, and running-job awareness must remain available.
-
-## 2. Tool hardening and safety
+## 1. Next — tool hardening and safety
 
 Goal: make the existing tool set safe and clear enough for productive daily
 use without weakening its ability to inspect, edit, build, and test a project.
@@ -159,13 +89,13 @@ Exit criterion: use the agent for a real inspect/edit/test cycle while every
 side effect is visible, risky actions require consent, Stop works at every
 stage, and no file tool can escape the selected project.
 
-## 3. DS4 execution technology parity
+## 2. DS4 execution technology parity
 
 Goal: finish the model-independent Metal/runtime capabilities in `ds4.c`
 before adding larger model families. Every capability must be shared by local
 chat and the HTTP endpoint through the single process-wide model owner.
 
-### 3.1 SSD streaming — first runtime priority
+### 2.1 SSD streaming — first runtime priority
 
 SSD streaming is the capacity prerequisite for larger models and therefore
 comes before GLM 5.2 and DeepSeek V4 Pro execution.
@@ -186,7 +116,7 @@ comes before GLM 5.2 and DeepSeek V4 Pro execution.
   the cache and I/O layer model-aware so later GLM/Pro milestones add policy and
   graph support rather than a second streaming subsystem.
 
-### 3.2 Speculative decoding: legacy MTP and DSpark
+### 2.2 Speculative decoding: legacy MTP and DSpark
 
 - Load and validate the optional Flash legacy-MTP or DSpark support GGUF without
   treating either as a standalone model. Preserve exact support-kind and target
@@ -206,7 +136,7 @@ comes before GLM 5.2 and DeepSeek V4 Pro execution.
 - GLM's in-model MTP path belongs to the GLM milestone, but it should reuse the
   verifier/session machinery established here.
 
-### 3.3 Remaining Metal execution controls
+### 2.3 Remaining Metal execution controls
 
 - Port directional steering files and exact FFN/attention application,
   including DS4 defaults, validation, zero-scale behavior, and checkpoint/model
@@ -218,7 +148,7 @@ comes before GLM 5.2 and DeepSeek V4 Pro execution.
 - Add hardware-backed token/activation fixtures for each mode and keep the
   ordinary resident Flash path unchanged when optional features are off.
 
-### 3.4 Single-machine server batching
+### 2.4 Single-machine server batching
 
 - Port DS4's resident multi-session batching and server scheduling only after
   the serialized path remains the correctness oracle. Preserve per-request
@@ -233,7 +163,7 @@ resident, SSD-streamed, MTP, DSpark, steering, and batched-server
 configurations, with optional modes off producing the same baseline behavior
 as today.
 
-## 4. Additional model execution
+## 3. Additional model execution
 
 Start these only after the shared capacity and execution technology above is
 stable. Catalog entries, settings, tokenizer work, or GGUF validation alone do
@@ -269,7 +199,7 @@ Exit criterion: each advertised model passes the same local-agent, checkpoint,
 HTTP, SSD-capacity, cancellation, and deterministic token-output matrix as
 DeepSeek V4 Flash.
 
-## 5. Product completion and verification
+## 4. Product completion and verification
 
 ### Reference parity and regression coverage
 
@@ -301,7 +231,7 @@ Exit criterion: a notarized build can be installed on a clean supported Mac,
 run the full local-agent and endpoint smoke matrix, restart into its previous
 sessions, and update without losing projects, transcripts, models, or KV data.
 
-## 6. Optional future extensions
+## 5. Optional future extensions
 
 These are not DS4 baseline parity and must not delay the milestones above.