@mrclrchtr/supi-code-intelligence 6.2.0 → 6.4.0

package/README.md

@@ -86,6 +86,8 @@ The package adds eight tools that Pi selects as needed:
 
 Pi's built-in `grep` remains the right tool for literal or regular-expression searches; these tools add symbol and source-structure awareness.
 
+`code_health({ refresh: true })` reports process-crash recovery as route-level data. It shows exact recovered, skipped, failed, and exhausted counts. It shows up to 16 server and workspace-relative root entries, plus the exact number of omitted entries. A skipped route gives the `use-exact-file` action. A failed or exhausted route gives the `reload-workspace` action. Markdown and expanded TUI output show route entries and bounded failure details. Compact TUI output shows the counts. Current and retained refresh results use the same outcome format.
+
 ## Install
 
 ```bash

package/node_modules/@mrclrchtr/supi-code-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-code-runtime",
-  "version": "6.2.0",
+  "version": "6.4.0",
   "description": "Shared workspace context and capability contracts for code intelligence",
   "license": "MIT",
   "repository": {

package/node_modules/@mrclrchtr/supi-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-core",
-  "version": "6.2.0",
+  "version": "6.4.0",
   "description": "Shared settings, configuration, reporting, and session infrastructure",
   "license": "MIT",
   "repository": {

package/node_modules/@mrclrchtr/supi-lsp/README.md

@@ -60,6 +60,8 @@ Server readiness follows LSP work-done progress: a created progress token is pen
 
 A workspace diagnostic refresh returns exact coverage counts for requested, confirmed, unconfirmed, failed, and removed tracked documents. `code_health` marks tracked-file diagnostics as complete when each requested document is confirmed or known to be removed. It shows non-empty tentative diagnostics as partial entries, reports the same coverage counts in summary and detailed views, and explains when a diagnostic republish is needed. A refresh attempt does not prove fresh evidence by itself. A removed file is reported by the refresh that finds it and is not retained in later tracked-file snapshots.
 
+An explicit diagnostic refresh also returns a bounded process-crash report. It gives exact recovered, skipped, failed, and exhausted route counts, up to 16 route entries, and an omitted-entry count. Each entry names the server and workspace-relative root. A skipped route recommends an exact-file refresh; a failed or exhausted route recommends a workspace reload. A failed entry may include only the caught error message, limited to 512 characters. Broad refreshes select only routes whose root overlaps the requested directory and use retained tracked-file paths from the crash snapshot. Exact-file readiness reports only the file's route. Recovery does not cold-start routes, consume an attempt for a skip, or add a second attempt.
+
 An explicit recovery pass restarts a push-only client only on a protocol-stall signal (a readiness stall, or repeated JSON-RPC request failures) — never on unconfirmed evidence alone, because the reopen-resync fallback recovers unconfirmed documents without discarding warm server state. It never restarts a pull-capable client because push evidence is absent, and it never restarts a client during passive health display. Each client route restarts at most once per workspace invalidation generation. The replacement process has a fixed startup bound of 5 seconds; exceeding the bound fails closed as start-failed without retry. Recovery telemetry records the outcome, elapsed time, attempted clients, restart count, the bounded server names involved, and the stall signal that triggered a restart, without changing the evidence semantics of the result.
 
 ### Optional diagnostic configuration

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-code-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-code-runtime",
-  "version": "6.2.0",
+  "version": "6.4.0",
   "description": "Shared workspace context and capability contracts for code intelligence",
   "license": "MIT",
   "repository": {

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-core",
-  "version": "6.2.0",
+  "version": "6.4.0",
   "description": "Shared settings, configuration, reporting, and session infrastructure",
   "license": "MIT",
   "repository": {

package/node_modules/@mrclrchtr/supi-lsp/node_modules/ignore/README.md

@@ -384,6 +384,58 @@ ignore({
 
 # Upgrade Guide
 
+## Known differences from `git`
+
+`ignore` aims to behave exactly like `git check-ignore`, and its test suite
+verifies every fixture against the real `git` binary. A few divergences are
+deliberate or inherited from how JavaScript differs from C. They are listed
+here so you do not have to discover them in production.
+
+### Characters, not bytes
+
+`git` matches patterns against the **UTF-8 bytes** of a path; JavaScript
+strings are sequences of UTF-16 code units, and `ignore` matches those.
+The two agree on ASCII and disagree on the width of everything else:
+
+```js
+// git needs two '?' to match 'é' (two bytes); ignore needs one:
+ignore().add('x?y').ignores('xéy')    // true;  git: false
+
+// a range cannot span multi-byte characters in git at all:
+ignore().add('m[À-È]n').ignores('mÁn') // true;  git: false
+```
+
+With `ignorecase` enabled, `git` folds case for ASCII only, while
+JavaScript's `i` flag folds Unicode — so `É.txt` ignores `é.txt` here and
+not in `git`. For ASCII paths and patterns there is no difference.
+
+### `ignorecase` defaults to `true`
+
+`git` on a case-sensitive filesystem (production Linux) is case-sensitive.
+`ignore` is case-insensitive unless you pass `ignorecase: false`. If your
+code runs against a real repository, pass the value of the repository's
+`core.ignorecase` explicitly.
+
+### `***` and friends follow the documentation, not the binary
+
+gitignore(5) says a run of more than two asterisks is "considered regular
+asterisks". The `git` binary, however, strips the literal prefix of a
+pattern before matching, which makes patterns like `***/foo`, `a/***` and
+`a**/b` behave as `**` globstars there. `ignore` follows the documented
+behavior. If you need the globstar, write `**`.
+
+### `checkIgnore()` and a directory passed with a trailing slash
+
+`git check-ignore` treats its arguments as plain strings: handed `a/`, it
+computes an empty basename, with surprising results — `a/**` matches `a/`
+itself, and a negated basename pattern like `!a` fails to match it. During
+an actual traversal git behaves differently: `a/**` does **not** exclude
+the directory `a` (that is what allows it to descend and exclude the
+contents), and `!a` negates it normally. `ignore` models the traversal
+semantics: `'a/'` means *the directory a*, with its basename `a/`. Where
+the two disagree, `ignore` sides with what `git status` actually does
+rather than with the string-level quirks of `check-ignore`.
+
 ## Upgrade 4.x -> 5.x
 
 Since `5.0.0`, if an invalid `Pathname` passed into `ig.ignores()`, an error will be thrown, unless `options.allowRelative = true` is passed to the `Ignore` factory.