@mindrian_os/cli 1.16.0-beta.5 → 1.16.0-beta.7

package/CHANGELOG.md

@@ -1,3 +1,41 @@
+## [1.16.0-beta.7] - 2026-08-01
+
+### Added
+- 
+
+### Fixed
+- **The statusline's room-health chip actually updates now, instead of showing you one frozen
+  warning forever and sending you to a command that could never clear it.** The chip that reads
+  `⚠ · -> run /mos:doctor --fix` is supposed to reflect whether your current room is healthy. In
+  practice it was stuck on whatever it happened to say the last time somebody ran a diagnostic by
+  hand in a terminal, which for most people means it either never appeared or never went away.
+  Running `/mos:doctor`, or even `/mos:doctor --fix`, did nothing to it -- not because those
+  commands were broken, but because they were never connected to it in the first place. The chip
+  reads a small cache file, and the one function in the whole codebase that writes that file had
+  exactly one caller: a manual command-line flag that nothing in the product ever runs. So the
+  warning was real once, and then it was just a fossil. Worse, the advice it gave you pointed at
+  the one command structurally incapable of helping. There WAS a second place in the code that
+  tried to wire this up, and it looked wired -- it checked whether the diagnostic module offered
+  a bind-time health function before calling it -- but that function was never written, so the
+  check was permanently false and the whole branch was dead code that read like working code, with
+  a comment promising a follow-up phase that never shipped. Now, whenever your session binds to a
+  room -- through the MCP front door or through the CLI's own binding path, both of which now run
+  the same single health check -- a real, current reading gets written, and the chip tells you what
+  is true right now. A health check that fails can never block or break a bind. And when the room
+  cannot be located at all, it says so honestly as drift rather than quietly reporting all-clear,
+  because the whole point of this fix is that a status signal you cannot trust is worse than no
+  signal. Verified end to end through the real MCP server: a stale drift warning cleared to sound
+  with a fresh timestamp on the next bind.
+- **A stale local search index could get stuck stale forever, even after a "successful" repair.**
+  Each room keeps a small lexical search index so Eureka can find relevant nodes fast. When nodes
+  get deleted, that index is supposed to self-heal the next time it rebuilds. It turned out the
+  rebuild only ever refreshed rows for nodes that still exist -- it had no way to remove rows left
+  behind by deleted ones, so once a room accumulated deleted nodes, no amount of rebuilding could
+  ever clear them. The one place in the codebase that DID know how to clean those rows up only ran
+  during a full graph rebuild, not the lightweight repair every other path relied on. Now that
+  cleanup step runs every time the index rebuilds, not just on a full rebuild, so a room's search
+  index actually recovers instead of silently staying broken behind a "fixed" label.
+
 ## [1.16.0-beta.5] - 2026-07-31
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindrian_os/cli",
-  "version": "1.16.0-beta.5",
+  "version": "1.16.0-beta.7",
   "description": "Install MindrianOS into Claude Code with one command -- `npx @mindrian_os/cli`. Ships the MindrianOS plugin (Larry + PWS methodology + Data Room) plus a setup/diagnostics CLI (install/doctor/update).",
   "scripts": {
     "mcp": "node bin/mindrian-mcp-server.cjs",