v0.5.2

Fixes

• The guide shadow reaches the review child again. v0.5.1 registered it on the plugin fiber's context, whose scope never reaches a review child, so every review kept the memory plugin's guide while nothing warned. It is registered on the child's own scope inside setup — the scope the empty section must replace — and dies with the child. A registration on any context that outlives the child (the plugin fiber, or an inject callback's scope) either misses the child or leaks the empty section onto every later one.

v0.5.1

Fixes

• The guide shadow now lands in the review child's own scope. A system-prompt section registration belongs to the calling context's scope, and the shadow registered from inside the child's setup could either leak onto a scope that outlives the review — stripping the guide from every later child — or find no service and silently do nothing but warn. It is now registered on the review's own context before the child is created, so the child's first assembly carries it and it cannot outlive the review.
• The prompt report states the real ceiling. budgetTokens is the whole prompt's limit (fixed text plus projected evidence) rather than the preamble-adjusted evidence room, so the page's "~N tok of B budget" reads correctly; failure reasons still report the evidence room the plan handed over.
• A shortfall prompt no longer claims the new work was complete. A prompt that carries no evidence reviewed nothing; reporting completeness let it advance the reviewed boundary and demote that work to a body-less trace.

Dependencies

• @deepseek-ai/dsh-system-prompt is declared as a runtime peer dependency (the shadow resolves it from the host at run time).

v0.5.0

0.5.0 replaces the single tail-cut review prompt with a two-zone projection
whose size is derived from the reviewer model instead of assumed.

Why

• Over 88 review prompts the static 32K cap truncated 44 % of them, while the
  largest contents were low-density (tool results 39.8 %, shell output 25.6 %,
  file reads 13.0 %).
• The Executor's reasoning was 30.1 % of the projection while its visible
  assistant output was under 2.5 % of its assistant content: a third of the
  evidence budget bought chain of thought, not evidence.
• The reviewer model's window never entered the calculation, so a 32K/64K
  reviewer could overflow into the host's compaction and judge a summary.
• Replaying this repository's own 567-step session (2,085 records) through the
  old and the new rules: the projection is 46 % smaller than the reasoning-free
  tail cut and 57 % smaller than the pre-drop one.

Changed

• The prompt budget is the smaller of review.maxContextTokens (default now
  64K) and contextWindow − preamble − output reserve − 2K margin, using the
  preamble the last review child actually carried (11,089 tokens here). A route
  that cannot hold the 4K-token evidence floor is refused with every number, at
  page save and at review time; a route that advertises no window keeps the cap.
• Two zones: the work since the last concluded review keeps evidence, the
  already-reviewed trace keeps only what the reviewer cannot re-obtain. Tool
  results are graded (read/grep/glob pointer; shell status plus failure lines
  and tail; edits, tool errors and foreign tools whole), reasoning is dropped,
  and up to six earlier-conclusion lines travel as a bounded orientation block.
• A review whose new-work zone was cut does not advance the boundary and says
  so in the prompt; the boundary line keeps its per-review nonce outside the
  cache prefix. The status page and the tab name which zone lost material.
• The transcript ring grows 400 → 900 lines to match the 64K cap.

Fixes folded in

• Shell exit status comes from the harness's trailing marker, not from words
  scanned out of the output: a successful command quoting a child's "exit code
  1" was reported as failed.
• Empty tool results and failures whose body is empty are no longer dropped; a
  compaction summary line is keyed to its checkpoint's surface seq, so later
  compactions can remove it instead of leaving a stale summary behind.
• Restored sidecar records are validated totally (finite counts, enum
  severity, list shapes); a malformed diagnostic entry no longer disables
  review and persistence for that session.

Docs

• README/README.zh describe the two zones, the graded evidence and the window
  behavior; DECISIONS records the measurements, the rejected alternatives and
  the follow-on rules; OPERATIONS gains both refusal causes.

Gates

• pnpm run verify: 21 files, 306 tests.
• Replay of the repository's own session bounded at 4K/8K/16K/64K.
• Live re-measurement of review cost and duration is the next gate.

v0.4.2

0.4.2 re-sizes the default review cadence from measurements instead of a round
number.

Why

• Re-measured over 43 sessions (20,576 step intervals, 103 reviews): a step is
  9.6 s median (p75 18.8 s), a concluded review 52 s (p75 113 s, p90 151 s), and
  a quarter of reviews hit the 180 s deadline.
• The median turn is 21 steps, and the ten-step default left 72 of the 79
  reviewed turns with exactly one review: a typical turn's second half was
  judged only once the session continued. Median detection delay was 3.2 min
  (p90 8.3 min).
• Replaying 242 recorded turns with the measured durations: eight steps takes
  ~20 s off the median and ~70 s off the p90 delay for ~15 % more review calls.
  Coverage (work judged before its turn ends) is flat across 6–12 steps, so the
  cadence is a latency/cost dial; eight is where the delay gain is still cheap.

Changed

• Default review.everySteps 10 → 8 (a configured value keeps its value).
• The page bundle's fallback default and both READMEs follow.
• DECISIONS records the measurements, the replay table and why not fewer steps;
  the reload test derives its pre-reload count from the configured cadence.

v0.4.1

0.4.1 is a correctness pass over the single step cadence v0.4.0 shipped.

Step counter

• A step boundary now persists the sidecar, so a reload resumes the cadence
  instead of forgetting the steps accrued since the last write.
• Steps counted before the lazy sidecar load are added to the restored total
  instead of being overwritten (the triggering step was always lost before).
