d365fo-mcp 1.17.2 → 1.17.3

package/dist/index.js

@@ -104,8 +104,37 @@ console.error = (...args) => {
     const isModuleDebugMessage = /^\[[\w\- ]+\]/.test(firstArg) && !hasErrorIndicator;
     if (!isModuleDebugMessage) {
         originalConsoleError(...args);
+        return;
     }
+    logFileOnly(args);
 };
+/**
+ * Write a line the client never sees to LOG_FILE anyway.
+ *
+ * Both filters below the tee — this one and the stdio console.log redirect — exist
+ * so the MCP client's stderr pane is not a scroll of operational chatter. They were
+ * dropping the line entirely, and since the tee sits on process.stderr, a dropped
+ * line never reached the log file either. So a session that hung for five and a
+ * half minutes on its first call left a log holding a start banner and nothing
+ * else: "Loading symbols…", "Database opened in Xs" and "Database loaded in N ms"
+ * are all log.step/log.ok, all suppressed, all the answer to what it was doing.
+ * Setting DEBUG_LOGGING=true was the only way to see them, and it turns the client
+ * pane into that same scroll. The file is the right place for both.
+ */
+function logFileOnly(args) {
+    if (!_logStream)
+        return;
+    try {
+        // Timestamped, unlike the tee'd lines: these are the progress lines, and the
+        // question they answer ("which phase took the five minutes?") is unanswerable
+        // without the clock. Time only — the banner above carries the date.
+        const at = new Date().toISOString().slice(11, 23);
+        _logStream.write(`[${at}] ` + args.map(a => (typeof a === 'string' ? a : String(a))).join(' ') + '\n');
+    }
+    catch {
+        // Mirroring is best-effort; it must never take down the caller.
+    }
+}
 // ─── Global safety net ────────────────────────────────────────────────────────
 // An unhandled promise rejection terminates the Node process by default
 // (Node ≥15, --unhandled-rejections=throw). In stdio mode that kills the MCP
@@ -550,7 +579,12 @@ async function main() {
                 msg.includes('Error') || msg.includes('error') ||
                 msg.includes('Failed') || msg.includes('failed')) {
                 process.stderr.write(msg + '\n');
+                return;
             }
+            // Suppressed from the client's pane, kept in LOG_FILE — see logFileOnly.
+            // This is where every startup progress line goes: log.step/ok/detail are
+            // console.log, and console.log is this function in stdio mode.
+            logFileOnly([msg]);
         };
         console.log = stderrWrite;
         console.info = stderrWrite;

package/dist/metadata/symbolIndex.d.ts

