instar 0.28.94 → 0.28.96

package/upgrades/side-effects/project-scope-phase1b-pr6.md

@@ -0,0 +1,136 @@
+# Side-Effects Review — project-scope Phase 1b PR 6 (Tone-gated round-complete message + delivery)
+
+**Version / slug:** `project-scope-phase1b-pr6`
+**Date:** `2026-05-11`
+**Author:** `echo`
+**Second-pass reviewer:** `required (new outbound-message template + new disk-backed idempotency surface)`
+
+## Summary of the change
+
+Sixth PR of project-scope Phase 1b. Ships the two final primitives the
+autonomous run loop will need to emit round-complete digests safely:
+
+- `formatRoundCompleteMessage(input)` — pure template function. Enforces
+  required-field PRESENCE (not non-emptiness, per spec § Phase 1.8 —
+  the gate "never silently rejects on a legitimate halt"). Returns
+  `{ok:true, message, idempotencyKey}` or `{ok:false, missingFields}`.
+- `RoundCompleteDeliveryHelper` — retry + idempotency wrapper around
+  a caller-provided send function. 3-attempt exponential backoff
+  (1s, 2s, 4s defaults). Records the `(projectId, roundIndex,
+  eventKind, projectVersion)` key in `.instar/local/round-complete-sent.json`
+  after the first successful send so tone-gate retries don't produce
+  duplicates. On permanent failure (all retries exhausted, or first
+  non-transient response), the caller's `onPermanentFail` runs.
+
+Nothing wires these up to an actual round-complete event yet — the
+autonomous run loop is the consumer. PR 6 ships the primitives so the
+run loop in a follow-up PR doesn't fork either of them.
+
+Spec source: `docs/specs/PROJECT-SCOPE-SPEC.md` § Phase 1.8.
+
+New files:
+- `src/core/ProjectRoundCompleteMessage.ts` (~290 lines) — the
+  template + delivery helper described above. Pure ESM, no extra deps.
+- `tests/unit/ProjectRoundCompleteMessage.test.ts` (20 cases) —
+  template required-field gate (all 9 required + halt-flavor whatHalted),
+  empty-string accepted, root-cause-default omitted, override link
+  rendered, evidence-cap honoured, idempotency-key permutations,
+  delivery first-attempt success, dedup short-circuit, transient retry
+  to success, non-transient bail with fallback, all-transient exhaust
+  with fallback, on-disk persistence across instances, no-record on
+  total failure, template-reject suppresses send.
+
+## Decision-point inventory
+
+- **Template required-field gate** (`formatRoundCompleteMessage`) —
+  **add** — rejects with `{ok:false, missingFields}` when any of the
+  9 required fields is undefined / null / non-array (for `evidenceCited`)
+  / non-integer (for `roundIndex`/`projectVersion`). Halt-flavor events
+  additionally require `whatHalted` to be a string. Empty strings are
+  ACCEPTED — the spec explicitly says presence is what matters.
+- **Idempotency-key dedup** (`RoundCompleteDeliveryHelper.sendOnce`) —
+  **add** — recorded only after a confirmed send. If all attempts
+  failed, the key is NOT recorded, so a subsequent retry with the
+  same input will be allowed to call `send` again. Bounded to 1000
+  recent keys so the dedup file doesn't grow unbounded.
+- **Fallback firing** (`onPermanentFail`) — **add** — fires once when
+  all retries are exhausted OR a non-transient failure is reported.
+  Caller decides whether the fallback path is attention-queue,
+  audit-log, `awaitingUser` population, or all three. The PR 6
+  delivery helper just signals "we couldn't deliver — your turn."
+
+## Over-block vs under-block analysis
+
+### Template gate
+Over-block: an `evidenceCited: []` (empty array) is accepted —
+required-field PRESENCE includes "array exists, possibly empty." The
+gate would reject `evidenceCited: undefined`. Matches spec.
+
+Under-block: there's no length cap on individual string fields. A
+30,000-char `whatLanded` would render in full. Acceptable: outbound
+content quality is the tone-gate's job (MessagingToneGate already
+flags excessive verbosity). The template just builds the string.
+
+### Delivery helper
+Over-block: a non-transient failure bails immediately rather than
+retrying. Matches the spec's implicit "permanent failure → fallback"
+semantics — retrying a 401 / 400 won't help.
+
+Under-block: dedup is keyed on `projectVersion`. If the project record
+is mutated between send attempts (which it normally is — the
+post-send tracker.update bumps version), a second attempt would have
+a different key and re-send. This is intentional — the version bump
+is what makes "same round, different state" distinguishable from
+"same round, same state, duplicate send."
+
+## Signal vs authority audit
+
+The template is a pure function — no signal/authority overlap. The
+delivery helper has authority only over its own idempotency ring; it
+delegates transport entirely to the caller's `send` function.
+
+## Interactions with existing systems
+
+- **`MessagingToneGate`.** The caller (the autonomous run loop, not
+  shipped yet) is responsible for routing the formatted message
+  through the tone gate before calling `helper.sendOnce`. The helper
+  does NOT call the tone gate directly — keeps the boundary clean
+  and the helper unit-testable.
+- **TelegramAdapter / Slack / WhatsApp.** None used here. The caller
+  supplies the `send` function.
+- **`.instar/local/`.** The dedup file lives at
+  `.instar/local/round-complete-sent.json` — machine-local, NOT
+  git-synced (same convention as the round-runner lock and the drift
+  ledger lock). Two machines won't dedupe each other's sends, which
+  is correct: each machine should make its own send decision and the
+  recipient platforms (Telegram, Slack) handle their own dedup.
+- **`SafeFsExecutor`.** Used for test cleanup; the in-class
+  persistence uses tmp+rename atomic writes (matches the pattern in
+  `MachineHeartbeat`).
+
+## Rollback cost
+
+Revert deletes `src/core/ProjectRoundCompleteMessage.ts` and the
+test file. The on-disk dedup file becomes orphaned but harmless.
+No schema migrations.
+
+## What this PR explicitly defers (to PR 7+)
+
+- **Wiring into the autonomous run loop.** The run loop is the
+  intended consumer; it ships separately. Until then, no caller
+  invokes `formatRoundCompleteMessage` or `sendOnce`.
+- **Attention queue / audit log / `awaitingUser` integration.** The
+  fallback callback is caller-provided; PR 6 only fires it. The
+  concrete callback that wires those three downstream channels
+  ships with the run loop.
+- **MessagingToneGate routing.** Same — the caller threads the
+  message through the gate; the helper accepts the formatted text
+  as-is.
+
+## Verification
+
+- `npm run lint` — passes (tsc + lint-no-direct-destructive).
+- `npx vitest run tests/unit/ProjectRoundCompleteMessage.test.ts` —
+  20/20 pass.
+- Existing PR 1-5 invariants unaffected (no shared code touched
+  outside the new file).

