instar 0.28.35 → 0.28.41

package/upgrades/0.28.10.md

@@ -1,19 +0,0 @@
-# Upgrade Guide — v0.28.10
-
-<!-- bump: patch -->
-
-## What Changed
-
-Job gate checks now retry up to 3 times with a 5-second delay between attempts before recording a skip. Previously, a single gate failure (e.g., health check returning non-zero during a brief server restart) would immediately skip the job. This caused guardian jobs scheduled at minute 0 to consistently miss their windows when the server restarts hourly at the same time.
-
-The existing `scheduleRetry` mechanism (1min, 5min, 15min escalating retries) remains as a second layer, but the in-gate retry handles the most common case: a health endpoint that's unavailable for a few seconds during restart.
-
-## What to Tell Your User
-
-- **More reliable scheduled jobs**: "Jobs that depend on health checks are now more resilient to brief server restart windows. If you've noticed guardian or monitoring jobs being skipped, they should start running consistently now."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Gate retry on transient failure | Automatic — no configuration needed |

package/upgrades/0.28.11.md

@@ -1,19 +0,0 @@
-# Upgrade Guide — v0.28.11
-
-<!-- bump: patch -->
-
-## What Changed
-
-The GET /context endpoint now includes the `contextDir` path in its response, making it possible for agents to verify that the server is looking in the same directory where their context files live. This helps diagnose the "0 bytes for all segments" issue that occurs when there's a path mismatch between the server's configured state directory and where hooks/sessions create context files.
-
-Response format changed from an array of segments to `{ contextDir: string, segments: [...] }`.
-
-## What to Tell Your User
-
-- **Better context diagnostics**: "If your context segments ever show as empty despite files being on disk, the context endpoint now shows the exact directory path the server is checking. This makes it easy to spot path mismatches."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Context directory path in response | GET /context now returns contextDir alongside segments |

package/upgrades/0.28.13.md

@@ -1,11 +0,0 @@
-## What Changed
-
-- **Prerequisites installer now auto-installs Homebrew on macOS.** Previously, on a fresh Mac without Homebrew, the installer would bail out and tell the user to install Homebrew manually. Now it offers to install Homebrew non-interactively using the official install script, then proceeds to install tmux via `brew install tmux`.
-
-## What to Tell Your User
-
-Nothing — this is a seamless improvement to the setup experience. Users on fresh Macs will now be prompted to install Homebrew automatically instead of being told to do it themselves.
-
-## Summary of New Capabilities
-
-- `npx instar` on a fresh macOS machine now handles the full dependency chain: Homebrew -> tmux -> Claude CLI, all with interactive prompts and no manual steps required.

package/upgrades/0.28.15.md

@@ -1,11 +0,0 @@
-## What Changed
-
-- **Fixed Homebrew installer failing on admin accounts.** The previous version used NONINTERACTIVE mode which prevented the sudo password prompt, causing installation to fail even on admin accounts with a misleading "needs to be an Administrator" error. Now stdio is inherited so the user can enter their password when prompted. Timeout also increased to 10 minutes to accommodate Xcode Command Line Tools installation.
-
-## What to Tell Your User
-
-Nothing — this is a fix to the setup experience. Installing on a fresh Mac will now correctly prompt for the password instead of failing silently.
-
-## Summary of New Capabilities
-
-No new capabilities — bug fix to Homebrew auto-install from 0.28.13.

package/upgrades/0.28.18.md

