@mrclrchtr/supi-lsp 11.0.0 → 11.1.0

package/README.md

@@ -153,7 +153,7 @@ Caller cancellation or deadline stops only that caller's wait. Explicit diagnost
 
 If another request first opens a document during an active semantic or diagnostic request, the client can synchronize and repeat the request once. The retry retains the caller's original signal and deadline. Content, workspace, close, and lifecycle changes still reject stale results. A diagnostic retry collects new request evidence; it does not promote an old cache. This retry is not route recovery. A second enrollment during the retry still rejects the result. Semantic failure reasons state whether the retry failed or was exhausted. The bounded `request.retry` debug event records the retry reason and outcome with the public call's opaque operation ID, when supplied. A completed RPC alone does not establish accepted semantic evidence.
 
-A read-only semantic request can also retry once after an LSP `ContentModified` error (`-32801`). This retry shares the same one-retry budget as enrollment; it does not add another try. The client keeps the original request parameters and checks changes from the first failed input revision. It runs the full input sync before retry and checks current inputs before it accepts a result. An enrollment is still the only input change that can permit a retry. A content, workspace, close, lifecycle, or retirement change blocks it. Client replacement, caller cancellation, and a deadline also block retry. The post-request check rejects a result if inputs change while that attempt runs. This error-code retry applies only to read-only semantic requests. Diagnostics, rename, code actions, and refactors keep the default policy and do not retry `ContentModified`. See the [LSP 3.17 message-ordering rule](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#messageOrdering), the [retry guard](src/client/client-request-enrollment.ts), and the [client query path](src/client/client.ts).
+A read-only semantic request can also retry once after an LSP `ContentModified` error (`-32801`). This retry shares the same one-retry budget as enrollment; it does not add another try. Before this protocol retry, the client waits 100 ms so an immediate retry does not race the same server analysis. The wait is cancellable, respects the original absolute deadline, and does not delay enrollment-only retries. The client keeps the original request parameters and checks changes from the first failed input revision. It runs the full input sync before retry and checks current inputs before it accepts a result. An enrollment is still the only input change that can permit a retry. A content, workspace, close, lifecycle, or retirement change blocks it. Client replacement, caller cancellation, and a deadline also block retry. The post-request check rejects a result if inputs change while that attempt runs. This error-code retry applies only to read-only semantic requests. Diagnostics, rename, code actions, and refactors keep the default policy and do not retry `ContentModified`. See the [LSP 3.17 message-ordering rule](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#messageOrdering), the [retry guard](src/client/client-request-enrollment.ts), and the [client query path](src/client/client.ts).
 
 Diagnostic collection does not close and reopen a document to obtain confirmation. It does not send a no-op `didChange` for that purpose. Refresh retains unchanged documents and their current server state, and resynchronizes changed or invalidated documents. A client restart may reopen tracked documents to restore client state; that is recovery, not diagnostic confirmation.
 

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

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-code-runtime",
-  "version": "11.0.0",
+  "version": "11.1.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": "11.0.0",
+  "version": "11.1.0",
   "description": "Shared settings, configuration, reporting, and session infrastructure",
   "license": "MIT",
   "repository": {

package/node_modules/@mrclrchtr/supi-core/src/debug-registry.ts

@@ -14,6 +14,8 @@ export interface DebugRegistryConfig {
   enabled: boolean;
   /** What the agent-callable debug tool may return. */
   agentAccess: DebugAgentAccess;
+  /** Whether Agent Run retrospective capture is explicitly enabled. */
+  agentRunRetrospectivesEnabled: boolean;
   /** Maximum number of session-local events to keep in memory. */
   maxEvents: number;
 }
@@ -21,6 +23,7 @@ export interface DebugRegistryConfig {
 export const DEBUG_REGISTRY_DEFAULTS: DebugRegistryConfig = {
   enabled: false,
   agentAccess: "sanitized",
+  agentRunRetrospectivesEnabled: false,
   maxEvents: 100,
 };
 
@@ -75,6 +78,9 @@ export interface DebugEventQueryResult {
 /** Receives a sanitized event whenever the registry records one. */
 export type DebugEventListener = (event: DebugEventView) => void;
 
+/** Receives sanitized events for persistence; separate from ordinary event subscriptions. */
+export type DebugPersistenceSink = (event: DebugEventView) => void;
+
 export interface DebugSummary {
   total: number;
   byLevel: Partial<Record<DebugLevel, number>>;
@@ -85,6 +91,7 @@ interface DebugRegistryState {
   config: DebugRegistryConfig;
   events: DebugEvent[];
   listeners: Set<DebugEventListener>;
+  persistenceSinks: Set<DebugPersistenceSink>;
   nextId: number;
 }
 
@@ -111,13 +118,15 @@ function getState(): DebugRegistryState {
       config: cloneConfig(DEBUG_REGISTRY_DEFAULTS),
       events: [],
       listeners: new Set(),
+      persistenceSinks: new Set(),
       nextId: 1,
     };
     (globalThis as Record<symbol, unknown>)[REGISTRY_KEY] = state;
   }
   // Keep the shared registry compatible with extension reloads that reuse an
-  // instance created before listeners existed.
+  // instance created before listener sets existed.
   if (!state.listeners) state.listeners = new Set();
+  if (!state.persistenceSinks) state.persistenceSinks = new Set();
   return state;
 }
 
@@ -200,6 +209,19 @@ export function isDebugRegistryEnabled(): boolean {
   return getState().config.enabled;
 }
 
+/**
+ * Return whether a retrospective can be captured: Debug and its explicit opt-in
+ * must be enabled, and at least one persistence sink must be registered.
+ */
+export function canRecordAgentRunRetrospective(): boolean {
+  const state = getState();
+  return (
+    state.config.enabled &&
+    state.config.agentRunRetrospectivesEnabled &&
+    state.persistenceSinks.size > 0
+  );
+}
+
 /** Best-effort redaction helper for data exposed through sanitized debug views. */
 export function redactDebugData<T>(value: T): T {
   return redactValue(value, 8) as T;
@@ -226,6 +248,16 @@ export function subscribeDebugEvents(listener: DebugEventListener): () => void {
   return () => state.listeners.delete(listener);
 }
 
+/**
+ * Register a sanitized event persistence sink. Sinks are tracked separately from
+ * ordinary listeners so eligibility checks only succeed when logging is active.
+ */
+export function subscribeDebugPersistence(sink: DebugPersistenceSink): () => void {
+  const state = getState();
+  state.persistenceSinks.add(sink);
+  return () => state.persistenceSinks.delete(sink);
+}
+
 /** Record a session-local debug event if debugging is enabled. */
 export function recordDebugEvent(input: DebugEventInput): DebugEvent | null {
   const state = getState();
@@ -251,6 +283,13 @@ export function recordDebugEvent(input: DebugEventInput): DebugEvent | null {
       // Debug-event consumers must not alter producer behavior.
     }
   }
+  for (const sink of state.persistenceSinks) {
+    try {
+      sink(toSanitizedView(event));
+    } catch {
+      // Persistence failures must not alter producer behavior.
+    }
+  }
   return {
     ...event,
     data: event.data === undefined ? undefined : redactDebugData(event.data),
@@ -309,5 +348,6 @@ export function resetDebugRegistry(): void {
   state.config = cloneConfig(DEBUG_REGISTRY_DEFAULTS);
   state.events = [];
   state.listeners.clear();
+  state.persistenceSinks.clear();
   state.nextId = 1;
 }

package/node_modules/ignore/README.md

@@ -173,6 +173,29 @@ ig.ignores(path.join('./abc'))  // path.join('./abc') -> 'abc'
 
 In other words, each `Pathname` here should be a relative path to the directory of the gitignore rules.
 
+A `.` or `..` component anywhere else in a `Pathname` is outside the
+convention as well, though no error is thrown for it: the check reads how the
+path starts, so that it costs nothing on a hot path. `path.relative()` never
+produces such a component, and one that carries it is not matched the way
+`git` matches it — `git` drops the component from the path first, `ignore`
+matches the path as it was given.
+
+```js
+// path.relative('/', '/a/./b')  -> 'a/b'
+
+// Right
+ignore().add('a/b').ignores('a/b')       // true
+
+// Outside the convention: git matches 'a/b' here and so says true
+ignore().add('a/b').ignores('a/./b')     // false
+
+// Outside the convention: git matches 'a' here and so says false
+ignore().add('a/.').ignores('a/.')       // true
+```
+
+A rule that matches an ancestor still agrees, since the component makes no
+difference to it: `add('a').ignores('a/./b')` is `true` either way.
+
 Suppose the dir structure is:
 
 ```
@@ -259,15 +282,23 @@ Returns `function(path)` the filter function.
 
 > New in 5.0.0
 
+**This method is NOT meant for ordinary users or everyday use.** If all you need is to tell whether a `pathname` is ignored, this is not the method you are looking for.
+
+`.test()` is meant for packages that build upon `ignore`. Besides whether a `pathname` is ignored, it tells whether a negative pattern unignored it, which such a package can use to control its own caching, such as what to cache and when a cached result can be reused.
+
+If you only need to know whether a `pathname` should be ignored, use `.ignores()` instead. It returns that answer as a boolean, and always agrees with `.test(pathname).ignored`.
+
 Returns `TestResult`
 
 ```ts
 // Since 5.0.0
 interface TestResult {
   ignored: boolean
-  // true if the `pathname` is finally unignored by some negative pattern
+  // true if a negative pattern matched the `pathname` itself, and no parent
+  //   directory of it is ignored -- see "When both are false" below
   unignored: boolean
-  // The `IgnoreRule` which ignores the pathname
+  // The `IgnoreRule` which ignores the pathname: the last rule to match, the
+  //   one `git check-ignore -v` reports
   rule?: IgnoreRule
 }
 
@@ -283,18 +314,51 @@ interface IgnoreRule {
 ```
 
 - `{ignored: true, unignored: false}`: the `pathname` is ignored
-- `{ignored: false, unignored: true}`: the `pathname` is unignored
-- `{ignored: false, unignored: false}`: the `pathname` is never matched by any ignore rules.
+- `{ignored: false, unignored: true}`: a negative pattern matched the `pathname` itself
+- `{ignored: false, unignored: false}`: no rule matched the `pathname` itself, and no parent directory of it is ignored
+
+### When both are `false`
+
+`{ignored: false, unignored: false}` covers two different situations:
+
+- no rule matched the `pathname`, nor any of its parent directories, or
+- no rule matched the `pathname` itself, but one of its parent directories is unignored by a negative pattern: the `pathname` is unignored **indirectly**.
+
+`unignored` stays `false` in the second case because only `ignored` passes down from a parent directory. A `pathname` whose parent directory is ignored is ignored as well — git never re-includes a file whose parent directory is excluded — but one whose parent directory is unignored is decided on its own, by the rules that match the `pathname` itself.
+
+```js
+const ig2 = ignore().add([
+  'foo*',
+  '!foobar'
+])
+
+// The directory `foobar/` is unignored directly, by `!foobar`
+ig2.test('foobar/')     // {ignored: false, unignored: true}
+
+// No rule matches `foobar/x.js` itself. It is not ignored only because its
+//   parent directory `foobar/` is not, so it is unignored indirectly
+ig2.test('foobar/x.js') // {ignored: false, unignored: false}
+```
+
+To tell the two situations apart, test the parent directories of the `pathname`, each with a trailing slash: the `pathname` is unignored indirectly if any of them is `unignored`.
+
+```js
+['foobar/'].some(dir => ig2.test(dir).unignored) // true
+```
 
 ## .checkIgnore(target: string): TestResult
 
 > new in 7.0.0
 
-Debugs gitignore / exclude files, which is equivalent to `git check-ignore -v`. Usually this method is used for other packages to implement the function of `git check-ignore -v` upon `node-ignore`
+Debugs gitignore / exclude files the way `git check-ignore -v` does. Usually this method is used for other packages to implement the function of `git check-ignore -v` upon `node-ignore`. Apart from the [known differences](#known-differences-from-git):
+
+- `ignored` is what `git check-ignore` answers for `target`.
+- When `ignored` is `true`, `rule` is the rule `git check-ignore -v` reports. Its `pattern` is the pattern as it was added, so trailing spaces that git trims are still there.
+- When the last pattern to match is a negative one, `git check-ignore -v` reports it, while `.checkIgnore()` returns `unignored: true` and no `rule`. For a directory passed with a trailing slash, `unignored` is also `true` when a negative pattern re-includes the directory itself, which `git check-ignore -v` does not report.
 
 - **target** `string` the target to test.
 
-Returns `TestResult`
+Returns `TestResult`, the same shape `.test()` returns, so `{ignored: false, unignored: false}` carries the [same two meanings](#when-both-are-false) here.
 
 ```js
 ig.add({
@@ -305,10 +369,10 @@ ig.add({
 const {
   ignored,
   rule
-} = checkIgnore('foo/')
+} = ig.checkIgnore('foo/')
 
 if (ignored) {
-  console.log(`.gitignore:${result}:${rule.mark}:${rule.pattern} foo/`)
+  console.log(`.gitignore:${rule.mark}:${rule.pattern} foo/`)
 }
 
 // .gitignore:60:foo/* foo/
@@ -416,13 +480,30 @@ not in `git`. For ASCII paths and patterns there is no difference.
 code runs against a real repository, pass the value of the repository's
 `core.ignorecase` explicitly.
 
-### `***` and friends follow the documentation, not the binary
+### A run of asterisks
+
+`git` reads a run of two or more asterisks as a globstar whenever the run
+fills a path segment: it starts the pattern or follows a `/`, and it ends
+the pattern or comes before a `/`. `ignore` does the same, so `***/foo`,
+`a/***` and `a/***/b` behave exactly as `**/foo`, `a/**` and `a/**/b`.
+
+`git` takes two more cases as a globstar, and `ignore` does not:
+
+- **A run right after a literal prefix**, as in `a**/b` or `a***/b`. Before
+  matching, `git` strips the part of a pattern that holds no wildcard, and
+  the run then starts what is left. gitignore(5) lists the positions where
+  `**` is special and calls every other run "regular asterisks", which is
+  what `ignore` does here.
+- **A run next to an escaped slash**, as in `**\/b` or `x\/**/b`.
+
+```js
+ignore().add('a**/b').ignores('axy/z/b')   // false;  git: true
+ignore().add('**\\/b').ignores('x/y/b')    // false;  git: true
+ignore().add('x\\/**/b').ignores('x/y/z/b') // false;  git: true
+```
 
-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 `**`.
+To get a globstar in either case, give the run a segment of its own, such as
+`a*/**/b`.
 
 ### `checkIgnore()` and a directory passed with a trailing slash
 

package/node_modules/ignore/index.d.ts

@@ -1,27 +1,62 @@
-type Pathname = string
-
-interface IgnoreRule {
-  pattern: string
-  mark?: string
-  negative: boolean
-}
-
-interface TestResult {
-  ignored: boolean
-  unignored: boolean
-  rule?: IgnoreRule
-}
-
-interface PatternParams {
-  pattern: string
-  mark?: string
-}
-
 /**
  * Creates new ignore manager.
  */
 declare function ignore(options?: ignore.Options): ignore.Ignore
 declare namespace ignore {
+  /**
+   * A path relative to the directory the rules belong to, as
+   *   `path.relative()` returns it.
+   */
+  type Pathname = string
+
+  interface PatternParams {
+    pattern: string
+    /**
+     * Carried through to `IgnoreRule.mark`, for packages that build upon
+     *   `ignore`.
+     */
+    mark?: string
+  }
+
+  interface IgnoreRule {
+    /**
+     * The original pattern.
+     */
+    pattern: string
+    /**
+     * Carried through from `PatternParams.mark`.
+     */
+    mark?: string
+    /**
+     * Whether the pattern is a negative one, such as `!foo`.
+     */
+    negative: boolean
+  }
+
+  interface TestResult {
+    /**
+     * Whether the pathname is ignored, by a rule or because a parent
+     *   directory of it is.
+     */
+    ignored: boolean
+    /**
+     * True if a negative pattern matched the pathname itself, and no parent
+     *   directory of it is ignored.
+     *
+     * Only `ignored` passes down from a parent directory, so a pathname that
+     *   is not ignored only because a parent directory was unignored keeps
+     *   this false, as does one no rule applies to at all. To tell those two
+     *   apart, test the parent directories, each with a trailing slash.
+     */
+    unignored: boolean
+    /**
+     * The rule that ignores the pathname, or the parent directory it is
+     *   ignored with: the last rule to match, which is the rule
+     *   `git check-ignore -v` reports. Present exactly when `ignored` is true.
+     */
+    rule?: IgnoreRule
+  }
+
   interface Ignore {
     /**
      * Adds one or several rules to the current manager.
@@ -54,7 +89,8 @@ declare namespace ignore {
     ignores(pathname: Pathname): boolean
 
     /**
-     * Returns whether pathname should be ignored or unignored
+     * Tests the pathname against the rules. `ignored` and `unignored` can
+     *   both be false: see `TestResult.unignored` for the two cases.
      * @param  {string} pathname a path to check
      * @returns TestResult
      */