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

package/CHANGELOG.md

@@ -1,3 +1,210 @@
+## [1.16.0-beta.13] - 2026-08-09
+
+### Fixed
+- **Larry can read the Brain again. Every single Brain call was failing before this, and nothing
+  told you so.** If you asked Larry anything that needed the teaching graph -- which framework fits
+  your problem, what the corpus says, a grade, a chain recommendation -- the call died before it
+  reached him, with a host error that looks like a network fault: `e.reduce is not a function`.
+  Nothing was wrong with the network. Nothing was wrong with the graph. The Brain was up the whole
+  time, serving 28,325 nodes and 23,014 relationships in a perfectly correct response, and the
+  plugin's own connection to it was healthy too. What broke it was a hook this plugin ships to
+  sanitize Brain responses before they reach the conversation, and it broke them in two ways at
+  once. It looked for the response text in a field the protocol never puts it in, so it found
+  nothing and sanitized an empty string. Then it handed back that empty string in the wrong
+  container shape -- a bare object where an array of content blocks belongs -- so the host tried to
+  measure the length of something that was not there and threw. Every Brain response, replaced with
+  nothing, in a shape nothing could read. The reason this ran for weeks without anyone noticing is
+  the more uncomfortable half: the Brain layer was under standing instructions to fall back silently
+  and never mention failures to you. So a total outage of the single most valuable thing in the
+  product looked, from the outside, exactly like a Larry who simply had less to say. Both defects
+  are now pinned by tests that feed the hook a real protocol-shaped response and assert the text
+  survives with the container intact, so an empty-string regression fails the suite instead of
+  reaching your session. The doctrine that hid it is being revisited separately, because a fix that
+  only works until the next silent failure is not a fix.
+- **Asking the Brain about a framework by name no longer gets blocked as a possible data leak.** The
+  guard that stops your private venture content from ever reaching the shared Brain was refusing
+  ordinary methodology questions too. Asking about "jobs to be done" -- a framework name, the kind
+  of generic handle the Brain exists to answer about, and the exact query the deployment's own
+  verification step uses -- was classified as content that might leak and stopped before it left
+  your machine. Content-free graph introspection now classifies as allowed, and the guard is
+  covered from both directions: a test proves the framework-name case gets through, and a companion
+  test proves real venture content is still blocked on the same paths. The boundary did not get
+  looser; it got accurate.
+
+## [1.16.0-beta.11] - 2026-08-06
+
+### Added
+- **`/mos:grade-grant` scores a pasted grant-application draft before you submit it, instead of
+  you finding out what a reviewer would flag only after you've already sent it in.** Starts with
+  Tnufa (Israel Innovation Authority pre-seed): paste a draft, get it checked against 18 real
+  eligibility/budget/legal/market criteria pulled from the actual Tnufa guide, each with the
+  specific "here's what people usually get wrong" line reviewers already use. The rubric lives
+  locally as its own reference pack, not in the shared Brain, and the schema is built to take the
+  other 7 Israel Innovation Authority programs the same way once their criteria get filled in.
+- **`/mos:grade-grant` now grades your room directly, hands back a build roadmap, and can run
+  the whole thing in reverse.** Your room already holds what a Tnufa application needs, so you
+  no longer have to paste a draft: room-mode reads every populated room section and grades the
+  room itself (paste-mode stays for anyone without a room yet). Every rubric criterion now knows
+  which of the 8 room sections its evidence lives in, so the grade is no longer just a score --
+  it is an offer: "build this in room/financial-model/, and here is what a strong entry looks
+  like", weakest section first, with pure submission/reporting items kept as an honest checklist
+  instead of being forced into a fake section. The same map runs backwards: hand over a finished
+  application and it gets decomposed into a NEW dedicated room (never your live venture room, so
+  grant prose cannot pollute real venture data) and then graded as a room. And the map is real
+  graph structure now, not just JSON: criterion nodes wired to section nodes through the one
+  governed graph door, so Brain can be asked for STRATEGIC advice about the room's shape (which
+  sections are covered, partial, or missing) without a single line of your content ever leaving
+  the machine.
+- **`/mos:grade-grant` can now convene a full reviewer panel instead of one holistic read --
+  and the panel actually argues.** The opt-in "Reviewer panel examination" mode fans out seven
+  adversarial reviewer personas, one per rubric category (eligibility / process / budget /
+  legal / reporting / market / ip), each reading ONLY its own criteria and asking the question
+  a real committee member asks: would I accept this section on its own? It rides the same BONO
+  fan-out and debate machinery the plugin already ships (no second engine), with a discipline
+  per seat: budget claims must show their arithmetic, market claims must cite a reason to doubt
+  before crediting demand, IP claims must name their protection mechanism and budget line. The
+  debate has teeth: a later reviewer who reads an earlier reviewer's argument can challenge its
+  finding downward (never upward -- the panel is at least as strict as its strictest reviewer),
+  a sustained challenge changes the score before it is computed, and every disagreement is
+  shown at the ruling gate instead of being averaged away. One rule survives everything: an
+  application that fails ANY eligibility criterion is rejected no matter how strong its
+  aggregate score, and the rejection reason lands in the graph as data, not as a footnote.
+
+## [1.16.0-beta.9] - 2026-08-05
+
+### Changed
+- **`/mos:pws-brain` now says plainly that it's retired, instead of quietly sending you down a
+  dead path.** The command was built to compare two ways of answering methodology questions
+  side by side: the production Brain, and a separate experimental Aura Agent. Both of those
+  routes have since been folded into one unified Memgraph-backed Brain, so the comparison this
+  command exists to run no longer means anything, and running it just walked you into a
+  pre-flight failure with no explanation of why. The command's description, its retirement
+  reason, and a note right under its own heading now say RETIRED and point at the real backend
+  by name, so anyone who reaches for it (navigator or Larry) understands immediately why it's
+  inert instead of guessing at a broken dependency. Nothing about the harness itself was
+  deleted, so it is still there to read as a historical record of the comparison, or to revive
+  deliberately if a future backend candidate ever needs the same side-by-side treatment again.
+
+## [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
+- **A documented, honest line on what the sensor bank actually controls about the reach dial
+  (quick-260731-35r).** When Larry surfaces the reach dial, the little ranked menu of next moves,
+  two different things are happening and it is easy to think they are one thing. The sensors, the
+  17 small detectors that watch a turn and fire when they recognise something, decide WHETHER that
+  dial appears at all. They do not decide WHAT sits at the top of it. The ordering comes entirely
+  from scoring your room's own graph nodes, on a completely separate code path that no sensor ever
+  reaches. Nothing changed in how any of it runs; what changed is that the boundary is now written
+  down at the exact function where a future reader would otherwise assume the opposite, plus a
+  finding artifact with every file and line number so anyone can check it in a minute instead of
+  tracing the code themselves. The practical payoff: nobody builds on the wrong mental model,
+  and nobody mistakes "a sensor fired" for "a sensor ranked what you are seeing."
+- 
+
 ## [1.16.0-beta.1] - 2026-07-31
 
 ### Added

package/package.json

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