package/upgrades/side-effects/project-scope-phase1b-pr7.md

@@ -0,0 +1,175 @@
+# Side-Effects Review — project-scope Phase 1b PR 7 (Autonomous run loop)
+
+**Version / slug:** `project-scope-phase1b-pr7`
+**Date:** `2026-05-11`
+**Author:** `echo`
+**Second-pass reviewer:** `required (new subprocess management + process-group signaling + filesystem allocation under target repo)`
+
+## Summary of the change
+
+Final PR of project-scope Phase 1b. Ships the autonomous run loop the
+spec § Phase 1.5 names (steps 1-11), wired against the lock + preflight
++ runner primitives that landed in PRs 3-6:
+
+- `ProjectRoundWorktrees` — lazy worktree allocator under
+  `<targetRepoPath>/.worktrees/<projectId>/<roundIndex>/<itemId>`.
+  Appends `.worktrees/` to `.git/info/exclude` on first call so the
+  namespace doesn't pollute `git status`.
+- `runRound(input, deps)` — the run loop. Acquires the lock, lazily
+  allocates the first worktree, spawns the autonomous child in a
+  detached process group, polls the project record every 60 seconds.
+  On mid-round mutation to `round.itemIds`, SIGTERMs the child's
+  process group (5s grace, then SIGKILL) and relaunches with the
+  new stop condition. On the child's natural exit, verifies per-item
+  artifacts via the caller-injected `verifyMergedItems` and sets
+  `round.status` to `complete` | `partially-complete`. On
+  `haltedAt` set mid-run, kills the child and returns `halted`.
+  Three-attempt resume cap on transient non-zero exits before
+  `failed`.
+
+Spec source: `docs/specs/PROJECT-SCOPE-SPEC.md` § Phase 1.5.
+
+New files:
+- `src/core/ProjectRoundWorktrees.ts` (~140 lines) — pathFor,
+  allocate, prune, remove, ensureExcludeEntry helpers. `SafeGitExecutor`
+  for all git invocations.
+- `src/core/ProjectRoundExecution.ts` (~340 lines) — the run loop
+  itself, plus `verifyMergedItemsViaGit` helper for callers that want
+  the real `git merge-base --is-ancestor` verifier instead of a stub.
+- `tests/unit/ProjectRoundWorktrees.test.ts` (8 cases) —
+  path-shape, allocate-creates, refuse-on-existing, idempotent
+  exclude entry, prune-on-empty, remove-on-missing,
+  remove-cleans-up, allocate-with-refuseExisting-false.
+- `tests/unit/ProjectRoundExecution.test.ts` (8 cases) —
+  lock-held-failure, first-pass-complete (no spawn), natural-exit
+  full-verification, natural-exit subset → partially-complete,
+  halt-mid-run, dynamic stop revalidation (itemIds mutation
+  triggers relaunch), worktree allocated, exclude entry written.
+
+## Decision-point inventory
+
+- **Spawn in detached process group** (`spawnAutonomousChild`) —
+  **add** — `detached: true` per Node `child_process.spawn`. The
+  child gets its own process group; the runner is NOT a member.
+  `process.kill(-pid, signal)` (negative PID = group target) reaps
+  the child's entire process tree (compilers, test runners spawned
+  by the autonomous skill) without reaping the runner. Spec § Phase
+  1.5 step 5 calls this out explicitly.
+- **Worktree allocation** — **add** — lazy on first use. Refuses
+  by default if path exists (spec semantics); callers can pass
+  `refuseExisting: false` to override (used on resume paths).
+- **Per-step halt checkpoint** — **add** — before every iteration of
+  the inner relaunch loop, re-reads `round.haltedAt` from the tracker.
+  Set → SIGTERM the child, return `halted`.
+- **Stop-condition verifier dependency injection** — **add** —
+  `verifyMergedItems` is required input. Default (used when no
+  override) is a no-op set (returns empty set), so production callers
+  MUST pass a real verifier. Tests pass stubs. The real production
+  verifier is `verifyMergedItemsViaGit`, exported alongside the run
+  loop.
+- **Resume cap** — **add** — 3 transient non-zero exits before
+  `failed`. Spec § Phase 1.5 step 11.
+
+## Over-block vs under-block analysis
+
+### Process group signaling
+Over-block: SIGTERM-grace-then-SIGKILL of the WHOLE process group
+will reap any descendant process the autonomous skill spawned —
+compilers, test runners, lockfile holders. This is intentional and
+matches the spec.
+
+Under-block: if the autonomous child somehow detaches FURTHER
+(creates its own grandchild group), that group escapes. Acceptable
+edge case — the autonomous skill is in-house and doesn't do that;
+we'd notice in observability before it becomes a leak.
+
+### Worktree allocation
+Over-block: a stale worktree directory under `.worktrees/` from a
+crashed previous run causes `allocate()` to throw. Callers (the
+runner's first-item path) pass `refuseExisting: false` so the
+allocator returns the existing path instead. Trade-off: a crashed
+run's stale worktree is silently reused. Acceptable: `prune()` runs
+on every successful round completion, and `git worktree add` would
+itself complain if the worktree is corrupt.
+
+Under-block: `prune()` runs `git worktree prune` against the whole
+repo, not just our namespace. Worktrees registered by OTHER tools
+(unrelated to project-scope) that have become stale will ALSO be
+pruned. Acceptable: `git worktree prune` only removes administrative
+entries pointing at missing paths — it does not delete live worktree
+directories.
+
+### Run loop
+Over-block: a long-running autonomous child that takes 4 hours to
+complete isn't capped here. Acceptable — the autonomous skill has
+its own duration cap (stop hook); the run loop just watches for exit.
+
+Under-block: a child that hangs without exiting AND without itemIds
+changing AND without `haltedAt` being set sits forever. Acceptable
+for this PR — the auto-advance poller's `LOCK_HELD` rejection will
+eventually surface the stuck round in telemetry, and the user can
+`POST /halt`.
+
+## Signal vs authority audit
+
+The run loop is **authority** for round-state transitions
+(`complete` / `partially-complete` / `failed`). The decision is
+deterministic: the caller-provided `verifyMergedItems` (a signal
+source) returns a set; the run loop counts matched/unmatched and
+sets `round.status` accordingly. The runner never sets a verdict
+the verifier didn't support.
+
+## Interactions with existing systems
+
+- **`ProjectRoundLock`** — acquired at step 1, released at step 8 in
+  the finally block (always releases even on throws).
+- **`InitiativeTracker`** — single source of truth for `round.itemIds`,
+  `round.haltedAt`, `round.status`. Polled every `pollIntervalMs`;
+  mutated on outcome via `tracker.update(...)` with `ifMatch`. OCC
+  races are silently ignored at outcome-recording time (next read
+  will see the conflicting writer's state).
+- **`SafeGitExecutor`** — every git invocation (worktree add / prune /
+  remove, merge-base --is-ancestor) routes through the safe executor.
+  No raw `execFileSync('git', ...)` anywhere.
+- **`ProjectRoundRunner.preflight`** (PR 3) — the run loop assumes
+  preflight has passed. It does NOT re-run preflight at step 1; the
+  caller is expected to do it (auto-advance poller does; /project
+  run-round skill does).
+- **`ProjectAutoAdvancePoller`** (PR 4) — the poller calls
+  `preflight` and then in PR 7+ can call `runRound` directly. PR 4
+  bookkeeps unacked count + clears autoAdvanceAt; the run loop is
+  the actual work-doer that follows.
+- **`RoundCompleteDeliveryHelper`** (PR 6) — the run loop does NOT
+  invoke the delivery helper. That's a caller concern (the poller
+  or the skill consumes the run-loop result and constructs the
+  message). Keeps the run loop's responsibilities tight.
+
+## Rollback cost
+
+Revert deletes `src/core/ProjectRoundWorktrees.ts`,
+`src/core/ProjectRoundExecution.ts`, the two test files. Existing
+worktree directories under `<targetRepoPath>/.worktrees/...` become
+orphaned but harmless. `git worktree prune` from a subsequent
+unrelated run cleans up the administrative entries. No schema
+changes.
+
+## What this PR explicitly defers
+
+- **Wiring the poller / skill to call `runRound`.** PR 4's poller
+  currently only bookkeeps; calling `runRound` is a small wiring
+  task in a follow-up PR (the runner instance is already in the
+  ctx; the poller just needs to invoke it).
+- **`GET /projects/:id/next` real implementation.** Still 501.
+- **Lazy merged-state reconciler on `GET /projects/:id`.** Spec
+  Phase 1.5 — the read-may-mutate behavior with the ≤3-children-per-GET
+  cap. Not implemented in PR 7; the
+  `verifyMergedItemsViaGit` helper here is the building block the
+  reconciler can call into in a follow-up.
+
+## Verification
+
+- `npm run lint` — passes (tsc + lint-no-direct-destructive).
+- `npx vitest run tests/unit/ProjectRoundExecution.test.ts
+  tests/unit/ProjectRoundWorktrees.test.ts` — 16/16 pass.
+- Existing PR 1-6 invariants unaffected (the run loop is a new
+  module; no shared-code mutations).

package/upgrades/side-effects/promise-beacon-ux-fixes.md

@@ -0,0 +1,146 @@
+<!--
+  Side-Effects Review — PromiseBeacon UX fixes
+  Phase 4 artifact for /instar-dev pass on echo/promise-beacon-ux-fixes.
+-->
+
+# Side-Effects Review — PromiseBeacon UX fixes
+
+**Version / slug:** `promise-beacon-ux-fixes`
+**Date:** `2026-05-12`
+**Author:** `echo`
+**Second-pass reviewer:** `pending`
+
+## Summary of the change
+
+PromiseBeacon's heartbeat templates ("still working — snapshot unchanged since last beat") gave the user no context about which promise was being watched, and heartbeats ran forever even when nothing was changing. Three commitments stacked on the same Telegram topic produced ~30+ context-free "no observable progress" messages over an evening with no way to stop them short of opening the dashboard. This change:
+
+1. Includes a truncated form of the promise text in every heartbeat so the user can see what's being tracked.
+2. Adds an auto-pause: after N consecutive unchanged-snapshot heartbeats (default N=12, ~2h at 10-min cadence), the beacon emits one final "auto-paused — reply 'keep watching' to resume" message and stops firing. Non-terminal; status stays `pending`.
+3. Adds `POST /commitments/:id/resume` and a literal "keep watching" detector in the Telegram inbound path that calls it for any paused beacon on the originating topic.
+
+Files touched:
+- `src/monitoring/CommitmentTracker.ts` — new optional schema fields (`beaconPaused`, `beaconPausedReason`, `beaconPausedAt`, `beaconAutoPauseAfterUnchanged`, `consecutiveUnchanged`); `resume(id)` method.
+- `src/monitoring/PromiseBeacon.ts` — promise-text excerpt in heartbeat composition; consecutive-unchanged counter; auto-pause flow; paused-state gate in `fire` and `schedule`.
+- `src/server/routes.ts` — `POST /commitments/:id/resume`.
+- `src/commands/server.ts` — extend `telegram.onMessageLogged` with literal "keep watching" detector that calls the resume endpoint.
+- Tests: new files under `tests/unit/` and `tests/integration/`.
+
+Decision points the change interacts with:
+- PromiseBeacon's heartbeat composition path (template selection, LLM call gating).
+- PromiseBeacon's scheduling path (timer arming, suppression checks).
+- Commitment lifecycle (new non-terminal state combination: `pending + beaconPaused`).
+- Telegram inbound path (new literal-match detector that triggers a server-side action).
+
+## Decision-point inventory
+
+- `PromiseBeacon.fire` heartbeat-template selection — **modify** — adds promise-text prefix to every template; adds auto-pause branch.
+- `PromiseBeacon.schedule` arming guard — **modify** — skips arming when `beaconPaused`.
+- `CommitmentTracker.resume(id)` — **add** — non-terminal flag clear + counter reset.
+- `POST /commitments/:id/resume` — **add** — API entrypoint for resume.
+- Telegram `onMessageLogged` literal-match — **add** — produces resume signal that calls the new endpoint.
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this change reject that it shouldn't?**
+
+The auto-pause has no block/allow surface — it stops outbound heartbeats from this agent, doesn't reject inputs. Strictly speaking it could "over-stop" if the user genuinely wanted updates on a long-running silent process. Mitigation: the final pause message tells the user how to resume; the resume path itself is idempotent.
+
+The "keep watching" detector uses literal substring match (`/keep[\s-]?watching/i`). False positives:
+- A user typing "I want to keep watching the build logs" while not intending to resume a beacon. Cost: a paused beacon resumes; user gets one more heartbeat and can re-pause by ignoring it (it'll auto-pause again after N cycles) or by withdrawing the commitment.
+- Whichever paused beacons exist on the topic all resume simultaneously, not selectively. Cost: minor; same recovery path.
+
+---
+
+## 2. Under-block
+
+**What failure modes does this still miss?**
+
+- The literal detector won't match paraphrases ("keep an eye on it", "stay on it", "don't give up"). Intentional: per signal-vs-authority, a brittle detector with blocking authority is forbidden. The detector is structurally simple by design. The final auto-pause message tells the user the exact phrase to use.
+- If the user wants to resume one specific paused beacon out of many, this implementation resumes all paused beacons on the topic. A future iteration could accept "keep watching <commitment-id>".
+- The auto-pause counter is per-commitment; multiple beacons on the same topic still produce N heartbeats each before pausing. The total heartbeat volume on a topic is not bounded by this change — only the per-beacon volume.
+
+---
+
+## 3. Level-of-abstraction fit
+
+The auto-pause counter belongs in PromiseBeacon — it's the only thing that knows the snapshot-hash and the consecutive-unchanged history. Putting it elsewhere would require lifting that state up.
+
+The resume endpoint mirrors the existing `/deliver` and `/withdraw` endpoints on `/commitments/:id` — it's at the same layer as those, which is correct.
+
+The Telegram "keep watching" detector lives in `server.ts`'s existing `onMessageLogged` extension because that's where every inbound message is observed once already (for PresenceProxy + TopicMemory). Adding a third small hook there is cheaper than building a new fan-out point. The detector itself is brittle by design (regex), but it only produces a signal — the resume endpoint is the authority for whether to act.
+
+---
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+- [ ] No — this change produces a signal consumed by an existing smart gate.
+- [x] No — the brittle parts (counter, regex) hold no blocking authority over messages or behavior. The counter triggers a structural state transition (pause); the regex triggers a structural state transition (resume). Neither blocks or modifies an inbound user message.
+- [ ] Yes — but the logic is a smart gate with full conversational context.
+- [ ] ⚠️ Yes, with brittle logic.
+
+The auto-pause counter is mechanics, not judgment (signal-vs-authority §"When this principle does NOT apply" — "Idempotency keys and dedup at the transport layer... not a judgment call — it's mechanics"). It counts identical snapshot hashes; that's a structural fact.
+
+The "keep watching" detector is a brittle regex that calls a structural API. The API itself is symmetric with `/withdraw` — idempotent, no judgment, just toggles state. A false positive resumes a paused beacon, which costs one more heartbeat and re-pauses if still idle. No message is blocked, filtered, or rejected; no agent behavior is constrained beyond the toggle.
+
+---
+
+## 5. Interactions
+
+- **Shadowing:** The auto-pause check sits inside `PromiseBeacon.fire` after the existing suppression/ownership/quiet-hours checks. It runs only when those passed and templated-unchanged branch was taken. It does not shadow `beaconSuppressed` (which is for boot-cap / spend-cap, distinct semantics) — `beaconPaused` is a new orthogonal non-terminal flag with `resolved-by` `/resume` (not by the existing suppression-clear path).
+- **Double-fire:** The "keep watching" detector lives inside the same `onMessageLogged` callback chain that already feeds PresenceProxy. Calling the resume endpoint enqueues a single mutate operation per matched commitment; no duplicate timers are created because `schedule()` clears any existing timer before arming.
+- **Races:** Concurrent withdraw + resume on the same commitment: the existing `mutate(id, fn)` queue serializes writes; resume is rejected by `mutate` if the commitment is already terminal (withdrawn).
+- **Feedback loops:** Resume → fire → snapshot unchanged → counter increments → re-pauses after N cycles. This is the intended steady state when a watched task is genuinely idle; the user can resume again. There is no autonomous loop that re-resumes itself.
+
+---
+
+## 6. External surfaces
+
+- **Other agents on the same machine:** No. PromiseBeacon state is per-agent.
+- **Other users of the install base:** Yes — every instar agent ships with PromiseBeacon. After this change, every install gets the new heartbeat text format, the auto-pause behavior, and the Telegram resume detector. The new endpoint is additive (no behavior change for callers that don't use it).
+- **External systems:** The Telegram messages emitted change format (now include promise text). Anyone tooling against the exact "still working — snapshot unchanged since last beat" string would break; we know of no such consumer outside test fixtures.
+- **Persistent state:** Three new optional fields on the Commitment schema. Forward-compatible: missing fields default to "not paused, counter at zero, threshold default 12." Existing commitments load cleanly without migration.
+- **Timing / runtime:** The 12-cycle threshold at default 10-min cadence yields ~2-hour silence before auto-pause. Tunable per-commitment via `beaconAutoPauseAfterUnchanged`. Quiet hours and boot-cap interactions unchanged.
+
+---
+
+## 7. Rollback cost
+
+Pure code change. Schema additions are optional. Revert the commit and ship the next patch — existing agents will continue to use whatever schema they had; new fields are simply ignored. No data migration. No agent state repair. Users see the previous (broken) UX again until a roll-forward fix; not a regression in correctness, only in UX.
+
+---
+
+## Conclusion
+
+The change addresses the user-reported spam directly: heartbeats now say what they're tracking, beacons stop themselves after extended silence, and the user can resume them from Telegram. The signal-vs-authority principle is honored: the brittle parts (counter, regex) only trigger structural state transitions, never block or judge messages. Schema additions are backward-compatible and rollback is a code revert. Clear to ship after Phase 5 second-pass review (required: change touches outbound messaging composition and commitment lifecycle).
+
+---
+
+## Second-pass review (if required)
+
+**Reviewer:** echo (Phase-5 independent pass)
+**Independent read of the artifact: concern → resolved**
+
+Concerns raised, with resolutions:
+
+- **Misleading resume ack on failure.** In `src/commands/server.ts` the "keep watching" handler `await`ed `fetch` to `/commitments/:id/resume` inside a `try`/`catch` that only `console.warn`'d on throw, never checked the HTTP response, and then unconditionally posted `⏳ resumed N watcher(s) on this topic.` to the user. A 404 (not paused / terminal), a 5xx, or a thrown fetch (server restart, partial outage) would all result in the user being told the beacon resumed when it did not.
+  **Fix applied:** the handler now inspects `response.ok` per call, counts successes, and tailors the ack: `⏳ resumed N watcher(s)` on full success, `⏳ resumed X of Y watchers — N didn't resume` on partial success, `⚠️ couldn't resume the watcher(s) on this topic — try again or open the dashboard` on total failure or fetch throw.
+- **Cold-mirror write of `consecutiveUnchanged` had no consumer.** The cold mirror was written every fire but never consulted by `fire()` or the threshold check (which uses `hot.consecutiveUnchanged`). Write amplification on the CAS queue with no benefit and a footgun for a future reader.
+  **Fix applied:** dropped the per-cycle cold write. The field is now written only at the pause boundary (with a comment in `autoPause()`) and on resume (set to 0). The schema field carries a docstring marking it as a non-authoritative observability mirror — hot-state is authoritative during a live run.
+
+Lower-priority observations (not blocking):
+- Over-match on "keep watching": "I'll keep watching the build logs", "good — keep watching for the alert" both resume any paused beacons on the topic. Cost is bounded (one more heartbeat, re-pauses) and matches the artifact's analysis. Acceptable.
+- `beaconSuppressed` × `beaconPaused` interaction: traced through — `fire()` early-exits on `beaconSuppressed` before reaching the auto-pause branch, so the two flags are mutually exclusive within a single fire. `schedule()` correctly rejects when either is set. No race.
+- Backwards-compat for existing commitments: `hot.consecutiveUnchanged` initializes to 0 in `loadHotState`'s defaults block (not undefined/NaN), and `beaconAutoPauseAfterUnchanged ?? defaultAutoPauseAfterUnchanged` falls back cleanly. Confirmed safe.
+- Spec line 161 ("suggest, don't auto-close"): this change is auto-PAUSE (`status` stays `pending`, resumable, no delivery semantics). Does not violate.
+
+---
+
+## Evidence pointers
+
+- Originating user report: Telegram topic 9429 ("progress update bug"), 2026-05-12.
+- Withdrawn runaway commitments providing the live reproduction: CMT-381, CMT-382, CMT-383 on topic 9210.
+- Spec extended (not violated): docs/specs/PROMISE-BEACON-SPEC.md (auto-pause is a new non-terminal suppression; auto-close-on-reply explicitly NOT added per spec line 161).