@@ -1,12 +0,0 @@
-## What Changed
-
-- **GitHub CLI is now a real prerequisite.** Previously the setup wizard only emitted a soft warning when gh was missing, then continued without it — silently disabling cloud-backed agent discovery, GitHub backup sync, CI status checks, and PR/issue management. GitHub CLI is now part of the prerequisites check alongside Node.js, tmux, and Claude CLI, with auto-install support via Homebrew on macOS and apt on Linux. If Homebrew is missing on macOS, the wizard offers to install Homebrew first (same flow as the existing tmux path).
-
-## What to Tell Your User
-
-If you're on a fresh machine, the setup wizard will now offer to install GitHub CLI automatically. After install, I can help you sign in to GitHub so I can sync state across machines and discover any other agents you've set up. Without GitHub CLI, I still work locally but can't back things up to GitHub or find your other agents.
-
-## Summary of New Capabilities
-
-- GitHub CLI added as a fourth prerequisite with auto-install on macOS (Homebrew) and Linux (apt)
-- Two-step install flow: if Homebrew is missing on macOS, wizard offers to install it before installing GitHub CLI

package/upgrades/0.28.20.md

@@ -1,19 +0,0 @@
-# Upgrade Guide — vNEXT
-
-<!-- bump: patch -->
-
-## What Changed
-
-- **Setup wizard now offers GitHub sign-in BEFORE asking for an agent name.** Previously, when GitHub CLI was installed but not authenticated (or when the discovery scan ran without GitHub access), the wizard silently moved on to "what should we call your agent?" — even if the user already had agents backed up to GitHub from another machine. Users were creating duplicates instead of restoring. The Entry Point B branches in `setup-wizard/SKILL.md` for `gh_status="auth-needed"` and `gh_status="unavailable"` are now MANDATORY blocking steps with imperative language.
-- **GitHub Device-Code Auth Flow documented.** Running `gh auth login --web --git-protocol https` synchronously inside Claude Code's Bash tool blocks on the device-code prompt and the user sees a frozen command with no instructions. The skill now instructs the agent to: run gh auth in the background, poll its output for the device code and URL, present them to the user conversationally, then poll `gh auth status` until the user completes the sign-in. Same flow is referenced from Phase 4 (cloud backup) so there's one canonical pattern.
-
-## What to Tell Your User
-
-If you're setting up a fresh machine and you've used Instar before, the wizard will now offer to sign you in to GitHub first so I can find any agents you've backed up — instead of creating a duplicate. The sign-in itself is also smoother: I'll show you the code to enter at github.com/login/device right in our chat instead of leaving you staring at a stuck terminal.
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Mandatory pre-name GitHub auth offer | Automatic during setup wizard |
-| Background device-code auth flow | Automatic during setup wizard |

package/upgrades/0.28.21.md

@@ -1,23 +0,0 @@
-# Upgrade Guide — v0.28.21
-
-<!-- bump: patch -->
-
-## What Changed
-
-- **Threadline delivery honesty**: `/messages/relay-agent` now awaits `ThreadlineRouter` and returns the real outcome (`spawned`, `resumed`, `injected`, `queued`, `error`) instead of always saying `delivered:true`. The `threadline_send` MCP tool surfaces the actual status to callers.
-- **First-contact messages no longer dropped**: `ThreadlineRouter` mints a UUID threadId for messages without one, routing them through `spawnNewThread` instead of silently returning `{handled:false}`.
-- **Fingerprint-based identity**: Reply waiters rekeyed by threadId (prevents same-name agent collisions). Self-guard compares fingerprints. Ambiguous targets (multiple agents sharing a name) now fail loudly with a fingerprint-qualifier hint.
-- **Live-session injection**: `ThreadlineRouter` tries `MessageDelivery.deliverToSession` (tmux send-keys) before falling back to spawn/resume — messages can reach already-running sessions without spawning a new process.
-
-## What to Tell Your User
-
-Agent-to-agent messaging (threadline) has been fixed. Messages between agents now actually reach the recipient's active session, first-contact messages work, and agents with the same name on different machines no longer collide.
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Honest delivery status | `threadline_send` now reports `spawned` / `resumed` / `injected` / `queued` instead of always `delivered` |
-| First-contact messaging | Just send — no threadId needed on first message, one is minted automatically |
-| Same-name agent disambiguation | Use `name:fpPrefix` format (e.g., `luna:ab12cd34`) when multiple agents share a name |
-| Live-session injection | Automatic — messages try injection into running sessions before spawning new ones |