@@ -299,6 +299,15 @@ export declare class XppSymbolIndex {
      *
      * Returns the names of top-level objects that were removed (for cache invalidation).
      */
+    /**
+     * How many regular (non-extension) object names the prefix sample may draw.
+     *
+     * inferPrefixFromObjectNames needs MIN_SAMPLE (4) of them and decides on a 60 %
+     * coverage threshold, so a few dozen settle the question as well as a few hundred
+     * — and this is the band that costs, since a model's extensions are counted in
+     * tens while its classes and tables run to thousands.
+     */
+    private static readonly REGULAR_NAME_SAMPLE;
     /**
      * Top-level object names belonging to one model — the evidence from which a
      * model's naming prefix is inferred (see utils/modelPrefixInference.ts).
@@ -330,6 +339,15 @@ export declare class XppSymbolIndex {
      * so the same model always yields the same sample — a silent, self-reinforcing
      * failure otherwise, since this server writes names with the inferred prefix and
      * those names become evidence for the next inference.
+     *
+     * The regular band is capped well below its share of the budget
+     * (REGULAR_NAME_SAMPLE), because it is the expensive half and the cheap half
+     * carries most of the signal: extensions state the infix outright, while regular
+     * objects only have to clear MIN_SAMPLE (4) and MIN_COVERAGE (60 %) for the
+     * leading token. Reading 400 of them to settle a 4-name question was paid on the
+     * first call of every session. They cannot be dropped altogether — the underscore
+     * form ("ConSK_" vs "ConSK") appears in no extension name, so only a regular
+     * object can decide it.
      */
     getModelObjectNames(model: string, limit?: number): string[];
     removeSymbolsByFile(filePath: string): {

package/dist/metadata/symbolIndex.js

@@ -1243,6 +1243,15 @@ export class XppSymbolIndex {
      *
      * Returns the names of top-level objects that were removed (for cache invalidation).
      */
+    /**
+     * How many regular (non-extension) object names the prefix sample may draw.
+     *
+     * inferPrefixFromObjectNames needs MIN_SAMPLE (4) of them and decides on a 60 %
+     * coverage threshold, so a few dozen settle the question as well as a few hundred
+     * — and this is the band that costs, since a model's extensions are counted in
+     * tens while its classes and tables run to thousands.
+     */
+    static REGULAR_NAME_SAMPLE = 60;
     /**
      * Top-level object names belonging to one model — the evidence from which a
      * model's naming prefix is inferred (see utils/modelPrefixInference.ts).
@@ -1274,6 +1283,15 @@ export class XppSymbolIndex {
      * so the same model always yields the same sample — a silent, self-reinforcing
      * failure otherwise, since this server writes names with the inferred prefix and
      * those names become evidence for the next inference.
+     *
+     * The regular band is capped well below its share of the budget
+     * (REGULAR_NAME_SAMPLE), because it is the expensive half and the cheap half
+     * carries most of the signal: extensions state the infix outright, while regular
+     * objects only have to clear MIN_SAMPLE (4) and MIN_COVERAGE (60 %) for the
+     * leading token. Reading 400 of them to settle a 4-name question was paid on the
+     * first call of every session. They cannot be dropped altogether — the underscore
+     * form ("ConSK_" vs "ConSK") appears in no extension name, so only a regular
+     * object can decide it.
      */
     getModelObjectNames(model, limit = 400) {
         if (!model)
@@ -1285,10 +1303,21 @@ export class XppSymbolIndex {
             if (cap <= 0)
                 return [];
             const rows = db
-                .prepare(`SELECT name FROM symbols
+                .prepare(
+            // Unary + on parent_name, for the same reason as searchCustomExtensions'
+            // `+type IN (…)`: written plainly, `parent_name IS NULL` makes the planner
+            // choose idx_symbols_parent_name, whose ANALYZE stats claim ~13 rows per
+            // value. NULL is not one value — it is every top-level object of every
+            // model, 180,664 of the 1,188,748 rows on the production DB, against 274
+            // for the one model being asked about. Measured warm: 454 ms on the
+            // parent_name plan, 1 ms on the model plan; cold it is the difference
+            // between a 5-minute first get_workspace_info and an instant one.
+            // EXPLAIN QUERY PLAN must keep reporting
+            // `SEARCH symbols USING INDEX idx_symbols_model`.
+            `SELECT name FROM symbols
            WHERE model = ?
              AND type ${extensions ? 'LIKE' : 'NOT LIKE'} '%-extension'
-             ${extensions ? '' : 'AND parent_name IS NULL'}
+             ${extensions ? '' : 'AND +parent_name IS NULL'}
              AND type NOT IN ('method', 'field')
            ORDER BY type, name
            LIMIT ?`)
@@ -1300,7 +1329,7 @@ export class XppSymbolIndex {
         // regular objects before the infix evidence is ever read.
         const half = Math.max(1, Math.ceil(limit / 2));
         const extensionNames = band(true, half);
-        const regularNames = band(false, limit - extensionNames.length);
+        const regularNames = band(false, Math.min(XppSymbolIndex.REGULAR_NAME_SAMPLE, limit - extensionNames.length));
         return [...extensionNames, ...regularNames];
     }
     removeSymbolsByFile(filePath) {

package/dist/scripts/build-database.js

@@ -2271,6 +2271,15 @@ var XppSymbolIndex = class _XppSymbolIndex {
    *
    * Returns the names of top-level objects that were removed (for cache invalidation).
    */
+  /**
+   * How many regular (non-extension) object names the prefix sample may draw.
+   *
+   * inferPrefixFromObjectNames needs MIN_SAMPLE (4) of them and decides on a 60 %
+   * coverage threshold, so a few dozen settle the question as well as a few hundred
+   * — and this is the band that costs, since a model's extensions are counted in
+   * tens while its classes and tables run to thousands.
+   */
+  static REGULAR_NAME_SAMPLE = 60;
   /**
    * Top-level object names belonging to one model — the evidence from which a
    * model's naming prefix is inferred (see utils/modelPrefixInference.ts).
@@ -2302,6 +2311,15 @@ var XppSymbolIndex = class _XppSymbolIndex {
    * so the same model always yields the same sample — a silent, self-reinforcing
    * failure otherwise, since this server writes names with the inferred prefix and
    * those names become evidence for the next inference.
+   *
+   * The regular band is capped well below its share of the budget
+   * (REGULAR_NAME_SAMPLE), because it is the expensive half and the cheap half
+   * carries most of the signal: extensions state the infix outright, while regular
+   * objects only have to clear MIN_SAMPLE (4) and MIN_COVERAGE (60 %) for the
+   * leading token. Reading 400 of them to settle a 4-name question was paid on the
+   * first call of every session. They cannot be dropped altogether — the underscore
+   * form ("ConSK_" vs "ConSK") appears in no extension name, so only a regular
+   * object can decide it.
    */
   getModelObjectNames(model, limit = 400) {
     if (!model) return [];
@@ -2310,10 +2328,20 @@ var XppSymbolIndex = class _XppSymbolIndex {
     const band = (extensions, cap) => {
       if (cap <= 0) return [];
       const rows = db.prepare(
+        // Unary + on parent_name, for the same reason as searchCustomExtensions'
+        // `+type IN (…)`: written plainly, `parent_name IS NULL` makes the planner
+        // choose idx_symbols_parent_name, whose ANALYZE stats claim ~13 rows per
+        // value. NULL is not one value — it is every top-level object of every
+        // model, 180,664 of the 1,188,748 rows on the production DB, against 274
+        // for the one model being asked about. Measured warm: 454 ms on the
+        // parent_name plan, 1 ms on the model plan; cold it is the difference
+        // between a 5-minute first get_workspace_info and an instant one.
+        // EXPLAIN QUERY PLAN must keep reporting
+        // `SEARCH symbols USING INDEX idx_symbols_model`.
         `SELECT name FROM symbols
            WHERE model = ?
              AND type ${extensions ? "LIKE" : "NOT LIKE"} '%-extension'
-             ${extensions ? "" : "AND parent_name IS NULL"}
+             ${extensions ? "" : "AND +parent_name IS NULL"}
              AND type NOT IN ('method', 'field')
            ORDER BY type, name
            LIMIT ?`
@@ -2322,7 +2350,10 @@ var XppSymbolIndex = class _XppSymbolIndex {
     };
     const half = Math.max(1, Math.ceil(limit / 2));
     const extensionNames = band(true, half);
-    const regularNames = band(false, limit - extensionNames.length);
+    const regularNames = band(
+      false,
+      Math.min(_XppSymbolIndex.REGULAR_NAME_SAMPLE, limit - extensionNames.length)
+    );
     return [...extensionNames, ...regularNames];
   }
   removeSymbolsByFile(filePath) {

package/dist/scripts/build-fts.js

@@ -2210,6 +2210,15 @@ var XppSymbolIndex = class _XppSymbolIndex {
    *
    * Returns the names of top-level objects that were removed (for cache invalidation).
    */
+  /**
+   * How many regular (non-extension) object names the prefix sample may draw.
+   *
+   * inferPrefixFromObjectNames needs MIN_SAMPLE (4) of them and decides on a 60 %
+   * coverage threshold, so a few dozen settle the question as well as a few hundred
+   * — and this is the band that costs, since a model's extensions are counted in
+   * tens while its classes and tables run to thousands.
+   */
+  static REGULAR_NAME_SAMPLE = 60;
   /**
    * Top-level object names belonging to one model — the evidence from which a
    * model's naming prefix is inferred (see utils/modelPrefixInference.ts).
@@ -2241,6 +2250,15 @@ var XppSymbolIndex = class _XppSymbolIndex {
    * so the same model always yields the same sample — a silent, self-reinforcing
    * failure otherwise, since this server writes names with the inferred prefix and
    * those names become evidence for the next inference.
+   *
+   * The regular band is capped well below its share of the budget
+   * (REGULAR_NAME_SAMPLE), because it is the expensive half and the cheap half
+   * carries most of the signal: extensions state the infix outright, while regular
+   * objects only have to clear MIN_SAMPLE (4) and MIN_COVERAGE (60 %) for the
+   * leading token. Reading 400 of them to settle a 4-name question was paid on the
+   * first call of every session. They cannot be dropped altogether — the underscore
+   * form ("ConSK_" vs "ConSK") appears in no extension name, so only a regular
+   * object can decide it.
    */
   getModelObjectNames(model, limit = 400) {
     if (!model) return [];
@@ -2249,10 +2267,20 @@ var XppSymbolIndex = class _XppSymbolIndex {
     const band = (extensions, cap) => {
       if (cap <= 0) return [];
       const rows = db.prepare(
+        // Unary + on parent_name, for the same reason as searchCustomExtensions'
+        // `+type IN (…)`: written plainly, `parent_name IS NULL` makes the planner
+        // choose idx_symbols_parent_name, whose ANALYZE stats claim ~13 rows per
+        // value. NULL is not one value — it is every top-level object of every
+        // model, 180,664 of the 1,188,748 rows on the production DB, against 274
+        // for the one model being asked about. Measured warm: 454 ms on the
+        // parent_name plan, 1 ms on the model plan; cold it is the difference
+        // between a 5-minute first get_workspace_info and an instant one.
+        // EXPLAIN QUERY PLAN must keep reporting
+        // `SEARCH symbols USING INDEX idx_symbols_model`.
         `SELECT name FROM symbols
            WHERE model = ?
              AND type ${extensions ? "LIKE" : "NOT LIKE"} '%-extension'
-             ${extensions ? "" : "AND parent_name IS NULL"}
+             ${extensions ? "" : "AND +parent_name IS NULL"}
              AND type NOT IN ('method', 'field')
            ORDER BY type, name
            LIMIT ?`
@@ -2261,7 +2289,10 @@ var XppSymbolIndex = class _XppSymbolIndex {
     };
     const half = Math.max(1, Math.ceil(limit / 2));
     const extensionNames = band(true, half);
-    const regularNames = band(false, limit - extensionNames.length);
+    const regularNames = band(
+      false,
+      Math.min(_XppSymbolIndex.REGULAR_NAME_SAMPLE, limit - extensionNames.length)
+    );
     return [...extensionNames, ...regularNames];
   }
   removeSymbolsByFile(filePath) {

package/dist/scripts/startupIndexWorker.js

@@ -1381,6 +1381,15 @@ var XppSymbolIndex = class _XppSymbolIndex {
    *
    * Returns the names of top-level objects that were removed (for cache invalidation).
    */
+  /**
+   * How many regular (non-extension) object names the prefix sample may draw.
+   *
+   * inferPrefixFromObjectNames needs MIN_SAMPLE (4) of them and decides on a 60 %
+   * coverage threshold, so a few dozen settle the question as well as a few hundred
+   * — and this is the band that costs, since a model's extensions are counted in
+   * tens while its classes and tables run to thousands.
+   */
+  static REGULAR_NAME_SAMPLE = 60;
   /**
    * Top-level object names belonging to one model — the evidence from which a
    * model's naming prefix is inferred (see utils/modelPrefixInference.ts).
@@ -1412,6 +1421,15 @@ var XppSymbolIndex = class _XppSymbolIndex {
    * so the same model always yields the same sample — a silent, self-reinforcing
    * failure otherwise, since this server writes names with the inferred prefix and
    * those names become evidence for the next inference.
+   *
+   * The regular band is capped well below its share of the budget
+   * (REGULAR_NAME_SAMPLE), because it is the expensive half and the cheap half
+   * carries most of the signal: extensions state the infix outright, while regular
+   * objects only have to clear MIN_SAMPLE (4) and MIN_COVERAGE (60 %) for the
+   * leading token. Reading 400 of them to settle a 4-name question was paid on the
+   * first call of every session. They cannot be dropped altogether — the underscore
+   * form ("ConSK_" vs "ConSK") appears in no extension name, so only a regular
+   * object can decide it.
    */
   getModelObjectNames(model, limit = 400) {
     if (!model) return [];
@@ -1420,10 +1438,20 @@ var XppSymbolIndex = class _XppSymbolIndex {
     const band = (extensions, cap) => {
       if (cap <= 0) return [];
       const rows = db.prepare(
+        // Unary + on parent_name, for the same reason as searchCustomExtensions'
+        // `+type IN (…)`: written plainly, `parent_name IS NULL` makes the planner
+        // choose idx_symbols_parent_name, whose ANALYZE stats claim ~13 rows per
+        // value. NULL is not one value — it is every top-level object of every
+        // model, 180,664 of the 1,188,748 rows on the production DB, against 274
+        // for the one model being asked about. Measured warm: 454 ms on the
+        // parent_name plan, 1 ms on the model plan; cold it is the difference
+        // between a 5-minute first get_workspace_info and an instant one.
+        // EXPLAIN QUERY PLAN must keep reporting
+        // `SEARCH symbols USING INDEX idx_symbols_model`.
         `SELECT name FROM symbols
            WHERE model = ?
              AND type ${extensions ? "LIKE" : "NOT LIKE"} '%-extension'
-             ${extensions ? "" : "AND parent_name IS NULL"}
+             ${extensions ? "" : "AND +parent_name IS NULL"}
              AND type NOT IN ('method', 'field')
            ORDER BY type, name
            LIMIT ?`
@@ -1432,7 +1460,10 @@ var XppSymbolIndex = class _XppSymbolIndex {
     };
     const half = Math.max(1, Math.ceil(limit / 2));
     const extensionNames = band(true, half);
-    const regularNames = band(false, limit - extensionNames.length);
+    const regularNames = band(
+      false,
+      Math.min(_XppSymbolIndex.REGULAR_NAME_SAMPLE, limit - extensionNames.length)
+    );
     return [...extensionNames, ...regularNames];
   }
   removeSymbolsByFile(filePath) {

package/dist/server/serverMode.d.ts

@@ -29,6 +29,29 @@
  * created without an Azure re-deploy.
  */
 export declare const LOCAL_TOOLS: Set<string>;
+/**
+ * The LOCAL_TOOLS that do read the symbol database after all, and so must NOT
+ * inherit this set's exemption from the dbReady wait in toolHandler.
+ *
+ * "Local" answers a question about LOCALITY — can this run away from the K:\ drive
+ * — and the dbReady exemption rode along on it as if it also meant "needs no
+ * index". For two of them it does not:
+ *
+ *  • get_workspace_info infers the model's prefix from symbols.getModelObjectNames
+ *    and reads getLastIndexedAt. Exempt, it had no timeout either: while the 2.5 GB
+ *    database opened, the tool a session STARTS with sat there with no answer and
+ *    no way to fail. Measured live 2026-09-07: 337.5 s, and 356 s / 424 s on two
+ *    earlier cold starts, where every other tool would have said "still loading,
+ *    retry" after 55 s. It also answered from the empty stub index when it did
+ *    return early — a configured prefix reported as if the model had taught it.
+ *  • update_symbol_index writes THROUGH context.symbolIndex (removeSymbolsByFile,
+ *    removeLabelsByFile). Before the swap that is the :memory: stub, so the call
+ *    reports a successful re-index of a database nobody will ever read.
+ *
+ * The rest (build, bp-check, systest, verify) genuinely only touch the filesystem
+ * and the compiler, and keep the exemption.
+ */
+export declare const DB_BACKED_LOCAL_TOOLS: Set<string>;
 /**
  * Tools exposed in EVERY server mode, bypassing the LOCAL_TOOLS partition,
  * because each spans both localities and gates unavailable actions at runtime:

package/dist/server/serverMode.js

@@ -36,6 +36,32 @@ export const LOCAL_TOOLS = new Set([
     'run_systest_class',
     'get_workspace_info',
 ]);
+/**
+ * The LOCAL_TOOLS that do read the symbol database after all, and so must NOT
+ * inherit this set's exemption from the dbReady wait in toolHandler.
+ *
+ * "Local" answers a question about LOCALITY — can this run away from the K:\ drive
+ * — and the dbReady exemption rode along on it as if it also meant "needs no
+ * index". For two of them it does not:
+ *
+ *  • get_workspace_info infers the model's prefix from symbols.getModelObjectNames
+ *    and reads getLastIndexedAt. Exempt, it had no timeout either: while the 2.5 GB
+ *    database opened, the tool a session STARTS with sat there with no answer and
+ *    no way to fail. Measured live 2026-09-07: 337.5 s, and 356 s / 424 s on two
+ *    earlier cold starts, where every other tool would have said "still loading,
+ *    retry" after 55 s. It also answered from the empty stub index when it did
+ *    return early — a configured prefix reported as if the model had taught it.
+ *  • update_symbol_index writes THROUGH context.symbolIndex (removeSymbolsByFile,
+ *    removeLabelsByFile). Before the swap that is the :memory: stub, so the call
+ *    reports a successful re-index of a database nobody will ever read.
+ *
+ * The rest (build, bp-check, systest, verify) genuinely only touch the filesystem
+ * and the compiler, and keep the exemption.
+ */
+export const DB_BACKED_LOCAL_TOOLS = new Set([
+    'get_workspace_info',
+    'update_symbol_index',
+]);
 /**
  * Tools exposed in EVERY server mode, bypassing the LOCAL_TOOLS partition,
  * because each spans both localities and gates unavailable actions at runtime:

package/dist/tools/analysis/searchLabels.js

@@ -72,7 +72,7 @@ function rowKey(r) {
  * the 2026-08-07 demo; `action="search"` never did, and search is the call an
  * agent makes BEFORE it reuses a label. Benchmark run d79f62a3 (2026-08-17) took
  * all three labels it needed from one search — the enum's, the field's and the
- * error message's — all reported as resolvable [AslFinanceSK] hits, none of them
+ * error message's — all reported as resolvable [ContosoFinanceSK] hits, none of them
  * on disk. `xppc` does not check labels, so the first build passed; the run paid
  * a second build, a second BP check and ~12 AIU to find out.
  *

package/dist/tools/readers/getObjectInfo.js

@@ -244,6 +244,11 @@ async function readObject(ref, context, allowTypeCorrection = true) {
     if (options?.include === 'xml') {
         const xml = await readObjectXml(objectType, name, {
             modelName: options.modelName,
+            // Without this the lookup only ever sees the CONFIGURED model's folder, so
+            // every read of a Microsoft or other-model object came back as "pass
+            // options.modelName" — a round trip for a fact this same tool prints in
+            // every other include mode.
+            index: context.symbolIndex,
             startLine: options.startLine,
             endLine: options.endLine,
             maxChars: options.maxChars,

package/dist/tools/readers/objectXml.d.ts

@@ -8,8 +8,14 @@
  * it. A recursive scan of PackagesLocalDirectory costs seconds; this is one
  * indexed lookup.
  */
+import { type SymbolFileLookupSource } from '../../utils/objectFileLookup.js';
 export interface ObjectXmlOptions {
     modelName?: string;
+    /**
+     * The symbol index, when the caller has one. Without it this falls back to the
+     * configured model's folder layout, which only ever finds objects in that model.
+     */
+    index?: SymbolFileLookupSource;
     /** 1-based, inclusive. Omit both for the whole file (up to maxChars). */
     startLine?: number;
     endLine?: number;
@@ -21,7 +27,16 @@ export interface ObjectXmlResult {
 }
 /** Render a file already located. Split out so it is testable without config. */
 export declare function renderObjectXml(filePath: string, objectType: string, objectName: string, options?: ObjectXmlOptions): Promise<ObjectXmlResult>;
-/** The message for an object with no file — never an empty result. */
-export declare function objectXmlNotFound(objectType: string, objectName: string, modelName?: string): ObjectXmlResult;
+/**
+ * The message for an object with no file — never an empty result.
+ *
+ * `elsewhere` are the models the index says DO hold an object of this name. Naming
+ * them is the whole difference between a message the caller can act on and one it
+ * can only guess at: "pass options.modelName" sent an agent looking for
+ * JournalVoucherNum in "Application Foundation" (wrong) before "Foundation"
+ * (right), three calls for one file. An empty list is itself an answer — no model
+ * has it, so retrying with a different modelName cannot help.
+ */
+export declare function objectXmlNotFound(objectType: string, objectName: string, modelName?: string, elsewhere?: string[]): ObjectXmlResult;
 export declare function readObjectXml(objectType: string, objectName: string, options?: ObjectXmlOptions): Promise<ObjectXmlResult>;
 //# sourceMappingURL=objectXml.d.ts.map

package/dist/tools/readers/objectXml.js

@@ -9,7 +9,7 @@
  * indexed lookup.
  */
 import * as fs from 'fs/promises';
-import { findD365FileOnDisk } from '../../utils/objectFileLookup.js';
+import { findD365FileOnDisk, findD365FileViaIndex, modelsHoldingObject, } from '../../utils/objectFileLookup.js';
 /** Default ceiling on returned XML. A large form is well past any useful read. */
 const DEFAULT_MAX_CHARS = 40_000;
 /** Render a file already located. Split out so it is testable without config. */
@@ -40,19 +40,45 @@ export async function renderObjectXml(filePath, objectType, objectName, options
         : '';
     return { isError: false, text: `${header}\n\`\`\`xml\n${body}\n\`\`\`${footer}` };
 }
-/** The message for an object with no file — never an empty result. */
-export function objectXmlNotFound(objectType, objectName, modelName) {
+/**
+ * The message for an object with no file — never an empty result.
+ *
+ * `elsewhere` are the models the index says DO hold an object of this name. Naming
+ * them is the whole difference between a message the caller can act on and one it
+ * can only guess at: "pass options.modelName" sent an agent looking for
+ * JournalVoucherNum in "Application Foundation" (wrong) before "Foundation"
+ * (right), three calls for one file. An empty list is itself an answer — no model
+ * has it, so retrying with a different modelName cannot help.
+ */
+export function objectXmlNotFound(objectType, objectName, modelName, elsewhere = []) {
+    const where = elsewhere.filter(m => m !== modelName);
+    const hint = where.length > 0
+        ? `The index has it in ${where.map(m => `"${m}"`).join(' · ')} — retry with ` +
+            `options.modelName="${where[0]}". If that also misses, the index row is stale ` +
+            `(the file was moved or deleted since the last index run).`
+        : `No model in the symbol index holds a ${objectType} of that name, so retrying with ` +
+            `a different options.modelName will not help — check the spelling and the ` +
+            `objectType, or the object does not exist yet.`;
     return {
         isError: true,
         text: `❌ get_object_info(include="xml"): no file on disk for ${objectType} "${objectName}"` +
-            `${modelName ? ` in model "${modelName}"` : ''}.\n` +
-            `The object may live in another model — pass options.modelName — or may not exist yet.`,
+            `${modelName ? ` in model "${modelName}"` : ''}.\n${hint}`,
     };
 }
 export async function readObjectXml(objectType, objectName, options = {}) {
-    const filePath = await findD365FileOnDisk(objectType, objectName, options.modelName);
-    if (!filePath)
-        return objectXmlNotFound(objectType, objectName, options.modelName);
-    return renderObjectXml(filePath, objectType, objectName, options);
+    // Configured-model layout first: it is a couple of fs.access calls, it is what a
+    // freshly created object (not yet indexed) resolves through, and it keeps the
+    // common case — reading something in the model being worked in — off the DB.
+    const onDisk = await findD365FileOnDisk(objectType, objectName, options.modelName);
+    if (onDisk)
+        return renderObjectXml(onDisk, objectType, objectName, options);
+    // Then the index, which knows every model rather than just the configured one.
+    if (options.index) {
+        const indexed = await findD365FileViaIndex(options.index, objectType, objectName, options.modelName);
+        if (indexed)
+            return renderObjectXml(indexed.filePath, objectType, objectName, options);
+        return objectXmlNotFound(objectType, objectName, options.modelName, modelsHoldingObject(options.index, objectType, objectName));
+    }
+    return objectXmlNotFound(objectType, objectName, options.modelName);
 }
 //# sourceMappingURL=objectXml.js.map

package/dist/tools/toolHandler.js

@@ -1,6 +1,6 @@
 import { CallToolRequestSchema } from '@modelcontextprotocol/sdk/types.js';
 import { getConfigManager } from '../utils/configManager.js';
-import { SERVER_MODE, LOCAL_TOOLS, TOOL_PROFILE, isToolAllowedInMode, isToolInProfile, } from '../server/serverMode.js';
+import { SERVER_MODE, LOCAL_TOOLS, DB_BACKED_LOCAL_TOOLS, TOOL_PROFILE, isToolAllowedInMode, isToolInProfile, } from '../server/serverMode.js';
 import { BRIDGE_BACKED_TOOLS, awaitBridgeReady } from '../bridge/bridgeReadiness.js';
 import { BRIDGE_FAILURE_MARKER, runWithBridgeFailureScope, renderBridgeFailureNote, } from '../bridge/bridgeFailure.js';
 import { runWithSideEffectScope, renderSideEffectNote, } from '../utils/writeSideEffects.js';
@@ -40,7 +40,7 @@ import { capToolResponse } from './responseCaps.js';
  */
 const WRITE_CAPABLE_TOOLS = new Set(['d365fo_file', 'labels']);
 import { buildProgressMessage } from '../utils/toolProgressMessage.js';
-import { createProgressReporter } from '../utils/progressReporter.js';
+import { createProgressReporter, startProgressHeartbeat } from '../utils/progressReporter.js';
 /**
  * Extract workspace path from GitHub Copilot _meta.
  * HTTP requests must not overwrite the shared runtimeContext (AsyncLocalStorage
@@ -101,6 +101,8 @@ function extractWorkspaceFromMeta(meta) {
  * The bridge-readiness wait below is untouched — different, much shorter gate.
  */
 const DB_FREE_TOOLS = new Set(['get_knowledge']);
+/** Tools that drive the progress reporter themselves, and must not be doubled up on. */
+const SELF_REPORTING_TOOLS = new Set(['build_d365fo_project']);
 export function registerToolHandler(server, context) {
     startMetricsLogging();
     server.setRequestHandler(CallToolRequestSchema, async (request, extra) => {
@@ -125,8 +127,12 @@ export function registerToolHandler(server, context) {
         // ctx.dbReady resolves once the real symbol database is loaded; await it so
         // tools use the real index instead of silently returning empty results.
         // LOCAL_TOOLS need no DB (filesystem/in-memory config only) and skip the
-        // wait; so do DB_FREE_TOOLS, whose answer is in-repo static data.
-        if (context.dbReady && !LOCAL_TOOLS.has(toolName) && !DB_FREE_TOOLS.has(toolName)) {
+        // wait — except DB_BACKED_LOCAL_TOOLS, which are local AND read the index, and
+        // whose exemption cost them the 55 s ceiling too. DB_FREE_TOOLS also skip it,
+        // their answer being in-repo static data.
+        const skipsDbWait = (LOCAL_TOOLS.has(toolName) && !DB_BACKED_LOCAL_TOOLS.has(toolName)) ||
+            DB_FREE_TOOLS.has(toolName);
+        if (context.dbReady && !skipsDbWait) {
             const t0 = Date.now();
             // Race dbReady against a 55-second timeout so VS Code's ~60 s client
             // timeout doesn't silently cancel the request. If the DB is still loading
@@ -268,6 +274,10 @@ export function registerToolHandler(server, context) {
                 // The reporter never rejects (both sends are try/caught inside), and the
                 // transport writes in call order, so the notification still precedes the result.
                 void reportProgress(progressMsg, 0);
+                // …and then nothing, for however long the tool takes — see startProgressHeartbeat.
+                const stopHeartbeat = SELF_REPORTING_TOOLS.has(toolName)
+                    ? null
+                    : startProgressHeartbeat(reportProgress, progressMsg);
                 return (async () => {
                     switch (toolName) {
                         case 'search':
@@ -340,7 +350,7 @@ export function registerToolHandler(server, context) {
                                 isError: true,
                             };
                     }
-                })();
+                })().finally(() => stopHeartbeat?.());
             }));
         }
         catch (err) {

package/dist/tools/write/resolveReferences.js

@@ -406,7 +406,7 @@ function extensionAddedFields(deps, tableName) {
     return names;
 }
 /**
- * `AslFinSK_QualityTier` → `qualitytier`. A member added to another model's
+ * `ConSK_QualityTier` → `qualitytier`. A member added to another model's
  * object carries that model's prefix (applyExtensionMemberPrefix mints it), so
  * the name in the agent's X++ and the name on disk routinely differ by exactly
  * this token.

package/dist/utils/indexStaleness.d.ts

@@ -34,6 +34,7 @@ export declare function findNewestMetadataMtime(rootDir: string): MtimeScanResul
 export type MtimeScanState = {
     status: 'ready';
     result: MtimeScanResult | null;
+    scannedAt: number;
 } | {
     status: 'pending';
 };
@@ -42,9 +43,16 @@ export type MtimeScanState = {
  *
  * `blocking: true` is the old behaviour — scan now, answer now — and is what
  * `diagnostics: true` uses, because the whole point of diagnostics is the full
- * picture. `blocking: false` answers from cache or says "pending" and schedules
- * the walk on a later tick, so the request path never carries it. Either way the
- * result lands in the same cache, so the NEXT call has the real verdict.
+ * picture. `blocking: false` answers from cache and schedules the walk on a later
+ * tick, so the request path never carries it.
+ *
+ * 'pending' is returned only while NO scan has ever completed for this root. Once
+ * one has, an expired entry is served — with the time it was taken — and a refresh
+ * is scheduled behind it. Expiring back to 'pending' made the "call again for the
+ * verdict" the caller is told to act on unwinnable: the entry lives SCAN_CACHE_MS
+ * (30 s) and an agent that re-asks any later than that gets the identical
+ * "still running" line, forever. Observed live on 2026-09-07: three
+ * get_workspace_info calls 105 s apart, byte-identical output every time.
  */
 export declare function findNewestMetadataMtimeCached(rootDir: string, opts?: {
     blocking?: boolean;

package/dist/utils/indexStaleness.js

@@ -47,16 +47,27 @@ export function findNewestMetadataMtime(rootDir) {
  *
  * `blocking: true` is the old behaviour — scan now, answer now — and is what
  * `diagnostics: true` uses, because the whole point of diagnostics is the full
- * picture. `blocking: false` answers from cache or says "pending" and schedules
- * the walk on a later tick, so the request path never carries it. Either way the
- * result lands in the same cache, so the NEXT call has the real verdict.
+ * picture. `blocking: false` answers from cache and schedules the walk on a later
+ * tick, so the request path never carries it.
+ *
+ * 'pending' is returned only while NO scan has ever completed for this root. Once
+ * one has, an expired entry is served — with the time it was taken — and a refresh
+ * is scheduled behind it. Expiring back to 'pending' made the "call again for the
+ * verdict" the caller is told to act on unwinnable: the entry lives SCAN_CACHE_MS
+ * (30 s) and an agent that re-asks any later than that gets the identical
+ * "still running" line, forever. Observed live on 2026-09-07: three
+ * get_workspace_info calls 105 s apart, byte-identical output every time.
  */
 export function findNewestMetadataMtimeCached(rootDir, opts = {}) {
     const hit = scanCache.get(rootDir);
-    if (hit && Date.now() - hit.at < SCAN_CACHE_MS)
-        return { status: 'ready', result: hit.result };
-    if (opts.blocking)
-        return { status: 'ready', result: findNewestMetadataMtime(rootDir) };
+    if (hit && Date.now() - hit.at < SCAN_CACHE_MS) {
+        return { status: 'ready', result: hit.result, scannedAt: hit.at };
+    }
+    if (opts.blocking) {
+        findNewestMetadataMtime(rootDir);
+        const fresh = scanCache.get(rootDir);
+        return { status: 'ready', result: fresh.result, scannedAt: fresh.at };
+    }
     if (!scanInFlight.has(rootDir)) {
         scanInFlight.add(rootDir);
         // setTimeout, not a worker: the walk is synchronous fs work either way, but
@@ -75,6 +86,11 @@ export function findNewestMetadataMtimeCached(rootDir, opts = {}) {
         }, 0);
         timer.unref?.();
     }
+    // An expired entry still answers the question better than "ask again" does; the
+    // refresh just scheduled replaces it, and checkIndexStaleness qualifies a 'fresh'
+    // verdict drawn from an aged scan.
+    if (hit)
+        return { status: 'ready', result: hit.result, scannedAt: hit.at };
     return { status: 'pending' };
 }
 function scanNewestMetadataMtime(rootDir) {
@@ -176,6 +192,10 @@ export function checkIndexStaleness(lastIndexedAt, modelMetadataDir, opts = {})
         };
     }
     const scan = state.result;
+    // How old the walk behind this verdict is. Zero on the blocking path and on a
+    // cache hit inside SCAN_CACHE_MS; larger only when an expired entry is being
+    // served while its replacement runs — see findNewestMetadataMtimeCached.
+    const scanAgeMs = Date.now() - state.scannedAt;
     if (!scan) {
         lines.push(`ℹ️  No metadata files found under ${modelMetadataDir} — nothing to compare.`);
         return {
@@ -197,6 +217,20 @@ export function checkIndexStaleness(lastIndexedAt, modelMetadataDir, opts = {})
             ],
         };
     }
+    // A 'stale' verdict from an aged scan is still true — files only ever get newer —
+    // so only 'fresh' has to admit what it did not look at. TOLERANCE_MS is the window
+    // the comparison already forgives, so a scan younger than that adds no blind spot.
+    if (scanAgeMs > TOLERANCE_MS) {
+        const scanAgeMin = Math.round(scanAgeMs / 60_000);
+        lines.push(`✅ No workspace file was newer than the index as of the last scan (${scanAgeMin} min ago).`, '   A rescan is running in the background; call again for the current verdict.');
+        return {
+            status: 'fresh',
+            lines,
+            compactLines: [
+                `Index       : up to date as of ${scanAgeMin} min ago (indexed ${ageHours} h ago, rescan running)`,
+            ],
+        };
+    }
     lines.push('✅ Index is up to date with the workspace.');
     return {
         status: 'fresh',

package/dist/utils/objectFileLookup.d.ts

@@ -12,6 +12,50 @@
  * This handles objects that were just created and are not yet indexed in the symbol database.
  */
 export declare function findD365FileOnDisk(objectType: string, objectName: string, modelName?: string, explicitPackagePath?: string): Promise<string | null>;
+/**
+ * The read surface findD365FileViaIndex needs, stated structurally so a util does
+ * not have to import the symbol index (and, through it, half the server) to ask
+ * one question of it. XppSymbolIndex satisfies it as-is.
+ */
+export interface SymbolFileLookupSource {
+    getReadDb(): {
+        prepare(sql: string): {
+            all(...params: any[]): any[];
+        };
+    };
+}
+/** Where the index says an object lives, once the path has been verified on disk. */
+export interface IndexedObjectFile {
+    filePath: string;
+    model: string;
+}
+/**
+ * Locate an object's XML through the SYMBOL INDEX rather than through the
+ * configured model's folder layout.
+ *
+ * findD365FileOnDisk answers "where would an object of this name be, in the model
+ * I am configured for" — which is the right question for a write and the wrong one
+ * for a read. Reads span every model: get_object_info(include="xml") on a Microsoft
+ * class, or on another custom model's class, hit the model-shaped lookup, missed,
+ * and were answered with "pass options.modelName" — a whole round trip to supply a
+ * fact the same server had already printed ("**Model:** Foundation") one call
+ * earlier, and one the caller then has to GUESS. Observed 2026-09-07: three such
+ * pairs in one session, one of which took three calls because the guess
+ * ("Application Foundation") was wrong.
+ *
+ * The index stores some paths absolute and some relative to a packages root (582
+ * of 60,918 classes on the production DB), so a relative row is resolved against
+ * the same roots findD365FileOnDisk prefers. Every candidate is checked on disk
+ * before it is returned: an index row whose file is gone is exactly the stale
+ * state `search` already warns about, and returning its path would turn a clean
+ * "not found" into "found it, but could not read it".
+ */
+export declare function findD365FileViaIndex(index: SymbolFileLookupSource, objectType: string, objectName: string, modelName?: string): Promise<IndexedObjectFile | null>;
+/**
+ * The models that hold an object of this type and name, for a "not found" message
+ * that can name the answer instead of asking the caller to guess it.
+ */
+export declare function modelsHoldingObject(index: SymbolFileLookupSource, objectType: string, objectName: string, limit?: number): string[];
 /**
  * The path an object's XML WOULD have, whether or not it exists yet.
  *

package/dist/utils/objectFileLookup.js

@@ -147,6 +147,92 @@ export async function findD365FileOnDisk(objectType, objectName, modelName, expl
     }
     return null;
 }
+/**
+ * Locate an object's XML through the SYMBOL INDEX rather than through the
+ * configured model's folder layout.
+ *
+ * findD365FileOnDisk answers "where would an object of this name be, in the model
+ * I am configured for" — which is the right question for a write and the wrong one
+ * for a read. Reads span every model: get_object_info(include="xml") on a Microsoft
+ * class, or on another custom model's class, hit the model-shaped lookup, missed,
+ * and were answered with "pass options.modelName" — a whole round trip to supply a
+ * fact the same server had already printed ("**Model:** Foundation") one call
+ * earlier, and one the caller then has to GUESS. Observed 2026-09-07: three such
+ * pairs in one session, one of which took three calls because the guess
+ * ("Application Foundation") was wrong.
+ *
+ * The index stores some paths absolute and some relative to a packages root (582
+ * of 60,918 classes on the production DB), so a relative row is resolved against
+ * the same roots findD365FileOnDisk prefers. Every candidate is checked on disk
+ * before it is returned: an index row whose file is gone is exactly the stale
+ * state `search` already warns about, and returning its path would turn a clean
+ * "not found" into "found it, but could not read it".
+ */
+export async function findD365FileViaIndex(index, objectType, objectName, modelName) {
+    // Types with no folder of their own are not objects this can read a file for.
+    if (!AOT_FOLDER_BY_OBJECT_TYPE[objectType])
+        return null;
+    let rows;
+    try {
+        const db = index.getReadDb();
+        // parent_name IS NULL keeps methods and fields of the same name out; the
+        // (type, name) index carries this lookup, so it costs a seek, not a scan.
+        const sql = `SELECT file_path, model FROM symbols
+       WHERE type = ? AND name = ? AND parent_name IS NULL` +
+            (modelName ? ` AND model = ?` : ``) +
+            ` LIMIT 20`;
+        const params = modelName ? [objectType, objectName, modelName] : [objectType, objectName];
+        rows = db.prepare(sql).all(...params);
+    }
+    catch {
+        return null; // index unavailable (stub context during startup, :memory:) — caller falls back
+    }
+    if (rows.length === 0)
+        return null;
+    // Resolved on first need: most rows carry an absolute path (60,336 of 60,918
+    // classes on the production DB), and those need no config at all.
+    let roots = null;
+    const packageRoots = async () => {
+        if (roots)
+            return roots;
+        const configManager = getConfigManager();
+        await configManager.ensureLoaded();
+        roots = [
+            await configManager.getCustomPackagesPath(),
+            configManager.getPackagePath() || fallbackPackagePath(),
+            await configManager.getMicrosoftPackagesPath(),
+        ].filter((r) => !!r);
+        return roots;
+    };
+    for (const row of rows) {
+        const candidates = path.isAbsolute(row.file_path)
+            ? [row.file_path]
+            : (await packageRoots()).map(root => path.join(root, row.file_path));
+        for (const candidate of candidates) {
+            try {
+                await fs.access(candidate);
+                return { filePath: candidate, model: row.model };
+            }
+            catch { /* next candidate */ }
+        }
+    }
+    return null;
+}
+/**
+ * The models that hold an object of this type and name, for a "not found" message
+ * that can name the answer instead of asking the caller to guess it.
+ */
+export function modelsHoldingObject(index, objectType, objectName, limit = 5) {
+    try {
+        const rows = index.getReadDb().prepare(`SELECT DISTINCT model FROM symbols
+       WHERE type = ? AND name = ? AND parent_name IS NULL
+       ORDER BY model LIMIT ?`).all(objectType, objectName, limit);
+        return rows.map(r => r.model);
+    }
+    catch {
+        return [];
+    }
+}
 /**
  * The path an object's XML WOULD have, whether or not it exists yet.
  *

package/dist/utils/objectNamingRules.js

@@ -54,7 +54,7 @@ const UNDERSCORE_EXTENSION = /^[A-Za-z]\w*_Extension$/;
  * Reinterpret `objectType` when the proposed name is unmistakably an extension.
  *
  * Callers reach for the base type — "is this a valid *form* name?" — while proposing
- * `AslFinCore_TaxTransReportChangeLog.AslFinSKExtension`. Validated as a plain form
+ * `ConCore_TaxTransReportChangeLog.ConSKExtension`. Validated as a plain form
  * that trips the "non-extension objects must not contain underscores" rule and comes
  * back as a hard ERROR, which is both wrong and a wasted round trip: run f2e7b71a
  * asked with `form`, was refused, and asked again with `form-extension` (T56 → T59).

package/dist/utils/progressReporter.d.ts

@@ -23,6 +23,31 @@ import type { Server } from '@modelcontextprotocol/sdk/server/index.js';
  * for a tool whose total is unknown. `total` may be omitted for open-ended work.
  */
 export type ProgressReporter = (message: string, progress: number, total?: number) => Promise<void>;
+/**
+ * How often an in-flight tool call re-announces itself.
+ *
+ * Long enough that a normal call never sends one, short enough to stay inside the
+ * request timeouts clients reset on each notification (VS Code's is ~60 s).
+ */
+export declare const PROGRESS_HEARTBEAT_MS = 15000;
+/**
+ * Keep saying "still running" until the returned stop() is called.
+ *
+ * The dispatcher sends one notification when a tool starts, and then nothing for
+ * however long it takes — so a call that runs for minutes is indistinguishable from
+ * a hung one. On 2026-09-07 a first get_workspace_info ran 337.5 s behind a cold
+ * database open: the IDE showed "⚙️ Reading workspace configuration" and no further
+ * sign of life for five and a half minutes, and the server log (which mirrors
+ * stderr, and startup progress does not reach stderr) held nothing either.
+ *
+ * A tick says the call is alive and how long it has been running, and — for clients
+ * that honour progress notifications — resets their request timeout, the mechanism
+ * build_d365fo_project already relies on to survive a long xppc. Elapsed seconds is
+ * the progress value because MCP requires it to increase and no total is known.
+ * Nothing fires before the first tick, so tools answering in milliseconds send
+ * exactly what they sent before.
+ */
+export declare function startProgressHeartbeat(report: ProgressReporter, message: string, everyMs?: number): () => void;
 /** The slice of the SDK's request `extra` that the reporter needs. */
 export interface ProgressRequestExtra {
     _meta?: Record<string, unknown>;

package/dist/utils/progressReporter.js

@@ -16,6 +16,40 @@
  * Both are best-effort: a client that rejects or ignores them must never fail
  * or stall the tool.
  */
+/**
+ * How often an in-flight tool call re-announces itself.
+ *
+ * Long enough that a normal call never sends one, short enough to stay inside the
+ * request timeouts clients reset on each notification (VS Code's is ~60 s).
+ */
+export const PROGRESS_HEARTBEAT_MS = 15_000;
+/**
+ * Keep saying "still running" until the returned stop() is called.
+ *
+ * The dispatcher sends one notification when a tool starts, and then nothing for
+ * however long it takes — so a call that runs for minutes is indistinguishable from
+ * a hung one. On 2026-09-07 a first get_workspace_info ran 337.5 s behind a cold
+ * database open: the IDE showed "⚙️ Reading workspace configuration" and no further
+ * sign of life for five and a half minutes, and the server log (which mirrors
+ * stderr, and startup progress does not reach stderr) held nothing either.
+ *
+ * A tick says the call is alive and how long it has been running, and — for clients
+ * that honour progress notifications — resets their request timeout, the mechanism
+ * build_d365fo_project already relies on to survive a long xppc. Elapsed seconds is
+ * the progress value because MCP requires it to increase and no total is known.
+ * Nothing fires before the first tick, so tools answering in milliseconds send
+ * exactly what they sent before.
+ */
+export function startProgressHeartbeat(report, message, everyMs = PROGRESS_HEARTBEAT_MS) {
+    const startedAt = Date.now();
+    const timer = setInterval(() => {
+        const elapsedSec = Math.round((Date.now() - startedAt) / 1000);
+        void report(`${message} — still running, ${elapsedSec}s`, elapsedSec);
+    }, everyMs);
+    // Never hold the process open for a heartbeat.
+    timer.unref?.();
+    return () => clearInterval(timer);
+}
 /**
  * Build a reporter bound to one in-flight tool call. Always returns a callable —
  * when the client offers neither channel the reporter is simply a no-op, so

package/dist/workspace/contextSnapshot.js

@@ -184,7 +184,14 @@ export async function buildContextSnapshot(context, opts = {}) {
                 recentObjects = cached.objects;
             }
             else {
-                recentPending = true;
+                // 'pending' only until the FIRST scan lands. After that an expired entry is
+                // served and refreshed behind the answer, because "call again for the list"
+                // is otherwise a promise this cannot keep: the entry lives RECENT_CACHE_MS
+                // (30 s), so any re-ask later than that finds it expired and is told to call
+                // again — the same line, forever. Half a minute stale was already declared
+                // an accurate answer here; several minutes stale still beats no answer.
+                recentObjects = cached?.objects ?? [];
+                recentPending = !cached;
                 // Not awaited. The result lands in the cache above, so the NEXT call
                 // shows it — the information is deferred, never dropped.
                 if (!recentScanInFlight.has(workspacePath)) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "d365fo-mcp",
-  "version": "1.17.2",
+  "version": "1.17.3",
   "description": "MCP Server for X++ Code Completion in D365 Finance & Operations",
   "type": "module",
   "main": "dist/index.js",