@lenne.tech/cli 1.41.2 → 1.42.0

package/build/lib/vscode-settings.js

@@ -0,0 +1,351 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.EXCLUDED_FROM_PROFILE = exports.MEMORY_PROFILE = void 0;
+exports.buildMergedValue = buildMergedValue;
+exports.detectVariants = detectVariants;
+exports.diffProfile = diffProfile;
+exports.formatChange = formatChange;
+exports.isEnablingFlagSet = isEnablingFlagSet;
+exports.isPreventingFlagSet = isPreventingFlagSet;
+exports.selectVariants = selectVariants;
+exports.settingsPathFor = settingsPathFor;
+exports.tuneSettingsFile = tuneSettingsFile;
+const fs_1 = require("fs");
+const os_1 = require("os");
+const path_1 = require("path");
+/**
+ * The tuning profile.
+ *
+ * Every value here was verified against the shipped extension manifests
+ * rather than copied from a blog post — three commonly recommended keys are
+ * deliberately ABSENT, see `EXCLUDED_FROM_PROFILE`.
+ *
+ * The exclude globs use `.nuxt*` / `.output*`, not `.nuxt` / `.output`. Both the
+ * framework and this CLI spawn SIBLING build directories — `.nuxt-check` for the
+ * check chain, `.nuxt-test` / `.output-test` for `lt dev test` — and a glob
+ * segment matches whole path segments, so `**\/.nuxt/**` does not cover
+ * `.nuxt-test`. A `.output-test` tree measures 37-294 MB; leaving it watched and
+ * indexed would undo the very saving this profile exists to make.
+ */
+exports.MEMORY_PROFILE = {
+    'files.watcherExclude': {
+        reason: 'Stops the file watcher from following build output and dependencies (CPU + memory per window).',
+        value: {
+            '**/.git/objects/**': true,
+            '**/.git/subtree-cache/**': true,
+            '**/.nuxt*/**': true,
+            '**/.output*/**': true,
+            '**/dist/**': true,
+            '**/node_modules/**': true,
+        },
+    },
+    'search.exclude': {
+        reason: 'Keeps full-text search from indexing generated trees.',
+        value: {
+            '**/.nuxt*/**': true,
+            '**/.output*/**': true,
+            '**/dist/**': true,
+            '**/node_modules/**': true,
+        },
+    },
+    'typescript.disableAutomaticTypeAcquisition': {
+        reason: 'Skips the @types download/scan pass — pointless in projects that declare their own types.',
+        value: true,
+    },
+    'typescript.preferences.includePackageJsonAutoImports': {
+        reason: 'Auto-import no longer scans every package.json in the workspace — the single biggest monorepo win.',
+        value: 'off',
+    },
+    'typescript.tsserver.maxTsServerMemory': {
+        reason: 'Lowers the per-server heap ceiling from the 3072 MB default; multiplies across every open root.',
+        value: 2048,
+    },
+};
+/**
+ * Keys intentionally NOT in the profile, with the measurement or manifest
+ * check that ruled them out. Surfaced by `lt dev vscode --explain` so the
+ * reasoning survives beyond the session that produced it.
+ */
+exports.EXCLUDED_FROM_PROFILE = [
+    {
+        key: 'typescript.tsserver.useSyntaxServer: "never"',
+        why: 'Would drop the 2nd server per root, but those measured only ~1.7 GB across 16 roots while costing editor responsiveness.',
+    },
+    {
+        key: 'vue.server.hybridMode',
+        why: 'Does not exist in Volar 3.x — hybrid mode is unconditional there. Setting it is a silent no-op.',
+    },
+    {
+        key: 'typescript.tsserver.maxTsServerMemory: 4096+',
+        why: 'v8 pointer compression caps the heap near 4 GB, so values above it are ignored (microsoft/vscode#127105).',
+    },
+];
+/**
+ * Merge semantics per value type.
+ *
+ * A plain value is replaced. An object value (the exclude maps) is merged with
+ * the user's existing entries winning, so tuning never silently drops a
+ * project-specific exclusion someone added by hand.
+ *
+ * A non-object `before` under an object-valued key (an array, say) is NOT
+ * mergeable and is replaced — VS Code's exclude settings are objects, so such a
+ * value is already being ignored by VS Code itself. That is the one case where
+ * the "never drops" promise above does not hold, and `--revert` cannot restore
+ * it either; the `.bak` is the recovery path.
+ */
+function buildMergedValue(before, desired) {
+    if (!isPlainObject(desired)) {
+        return desired;
+    }
+    if (!isPlainObject(before)) {
+        return Object.assign({}, desired);
+    }
+    return Object.assign(Object.assign({}, desired), before);
+}
+/** Every known variant, flagged by whether its settings file exists. */
+function detectVariants(platform = process.platform, home = (0, os_1.homedir)()) {
+    const known = [
+        { dir: 'Code', id: 'code', label: 'VS Code' },
+        { dir: 'Code - Insiders', id: 'insiders', label: 'VS Code Insiders' },
+        { dir: 'Cursor', id: 'cursor', label: 'Cursor' },
+        { dir: 'VSCodium', id: 'vscodium', label: 'VSCodium' },
+    ];
+    return known.map((k) => {
+        const settingsPath = settingsPathFor(k.dir, platform, home);
+        return { id: k.id, installed: (0, fs_1.existsSync)(settingsPath), label: k.label, settingsPath };
+    });
+}
+/**
+ * Compare the profile against a parsed settings object.
+ *
+ * Object-valued keys (the two exclude maps) are treated as SETS of entries in
+ * both directions: applying merges (the user's entries win), and reverting
+ * subtracts only the entries this profile contributes. Deleting the whole key on
+ * revert would take the user's hand-maintained exclusions with it — an undo that
+ * destroys data the tool never added is worse than no undo at all.
+ *
+ * Scalar keys are removed outright on revert, which restores VS Code's own
+ * default. An explicit pre-existing scalar (`maxTsServerMemory: 3072`, say) is
+ * not restored — recovering that is what the `.bak` is for.
+ */
+function diffProfile(current, remove = false) {
+    return Object.entries(exports.MEMORY_PROFILE).map(([key, entry]) => {
+        const before = current[key];
+        const after = remove ? buildRevertedValue(before, entry.value) : buildMergedValue(before, entry.value);
+        let action;
+        if (remove) {
+            action = before === undefined || sameJson(before, after) ? 'unchanged' : 'removed';
+        }
+        else if (before === undefined) {
+            action = 'added';
+        }
+        else {
+            action = sameJson(before, after) ? 'unchanged' : 'changed';
+        }
+        return { action, after, before, key };
+    });
+}
+/**
+ * One `key: before → after` line, coloured by what happens to it.
+ *
+ * Lives here rather than in the command so it can be unit-tested; it takes the
+ * colour helpers as an argument and is otherwise pure.
+ */
+function formatChange(change, colors) {
+    const short = (v) => {
+        if (v === undefined) {
+            return '—';
+        }
+        const s = JSON.stringify(v);
+        return s.length > 52 ? `${s.slice(0, 49)}…` : s;
+    };
+    const tag = {
+        added: colors.green('+'),
+        changed: colors.yellow('~'),
+        removed: colors.red('-'),
+        unchanged: colors.dim('='),
+    }[change.action];
+    if (change.action === 'unchanged') {
+        return `${tag} ${colors.dim(change.key)} ${colors.dim(short(change.before))}`;
+    }
+    return `${tag} ${change.key}: ${colors.dim(short(change.before))} → ${short(change.after)}`;
+}
+/**
+ * Whether an ENABLING flag (`--revert`, `--explain`) is set.
+ *
+ * gluegun declares no booleans to yargs-parser, so `--revert=true` arrives as
+ * the STRING `'true'`. For a flag that turns something ON, a parse quirk that
+ * reads as "not set" fails CLOSED, which is the safe direction.
+ */
+function isEnablingFlagSet(value) {
+    return value === true || value === 'true';
+}
+/**
+ * Whether a PREVENTING flag (`--dry-run`) is set.
+ *
+ * Deliberately NOT `=== true || === 'true'`. That idiom is exactly backwards for
+ * a flag whose job is to STOP a write: `--dry-run=1` parses to the number `1`
+ * and `--dry-run=yes` to a string, both of which would read as "not set" and let
+ * the write proceed — the failure mode this repo already paid for once with
+ * `--keep-db` (see CLAUDE.md). Presence is intent; only an explicit negation
+ * proceeds.
+ */
+function isPreventingFlagSet(options, ...names) {
+    return names.some((name) => {
+        if (!(name in options)) {
+            return false;
+        }
+        const v = options[name];
+        return v !== false && v !== 'false' && v !== 0 && v !== '0';
+    });
+}
+/**
+ * Split the detected variants into what to act on, given an optional `--variant`.
+ *
+ * `unknownFilter` is reported separately from "nothing installed": a bare
+ * `--variant` parses to boolean `true` and matches no id, and conflating that
+ * with "no editor found" told users VS Code was missing while it was installed.
+ */
+function selectVariants(all, filter) {
+    const installed = all.filter((v) => v.installed);
+    if (filter === undefined || filter === null) {
+        return { targets: installed };
+    }
+    const wanted = String(filter);
+    if (!all.some((v) => v.id === wanted)) {
+        return { targets: [], unknownFilter: wanted };
+    }
+    return { targets: installed.filter((v) => v.id === wanted) };
+}
+/**
+ * Absolute path to a variant's user-settings file, per platform.
+ *
+ * All VS Code forks reuse the upstream layout, only the application support
+ * directory name differs. The joiner is selected per platform rather than taken
+ * from the ambient `path`, so the Windows branch produces real Windows paths
+ * (and stays assertable) when called from a test on macOS or Linux.
+ */
+function settingsPathFor(dirName, platform = process.platform, home = (0, os_1.homedir)()) {
+    if (platform === 'win32') {
+        const appData = process.env.APPDATA || path_1.win32.join(home, 'AppData', 'Roaming');
+        return path_1.win32.join(appData, dirName, 'User', 'settings.json');
+    }
+    if (platform === 'darwin') {
+        return path_1.posix.join(home, 'Library', 'Application Support', dirName, 'User', 'settings.json');
+    }
+    return path_1.posix.join(home, '.config', dirName, 'User', 'settings.json');
+}
+/**
+ * Apply (or revert) the profile on one settings file.
+ *
+ * JSONC-safe: the file is edited through `jsonc-parser`, which preserves
+ * comments, key order and the user's formatting. A naive
+ * `JSON.parse` → `JSON.stringify` round-trip would silently delete every
+ * comment in a file people hand-maintain.
+ *
+ * `jsonc-parser` is required lazily: gluegun eagerly loads every command module
+ * on every `lt` invocation, and this is its only consumer, so a top-level import
+ * would put the load cost on `lt --version` too. Matches how the repo already
+ * treats `open`, `js-yaml`, `playwright-core` and `ts-morph`.
+ *
+ * Never writes when nothing would change, so re-running is a true no-op. Every
+ * failure is returned as `error` rather than thrown — the caller renders it per
+ * installation and carries on with the others.
+ */
+function tuneSettingsFile(settingsPath, options = {}) {
+    var _a;
+    const { dryRun = false, remove = false } = options;
+    if (!(0, fs_1.existsSync)(settingsPath)) {
+        return { changes: [], error: `settings file not found: ${settingsPath}`, settingsPath, written: false };
+    }
+    // Never write THROUGH a symlink — the target may be any file the user's
+    // account can reach, and we were asked to tune settings, not to overwrite it.
+    if (isSymbolicLink(settingsPath)) {
+        return { changes: [], error: `refusing to write through a symlink: ${settingsPath}`, settingsPath, written: false };
+    }
+    const { applyEdits, modify, parse, printParseErrorCode } = require('jsonc-parser');
+    let raw;
+    try {
+        raw = (0, fs_1.readFileSync)(settingsPath, 'utf8');
+    }
+    catch (e) {
+        return { changes: [], error: `cannot read ${settingsPath}: ${errText(e)}`, settingsPath, written: false };
+    }
+    const errors = [];
+    const current = ((_a = parse(raw, errors, { allowTrailingComma: true })) !== null && _a !== void 0 ? _a : {});
+    // Refuse to touch a file we cannot read reliably — writing into a
+    // malformed settings.json risks destroying the user's configuration.
+    if (errors.length > 0) {
+        const first = errors[0];
+        return {
+            changes: [],
+            error: `cannot parse ${settingsPath}: ${printParseErrorCode(first.error)} at offset ${first.offset}`,
+            settingsPath,
+            written: false,
+        };
+    }
+    const changes = diffProfile(current, remove);
+    const effective = changes.filter((c) => c.action !== 'unchanged');
+    if (effective.length === 0 || dryRun) {
+        return { changes, settingsPath, written: false };
+    }
+    let content = raw;
+    for (const change of effective) {
+        // `after === undefined` deletes the key; an exclude map emptied by the
+        // revert subtraction lands here too.
+        const edits = modify(content, [change.key], change.after, {
+            formattingOptions: { insertSpaces: true, tabSize: 4 },
+        });
+        content = applyEdits(content, edits);
+    }
+    // Keep the FIRST backup. It is the only record of what the file looked like
+    // before this tool ever touched it — overwriting it on a later run (notably on
+    // `--revert`, which would then back up the *tuned* file) destroys exactly the
+    // state a user reaching for the backup wants to get back to.
+    const backupPath = `${settingsPath}.bak`;
+    try {
+        if (!(0, fs_1.existsSync)(backupPath)) {
+            (0, fs_1.copyFileSync)(settingsPath, backupPath);
+        }
+        (0, fs_1.writeFileSync)(settingsPath, content, 'utf8');
+    }
+    catch (e) {
+        return { changes, error: `cannot write ${settingsPath}: ${errText(e)}`, settingsPath, written: false };
+    }
+    return { backupPath, changes, settingsPath, written: true };
+}
+/**
+ * The value a key should hold after `--revert`.
+ *
+ * For an object-valued profile entry: the user's map minus our own entries, or
+ * `undefined` when nothing of theirs remains. For anything else: `undefined`
+ * (delete the key).
+ */
+function buildRevertedValue(before, desired) {
+    if (!isPlainObject(desired) || !isPlainObject(before)) {
+        return undefined;
+    }
+    const kept = Object.fromEntries(Object.entries(before).filter(([k]) => !(k in desired)));
+    return Object.keys(kept).length > 0 ? kept : undefined;
+}
+/** Message text of an unknown thrown value. */
+function errText(e) {
+    return e instanceof Error ? e.message : String(e);
+}
+/** Narrow to a non-null, non-array object. */
+function isPlainObject(value) {
+    return typeof value === 'object' && value !== null && !Array.isArray(value);
+}
+/** True when `path` is a symlink (never follows it). */
+function isSymbolicLink(path) {
+    try {
+        return (0, fs_1.lstatSync)(path).isSymbolicLink();
+    }
+    catch (_a) {
+        return false;
+    }
+}
+/** Structural equality via JSON, sufficient for the plain values in the profile. */
+function sameJson(a, b) {
+    return JSON.stringify(a) === JSON.stringify(b);
+}

