@mindrian_os/cli 1.16.0-beta.1 → 1.16.0-beta.11

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 +174 -0
  2. package/package.json +1 -1
package/CHANGELOG.md CHANGED
@@ -1,3 +1,177 @@
1
+ ## [1.16.0-beta.11] - 2026-08-06
2
+
3
+ ### Added
4
+ - **`/mos:grade-grant` scores a pasted grant-application draft before you submit it, instead of
5
+ you finding out what a reviewer would flag only after you've already sent it in.** Starts with
6
+ Tnufa (Israel Innovation Authority pre-seed): paste a draft, get it checked against 18 real
7
+ eligibility/budget/legal/market criteria pulled from the actual Tnufa guide, each with the
8
+ specific "here's what people usually get wrong" line reviewers already use. The rubric lives
9
+ locally as its own reference pack, not in the shared Brain, and the schema is built to take the
10
+ other 7 Israel Innovation Authority programs the same way once their criteria get filled in.
11
+ - **`/mos:grade-grant` now grades your room directly, hands back a build roadmap, and can run
12
+ the whole thing in reverse.** Your room already holds what a Tnufa application needs, so you
13
+ no longer have to paste a draft: room-mode reads every populated room section and grades the
14
+ room itself (paste-mode stays for anyone without a room yet). Every rubric criterion now knows
15
+ which of the 8 room sections its evidence lives in, so the grade is no longer just a score --
16
+ it is an offer: "build this in room/financial-model/, and here is what a strong entry looks
17
+ like", weakest section first, with pure submission/reporting items kept as an honest checklist
18
+ instead of being forced into a fake section. The same map runs backwards: hand over a finished
19
+ application and it gets decomposed into a NEW dedicated room (never your live venture room, so
20
+ grant prose cannot pollute real venture data) and then graded as a room. And the map is real
21
+ graph structure now, not just JSON: criterion nodes wired to section nodes through the one
22
+ governed graph door, so Brain can be asked for STRATEGIC advice about the room's shape (which
23
+ sections are covered, partial, or missing) without a single line of your content ever leaving
24
+ the machine.
25
+ - **`/mos:grade-grant` can now convene a full reviewer panel instead of one holistic read --
26
+ and the panel actually argues.** The opt-in "Reviewer panel examination" mode fans out seven
27
+ adversarial reviewer personas, one per rubric category (eligibility / process / budget /
28
+ legal / reporting / market / ip), each reading ONLY its own criteria and asking the question
29
+ a real committee member asks: would I accept this section on its own? It rides the same BONO
30
+ fan-out and debate machinery the plugin already ships (no second engine), with a discipline
31
+ per seat: budget claims must show their arithmetic, market claims must cite a reason to doubt
32
+ before crediting demand, IP claims must name their protection mechanism and budget line. The
33
+ debate has teeth: a later reviewer who reads an earlier reviewer's argument can challenge its
34
+ finding downward (never upward -- the panel is at least as strict as its strictest reviewer),
35
+ a sustained challenge changes the score before it is computed, and every disagreement is
36
+ shown at the ruling gate instead of being averaged away. One rule survives everything: an
37
+ application that fails ANY eligibility criterion is rejected no matter how strong its
38
+ aggregate score, and the rejection reason lands in the graph as data, not as a footnote.
39
+
40
+ ## [1.16.0-beta.9] - 2026-08-05
41
+
42
+ ### Changed
43
+ - **`/mos:pws-brain` now says plainly that it's retired, instead of quietly sending you down a
44
+ dead path.** The command was built to compare two ways of answering methodology questions
45
+ side by side: the production Brain, and a separate experimental Aura Agent. Both of those
46
+ routes have since been folded into one unified Memgraph-backed Brain, so the comparison this
47
+ command exists to run no longer means anything, and running it just walked you into a
48
+ pre-flight failure with no explanation of why. The command's description, its retirement
49
+ reason, and a note right under its own heading now say RETIRED and point at the real backend
50
+ by name, so anyone who reaches for it (navigator or Larry) understands immediately why it's
51
+ inert instead of guessing at a broken dependency. Nothing about the harness itself was
52
+ deleted, so it is still there to read as a historical record of the comparison, or to revive
53
+ deliberately if a future backend candidate ever needs the same side-by-side treatment again.
54
+
55
+ ## [1.16.0-beta.7] - 2026-08-01
56
+
57
+ ### Added
58
+ -
59
+
60
+ ### Fixed
61
+ - **The statusline's room-health chip actually updates now, instead of showing you one frozen
62
+ warning forever and sending you to a command that could never clear it.** The chip that reads
63
+ `⚠ · -> run /mos:doctor --fix` is supposed to reflect whether your current room is healthy. In
64
+ practice it was stuck on whatever it happened to say the last time somebody ran a diagnostic by
65
+ hand in a terminal, which for most people means it either never appeared or never went away.
66
+ Running `/mos:doctor`, or even `/mos:doctor --fix`, did nothing to it -- not because those
67
+ commands were broken, but because they were never connected to it in the first place. The chip
68
+ reads a small cache file, and the one function in the whole codebase that writes that file had
69
+ exactly one caller: a manual command-line flag that nothing in the product ever runs. So the
70
+ warning was real once, and then it was just a fossil. Worse, the advice it gave you pointed at
71
+ the one command structurally incapable of helping. There WAS a second place in the code that
72
+ tried to wire this up, and it looked wired -- it checked whether the diagnostic module offered
73
+ a bind-time health function before calling it -- but that function was never written, so the
74
+ check was permanently false and the whole branch was dead code that read like working code, with
75
+ a comment promising a follow-up phase that never shipped. Now, whenever your session binds to a
76
+ room -- through the MCP front door or through the CLI's own binding path, both of which now run
77
+ the same single health check -- a real, current reading gets written, and the chip tells you what
78
+ is true right now. A health check that fails can never block or break a bind. And when the room
79
+ cannot be located at all, it says so honestly as drift rather than quietly reporting all-clear,
80
+ because the whole point of this fix is that a status signal you cannot trust is worse than no
81
+ signal. Verified end to end through the real MCP server: a stale drift warning cleared to sound
82
+ with a fresh timestamp on the next bind.
83
+ - **A stale local search index could get stuck stale forever, even after a "successful" repair.**
84
+ Each room keeps a small lexical search index so Eureka can find relevant nodes fast. When nodes
85
+ get deleted, that index is supposed to self-heal the next time it rebuilds. It turned out the
86
+ rebuild only ever refreshed rows for nodes that still exist -- it had no way to remove rows left
87
+ behind by deleted ones, so once a room accumulated deleted nodes, no amount of rebuilding could
88
+ ever clear them. The one place in the codebase that DID know how to clean those rows up only ran
89
+ during a full graph rebuild, not the lightweight repair every other path relied on. Now that
90
+ cleanup step runs every time the index rebuilds, not just on a full rebuild, so a room's search
91
+ index actually recovers instead of silently staying broken behind a "fixed" label.
92
+
93
+ ## [1.16.0-beta.5] - 2026-07-31
94
+
95
+ ### Added
96
+ - **The ranked dial you pick from now actually listens to what you said, and Brain's own
97
+ suggestion can no longer be silently discarded (Phase 245).** The previous entry documented an
98
+ honest finding: the sensor bank that watches a turn decides only WHETHER a dial appears, never
99
+ WHAT sits on top of it -- that ranking came entirely from your room's graph-node recency, a
100
+ completely separate code path. This phase closes that gap for real, at the one seam that
101
+ actually renders the dial (`scripts/intent-classifier.cjs`), not the seam that looked like the
102
+ right place but turned out to be a dead end -- a same-day research pass caught that the obvious
103
+ fix (wiring the fusion into `reach-hedge-ranker.cjs`) would have shipped, passed every test, and
104
+ moved the visible dial by nothing, because that ranker and the dial's renderer read the same
105
+ score map without either one feeding the other. Two turns with different intent in the same
106
+ session now surface two different top-ranked cards, proven by literally commenting out the merge
107
+ and watching the acceptance test fail with the exact symptom the SPEC named, then restoring it
108
+ and watching it pass. Brain's own suggested next step, when Brain has one, now genuinely factors
109
+ into that ranking too -- previously it was computed nowhere reachable, buried behind a routing
110
+ precedence chain a fired sensor almost always won first, so even a fresh, correct Brain read had
111
+ no way to ever surface. Bounded so it stays a nudge: no single signal can push a card across the
112
+ frozen 0.70 "recommended" threshold on its own, verified by sweeping the fusion math with
113
+ deliberately extreme inputs.
114
+ - **`BRAIN.md` now actually refreshes itself instead of quietly going stale for weeks while still
115
+ claiming to be fresh (Phase 245).** The re-derivation trigger, queue, and drain machinery for
116
+ keeping a room's Brain-derived insight current already existed, fully wired -- it just silently
117
+ did nothing. The drain measured its own timing budget starting *before* a slow one-time
118
+ `require()`, so a cold process routinely blew a 100ms budget it thought it had 100ms left in,
119
+ aborted after spawning zero re-derive jobs, and had already removed every job from the queue on
120
+ the way in. No error, no warning -- just a room that reports `staleness: "fresh"` while running
121
+ on a read from 12 days ago. Fixed at the root (hoist the slow require above the clock, and make
122
+ queue removal contingent on an actual job having spawned, so a future slow tick degrades
123
+ gracefully instead of losing work outright), not patched at the symptom. `BRAIN.md` now
124
+ re-derives on any of three real triggers: the room's governing thought changing, a section aging
125
+ past its staleness window, or an explicit ask -- never a blanket call on every single turn, which
126
+ independent research confirmed would blow the product's own 1200ms navigation budget.
127
+ - **Six Thinking Hats can now surface itself, proactively, for the first time (Phase 245).** `hats`
128
+ has been one of exactly six frozen reach categories since Phase 148 -- fully built on the render
129
+ side, completely unreachable from the sensor side. A navigator could only ever get there by
130
+ picking it manually, directly contradicting the product's own doctrine for when a hats rotation
131
+ should be offered. A new sensor closes the gap, firing when two or more fresh, unresolved
132
+ contradictions accumulate in a room (one is treated as a bridge to another topic; two or more
133
+ unresolved is treated as a genuine perspective lock worth rotating hats on) -- tuned specifically
134
+ not to double-fire alongside the existing sensor that already reacts to the first contradiction.
135
+ Also repaired: three shipped commands had been declaring a hats trigger that pointed at a sensor
136
+ which fires a completely different category and could never have produced hats in the first
137
+ place -- a real, live registry-truth bug now corrected alongside the sensor that actually makes
138
+ the declaration true.
139
+ - **When multiple signals fire on the same turn, the winner is now a documented priority, not
140
+ whichever file happened to load first (Phase 245).** 65% of the sensor bank can independently
141
+ produce the same output category on a single turn, and until now the tie always went to
142
+ registration order -- an accident of file layout, not a designed hierarchy. A frozen,
143
+ doctrine-authored priority table now decides, enforced by a completeness gate that fails the
144
+ build closed if a sensor ships without a ranked entry, so this can't silently drift again the way
145
+ the registration-order behavior did.
146
+ - **A Part 8 privacy guard was blocking harmless, contentless Brain calls while letting real
147
+ user-content calls through -- backwards from what a leak-prevention guard should ever do (Phase
148
+ 245).** Root-caused to a single over-broad catch-all with no way to recognize a call that
149
+ structurally cannot carry user data. A stats-style call with no arguments now passes; the
150
+ catch-all itself is untouched and still blocks by default on anything that actually could carry
151
+ content.
152
+ - **Frozen, zero-cost mapping from the product's ten canonical routing verbs to the six dial
153
+ categories they can actually produce (Phase 245).** Half the vocabulary had no path to ever fire
154
+ at all -- not a bug exactly, but an unmeasured gap nobody had named. Derived once, offline, from
155
+ a local sentence encoder already shipped in this repo for an unrelated feature (Canon Part 7:
156
+ reuse, don't rebuild) -- zero network calls, zero ongoing cost, and ground truth checked first so
157
+ a close embedding score can never overrule a fact the routing engine already knows for certain.
158
+
159
+ ## [1.16.0-beta.3] - 2026-07-31
160
+
161
+ ### Added
162
+ - **A documented, honest line on what the sensor bank actually controls about the reach dial
163
+ (quick-260731-35r).** When Larry surfaces the reach dial, the little ranked menu of next moves,
164
+ two different things are happening and it is easy to think they are one thing. The sensors, the
165
+ 17 small detectors that watch a turn and fire when they recognise something, decide WHETHER that
166
+ dial appears at all. They do not decide WHAT sits at the top of it. The ordering comes entirely
167
+ from scoring your room's own graph nodes, on a completely separate code path that no sensor ever
168
+ reaches. Nothing changed in how any of it runs; what changed is that the boundary is now written
169
+ down at the exact function where a future reader would otherwise assume the opposite, plus a
170
+ finding artifact with every file and line number so anyone can check it in a minute instead of
171
+ tracing the code themselves. The practical payoff: nobody builds on the wrong mental model,
172
+ and nobody mistakes "a sensor fired" for "a sensor ranked what you are seeing."
173
+ -
174
+
1
175
  ## [1.16.0-beta.1] - 2026-07-31
2
176
 
3
177
  ### Added
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@mindrian_os/cli",
3
- "version": "1.16.0-beta.1",
3
+ "version": "1.16.0-beta.11",
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",