package/upgrades/0.28.22.md

@@ -1,23 +0,0 @@
-# Upgrade Guide — v0.28.22
-
-<!-- bump: patch -->
-<!-- Valid values: patch, minor, major -->
-<!-- patch = bug fixes, refactors, test additions, doc updates -->
-<!-- minor = new features, new APIs, new capabilities (backwards-compatible) -->
-<!-- major = breaking changes to existing APIs or behavior -->
-
-## What Changed
-
-- Replaced all `execSync` calls in server startup (better-sqlite3 auto-rebuild) with shell-free `execFileSync` using npm's CLI JS directly. Fixes "spawnSync /bin/sh ENOENT" failures in minimal/containerized environments.
-- Added `findNpmCli()` helper that locates npm's entry point without requiring a shell.
-- Affects `ensureSqliteBindings()` preflight and TopicMemory auto-rebuild fallback.
-
-## What to Tell Your User
-
-- **Better startup reliability**: "Agents running in Docker or minimal Linux environments should no longer see SemanticMemory or TopicMemory degradation at startup. The native module rebuild now works without requiring a system shell."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Shell-free native module rebuild | Automatic — no user action needed |

package/upgrades/0.28.23.md

@@ -1,19 +0,0 @@
-# Upgrade Guide — v0.28.23
-
-<!-- bump: patch -->
-
-## What Changed
-
-- Replaced all shell-dependent npm calls in server startup (better-sqlite3 auto-rebuild) with shell-free alternatives using npm's CLI JS directly via Node.js. Fixes "spawnSync /bin/sh ENOENT" failures in minimal/containerized environments.
-- Added findNpmCli helper that locates npm's entry point without requiring a shell.
-- Affects ensureSqliteBindings preflight and TopicMemory auto-rebuild fallback.
-
-## What to Tell Your User
-
-- **Better startup reliability**: "Agents running in Docker or minimal Linux environments should no longer see memory system degradation at startup. The native module rebuild now works without requiring a system shell."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Shell-free native module rebuild | Automatic — no user action needed |

package/upgrades/0.28.24.md

@@ -1,18 +0,0 @@
-# Upgrade Guide — v0.28.24
-
-<!-- bump: patch -->
-
-## What Changed
-
-- The /semantic/export-memory endpoint no longer overwrites MEMORY.md when SemanticMemory has 0 entities. Previously, an empty export would destroy manually-curated memory content. Now skips the write and returns existing file metadata with a skipped flag.
-- MemoryExporter.write() guards against empty-entity overwrites at the class level.
-
-## What to Tell Your User
-
-- **Memory file protection**: "Your MEMORY.md is now safe from accidental overwrites. If the knowledge graph hasn't been populated yet, the export will leave your existing memory file untouched instead of replacing it with an empty template."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Empty-export guard | Automatic — no user action needed |

package/upgrades/0.28.25.md

@@ -1,21 +0,0 @@
-# Upgrade Guide — v0.28.25
-
-<!-- bump: patch -->
-
-## What Changed
-
-- Fixed dashboard apiFetch to properly pass method, headers, and body options to fetch. Feature toggles and autonomy profile changes now persist instead of silently failing as GET requests.
-- Fixed degradation-digest job gate and skill to read from the correct file path (.instar/degradations.json instead of .instar/state/degradation-events.json). The job can now actually run.
-- Fixed MemoryExporter to not overwrite existing MEMORY.md when SemanticMemory has 0 entities.
-
-## What to Tell Your User
-
-- **Dashboard feature toggles work now**: "Feature toggles and autonomy profile changes in the dashboard now actually save. Previously they appeared to toggle but silently reverted."
-- **Degradation monitoring active**: "The degradation digest job can now run properly. It was blocked by a wrong file path since it was created."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Working dashboard toggles | Toggle features in the dashboard Features tab |
-| Degradation digest job | Automatic — runs every 4 hours when degradation events exist |

package/upgrades/0.28.26.md

