@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.
- package/CHANGELOG.md +53 -0
- 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.
|
|
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",
|