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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/CHANGELOG.md +53 -0
  2. package/package.json +1 -1
package/CHANGELOG.md CHANGED
@@ -1,3 +1,56 @@
1
+ ## [1.16.0-beta.9] - 2026-08-05
2
+
3
+ ### Changed
4
+ - **`/mos:pws-brain` now says plainly that it's retired, instead of quietly sending you down a
5
+ dead path.** The command was built to compare two ways of answering methodology questions
6
+ side by side: the production Brain, and a separate experimental Aura Agent. Both of those
7
+ routes have since been folded into one unified Memgraph-backed Brain, so the comparison this
8
+ command exists to run no longer means anything, and running it just walked you into a
9
+ pre-flight failure with no explanation of why. The command's description, its retirement
10
+ reason, and a note right under its own heading now say RETIRED and point at the real backend
11
+ by name, so anyone who reaches for it (navigator or Larry) understands immediately why it's
12
+ inert instead of guessing at a broken dependency. Nothing about the harness itself was
13
+ deleted, so it is still there to read as a historical record of the comparison, or to revive
14
+ deliberately if a future backend candidate ever needs the same side-by-side treatment again.
15
+
16
+ ## [1.16.0-beta.7] - 2026-08-01
17
+
18
+ ### Added
19
+ -
20
+
21
+ ### Fixed
22
+ - **The statusline's room-health chip actually updates now, instead of showing you one frozen
23
+ warning forever and sending you to a command that could never clear it.** The chip that reads
24
+ `⚠ · -> run /mos:doctor --fix` is supposed to reflect whether your current room is healthy. In
25
+ practice it was stuck on whatever it happened to say the last time somebody ran a diagnostic by
26
+ hand in a terminal, which for most people means it either never appeared or never went away.
27
+ Running `/mos:doctor`, or even `/mos:doctor --fix`, did nothing to it -- not because those
28
+ commands were broken, but because they were never connected to it in the first place. The chip
29
+ reads a small cache file, and the one function in the whole codebase that writes that file had
30
+ exactly one caller: a manual command-line flag that nothing in the product ever runs. So the
31
+ warning was real once, and then it was just a fossil. Worse, the advice it gave you pointed at
32
+ the one command structurally incapable of helping. There WAS a second place in the code that
33
+ tried to wire this up, and it looked wired -- it checked whether the diagnostic module offered
34
+ a bind-time health function before calling it -- but that function was never written, so the
35
+ check was permanently false and the whole branch was dead code that read like working code, with
36
+ a comment promising a follow-up phase that never shipped. Now, whenever your session binds to a
37
+ room -- through the MCP front door or through the CLI's own binding path, both of which now run
38
+ the same single health check -- a real, current reading gets written, and the chip tells you what
39
+ is true right now. A health check that fails can never block or break a bind. And when the room
40
+ cannot be located at all, it says so honestly as drift rather than quietly reporting all-clear,
41
+ because the whole point of this fix is that a status signal you cannot trust is worse than no
42
+ signal. Verified end to end through the real MCP server: a stale drift warning cleared to sound
43
+ with a fresh timestamp on the next bind.
44
+ - **A stale local search index could get stuck stale forever, even after a "successful" repair.**
45
+ Each room keeps a small lexical search index so Eureka can find relevant nodes fast. When nodes
46
+ get deleted, that index is supposed to self-heal the next time it rebuilds. It turned out the
47
+ rebuild only ever refreshed rows for nodes that still exist -- it had no way to remove rows left
48
+ behind by deleted ones, so once a room accumulated deleted nodes, no amount of rebuilding could
49
+ ever clear them. The one place in the codebase that DID know how to clean those rows up only ran
50
+ during a full graph rebuild, not the lightweight repair every other path relied on. Now that
51
+ cleanup step runs every time the index rebuilds, not just on a full rebuild, so a room's search
52
+ index actually recovers instead of silently staying broken behind a "fixed" label.
53
+
1
54
  ## [1.16.0-beta.5] - 2026-07-31
2
55
 
3
56
  ### Added
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@mindrian_os/cli",
3
- "version": "1.16.0-beta.5",
3
+ "version": "1.16.0-beta.9",
4
4
  "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).",
5
5
  "scripts": {
6
6
  "mcp": "node bin/mindrian-mcp-server.cjs",