@@ -1,20 +0,0 @@
-# Upgrade Guide — v0.28.26
-
-<!-- bump: patch -->
-
-## What Changed
-
-Fixed a false-positive detection bug in OrphanProcessReaper where any process with "claude" as a substring in its file path (e.g., cloudflared running from a `/demiclaude/` directory) was incorrectly classified as a Claude Code process. The reaper now uses regex word-boundary matching to identify actual Claude CLI binaries, and the server's own tmux session is protected from being killed during orphan cleanup.
-
-Previously, on agents whose project name contained "claude" (like "demiclaude"), the reaper would kill cloudflared every hour, taking down the server tmux session as collateral damage and causing progressive restart drift.
-
-## What to Tell Your User
-
-- **Stability fix**: "The background process monitor was accidentally killing my own server every hour because of a name collision. That's fixed now — no more mysterious restarts."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Improved orphan process detection | Automatic — no action needed |
-| Server session kill protection | Automatic — server tmux session can no longer be killed by the orphan reaper |

package/upgrades/0.28.27.md

@@ -1,20 +0,0 @@
-# Upgrade Guide — v0.28.27
-
-<!-- bump: patch -->
-
-## What Changed
-
-Fixed a false-positive detection bug in OrphanProcessReaper where any process with "claude" as a substring in its file path (e.g., cloudflared running from a directory whose name contains "claude") was incorrectly classified as a Claude Code process. The reaper now uses regex word-boundary matching to identify actual Claude CLI binaries, and the server's own tmux session is protected from being killed during orphan cleanup.
-
-Previously, on agents whose project name contained "claude", the reaper would kill cloudflared every hour, taking down the server tmux session as collateral damage and causing progressive restart drift.
-
-## What to Tell Your User
-
-- **Stability fix**: "The background process monitor was accidentally killing my own server every hour because of a name collision. That's fixed now — no more mysterious restarts or time drift."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Improved orphan process detection | Automatic — no action needed |
-| Server session kill protection | Automatic — server tmux session can no longer be killed by the orphan reaper |

package/upgrades/0.28.28.md

@@ -1,20 +0,0 @@
-# Upgrade Guide — v0.28.28
-
-<!-- bump: patch -->
-
-## What Changed
-
-Fixed a false-positive detection bug in OrphanProcessReaper where any process with "claude" as a substring in its file path (e.g., cloudflared running from a directory whose name contains "claude") was incorrectly classified as a Claude Code process. The reaper now uses regex word-boundary matching to identify actual Claude CLI binaries, and the server's own tmux session is protected from being killed during orphan cleanup.
-
-Previously, on agents whose project name contained "claude", the reaper would kill cloudflared every hour, taking down the server tmux session as collateral damage and causing progressive restart drift.
-
-## What to Tell Your User
-
-- **Stability fix**: "The background process monitor was accidentally killing my own server every hour because of a name collision. That's fixed now — no more mysterious restarts or time drift."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Improved orphan process detection | Automatic — no action needed |
-| Server session kill protection | Automatic — server tmux session can no longer be killed by the orphan reaper |

package/upgrades/0.28.30.md

@@ -1,25 +0,0 @@
-# Upgrade Guide — v0.28.30
-
-<!-- bump: patch -->
-
-## What Changed
-
-The health endpoint's systemReview section now includes a failedProbes array with per-probe details (probeId, name, tier, error, remediation) so agents can drill into failures without a second API call. A detailsUrl field points to /system-reviews/latest for the full report.
-
-Two new aliases were added for discoverability:
-- GET /health/probes — returns all probe results (pass and fail) with timestamps, stats, and skipped list.
-- GET /system-review (singular) — alias for /system-reviews/latest, matching the natural URL shape agents try first.
-
-Previously when the health endpoint reported 3 of 16 probes failed, there was no way to see WHICH probes failed from the health response itself. Agents had to know the exact plural endpoint name to drill in. This closes that gap — failures are now self-describing at the top-level health call, and the common URL shapes agents naturally try now work.
-
-## What to Tell Your User
-
-- **Clearer health drill-down**: "When I check my own system health and see failures, I can now immediately see which checks failed and what to do about them — no more guessing."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Per-probe failure details in health | GET /health then read systemReview.failedProbes |
-| Full probe list (pass and fail) | GET /health/probes |
-| Latest review alias | GET /system-review |

