instar 1.3.178 → 1.3.180

package/upgrades/1.3.180.md

@@ -0,0 +1,133 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+**Agent-to-agent reply-waits no longer flood the user's chat with "⏳ awaiting
+reply" heartbeats.** When an agent sent a Threadline message to another agent,
+`TopicLinkageHandler` created the reply-tracking commitment with
+`beaconEnabled: true` **and** the user's topic id attached. `PromiseBeacon` then
+fired cadenced `⏳ … awaiting reply` heartbeats straight into the user's Telegram
+topic for what is purely an agent-to-agent conversation — observed in the wild as
+dozens of heartbeats burying one topic, making real work invisible and reading as
+"stuck."
+
+The reply already routes back on its own: the threadline-reply commitment carries
+`relatedThreadId` + `topicId`, and the inbound dispatch matches on those when the
+reply lands — entirely independent of the beacon. So the heartbeat was pure
+housekeeping noise. The fix sets `beaconEnabled: false` on these reply-wait
+commitments. This is a direct application of the **Near-Silent Notifications**
+standard: routine agent-to-agent status belongs in logs, never the user's chat.
+
+The per-feature LLM metrics now actually collect data. Phase 1a added the ledger
++ `GET /metrics/features`; **Phase 1b adds the funnel tap** — the one shared LLM
+call (`CircuitBreakingIntelligenceProvider.evaluate`) now records, per gate/
+sentinel, its latency, whether it had to wait out a rate-limit window, and
+success/error. So `/metrics/features` goes from empty to live as your checks run.
+
+It's pure observability: a single side-channel `record()` per call, in a
+swallow-all try/catch, with the breaker/rate-limit control flow byte-identical.
+No gate changes behavior.
+
+New read-only observability: **per-feature LLM metrics**. A new
+`FeatureMetricsLedger` (SQLite, like the token ledger) plus `GET
+/metrics/features` let you see what each LLM-driven gate/sentinel actually
+costs (tokens, latency) and how often it fires — so tuning them is evidence-
+based (which to thin, which to strengthen) instead of guessed.
+
+This is **Phase 1a**: the store + endpoint. It changes no existing gate's
+behavior and writes nothing in production yet — the single funnel tap that
+feeds it lands in **Phase 1b**, on top of the in-flight rate-limit-resilience
+change (#638), so the two don't collide.
+
+New per-agent, opt-in config flag **`updates.restartImmediately`** (default
+**false**). When true, that agent's update restarts are **never deferred** — not
+for active sessions, not for the restart window — so it always rolls onto the
+latest version as soon as it is downloaded.
+
+This is intended for the instar developer's own agent (always-current is
+required when you build and dogfood the fleet). It is **off by default**, so the
+fleet's existing session-aware + window-aware restart deferral is unchanged.
+
+## What to Tell Your User
+
+Nothing to configure. If your agent talks to other agents over Threadline, it will
+no longer spam your chat with "⏳ awaiting reply" heartbeats while it waits for a
+peer — the peer's reply still arrives and routes to the right place exactly as
+before. Beacons that were already running before this update auto-pause on their
+own; new ones won't be created.
+
+Nothing required. If asked: I can now show real per-check cost and timing, how
+often each check runs, and how often it hits a rate-limit wait — the data that
+lets us tune the checks with evidence.
+
+Nothing required. If asked: I can now report, per safety check, how much it costs
+and how often it fires — which is what lets us tune the checks with real data
+instead of guesses.
+
+Nothing for almost everyone — this is off by default and changes nothing unless
+you explicitly turn it on. If you run the kind of agent that must always be on the
+latest build, I can switch it to restart right away whenever an update lands. A
+restart does not close your sessions — they resume right where they left off; the
+only cost is a brief pause in messaging while the server bounces. Just ask me and
+I can turn it on and confirm it's active.
+
+## Summary of New Capabilities
+
+- `TopicLinkageHandler` creates threadline-reply commitments with
+  `beaconEnabled: false` — the reply-routing (relatedThreadId + topicId) is
+  preserved; only the user-facing heartbeat is suppressed.
+- No change to user-facing PromiseBeacons for genuine commitments *to the user*;
+  this scopes the suppression to agent-to-agent reply-waits only.
+
+- `CircuitBreakingIntelligenceProvider` instruments every LLM call into the
+  `FeatureMetricsLedger` via a module-level recorder (`setFeatureMetricsRecorder`),
+  wired once in the server so it covers all current and future LLM features.
+- Per-feature data: call-count, latency (p50/p95), rate-limit wait-rate, error-rate.
+  (Fired-vs-noop verdict + token attribution are Phase 2.)
+
+- `GET /metrics/features` (`?sinceHours=` / `?feature=`) — per-feature rollup:
+  calls, tokens, fired/no-op, fire-rate, p50/p95 latency, wait-stats.
+- `FeatureMetricsLedger` — read-only per-feature LLM observability store.
+- Agents learn about it via the CLAUDE.md template (new) + migration (existing).
+
+- `updates.restartImmediately` config flag (default false). `UpdateGate` gains
+  `alwaysRestartImmediately` (short-circuits `canRestart` to allow, never starts
+  the deferral clock) + a runtime `setAlwaysRestartImmediately` setter; the
+  `AutoUpdater` constructs the gate with it, skips the restart-window wait when
+  set, and re-reads the flag each tick so a live config edit takes effect without
+  a restart. The same-version cooldown + cascade dampener (loop protection) are
+  preserved.
+- Observability: both `UpdateGate.getStatus()` and `AutoUpdater.getStatus()` /
+  `GET /updates/status` surface the active value.
+
+## Evidence
+
+- `tests/unit/TopicLinkageHandler.test.ts` — the threadline-reply commitment now
+  asserts `beaconEnabled === false` (regression pin).
+- `tests/unit/CommitmentTracker-threadline-reply.test.ts` — the tracker still
+  honors an explicit `beaconEnabled: true` (mechanism unchanged); stale "matches
+  call-site" comment corrected. 32/32 green across both files.
+
+- Spec: `docs/specs/llm-feature-metrics-spec.md` (Phase 1b; approved Telegram 13435).
+- Tests: `tests/unit/CircuitBreaking-feature-metrics-tap.test.ts` (+8, incl. an
+  end-to-end feed into a real ledger); all 74 existing CircuitBreaking/breaker tests
+  pass unchanged; `npm run lint` clean.
+
+- Spec: `docs/specs/llm-feature-metrics-spec.md` (+ `.eli16.md`), review-convergence
+  + approved by Justin (Telegram 13435, 2026-05-31).
+- Tests (3-tier): `tests/unit/FeatureMetricsLedger.test.ts`,
+  `tests/unit/PostUpdateMigrator-metricsFeatures.test.ts`,
+  `tests/integration/metrics-features-routes.test.ts`,
+  `tests/e2e/metrics-features-lifecycle.test.ts` (feature-is-alive: 200 not 503).
+  `npm run lint` clean.
+
+- Spec: `docs/specs/restart-immediately-spec.md` (approved Telegram 13435,
+  2026-06-01).
+- Tests: `tests/unit/UpdateGate.test.ts` (+7: allow-despite-healthy-session,
+  pure-no-deferral, monitor-not-consulted, default-still-blocks, runtime
+  toggle both directions) and `tests/unit/AutoUpdater.test.ts` (+2: default
+  false; `restartImmediately:true` reflected in status via the real gate). All
+  19 UpdateGate + 18 AutoUpdater tests pass; `npm run lint` (tsc) clean.