package/docs/LT-ECOSYSTEM-GUIDE.md

@@ -153,7 +153,7 @@ All code generators are **mode-aware**: In vendor mode they use relative paths t
 | Command | Purpose |
 |---------|---------|
 | `lt fullstack init` | Create fullstack monorepo (see above) |
-| `lt fullstack update` | Show mode-specific update instructions for backend AND frontend |
+| `lt fullstack update` | Show mode-specific update instructions — **and self-heal generated project scaffolding** (see `docs/commands.md`) |
 | **`lt fullstack convert-mode`** | **Convert backend AND frontend between npm and vendor mode in a single command** |
 
 **Fullstack mode conversion in one command:**

package/docs/commands.md

@@ -606,6 +606,46 @@ lt dev doctor
 
 ---
 
+### `lt dev vscode`
+
+Apply a verified low-memory profile to VS Code's **user** settings. Targets the per-workspace TypeScript servers, which dominate memory once several monorepos are open at once: every workspace root spawns its own semantic TS server, so eight monorepos with an `api` and an `app` root each add up to 16 of them.
+
+**Usage:**
+```bash
+lt dev vscode              # preview, then apply after confirmation
+lt dev vscode --dry-run    # show the diff, write nothing
+lt dev vscode --explain    # print the profile with reasons + the keys left out on purpose
+lt dev vscode --revert     # remove the profile keys again
+lt dev vscode --variant cursor   # limit to one: code | insiders | cursor | vscodium
+lt dev vscode --noConfirm  # skip the confirmation prompt
+```
+
+**Alias:** `lt d vsc`
+
+**Profile:**
+
+| Key | Value | Why |
+|---|---|---|
+| `typescript.tsserver.maxTsServerMemory` | 2048 | Per-server heap ceiling; the default is 3072 and multiplies across every open root |
+| `typescript.preferences.includePackageJsonAutoImports` | `off` | Auto-import stops scanning every package.json — the largest monorepo win |
+| `typescript.disableAutomaticTypeAcquisition` | `true` | Skips the `@types` download/scan pass |
+| `files.watcherExclude` | node_modules, dist, `.nuxt*`, `.output*`, .git internals | Keeps the file watcher off generated trees |
+| `search.exclude` | node_modules, dist, `.nuxt*`, `.output*` | Keeps full-text search from indexing them |
+
+The globs are `.nuxt*` / `.output*`, not the bare names: a glob segment matches whole path segments, so `**/.nuxt/**` would leave the sibling build dirs (`.nuxt-check` from the check chain, `.nuxt-test` / `.output-test` from `lt dev test`) watched and indexed — and a `.output-test` tree is 37-294 MB.
+
+**Safety:** JSONC-aware via `jsonc-parser`, so comments and formatting in a hand-maintained `settings.json` survive. Refuses to write into a file it cannot parse or a symlink, backs up to `settings.json.bak` (the **first** backup is kept, so a later run — including `--revert` — cannot overwrite the record of the pre-tuning state), and merges the object-valued exclude maps so hand-added entries are kept. Re-running is a true no-op.
+
+**`--revert`** subtracts only the entries this profile contributed, so a hand-maintained exclusion is never removed along with them. For the scalar keys it deletes the key, restoring VS Code's own default — an explicit value that preceded the tuning is not restored; that is what the `.bak` is for.
+
+**Detects:** VS Code, VS Code Insiders, Cursor, VSCodium — every variant whose user settings file exists.
+
+**After applying**, restart VS Code (or run *Developer: Reload Window*) — the TypeScript servers read these settings at startup, so nothing changes until they do.
+
+Run `--explain` to see three commonly recommended keys the profile deliberately omits, each with the manifest check or measurement that ruled it out.
+
+---
+
 ### `lt dev test`
 
 One-shot E2E wrapper: ensure `up`, wait for the App URL, run `pnpm run test:e2e` with the `.lt-dev/.env` bridge loaded. Optional teardown after.