package/upgrades/0.28.31.md

@@ -1,38 +0,0 @@
-# Upgrade Guide — v0.28.31
-
-<!-- bump: patch -->
-
-## What Changed
-
-Scheduler skip events now report the actual gating reason instead of always saying "quota".
-
-When a job is blocked from spawning, the scheduler runs `canRunJob(priority)`. Previously this callback returned a bare `boolean`, so when it returned `false` the scheduler unconditionally logged `Job "X" skipped (quota)` and recorded reason `quota` in the SkipLedger — even when the real cause was memory pressure or another gate stacked on top of quota.
-
-Now the callback may return either a boolean (legacy behavior) or a richer `CanRunJobResult`:
-
-```ts
-interface CanRunJobResult {
-  allowed: boolean;
-  reason?: SkipReason;   // 'quota' | 'memory-pressure' | 'gate' | ...
-  detail?: string;       // human-readable context
-}
-```
-
-The server's memory gate wrapper (`src/commands/server.ts` ~line 4097) now returns the rich form, surfacing `memory-pressure` plus the underlying `memCheck.reason` (e.g. `"elevated (79.9%)"`). The scheduler logs this verbatim, records it in the SkipLedger as `memory-pressure`, and includes `gateReason` / `gateDetail` in the `job_skipped` event metadata.
-
-A new `'memory-pressure'` value was added to the `SkipReason` union.
-
-This fixes a long-standing diagnostic confusion where 31+ jobs would appear "skipped (quota)" in logs while `/quota` reported normal — because the actual cause was memory pressure on a 16GB machine sitting at 79% baseline usage.
-
-Backwards compatible: any existing `canRunJob` wrapper that returns a plain boolean continues to work and still records reason `quota`.
-
-## What to Tell Your User
-
-- **Clearer skip reasons**: "When I can't start a job, I'll now tell you exactly why — memory pressure versus quota versus a gate check — instead of always blaming quota. That should make it much faster to figure out why scheduled work isn't running."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Memory-pressure skip reason | Automatic — appears in skip ledger and `job_skipped` events |
-| Rich `CanRunJobResult` from gate callbacks | Return `{ allowed, reason, detail }` from custom `canRunJob` wrappers |

package/upgrades/0.28.32.md

@@ -1,22 +0,0 @@
-# Upgrade Guide — v0.28.32
-
-<!-- bump: patch -->
-
-## What Changed
-
-- **Threadline `getThreadHistory` now returns real messages.** The MCP stdio entry point previously hard-coded an empty `ThreadHistoryResult`, so agents could never read any Threadline conversation content — only metadata. The tool now queries the local agent server's `GET /messages/thread/:threadId` endpoint, normalizes the returned `MessageEnvelope` list into `ThreadHistoryMessage` shape (id, from, body, timestamp, threadId), applies the requested `limit` (trailing window of most-recent messages) and optional `before` timestamp filter, and reports an accurate `totalCount` / `hasMore`. Fails soft to an empty result on any transport or server error so a stopped agent server doesn't surface as an MCP error.
-- Feedback cluster: `cluster-threadline-history-returns-empty-getthreadhistory-is-stubbed`.
-- **Built-in job gates self-heal stale port references.** When the configured server port no longer matched the port baked into an existing `jobs.json` entry, built-in job `gate` and `execute.value` commands kept their old `localhost:NNNN` references. Health-gated jobs like `state-integrity-check`, `guardian-pulse`, `session-continuity-check`, and `memory-export` would fail their gate forever and silently skip every run. `refreshJobs` now scans built-in jobs (matched by slug against `getDefaultJobs`) and rewrites stale `localhost:OTHERPORT/` references to the configured port. User-defined jobs are left untouched. Fallback default port was also normalized from 4321 to 4040 to match the rest of the codebase.
-- Feedback cluster: `cluster-job-gate-commands-hardcoded-to-port-4040-ignoring-configured`.
-
-## What to Tell Your User
-
-- **Conversation history now works:** "I can finally read back the messages other agents have sent me — before this release I could see that a conversation existed but not what anyone actually said."
-- **Health checks start working again after a port change:** "If you ever moved the agent to a different port, some of my background health checks were quietly skipping every run because they were still looking at the old port. They'll fix themselves on the next refresh and start running normally again."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Read Threadline conversation history | `threadline_history` MCP tool now returns actual message content |
-| Self-healing job gates | Built-in jobs whose gate or execute commands reference a stale port get rewritten on refresh |