package/upgrades/side-effects/llm-feature-metrics-phase1b.md

@@ -0,0 +1,83 @@
+# Side-Effects Review — Per-feature LLM metrics, Phase 1b (the funnel tap)
+
+**Slug:** `llm-feature-metrics-phase1b`
+**Date:** 2026-06-01
+**Author:** echo
+**Spec:** `docs/specs/llm-feature-metrics-spec.md` (Phase 1b; approved by Justin, Telegram 13435)
+
+## Summary of the change
+
+Phase 1a (#639) shipped the `FeatureMetricsLedger` + `/metrics/features` but nothing
+wrote to it in production. Phase 1b adds the **funnel tap**: the one shared
+`CircuitBreakingIntelligenceProvider.evaluate()` now records, per call, the calling
+feature + latency + whether a rate-limit bounded-wait was engaged + success/error —
+so every LLM-driven gate/sentinel is measured through a single instrumentation point
+(built on top of #638's now-merged `evaluate()`, measuring its wait-behavior).
+
+**Files changed (source):**
+- `src/core/CircuitBreakingIntelligenceProvider.ts`:
+  - new `FeatureMetricsRecorder` **interface** (kept local so core/ never imports
+    monitoring/ — no dependency cycle) + module-level recorder + `setFeatureMetricsRecorder()` /
+    `getFeatureMetricsRecorder()`.
+  - `evaluate()` records on all three exits — success (`noop`), inner failure (`error`),
+    and the circuit-open skip (`noop`, marking `waited`) — via a private `recordMetric()`
+    that **swallows all errors** (observability must never break the LLM path).
+- `src/server/AgentServer.ts`: after constructing the `FeatureMetricsLedger`, call
+  `setFeatureMetricsRecorder(this.featureMetricsLedger)` once — a single injection point
+  that instruments every wrapped provider (current and future).
+
+**Files changed (tests):**
+- `tests/unit/CircuitBreaking-feature-metrics-tap.test.ts` — +8: success→noop, unlabeled
+  bucketing, failure→error+rethrow, the rate-limit wait path (`waited`+`waitMs`), the
+  circuit-open skip (no inner call, throws `LlmCircuitOpenError`), safe no-op with no
+  recorder, a throwing recorder never breaks the call, and an **end-to-end** test feeding
+  a real `FeatureMetricsLedger` and asserting the queryable rollup.
+
+## Blast radius
+
+The hot LLM path gains one side-channel `record()` call per `evaluate()`. It is fully
+isolated: `recordMetric()` is in a try/catch that swallows everything, and a null
+recorder (CLI / no server) is a clean no-op. The breaker/rate-limit control flow is
+**byte-identical** to before — all 74 existing CircuitBreaking + breaker-wait tests pass
+unchanged. No route, config, or behavior of any gate changes.
+
+## Behavior delta
+
+| Scenario | Before (1a) | After (1b) |
+|---|---|---|
+| an LLM gate calls `evaluate()` | nothing recorded | one per-feature row (latency, waited, success/error) |
+| `/metrics/features` | alive but empty | populated as gates run |
+| rate-limit bounded wait (#638) | invisible | recorded (`waited`/`waitMs`) |
+| no recorder set (CLI) | n/a | no-op (no record) |
+| metrics write throws | n/a | swallowed; LLM call unaffected |
+| breaker / rate-limit control flow | as-is | **unchanged** (byte-identical) |
+
+## Outcome semantics (honest scoping)
+
+At the funnel, `outcome` is `noop` for a completed call and `error` for a failure — the
+**fired-vs-noop verdict** is the *caller's* interpretation of the result string, not
+visible here, and **tokens** live in TokenLedger (the provider returns a string). So
+Phase 1b delivers per-feature **call-count, latency (p50/p95), wait-rate, error-rate**;
+the verdict + token-join are **Phase 2** (caller-side `recordEvent` / TokenLedger
+attribution join). This is stated in the spec and the metric is labeled accordingly.
+
+## Risks considered
+
+- **Dependency cycle (core→monitoring)?** Avoided — the provider depends only on a local
+  `FeatureMetricsRecorder` interface; the concrete ledger is injected at runtime.
+- **Hot-path safety?** `recordMetric` swallows all errors; an end-to-end + a throwing-recorder
+  test prove the LLM path is never broken.
+- **Coverage of all providers?** The module-level recorder is read by every
+  `CircuitBreakingIntelligenceProvider` instance (all created via the same wrap), so one
+  `setFeatureMetricsRecorder()` covers all current and future LLM features — no per-call-site wiring.
+
+## Migration parity
+
+None needed — no agent-installed file changes (no hook/config/skill/CLAUDE.md template).
+The `/metrics/features` awareness shipped in Phase 1a (#639); Phase 1b only makes the
+existing endpoint produce data.
+
+## Tests / lint
+
+8 new + 74 existing CircuitBreaking/breaker tests pass; `npm run lint` (tsc +
+destructive/LLM/URL-log/codex-drift) clean.

package/upgrades/side-effects/llm-feature-metrics.md

@@ -0,0 +1,82 @@
+# Side-Effects Review — Per-feature LLM metrics (Phase 1a)
+
+**Slug:** `llm-feature-metrics`
+**Date:** 2026-05-31
+**Author:** echo
+**Spec:** `docs/specs/llm-feature-metrics-spec.md` (review-convergence + approved by Justin, Telegram 13435)
+
+## Summary of the change
+
+Adds a read-only per-feature LLM observability ledger + endpoint, so every gate/
+sentinel's cost (tokens, latency) and hit-rate becomes a tracked number and tuning
+is evidence-based. **Phase 1a: the store + route only — no funnel edit, so zero
+collision with the open #638** (which restructures the same `evaluate()` with
+bounded-wait). Phase 1b (after #638) adds the ~3-line funnel tap that feeds it.
+
+**Files changed (source):**
+- `src/monitoring/FeatureMetricsLedger.ts` — NEW. SQLite-backed, read-mostly, modeled
+  on TokenLedger (opened via `NativeModuleHealer.openWithHealSync` for ABI resilience).
+  `record()` / `recordEvent()` append; `byFeature()` / `summary()` roll up per feature
+  (calls, tokens, fired/noop, fire-rate, p50/p95 latency, wait-stats). Never gates.
+- `src/server/AgentServer.ts` — construct the ledger in its OWN try/catch inside the
+  stateDir block (cascade-isolated, mirroring FrameworkIssueLedger); add the field +
+  import; pass `featureMetricsLedger` into the route context.
+- `src/server/routes.ts` — `GET /metrics/features` (mirrors `/tokens/summary`):
+  503-stub on a null ledger; `?sinceHours=` / `?feature=` filters; add the ctx type field.
+- `src/scaffold/templates.ts` — Agent Awareness: a "Per-Feature LLM Metrics" read-surface
+  blurb in the template Capabilities (new agents).
+- `src/core/PostUpdateMigrator.ts` — Migration Parity: an idempotent, content-sniffed
+  (`/metrics/features`) `migrateClaudeMd` block (existing agents). Marker shared with the
+  template → no double-patch.
+- `src/server/CapabilityIndex.ts` — classify the new `/metrics` route prefix as a
+  `featureMetrics` capability (surfaces in `GET /capabilities`), as the
+  capabilities-discoverability lint requires for every registered route prefix.
+
+**Files changed (docs/tests):**
+- `docs/specs/llm-feature-metrics-spec.md` (+ `.eli16.md`).
+- `tests/unit/FeatureMetricsLedger.test.ts` (+8), `tests/unit/PostUpdateMigrator-metricsFeatures.test.ts` (+3),
+  `tests/integration/metrics-features-routes.test.ts` (+3), `tests/e2e/metrics-features-lifecycle.test.ts` (+3),
+  and the `/metrics/features` registration in `tests/unit/feature-delivery-completeness.test.ts`.
+
+## Blast radius
+
+Confined to a new ledger + one new read route + CLAUDE.md awareness text. **No existing
+gate, sentinel, job, or flow changes behavior.** The ledger is read-only observability
+(same guarantee as TokenLedger); in Phase 1a nothing even writes to it in production yet
+(the funnel tap is Phase 1b), so the live effect is purely: a new `/metrics/features`
+endpoint that returns an empty-but-alive rollup.
+
+## Behavior delta
+
+| Scenario | Before | After |
+|---|---|---|
+| `GET /metrics/features` | 404 (no route) | 200 + per-feature rollup (empty until Phase 1b) |
+| ledger init fails / no stateDir | — | route 503-stubs (graceful, like /tokens) |
+| existing LLM gates (tone, coherence, stop) | run as-is | **unchanged** (no funnel edit) |
+| new agent init | no metrics awareness | template Capabilities mentions /metrics/features |
+| existing agent update | no metrics awareness | migrateClaudeMd appends it once (idempotent, no double-patch) |
+
+## Risks considered
+
+- **Collision with #638?** None — Phase 1a does not touch `CircuitBreakingIntelligenceProvider`
+  or any gate file #638 edits. The tap (Phase 1b) is built on top of #638's merged funnel.
+- **Observability breaking the path it observes?** No — `record()` swallows write errors;
+  the ledger is a side-channel, never a gate (Close the Loop: measurement must not become a blocker).
+- **ABI / native-module?** Opened via the same `NativeModuleHealer` path as TokenLedger.
+- **Double-patch a fresh agent?** No — template + migration share the `/metrics/features`
+  content-sniff marker; covered by an explicit test.
+- **Unbounded growth?** Same retention approach as TokenLedger (follow-up); Phase 1a writes
+  nothing in production yet.
+
+## Migration parity
+
+Handled: template (new agents) + content-sniffed `migrateClaudeMd` (existing agents),
+registered in `feature-delivery-completeness` `legacyMigratorSections` (a read-surface like
+`/codex/usage` / `/tokens`, not a framework-shadowed user capability). No config default,
+hook, or skill changed.
+
+## Tests
+
+3-tier, all green: unit (ledger + migration), integration (route 200/503/filter), E2E
+(feature-is-alive on the real AgentServer init: 200 not 503, auth-gated, read-only).
+`npm run lint` (tsc + destructive/LLM/URL-log/codex-drift) clean.

package/upgrades/side-effects/llm-ratelimit-bounded-wait.md

@@ -0,0 +1,46 @@
+# Side effects — coherence-critical LLM rate-limit bounded wait
+
+## What changes at runtime
+
+When the shared LLM circuit breaker is open (account rate-limited), a small set
+of coherence-critical guards now WAIT (bounded) for the window to clear before
+falling back, instead of instantly failing open. Everything else is unchanged.
+
+## Who is affected
+
+- **Callers that do NOT set `rateLimitWaitMs`** (the vast majority — every
+  best-effort/observability LLM consumer): **zero behavior change.** When the
+  breaker is open they still throw `LlmCircuitOpenError` immediately and run
+  their existing fail-open fallback. Proven by a dedicated test (instant throw,
+  zero sleeps, inner provider never called).
+- **MessagingToneGate** (outbound gate): when rate-limited, waits up to 120s for
+  the window, then falls back to its current pass-through. Net effect: under rate
+  limit, an outbound message may be delayed up to 2 min to be properly reviewed,
+  rather than sent unreviewed.
+- **UnjustifiedStopGate**: waits up to 8s (short — it's on the Stop critical
+  path), then its existing fail-open behavior. A stop may be delayed up to 8s
+  under rate limit.
+- **CoherenceGate high-stakes reviewers** (value-alignment, claim-provenance,
+  capability-accuracy, information-leakage): wait up to 60s. Other reviewers
+  unchanged (instant fail-open).
+
+## Blast radius
+
+- 7 files, all in `src/core/`. No config keys, no new env, no migration (the
+  change is compiled source, not an agent-installed file/hook/skill).
+- The breaker remains a single process-global singleton; no new global state
+  beyond a per-trip window length field.
+- `isRateLimitError` detection is byte-identical (reimplemented as
+  `classifyRateLimit(m).isLimit`).
+
+## Failure modes considered
+
+- **Latency under rate limit:** bounded by `maxWaitMs` per callsite; the
+  Stop-path wait is deliberately small (8s). A wait can never hang indefinitely.
+- **Thundering herd on window-close:** `acquireOrWait` re-consults `acquire()`
+  so waiters serialize behind the single half-open probe; exactly one call
+  probes the provider on recovery.
+- **Retry-after parse error:** parsed values are clamped to [1s, 15min]; any
+  unparseable/absurd value falls back to the flat 15-min default window.
+- **Load shedding preserved:** best-effort high-volume callers keep failing open,
+  so they don't consume the scarce probe slot or re-trip the breaker.

package/upgrades/side-effects/restart-immediately.md

@@ -0,0 +1,96 @@
+# Side-Effects Review — Primary-developer mode (`updates.restartImmediately`)
+
+**Slug:** `restart-immediately`
+**Date:** 2026-06-01
+**Author:** echo
+**Spec:** `docs/specs/restart-immediately-spec.md` (approved by Justin, Telegram topic 13435)
+
+## Summary of the change
+
+A per-agent, opt-in config flag `updates.restartImmediately` (default **false**).
+When true, the agent's update restarts are never deferred — not for active
+sessions (UpdateGate) and not for the restart window (AutoUpdater) — so it always
+rolls onto the latest version as soon as it is downloaded. Intended for the
+instar developer's own agent; explicitly **not** a fleet default.
+
+**Files changed (source):**
+- `src/core/UpdateGate.ts`:
+  - `UpdateGateConfig.alwaysRestartImmediately` (default false) + a constructor
+    default + `UpdateGateStatus.alwaysRestartImmediately`.
+  - `canRestart()` short-circuits at the very top when the flag is set:
+    `reset()` + return `{ allowed: true }` *before* listing sessions, so the
+    deferral clock never starts and the session monitor is never consulted.
+  - new `setAlwaysRestartImmediately(value)` — runtime toggle (clears an
+    in-flight deferral when turned on) for live `LiveConfig` edits.
+- `src/core/AutoUpdater.ts`:
+  - `AutoUpdaterConfig.restartImmediately` (default false) + constructor default;
+    constructs `UpdateGate` with `{ alwaysRestartImmediately: this.config.restartImmediately }`.
+  - `gatedRestart()` skips the restart-window deferral when the flag is set
+    (session gate already satisfied inside `UpdateGate`).
+  - `reloadDynamicConfig()` re-reads `updates.restartImmediately` (both the
+    `LiveConfig` path and the file-read fallback) and pushes changes into the
+    gate via the setter.
+  - `AutoUpdaterStatus.restartImmediately` (sourced from the gate's status).
+- `src/commands/server.ts`: maps `config.updates?.restartImmediately ?? false`
+  into the `AutoUpdater` config at construction.
+- `src/core/types.ts`: `UpdateConfig.restartImmediately?: boolean` (typed).
+
+**Files changed (tests):**
+- `tests/unit/UpdateGate.test.ts` — +7 (new `alwaysRestartImmediately` describe):
+  allow-despite-healthy-active-session (with a baseline assertion that the same
+  fixture blocks by default), pure-no-deferral-clock, monitor-never-consulted,
+  default-false-still-blocks, runtime setter true→allowed (clears deferral) and
+  false→blocks again.
+- `tests/unit/AutoUpdater.test.ts` — +2: default `restartImmediately` false;
+  `restartImmediately:true` reflected in `getStatus().restartImmediately`
+  (sourced from `gate.getStatus()` — proves the flag reached the real gate).
+
+## Blast radius
+
+Default false ⇒ **zero fleet impact**. With the flag unset, `canRestart` runs
+exactly as before (the new branch is skipped), `gatedRestart`'s window check is
+unchanged (`!this.config.restartImmediately` is true), and the gate is
+constructed with `alwaysRestartImmediately: false`. All 19 existing UpdateGate +
+18 existing AutoUpdater tests pass unmodified.
+
+## Behavior delta
+
+| Scenario | Before | After (flag OFF — default) | After (flag ON) |
+|---|---|---|---|
+| healthy active session + update ready | defer indefinitely | defer indefinitely (unchanged) | restart now |
+| outside restart window + update ready | defer to window | defer to window (unchanged) | restart now |
+| same version within 30 min | cooldown skip | cooldown skip (unchanged) | cooldown skip (preserved) |
+| two releases within ~15 min | dampener coalesces | dampener coalesces (unchanged) | dampener coalesces (preserved) |
+| sessions during restart | survive (CONTINUATION) | survive | survive (unchanged) |
+| `GET /updates/status` | no field | `restartImmediately: false` | `restartImmediately: true` |
+
+## Risks considered
+
+- **Does it kill sessions?** No. A server restart bounces the server process;
+  tmux sessions survive and resume via CONTINUATION. The flag changes *when* the
+  server restarts, never *whether* sessions survive.
+- **Restart loop / storm?** The same-version 30-min cooldown and the cascade
+  dampener are deliberately preserved — only genuinely back-to-back distinct
+  releases coalesce (≤15 min), and a flapping single version cannot re-restart.
+- **Accidental fleet-wide enablement?** Default false + no `migrateConfig` entry
+  ⇒ existing and new agents are false-by-absence; only an explicit per-agent
+  config edit turns it on. This is intentional (the directive forbids a fleet
+  default).
+- **Stale cached flag after a live edit?** `reloadDynamicConfig()` re-reads it
+  each tick and pushes it into the gate, and the setter clears any in-flight
+  deferral — so enabling it on disk takes effect at the next tick without a
+  restart.
+
+## Migration parity
+
+No agent-installed file changes (no hook/skill/CLAUDE.md template). A new config
+default is normally added to `migrateConfig()` — **intentionally not done here**:
+the flag must default to false for the fleet, and absence already yields false in
+code. Adding a fleet migration that set it true would violate the directive
+("not for all instar agents"). Echo's own `.instar/config.json` is set directly
+(operational, outside this PR).
+
+## Tests / lint
+
+19 UpdateGate (+7 new) + 18 AutoUpdater (+2 new) tests pass; `npm run lint`
+(tsc + destructive/LLM/URL-log/codex-drift) clean.