@@ -649,7 +689,37 @@ lt dev test -- --ui spec.ts      # everything after `--` is forwarded to playwri
 | `LT_DEV_ACTIVE`, `LT_DEV_DB_NAME` | Marker keys for consumers |
 | `NODE_EXTRA_CA_CERTS` | Path to Caddy's root CA cert (auto-detected) |
 
-`lt dev init` injects a tiny `// >>> lt-dev:bridge >>>` block at the top of `playwright.config.ts` that loads this file at config-load time — making Playwright (CLI, IDE, VS Code extension) automatically use the `lt dev` URLs and trust the local CA, without inheriting the parent shell.
+Additionally, `lt dev test` exports two build-directory keys into the app process it
+spawns. They are **not** written to the bridge file — they scope one run, not the
+project:
+
+| Key | Value | Why |
+|-----|-------|-----|
+| `NUXT_BUILD_DIR` | `.nuxt-test` | Nuxt holds its lock on the build dir (`acquireLock(nuxt.options.buildDir)`). Sharing `.nuxt` with a parked `nuxt dev` did not interleave writes — it made the test build **abort** with "Another Nuxt dev is already running", so the app never came up and every spec failed on a missing selector. That reads like broken specs while being pure infrastructure. |
+| `NITRO_OUTPUT_DIR` | `.output-test` | A separate axis: `buildDir` and Nitro's `output.dir` are unrelated knobs. `lt dev test` serves the production bundle, so it rebuilds on every run and used to overwrite the `.output` a local `pnpm run build` was using. |
+
+**The project must forward both**, or the isolation silently degrades to the shared
+directories. `nuxt-base-starter` ≥ 2.16.0 does this out of the box:
+
+```ts
+// nuxt.config.ts
+buildDir: process.env.NUXT_BUILD_DIR || '.nuxt',
+nitro: { output: { dir: process.env.NITRO_OUTPUT_DIR || '.output' } },
+```
+
+**Neither key is framework-native**, despite the prefixes — verified against
+`@nuxt/schema`, `nitropack` and `c12`: none of them reads `NUXT_BUILD_DIR` or
+`NITRO_OUTPUT_DIR`. Both levers are opened by the project's own `nuxt.config.ts`,
+which is why the two-line snippet above is required rather than optional. (Singling
+one of them out as "not a framework feature" reads as if the other one were, and a
+reader acting on that forwards only half — leaving exactly the collision this
+section exists to prevent.) For projects that have not adopted it, the CLI keeps a
+`.output/server/index.mjs` fallback when locating the built server.
+
+A project that ignores both keys still works; it just loses the isolation, so a
+`lt dev test` run and a parked `nuxt dev` collide again.
+
+`lt dev init` injects a tiny `// >>> lt-dev:bridge v2 >>>` block at the top of `playwright.config.ts` that loads this file at config-load time — making Playwright (CLI, IDE, VS Code extension) automatically use the `lt dev` URLs and trust the local CA, without inheriting the parent shell.
 
 `lt dev down` removes the bridge file so subsequent runs without `lt dev up` fall back cleanly to the classic `localhost:3000`/`localhost:3001` defaults.
 