• The sidecar's cursor field was written and never read; it is gone, with the
  state write and the ReviewTick wrapper it needed. Sidecars that still carry
  it keep loading.

Page

• The cadence field no longer says "steps within a turn": the counter spans turns.
• Delivery state is matched per review by time as well, so a second review in the
  same turn no longer inherits the first one's "delivered" badge.
• A cleared numeric box is rejected instead of saving as 0 (which means
  "automatic review off" for the cadence field).

Docs

• The delivery guarantee is qualified to follow-up notes; the compiled-context
  boundary is described as "concluded review"; a model-less overlay is described
  as loading disabled (loud only when enabled: true is asked for); the state
  file lists what it actually holds; the page no longer restates the GUI's
  cookie/Host fence; pnpm run verify documents the client syntax check.
• DECISIONS keeps only the measurements of the superseded round cadence, and
  states what everySteps: 0 meant in v0.3 versus now.

v0.4.0

One review interval instead of two, and it is measured in steps.

• review.everyTurns (the reply/round cadence) is removed. A review now
  starts once review.everySteps completed steps (default 10) have accrued
  since the previous attempt finished. A step — one model call plus the tools it
  ran — is the host's progress unit, so one counter covers work inside a long
  turn and work spread across many short turns; the two intervals could
  disagree and no longer can.
• Breaking for configuration: a row or config.json that still sets
  everyTurns keeps loading — the key is ignored, never rejected, so an
  upgrade does not drop the page overrides — and the next page save rewrites
  the file without it.
• The first review of a session now waits for a full cadence instead of firing
  on the first reply; a one-step question no longer buys a reviewer call.
• A turn's final answer triggers nothing of its own. A session that stops
  before the next full cadence leaves that tail to the steps that follow.
• The step cursor now paces attempts: every review advances it to the steps
  seen at its end (no chaining, and a broken route is retried once per cadence,
  not once per step). The transcript boundary still advances only on a
  concluded review, so a failed or cancelled review's material is re-read.
• everySteps: 0 keeps its meaning as an explicit off switch: no automatic
  review at all.
• The page's configuration form loses the round-cadence field and keeps the
  step one; the tab reports the cadence it is running.

v0.3.0

Mid-turn reviews for long-running turns.

• A review can now start on a completed step, not only on a reply round:
  review.everySteps (default 10, 0 disables). A turn that runs for
  dozens of tool steps crosses no reply boundary until its final answer — one
  live session measured 46 steps in one turn and zero reviews — so the round
  cadence alone never saw work in flight.
• The step cursor advances when a review finishes, so a review slower than
  the cadence cannot chain into the next one, and a step boundary never
  inherits the round rhythm's "first review is due immediately".
• Round and step counters are now absolute and persisted: a reload resumes the
  rhythm instead of forgiving the rounds and steps that accrued since the last
  review. A sidecar written before the counters existed seeds its round total
  from lastReviewedRound.
• The page's configuration form edits everySteps (0 = off); values are
  validated with the host's bounds on both ends.
• Default sized from measured runs of this deployment (~8 s per step, ~100 s
  per review): about one mid-turn review every three minutes of continuous
  work, while turns shorter than ten steps are unchanged and still covered by
  the reply-round cadence.

v0.2.0

Reviewer attention

• Reviews now start at the work done since the last completed review. The
  compiled projection marks that boundary, the reviewer is told to judge from
  there first, and it is asked to conclude within three steps (batched reads, at
  most five) — measured reviews on this repository previously spent 13–30 steps
  re-reading turns an earlier review had already covered.
• The boundary line carries a random nonce minted per review, so a quoted copy
  inside a tool result, a file body or a model message cannot pose as the
  boundary.
• A failed or cancelled review does not advance the boundary: its material stays
  marked as new to the next reviewer.
• Fixed: the boundary no longer slides when the 400-line transcript buffer trims
  old lines while a review is running — that could make genuinely new work look
  like older context and invite the next review to skip it.

Advisor tab

• Notes handed to a running Executor's inbox are now visible while they wait for
  the next step boundary to admit them: the queue block shows the row with the
  delivered note body, and it clears when the note reaches the model context.
  A steered note still counts as delivered at the hand-off; the row is display
  state only.

v0.1.3

No runtime change: the package contents are the same build as v0.1.2.

• Publishing now runs on OIDC trusted publishing. The bootstrap access-token
  secret has been deleted; the repository stores no npm credential. The first
  release published through the new trusted publisher also validates it.
• Install docs say the package is on npm with a provenance attestation, and
  that a development checkout can still be linked.

v0.1.2

Patch release. No runtime behaviour changes; the package contents are the same
build as v0.1.1.

• Clean install works again under pnpm 12. v0.1.1's pnpm-workspace.yaml
  still used the legacy onlyBuiltDependencies list, which pnpm 12 ignores: a
  clean checkout failed with ERR_PNPM_IGNORED_BUILDS on esbuild, so the
  repository could not be built from scratch and the new publish workflow could
  not reach its publish step. The build approval now lives in allowBuilds.

• npm publication is automated. .github/workflows/publish.yml publishes a
  released tag through OIDC trusted publishing (npm publish --provenance --access public), after checking that the tag matches package.json and
  running the same verify gate as a local release. A one-time granular access
  token can bootstrap the very first upload, which npm cannot accept over OIDC
  because the package must exist before a trusted publisher can be configured.

• Docs. docs/OPERATIONS.md records the release procedure, the bootstrap
  steps for npm, and the difference between "routes are healthy" and "the
  reconcile actually reloaded the built entry" (a release with no source delta
  is byte-identical to the deployed one).