package/upgrades/0.28.33.md

@@ -1,22 +0,0 @@
-# Upgrade Guide — v0.28.33
-
-<!-- bump: patch -->
-<!-- Valid values: patch, minor, major -->
-<!-- patch = bug fixes, refactors, test additions, doc updates -->
-<!-- minor = new features, new APIs, new capabilities (backwards-compatible) -->
-<!-- major = breaking changes to existing APIs or behavior -->
-
-## What Changed
-
-- **Built-in job gate/execute commands now self-heal on refresh.** Generalizes the v0.28.32 port-repair fix. `refreshJobs` now syncs the entire `gate` field and `execute.type`/`execute.value` fields of built-in jobs (matched by slug) to the current source-of-truth defaults from `getDefaultJobs(port)`. User-tunable fields (`enabled`, `schedule`, `priority`, `model`, `telegramNotify`, etc.) are left untouched. This closes a class of bugs where existing installs' `jobs.json` keeps old gate/execute logic after a source update, causing built-in jobs to silently skip forever. The motivating case: `degradation-digest` had an old gate that checked `.instar/state/degradation-events.json` (always empty), while the current source checks `.instar/degradations.json` (the real file) — leaving 11 unreported degradations undetected for ~2 weeks. Contract change: built-in `gate`/`execute` are implementation details that track the codebase. To customize, fork under a different slug.
-- Feedback cluster: `cluster-degradation-digest-gate-checks-wrong-file-job-never-runs`.
-
-## What to Tell Your User
-
-- **Background health checks self-heal after upgrades:** "A few of my background checks were quietly looking at outdated places after past upgrades and never running. They'll fix themselves automatically. One that was supposed to surface system warnings to you had been dark for about two weeks — it'll start working again."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Self-healing built-in job gate/execute | Automatic on refresh — built-in jobs whose gate or execute commands drifted from source defaults are resynced |

package/upgrades/0.28.35.md

@@ -1,37 +0,0 @@
-# Upgrade Guide — v0.28.35
-
-<!-- bump: patch -->
-
-## What Changed
-
-**Telegram polling diagnostics + transient 401 retry.**
-
-Previously, `TelegramAdapter.poll()` set `this.polling = false` permanently on
-ANY 401 response — including transient auth blips — with no retry and no signal
-to the probe layer. Health probes reported "polling not active" with no WHY,
-and operators had to dig through logs to discover whether the token was actually
-revoked or had just hiccuped.
-
-This release adds:
-- **Single 30s retry on first 401** before declaring fatal. Genuine token
-  revocation still stops polling; transient 401s recover automatically.
-- **Diagnostic state on the adapter**: `lastError`, `consecutivePollErrors`,
-  `fatalReason` (`'401' | 'network' | null`), `stoppedAt`. Exposed via
-  `TelegramAdapter.getStatus()`.
-- **MessagingProbe** now surfaces these fields. The `instar.messaging.connected`
-  probe description includes the fatal reason or last error, and remediation
-  steps for a 401 now point operators at @BotFather rather than generic advice.
-
-Reset of all diagnostic fields happens in `start()` so re-starts begin clean.
-
-## What to Tell Your User
-
-- **Better visibility when Telegram messaging stops**: "If my Telegram connection ever drops, I can now tell you exactly why instead of just saying it's down."
-- **Resilience to brief auth hiccups**: "A momentary blip in the Telegram service won't permanently knock me offline anymore — I'll retry once before giving up."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Telegram polling diagnostics | Automatic — visible in health probe output |
-| Transient 401 retry | Automatic — single 30s retry before declaring fatal |