@@ -1127,6 +1197,36 @@ lt fullstack add-app [options]
 
 ---
 
+### `lt fullstack update`
+
+Prints the mode-specific update entry points for backend and frontend — **and repairs generated project scaffolding on the way**. The name undersells it: this command writes files.
+
+**Usage:**
+```bash
+lt fullstack update
+```
+
+**Self-heals** (each is idempotent and a no-op when nothing is wrong):
+
+| What | Why it needs healing |
+|---|---|
+| `.gitignore` — adds `.lt-dev/` | Added after many projects were scaffolded |
+| `check` wrapper script | Same |
+| Vendor `CLAUDE.md` | Same |
+| `migrations-utils/migrate.js` | Written **once**, at vendor-conversion time. It is project scaffolding, not `src/core/`, so no update path ever revisits it — a project converted before the template stopped requiring `ts-node` unconditionally keeps the broken file forever, and every deployed container then dies with `Cannot find module 'ts-node'` before applying a single migration (silently, because the entrypoint degrades a migration failure to a warning on purpose). |
+
+The migration-store repair is deliberately narrow. It acts **only** when the `require('./ts-compiler')` is a top-level, unconditional statement — the one shape that provably cannot survive a production image where `ts-node` was pruned. Any conditional form (inside `try`, `if`, a function, a ternary) is the project's own working solution and is left untouched, because the replacement is not behaviour-neutral: the bundled template hardcodes the collection name and takes its URI from `./mongo-uri`, so overwriting a customized store would empty the migration ledger and re-run every historical migration.
+
+Before overwriting, the command establishes that the change is undoable. A file that git tracks and that is unmodified is simply replaced (git has the copy). A file git cannot recover — untracked, `.gitignore`d, or outside a repo — gets a `.bak` first. A tracked file with **uncommitted** changes is never touched and is reported as skipped:
+
+```
+migrations-utils/migrate.js (skipped: uncommitted changes — commit or discard them, then re-run)
+```
+
+That skip line is the only signal that a repair was needed but not applied — commit or discard, then re-run.
+
+---
+
 ### `lt fullstack convert-mode`
 
 Convert **both** backend (`projects/api/`) and frontend (`projects/app/`) of a fullstack monorepo between npm mode and vendor mode in a single command. Auto-detects the subprojects, shows the plan for each side, and orchestrates the backend + frontend conversions sequentially.
