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

package/CHANGELOG.md

@@ -1,3 +1,107 @@
+## [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
+- **The ranked dial you pick from now actually listens to what you said, and Brain's own
+  suggestion can no longer be silently discarded (Phase 245).** The previous entry documented an
+  honest finding: the sensor bank that watches a turn decides only WHETHER a dial appears, never
+  WHAT sits on top of it -- that ranking came entirely from your room's graph-node recency, a
+  completely separate code path. This phase closes that gap for real, at the one seam that
+  actually renders the dial (`scripts/intent-classifier.cjs`), not the seam that looked like the
+  right place but turned out to be a dead end -- a same-day research pass caught that the obvious
+  fix (wiring the fusion into `reach-hedge-ranker.cjs`) would have shipped, passed every test, and
+  moved the visible dial by nothing, because that ranker and the dial's renderer read the same
+  score map without either one feeding the other. Two turns with different intent in the same
+  session now surface two different top-ranked cards, proven by literally commenting out the merge
+  and watching the acceptance test fail with the exact symptom the SPEC named, then restoring it
+  and watching it pass. Brain's own suggested next step, when Brain has one, now genuinely factors
+  into that ranking too -- previously it was computed nowhere reachable, buried behind a routing
+  precedence chain a fired sensor almost always won first, so even a fresh, correct Brain read had
+  no way to ever surface. Bounded so it stays a nudge: no single signal can push a card across the
+  frozen 0.70 "recommended" threshold on its own, verified by sweeping the fusion math with
+  deliberately extreme inputs.
+- **`BRAIN.md` now actually refreshes itself instead of quietly going stale for weeks while still
+  claiming to be fresh (Phase 245).** The re-derivation trigger, queue, and drain machinery for
+  keeping a room's Brain-derived insight current already existed, fully wired -- it just silently
+  did nothing. The drain measured its own timing budget starting *before* a slow one-time
+  `require()`, so a cold process routinely blew a 100ms budget it thought it had 100ms left in,
+  aborted after spawning zero re-derive jobs, and had already removed every job from the queue on
+  the way in. No error, no warning -- just a room that reports `staleness: "fresh"` while running
+  on a read from 12 days ago. Fixed at the root (hoist the slow require above the clock, and make
+  queue removal contingent on an actual job having spawned, so a future slow tick degrades
+  gracefully instead of losing work outright), not patched at the symptom. `BRAIN.md` now
+  re-derives on any of three real triggers: the room's governing thought changing, a section aging
+  past its staleness window, or an explicit ask -- never a blanket call on every single turn, which
+  independent research confirmed would blow the product's own 1200ms navigation budget.
+- **Six Thinking Hats can now surface itself, proactively, for the first time (Phase 245).** `hats`
+  has been one of exactly six frozen reach categories since Phase 148 -- fully built on the render
+  side, completely unreachable from the sensor side. A navigator could only ever get there by
+  picking it manually, directly contradicting the product's own doctrine for when a hats rotation
+  should be offered. A new sensor closes the gap, firing when two or more fresh, unresolved
+  contradictions accumulate in a room (one is treated as a bridge to another topic; two or more
+  unresolved is treated as a genuine perspective lock worth rotating hats on) -- tuned specifically
+  not to double-fire alongside the existing sensor that already reacts to the first contradiction.
+  Also repaired: three shipped commands had been declaring a hats trigger that pointed at a sensor
+  which fires a completely different category and could never have produced hats in the first
+  place -- a real, live registry-truth bug now corrected alongside the sensor that actually makes
+  the declaration true.
+- **When multiple signals fire on the same turn, the winner is now a documented priority, not
+  whichever file happened to load first (Phase 245).** 65% of the sensor bank can independently
+  produce the same output category on a single turn, and until now the tie always went to
+  registration order -- an accident of file layout, not a designed hierarchy. A frozen,
+  doctrine-authored priority table now decides, enforced by a completeness gate that fails the
+  build closed if a sensor ships without a ranked entry, so this can't silently drift again the way
+  the registration-order behavior did.
+- **A Part 8 privacy guard was blocking harmless, contentless Brain calls while letting real
+  user-content calls through -- backwards from what a leak-prevention guard should ever do (Phase
+  245).** Root-caused to a single over-broad catch-all with no way to recognize a call that
+  structurally cannot carry user data. A stats-style call with no arguments now passes; the
+  catch-all itself is untouched and still blocks by default on anything that actually could carry
+  content.
+- **Frozen, zero-cost mapping from the product's ten canonical routing verbs to the six dial
+  categories they can actually produce (Phase 245).** Half the vocabulary had no path to ever fire
+  at all -- not a bug exactly, but an unmeasured gap nobody had named. Derived once, offline, from
+  a local sentence encoder already shipped in this repo for an unrelated feature (Canon Part 7:
+  reuse, don't rebuild) -- zero network calls, zero ongoing cost, and ground truth checked first so
+  a close embedding score can never overrule a fact the routing engine already knows for certain.
+
 ## [1.16.0-beta.3] - 2026-07-31
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindrian_os/cli",
-  "version": "1.16.0-beta.3",
+  "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",