package/upgrades/0.28.5.md

@@ -1,17 +0,0 @@
-# Upgrade Guide — v0.28.5
-
-<!-- bump: patch -->
-
-## What Changed
-
-- **Topic cleanup no longer closes explicitly-configured topics**: The startup topic cleanup was closing forum topics for on-alert and silent jobs even when those topics were explicitly configured in jobs.json or shared with other active jobs. Now only dynamically-created topic mappings are cleaned up, and only if no other job references the same topic.
-
-## What to Tell Your User
-
-- **"Your Telegram forum topics should stay open now"**: If your user noticed that certain Telegram topics kept getting closed after server restarts, that should be resolved. The system was incorrectly treating explicitly-configured topics as stale.
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Safe topic cleanup | Automatic — explicitly-configured topics are preserved on restart |

package/upgrades/0.28.7.md

@@ -1,24 +0,0 @@
-# Upgrade Guide — v0.28.7
-
-<!-- bump: patch -->
-<!-- Valid values: patch, minor, major -->
-<!-- patch = bug fixes, refactors, test additions, doc updates -->
-<!-- minor = new features, new APIs, new capabilities (backwards-compatible) -->
-<!-- major = breaking changes to existing APIs or behavior -->
-
-## What Changed
-
-Added `PATCH /config` endpoint that all FeatureDefinition enable/disable actions reference. Previously, toggling features from the dashboard (evolution, threadline, publishing, tunnel, etc.) returned 404 because the endpoint didn't exist. The new endpoint deep-merges the request body into config.json with an allowlist of safe config keys, and updates runtime config.
-
-Also includes CI test fixes from previous commits (trust wiring, quota tracking, config validation, job scheduler edge cases).
-
-## What to Tell Your User
-
-- **Dashboard feature toggles now work**: "You can now enable/disable features from the dashboard — the toggle buttons actually persist your choice."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Config patch API | `PATCH /config` with JSON body — dashboard uses this automatically |
-| Feature toggle persistence | Toggle features on/off from dashboard, changes persist to config.json |

package/upgrades/0.28.8.md

@@ -1,21 +0,0 @@
-# Upgrade Guide — v0.28.8
-
-<!-- bump: patch -->
-
-## What Changed
-
-Fixed a bug where `loadConfig()` silently dropped many optional config fields — including `safety`, `evolution`, `agentAutonomy`, `externalOperations`, `autonomyProfile`, `notifications`, `responseReview`, `inputGuard`, `dashboard`, and `moltbridge`. These fields were defined in `InstarConfig` and written to `config.json` by subsystems like `AutonomyProfileManager.applyProfileToConfig()`, but were never read back because `loadConfig()` constructed its return object with only explicitly listed properties.
-
-The fix spreads `fileConfig` as the base object before applying explicit overrides, so all config fields pass through while preserving existing defaults and transformations.
-
-**Impact**: If you had manually set `safety.level` in your config or changed autonomy profile settings, those overrides were being silently ignored — the system always fell back to profile defaults. After this update, your config file settings will be respected.
-
-## What to Tell Your User
-
-- **Config settings now fully respected**: "If you've customized safety levels, autonomy settings, or other advanced configuration, those settings are now properly loaded. Previously they could be silently ignored — that's fixed now."
-
-## Summary of New Capabilities
-
-| Capability | How to Use |
-|-----------|-----------|
-| Config passthrough fix | Automatic — all config.json fields now properly loaded |