@@ -1220,6 +1320,36 @@ them from the TurboOps stage env at runtime, so nothing is patched there):
 `environment.ts` (local dev) is never touched. Only the URL origin is replaced, so
 custom paths (`/v2/graphql`) survive and a re-run with a new domain updates them.
 
+#### Database host: always stack-prefixed, never bare `mongo`
+
+The printed checklist spells the DB URI out per stage, and the exact host matters:
+
+```
+NSC__MONGOOSE__URI=mongodb://<user>:<pass>@<project>-production_mongo:27017/<db>?authSource=admin
+NSC__MONGOOSE__URI=mongodb://<user>:<pass>@<project>-dev_mongo:27017/<db>?authSource=admin
+```
+
+**Never `mongodb://mongo:27017/<db>`.** The project's own `docker-compose.yml` names
+the service `mongo`, which makes the short name the obvious guess — and the wrong
+one. TurboOps deploys every stack onto a shared overlay network, where the bare
+service name is an alias that *every* stack's `mongo` answers to. The connection
+then lands on a foreign project's database, and on a different one per connection.
+
+The symptoms do not look like a configuration problem: writes split across two
+databases, sessions that vanish after a reconnect, files whose bytes are "sometimes"
+missing. Meanwhile the application's own database sits empty. A project lost a day of
+debugging to this (DEV-2140) with the application code fully correct.
+
+TurboOps rejects bare DB hosts and isolates bare-named DB services from the shared
+overlay since v1.72.0 — but only from that version, and only for stacks deployed
+after it. The stack-prefixed host is correct either way, so use it unconditionally.
+
+The prefix fixes **which** database you reach, not **who** may reach it: the overlay
+network stays shared, so the database credentials are the actual boundary. Give the
+mongo service a user and password and connect with
+`mongodb://<user>:<pass>@<project>-<stage>_mongo:27017/<db>?authSource=admin` — an
+unauthenticated instance is readable and writable by every co-tenant stack.
+
 **Usage:**
 ```bash
 lt deployment create [name] [domain] [options]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/cli",
-  "version": "1.41.2",
+  "version": "1.42.0",
   "description": "lenne.Tech CLI: lt",
   "keywords": [
     "lenne.Tech",
@@ -57,19 +57,20 @@
     "bin"
   ],
   "dependencies": {
-    "@aws-sdk/client-s3": "3.1090.0",
+    "@aws-sdk/client-s3": "3.1100.0",
     "@lenne.tech/cli-plugin-helper": "0.0.14",
-    "axios": "1.18.1",
+    "axios": "1.19.0",
     "bcrypt": "6.0.0",
-    "defuddle": "0.19.1",
+    "defuddle": "0.19.2",
     "glob": "13.0.6",
     "gluegun": "5.2.2",
-    "js-sha256": "0.11.1",
+    "js-sha256": "1.0.0",
     "js-yaml": "4.3.0",
     "jsdom": "29.1.1",
+    "jsonc-parser": "3.3.1",
     "lodash": "4.18.1",
     "open": "11.0.0",
-    "playwright-core": "1.61.1",
+    "playwright-core": "1.62.1",
     "ts-morph": "28.0.0",
     "ts-node": "10.9.2",
     "turndown": "7.2.4",
@@ -77,39 +78,53 @@
     "typescript": "6.0.3"
   },
   "devDependencies": {
-    "@lenne.tech/eslint-config-ts": "2.1.4",
+    "@lenne.tech/eslint-config-ts": "2.3.0",
     "@lenne.tech/npm-package-helper": "0.0.12",
     "@types/ejs": "3.1.5",
     "@types/jest": "30.0.0",
     "@types/js-yaml": "4.0.9",
     "@types/jsdom": "28.0.1",
     "@types/lodash": "4.17.24",
-    "@types/node": "26.1.1",
+    "@types/node": "26.1.2",
     "@types/turndown": "5.0.6",
     "ejs": "6.0.1",
-    "eslint": "9.39.4",
+    "eslint": "10.8.0",
     "husky": "9.1.7",
     "jest": "30.4.2",
+    "minimatch": "10.2.6",
     "prettier": "3.8.3",
     "rimraf": "6.1.3",
-    "ts-jest": "29.4.11"
+    "ts-jest": "29.4.12"
   },
   "//overrides": {
     "semver@*": "Force latest semver 7.x across all sub-deps; gluegun@5.2.2 pins semver@7.7.0 which is stale - remove once gluegun updates its dep.",
-    "brace-expansion@<1.1.16": "DoS via exponential-time expansion of consecutive non-expanding {} groups (GHSA-3jxr-9vmj-r5cp, high). Transitive via dotgitignore/eslint/fs-jetpack/glob/test-exclude > minimatch. One bounded key per affected major so each can only raise a vulnerable version, never cap a patched one - remove once minimatch requests the patched ranges.",
-    "brace-expansion@>=2.0.0 <2.1.2": "Same advisory, 2.x line.",
-    "brace-expansion@>=5.0.0 <5.0.7": "Same advisory, 5.x line. Floored at >=5.0.0 so a future 3.x/4.x dependency is not silently forced across two majors."
+    "brace-expansion@<1.1.18": "Two DoS advisories: exponential-time expansion of consecutive non-expanding {} groups (GHSA-3jxr-9vmj-r5cp, high) and unbounded expansion length causing an OOM crash (GHSA-mh99-v99m-4gvg, high). Transitive via dotgitignore/eslint/fs-jetpack/glob/test-exclude/ts-morph > minimatch. One bounded key per affected major so each can only raise a vulnerable version, never cap a patched one - remove once minimatch requests the patched ranges.",
+    "brace-expansion@>=2.0.0 <2.1.4": "Same advisories, 2.x line.",
+    "brace-expansion@>=5.0.0 <5.0.9": "Same advisories, 5.x line. Floored at >=5.0.0 so a future 3.x/4.x dependency is not silently forced across two majors.",
+    "//minimatch-note": "brace-expansion 1.x and 2.x are END OF LINE for GHSA-mh99-v99m-4gvg: the advisory range is <=5.0.7 across ALL majors and upstream patched ONLY 5.0.8+. 1.1.18 and 2.1.4 are the newest releases of their majors and remain vulnerable. Forcing brace-expansion 5.x globally is NOT an option: 5.x is ESM/tshy and exports an object ({ expand, ... }) while 1.x/2.x export the function itself, so minimatch 3.x/5.x would die on `expand is not a function`. The only real fix is to raise each CONSUMER off minimatch 3.x/5.x, which is what the scoped entries below do. Each was verified against the consumer's actual call site before being added. The eslint / @eslint/eslintrc / @eslint/config-array entries were REMOVED in 1.42.0: eslint 10 requests minimatch ^10.2.5 itself, config-array ^10.2.4, and eslintrc is no longer in the tree at all.",
+    "minimatch@>=4 <10": "Bounded raise of every minimatch 4.x-9.x install to 10.2.6, whose brace-expansion ^5.0.8 is patched. Covers filelist (gluegun > ejs > jake > filelist, PRODUCTION-reachable, minimatch ^5.0.1), @typescript-eslint/typescript-estree (^9.0.4) and jest-config/jest-runtime/@jest/reporters (^9). Verified safe per consumer: filelist calls only the static helper `minimatch.match(files, pat, opts)`; typescript-estree calls the named `minimatch(filePath, pattern, { dot: true })`; the three jest packages declare minimatch but never require it. Floored at >=4 so the 3.x line is NOT swept in: minimatch 3.x is callable while 9.x/10.x export an object with __esModule but no `default` key, so sweeping it would break any consumer that calls the default export. Drop once these consumers request minimatch >=10 themselves.",
+    "babel-plugin-istanbul > test-exclude@<8": "test-exclude 6.0.0 pins minimatch ^3.0.4 and glob ^7. test-exclude 8.0.0 uses minimatch ^10.2.2 + glob ^13 (the glob major this project already ships) and is still CJS with the same `module.exports = TestExclude` class shape, so babel-plugin-istanbul's _interopRequireDefault + `new TestExclude(opts)` keeps working. Drop once babel-plugin-istanbul widens its ^6.0.0 range.",
+    "fs-jetpack > minimatch@<10": "Same chain, PRODUCTION-reachable (gluegun > fs-jetpack). Safe: lib/utils/matcher.js does `require('minimatch').Minimatch` and uses only `new Minimatch(pattern, { matchBase, nocomment, nocase, dot })`, `.negate` and `.match()` - all verified against 10.x. Not fixable by upgrading fs-jetpack: gluegun@5.2.2 is the latest release and fs-jetpack@5.1.0 still requests minimatch ^5.1.0 (brace-expansion ^2.0.1, also unpatched)."
   },
   "overrides": {
     "semver@*": "7.8.5",
-    "brace-expansion@<1.1.16": "1.1.16",
-    "brace-expansion@>=2.0.0 <2.1.2": "2.1.2",
-    "brace-expansion@>=5.0.0 <5.0.7": "5.0.7"
+    "brace-expansion@<1.1.18": "1.1.18",
+    "brace-expansion@>=2.0.0 <2.1.4": "2.1.4",
+    "brace-expansion@>=5.0.0 <5.0.9": "5.0.9",
+    "fs-jetpack": {
+      "minimatch@<10": "10.2.6"
+    },
+    "babel-plugin-istanbul": {
+      "test-exclude@<8": "8.0.0"
+    },
+    "minimatch@>=4 <10": "10.2.6"
   },
+  "//jest.workerIdleMemoryLimit": "Recycle a ts-jest worker once its heap passes this. Guards against an intermittent `A jest worker process was terminated by another process: signal=SIGSEGV` that kills ONE suite while every other test passes (seen twice in marketplace*, both under `npm run check`, never reproducible on demand - 0 in 9 targeted runs incl. --maxWorkers=16). It is a worker crash, NOT an assertion failure: the signature is `Test suite failed to run` with the remaining count still green. All versions are current and in-range (node 24 / jest 30 / ts-jest 29 / ts 6), so this is a resilience measure against unbounded worker heap growth, not a proven root-cause fix - if it recurs, capture the suite name and re-open.",
   "jest": {
     "testEnvironment": "node",
     "rootDir": "__tests__",
     "testTimeout": 60000,
+    "workerIdleMemoryLimit": "512MB",
     "testMatch": [
       "<rootDir>/*.test.ts"
     ],