@futdevpro/nts-dynamo 1.15.151 → 1.15.154

package/__documentations/2026-08-21-distributed-rate-limit-bfr-ctm-010.md

@@ -1,59 +1,59 @@
-# Dynamo NTS distributed rate-limit boundary
-
-**Contract:** `dynts-rate-limit/2`
-
-**Release candidate:** `@futdevpro/nts-dynamo@1.15.147`
-
-**Consumer trace:** `BFR-CTM-010`
-
-## Purpose
-
-This Bedrock boundary makes one rate-limit decision atomic across application processes while keeping persistence
-application-owned. It replaces the former process-local-only middleware behavior without adding a replaceable
-framework abstraction: consumers use the published `@futdevpro/nts-dynamo/rate-limit` types and middleware
-directly and provide the storage adapter required by their deployment.
-
-## Contract
-
-`DyNTS_RateLimit_Store_Interface.consume(...)` receives one opaque bucket key, the active limit and window, the
-positive request cost and a caller-supplied millisecond timestamp. It resolves one committed decision containing
-`allowed`, `remaining` and `resetAt`. A production host enables `requireSharedStore` and supplies:
-
-- a store advertising `storeKind: shared`;
-- an explicit opaque subject extractor;
-- an explicit stable endpoint-group extractor.
-
-Configuration fails closed when any of these requirements is absent. Runtime store exceptions and malformed
-store results become stable 503 errors without reflecting the bucket, the adapter exception or request content.
-Policy rejection remains a stable 429 and includes the committed reset interval in response headers.
-
-## Security and privacy properties
-
-- The middleware never reads `x-forwarded-for` directly. Its local default uses Express `req.ip`, whose proxy
-  trust policy belongs to the host; production still requires an explicit extractor.
-- Extractor exceptions, invalid callbacks, invalid clocks and malformed bucket components are converted to
-  content-free errors.
-- Limits, windows, costs, timestamps, bucket component lengths and store results have hard numeric/structural
-  bounds.
-- No raw storage key or adapter exception is placed in the generated error.
-- The shared-store interface carries opaque identifiers only. The consuming application is responsible for
-  purpose-scoped pseudonymization and retention.
-- The module starts no timer, cleanup loop, polling process or background task. Local cleanup is caller-triggered.
-
-## Semantics
-
-The provided in-memory implementation uses exact sliding-window timestamps. It exists for deterministic tests and
-explicitly single-instance development, not production. A shared implementation may use exact sliding-window
-semantics or a conservatively safe equivalent, but its read/prune/admit/write decision must be atomic. Concurrent
-requests for the final permit may produce exactly one successful decision.
-
-Weighted requests consume multiple permit units. An unsuccessful weighted request does not mutate the committed
-usage, so `remaining` can be positive but lower than the attempted cost.
-
-## Verification
-
-The focused Bedrock suite covers singleton behavior, forwarding-header spoof resistance, deterministic window
-reset, weighted cost, subject/endpoint isolation, headers, policy precedence, invalid configuration atomicity,
-the production shared-store gate, cross-instance state, concurrent final-permit behavior, non-reflective store
-failure, malformed store results and explicit timer-free cleanup. Full-package compilation, tests, lint, import and
-naming validation are release gates for the candidate.
+# Dynamo NTS distributed rate-limit boundary
+
+**Contract:** `dynts-rate-limit/2`
+
+**Release candidate:** `@futdevpro/nts-dynamo@1.15.147`
+
+**Consumer trace:** `BFR-CTM-010`
+
+## Purpose
+
+This Bedrock boundary makes one rate-limit decision atomic across application processes while keeping persistence
+application-owned. It replaces the former process-local-only middleware behavior without adding a replaceable
+framework abstraction: consumers use the published `@futdevpro/nts-dynamo/rate-limit` types and middleware
+directly and provide the storage adapter required by their deployment.
+
+## Contract
+
+`DyNTS_RateLimit_Store_Interface.consume(...)` receives one opaque bucket key, the active limit and window, the
+positive request cost and a caller-supplied millisecond timestamp. It resolves one committed decision containing
+`allowed`, `remaining` and `resetAt`. A production host enables `requireSharedStore` and supplies:
+
+- a store advertising `storeKind: shared`;
+- an explicit opaque subject extractor;
+- an explicit stable endpoint-group extractor.
+
+Configuration fails closed when any of these requirements is absent. Runtime store exceptions and malformed
+store results become stable 503 errors without reflecting the bucket, the adapter exception or request content.
+Policy rejection remains a stable 429 and includes the committed reset interval in response headers.
+
+## Security and privacy properties
+
+- The middleware never reads `x-forwarded-for` directly. Its local default uses Express `req.ip`, whose proxy
+  trust policy belongs to the host; production still requires an explicit extractor.
+- Extractor exceptions, invalid callbacks, invalid clocks and malformed bucket components are converted to
+  content-free errors.
+- Limits, windows, costs, timestamps, bucket component lengths and store results have hard numeric/structural
+  bounds.
+- No raw storage key or adapter exception is placed in the generated error.
+- The shared-store interface carries opaque identifiers only. The consuming application is responsible for
+  purpose-scoped pseudonymization and retention.
+- The module starts no timer, cleanup loop, polling process or background task. Local cleanup is caller-triggered.
+
+## Semantics
+
+The provided in-memory implementation uses exact sliding-window timestamps. It exists for deterministic tests and
+explicitly single-instance development, not production. A shared implementation may use exact sliding-window
+semantics or a conservatively safe equivalent, but its read/prune/admit/write decision must be atomic. Concurrent
+requests for the final permit may produce exactly one successful decision.
+
+Weighted requests consume multiple permit units. An unsuccessful weighted request does not mutate the committed
+usage, so `remaining` can be positive but lower than the attempted cost.
+
+## Verification
+
+The focused Bedrock suite covers singleton behavior, forwarding-header spoof resistance, deterministic window
+reset, weighted cost, subject/endpoint isolation, headers, policy precedence, invalid configuration atomicity,
+the production shared-store gate, cross-instance state, concurrent final-permit behavior, non-reflective store
+failure, malformed store results and explicit timer-free cleanup. Full-package compilation, tests, lint, import and
+naming validation are release gates for the candidate.

package/__documentations/2026-08-22-content-free-process-error-boundary.md

@@ -0,0 +1,91 @@
+# Content-free process error boundary
+
+**Date:** 2026-08-22
+**Status:** implemented; verification evidence is recorded below
+**Contract:** `dynts-safe-diagnostic/1`
+**Package surface:** `@futdevpro/nts-dynamo`, server module exports
+
+## Purpose
+
+Dynamo-NTS must remain debuggable without copying arbitrary application content into framework-owned logs or
+error forwarding. Process failures can contain credentials, personal data, workbook values, HTTP request data,
+provider responses or attacker-controlled strings in `message`, `stack`, rejected promises and nested error
+objects. This boundary converts such failures to a fixed allowlist before they reach a Dynamo-NTS logger or the
+global handler from `DyNTS_App`.
+
+The capability is direct Dynamo Bedrock. Consuming applications must use it as supplied and may add their own
+product metadata only through a separately reviewed, content-free contract.
+
+## Normative public contract
+
+`DyNTS_SafeDiagnostic_Interface` contains exactly these fields:
+
+| Field | Meaning |
+|---|---|
+| `contractVersion` | Literal `dynts-safe-diagnostic/1`. |
+| `code` | Stable uppercase error code; invalid caller input fails closed to a fixed fallback. |
+| `stage` | Closed lifecycle-stage enum. |
+| `causeType` | Coarse classification only: Dynamo error, native error, object, primitive or unknown. |
+| `fingerprint` | SHA-256 correlation of contract version, code, stage, cause type and status only. |
+| `status` | Valid HTTP-style integer from 100 through 599; otherwise 500. |
+
+No raw failure content participates in the returned object or the fingerprint. In particular, `message`,
+`stack`, request/response objects, rejected promises, MongoDB URIs, usernames, passwords, tokens, workbook data
+and arbitrary nested properties are not public fields and are never read for fingerprint construction.
+
+The projection is immutable. `project()` returns it without side effects, `report()` logs only that projection,
+and `toError()` creates a `DyFM_Error` whose message and additional content are derived solely from the safe
+projection.
+
+## Framework integration
+
+`DyNTS_App` applies the projection before framework-owned logging and forwarding at these boundaries:
+
+- bootstrap rejection and `unhandledRejection`;
+- post-process, memory guard, event-loop diagnostics and collection-growth monitor failures;
+- readiness reporting;
+- initial MongoDB connect failure, runtime connection error and reconnect-guard diagnostics;
+- HTTP and HTTPS server error/uncaught-exception events;
+- open/secure route configuration and duplicate-route failures;
+- Express error fallback and secondary global-handler failures;
+- retention installation diagnostics.
+
+MongoDB connection success logs only the stable fact that MongoDB is connected. Malformed URI warnings,
+initial connection failure and runtime connection failure do not interpolate the URI. The URI remains an input
+to Mongoose because it is operationally required, but it is not a diagnostic value.
+
+The default `DyNTS_GlobalService` handler also projects a raw failure before logging. A consumer-supplied global
+handler remains a consumer boundary; failures forwarded by `DyNTS_App` reach it as a content-free `DyFM_Error`.
+If that handler throws or rejects, Dynamo-NTS projects the secondary failure rather than recursively logging it.
+
+## Security and privacy properties
+
+- The output is an exact allowlist rather than a denylist-based redaction attempt.
+- Hostile getters on error objects cannot make raw content appear in the projection.
+- Correlation is deterministic for the same safe classification but cannot be used to dictionary-test an error
+  message, password or token because raw values are excluded from the hash input.
+- Invalid codes and statuses fail closed to stable defaults.
+- Client responses continue to use the existing client-safe error utility; this capability governs
+  framework-owned process diagnostics and forwarding.
+- This boundary reduces disclosure risk but does not authorize logging sensitive values elsewhere in a
+  consuming application.
+
+## Verification matrix
+
+| Evidence | Required assertion |
+|---|---|
+| Safe-diagnostic unit tests | Exact frozen allowlist, stable fingerprint, cause classification and fail-closed hostile input. |
+| Report/toError unit test | Logger and serialized `DyFM_Error` contain the safe contract and exclude a credential-bearing canary. |
+| Process-boundary runtime test | Unhandled rejection is projected before both logging and global-handler forwarding. |
+| Bootstrap runtime test | Rejected construction is projected before logging/forwarding and terminates with exit code 1. |
+| Default-handler runtime test | Raw input is projected before default global logging. |
+| App-params test | A malformed credential-bearing MongoDB URI triggers a warning without exposing the URI. |
+| Static source scan | No Dynamo-NTS App log call receives raw error, stack, promise, construct-error collection or DB URI. |
+| Full package regression | Build, complete Jasmine suite and project validators remain green. |
+
+## Consumer adoption requirement
+
+A consumer adopts the capability by pinning the first exact `@futdevpro/nts-dynamo` version that contains this
+document and by proving the package-level runtime tests in its dependency tree. Reimplementing the boundary in
+the product does not count as Bedrock adoption. Product-specific diagnostics may compose the safe fields, but
+must not copy or reinterpret raw failure content.

package/__documentations/2026-08-22-npm-token-state-classifier.md

@@ -1,92 +1,92 @@
-# NPM-token állapot-osztályozó (FR-320)
-
-**Dátum:** 2026-08-22 · **Csomag:** `@futdevpro/nts-dynamo` ≥ `01.15.150` ·
-**Belépési pont:** `checkNpmToken()` + `classifyNpmTokenShape()` / `classifyNpmTokenProbe()`
-
-## 1. Miért kellett — a hibaosztály
-
-2026-08-20-án a flotta npm-tokenje **lejárt**, majd a pótlására beállított token **nem kapott
-írási / 2FA-bypass jogot**. A diagnózis **több napot és több kört** vitt el, mert az npm
-**létezés-elrejtést** alkalmaz privát csomagnál: a jogosulatlan kérésre **404**-et ad, nem 401-et.
-
-**Három külön képesség — mind ugyanazzal a hibakóddal bukik:**
-
-| képesség | hibás tokennel | amit az operator lát |
-|---|---|---|
-| olvasás (`GET /@scope%2fpkg`) | **404** | „nincs ilyen csomag" |
-| publikálás (`PUT /@scope%2fpkg`) | **404** | „nincs ilyen csomag" |
-| hitelesítés (`GET /-/whoami`) | **401** | ← az **egyetlen** egyértelmű jel |
-
-Emiatt a *„nincs ilyen csomag"*, a *„lejárt kulcs"* és a *„rossz jogú kulcs"* megkülönböztethetetlen
-volt. Élesben ez így nézett ki: `ERR_PNPM_FETCH_404` négy projektben, `npm-publish` némán bukva, és
-egy `PUT … 404`, **miközben ugyanaz a token olvasni tudta a csomagot**.
-
-## 2. A kulcs-diszkriminátor
-
-**Mindig a `/-/whoami`-val kell kezdeni.** Az **csomag-független**, ezért nem esik a 404-csapdába:
-
-- rossz / hiányzó token → **401**
-- érvényes token → **200** + `username`
-
-Csak ha ez 200, akkor értelmezhető bármilyen csomag-szintű 404 — és élő token mellett az **mindig
-jogosultság**, sosem hiányzó csomag.
-
-## 3. Megkülönböztetett állapotok
-
-| állapot | mit jelent | mérés |
-|---|---|---|
-| `missing` | nincs beállítva (env **és** `~/.npmrc`) | helyi, hálózat nélkül |
-| `malformed` | van érték, de nem token-alakú (idézőjel, whitespace, bemásolt `.npmrc`-sor) | helyi |
-| `invalid` | a registry elutasítja | whoami **401** |
-| `no-scope-access` | a token él, de a csomagra nincs joga | whoami 200 + csomag 404/403 |
-| `missing-publish-right` | olvas, de **publikálni nem tud** | whoami 200 + `EOTP`/`E403`/**`E404`** publish-hiba |
-| `ok` | érvényes és a vizsgált csomagot is eléri | whoami 200 + csomag 200 |
-| `unknown` | a próba el sem jutott a registryig | **nem** bizonyíték a token ellen |
-
-## 4. Amit szándékosan NEM ígér
-
-- A **2FA-bypass hiánya read-only próbával nem állapítható meg** — csak egy már elbukott publish
-  hibakódjából (`EOTP`). Ezért van opcionális `publishErrorCode` bemenet.
-- A **lejárt** és a **visszavont** token kívülről egyforma 401.
-- A token **élettartama** nem kérdezhető le.
-- **Granular** tokennél az npm a `readonly`/`automation` mezőket sem teszi közzé
-  (`GET /-/npm/v1/tokens` → 200, de a jogok nélkül) — mérve.
-
-## 5. Biztonság
-
-A **token értéke sosem kerül a kimenetbe** — sem logba, sem eredménybe. A helyi alak-ellenőrzés
-kizárólag minta-illesztés; külön teszt állítja, hogy nincs `cat /root/.npmrc` és nincs
-`echo $NPM_TOKEN`. A `.npmrc`-t **csak olvassuk** — létrehozni flotta-szintű hard rule tiltja.
-
-## 6. Használat
-
-```ts
-import { checkNpmToken, DyNTS_NpmTokenState } from '@futdevpro/nts-dynamo';
-
-const result = await checkNpmToken({ scopedPackage: '@futdevpro/cli-dynamo' });
-if (result.state !== DyNTS_NpmTokenState.ok) {
-  // result.detail = ember-olvasható magyarázat + a KÖVETKEZŐ LÉPÉS
-}
-```
-
-Token-feloldás prioritása: explicit paraméter → `NPM_TOKEN` env → `~/.npmrc`.
-
-## 7. Teszt
-
-27 spec. Élesben igazolva mindhárom ág: jó token → `ok` (whoami 200 + csomag 200), érvénytelen →
-`invalid` (401), rossz alak → `malformed`.
-
-**Két saját hibát a tesztek/mérés fogtak meg — mindkettő hamis negatív lett volna:**
-
-1. Az első változat **csak a `process.env.NPM_TOKEN`-t** nézte → a workstationon `missing`-et adott,
-   holott az npm ott működött (a token a `~/.npmrc`-ben áll). Épp a legfontosabb helyeken
-   (runner-konténer, hosztok) sült volna el, ahol a token szintén fájlban van.
-2. A host-összehasonlításnál csak az **egyik oldalt** normalizáltam, a `.npmrc` viszont **záró
-   perjellel** írja a hostot (`//registry.npmjs.org/`) → sosem illeszkedett.
-
-## 8. Kapcsolódó
-
-A lánc, ami emiatt állt: `install` (404) → `npm-publish` (💤/❌) → `trigger-runner-cli-hot-update`
-(💤) → **a runnereken befagyott a CLI**. Az automatizmus nem volt hibás, csak **blokkolt** — egyetlen
-ponton. Runner-oldali próba: `fdp-devops` FR-318/FR-319 (`POST /diag/runner/registry-auth` +
-a `fdp diag-all` `2b. RUNNER REGISTRY-AUTH` szekciója).
+# NPM-token állapot-osztályozó (FR-320)
+
+**Dátum:** 2026-08-22 · **Csomag:** `@futdevpro/nts-dynamo` ≥ `01.15.150` ·
+**Belépési pont:** `checkNpmToken()` + `classifyNpmTokenShape()` / `classifyNpmTokenProbe()`
+
+## 1. Miért kellett — a hibaosztály
+
+2026-08-20-án a flotta npm-tokenje **lejárt**, majd a pótlására beállított token **nem kapott
+írási / 2FA-bypass jogot**. A diagnózis **több napot és több kört** vitt el, mert az npm
+**létezés-elrejtést** alkalmaz privát csomagnál: a jogosulatlan kérésre **404**-et ad, nem 401-et.
+
+**Három külön képesség — mind ugyanazzal a hibakóddal bukik:**
+
+| képesség | hibás tokennel | amit az operator lát |
+|---|---|---|
+| olvasás (`GET /@scope%2fpkg`) | **404** | „nincs ilyen csomag" |
+| publikálás (`PUT /@scope%2fpkg`) | **404** | „nincs ilyen csomag" |
+| hitelesítés (`GET /-/whoami`) | **401** | ← az **egyetlen** egyértelmű jel |
+
+Emiatt a *„nincs ilyen csomag"*, a *„lejárt kulcs"* és a *„rossz jogú kulcs"* megkülönböztethetetlen
+volt. Élesben ez így nézett ki: `ERR_PNPM_FETCH_404` négy projektben, `npm-publish` némán bukva, és
+egy `PUT … 404`, **miközben ugyanaz a token olvasni tudta a csomagot**.
+
+## 2. A kulcs-diszkriminátor
+
+**Mindig a `/-/whoami`-val kell kezdeni.** Az **csomag-független**, ezért nem esik a 404-csapdába:
+
+- rossz / hiányzó token → **401**
+- érvényes token → **200** + `username`
+
+Csak ha ez 200, akkor értelmezhető bármilyen csomag-szintű 404 — és élő token mellett az **mindig
+jogosultság**, sosem hiányzó csomag.
+
+## 3. Megkülönböztetett állapotok
+
+| állapot | mit jelent | mérés |
+|---|---|---|
+| `missing` | nincs beállítva (env **és** `~/.npmrc`) | helyi, hálózat nélkül |
+| `malformed` | van érték, de nem token-alakú (idézőjel, whitespace, bemásolt `.npmrc`-sor) | helyi |
+| `invalid` | a registry elutasítja | whoami **401** |
+| `no-scope-access` | a token él, de a csomagra nincs joga | whoami 200 + csomag 404/403 |
+| `missing-publish-right` | olvas, de **publikálni nem tud** | whoami 200 + `EOTP`/`E403`/**`E404`** publish-hiba |
+| `ok` | érvényes és a vizsgált csomagot is eléri | whoami 200 + csomag 200 |
+| `unknown` | a próba el sem jutott a registryig | **nem** bizonyíték a token ellen |
+
+## 4. Amit szándékosan NEM ígér
+
+- A **2FA-bypass hiánya read-only próbával nem állapítható meg** — csak egy már elbukott publish
+  hibakódjából (`EOTP`). Ezért van opcionális `publishErrorCode` bemenet.
+- A **lejárt** és a **visszavont** token kívülről egyforma 401.
+- A token **élettartama** nem kérdezhető le.
+- **Granular** tokennél az npm a `readonly`/`automation` mezőket sem teszi közzé
+  (`GET /-/npm/v1/tokens` → 200, de a jogok nélkül) — mérve.
+
+## 5. Biztonság
+
+A **token értéke sosem kerül a kimenetbe** — sem logba, sem eredménybe. A helyi alak-ellenőrzés
+kizárólag minta-illesztés; külön teszt állítja, hogy nincs `cat /root/.npmrc` és nincs
+`echo $NPM_TOKEN`. A `.npmrc`-t **csak olvassuk** — létrehozni flotta-szintű hard rule tiltja.
+
+## 6. Használat
+
+```ts
+import { checkNpmToken, DyNTS_NpmTokenState } from '@futdevpro/nts-dynamo';
+
+const result = await checkNpmToken({ scopedPackage: '@futdevpro/cli-dynamo' });
+if (result.state !== DyNTS_NpmTokenState.ok) {
+  // result.detail = ember-olvasható magyarázat + a KÖVETKEZŐ LÉPÉS
+}
+```
+
+Token-feloldás prioritása: explicit paraméter → `NPM_TOKEN` env → `~/.npmrc`.
+
+## 7. Teszt
+
+27 spec. Élesben igazolva mindhárom ág: jó token → `ok` (whoami 200 + csomag 200), érvénytelen →
+`invalid` (401), rossz alak → `malformed`.
+
+**Két saját hibát a tesztek/mérés fogtak meg — mindkettő hamis negatív lett volna:**
+
+1. Az első változat **csak a `process.env.NPM_TOKEN`-t** nézte → a workstationon `missing`-et adott,
+   holott az npm ott működött (a token a `~/.npmrc`-ben áll). Épp a legfontosabb helyeken
+   (runner-konténer, hosztok) sült volna el, ahol a token szintén fájlban van.
+2. A host-összehasonlításnál csak az **egyik oldalt** normalizáltam, a `.npmrc` viszont **záró
+   perjellel** írja a hostot (`//registry.npmjs.org/`) → sosem illeszkedett.
+
+## 8. Kapcsolódó
+
+A lánc, ami emiatt állt: `install` (404) → `npm-publish` (💤/❌) → `trigger-runner-cli-hot-update`
+(💤) → **a runnereken befagyott a CLI**. Az automatizmus nem volt hibás, csak **blokkolt** — egyetlen
+ponton. Runner-oldali próba: `fdp-devops` FR-318/FR-319 (`POST /diag/runner/registry-auth` +
+a `fdp diag-all` `2b. RUNNER REGISTRY-AUTH` szekciója).

package/__documentations/nts-integration-tests-2026-03-17.md

@@ -1,26 +1,26 @@
-# NTS integration tests (unified host)
-
-**Date:** 2026-03-17
-
-## Summary
-
-First integration tests for dynamo-nts were added to cover the unified host behaviour (static client, API base path, socket path, default 404 page).
-
-## Additions
-
-- **Integration mock:** [src/_modules/mock/app-integration-test.mock.ts](../src/_modules/mock/app-integration-test.mock.ts)  
-  `DyNTS_AppIntegrationTest_Mock` extends `DyNTS_AppWbMock_Mock`, runs without DB, and provides:
-  - `getAppParams()` with no `dbName`/`dbUri`
-  - `getPortSettings()` with `httpPort: 54536`, `socketPath: '/socket'`
-  - `getApiBasePath()` returning `'/api'`
-  - `getStaticClientSettings()` returning `root` from static property `integrationStaticRoot` (set by the spec), no `fallbackPath` (so 404 uses default HTML)
-
-- **Integration spec:** [src/_modules/socket/app-extended.integration.spec.ts](../src/_modules/socket/app-extended.integration.spec.ts)  
-  - Uses a temp dir for static files and starts the app in `beforeAll`; stops app and removes temp dir in `afterAll`.
-  - Timeout set to 15s for this suite.
-  - Tests: app starts (`started === true`), GET non-existent path → 404 + default “Page not found” HTML, GET `/index.html` → 200 + static content, GET `/api/test-0/test-base` and `/api/test-0/test-simple` → 200 with expected body.
-
-## Conventions
-
-- Same test style as existing NTS specs: Jasmine, `*.spec.ts`, run via `pnpm test` (build + jasmine).
-- Port **54536** must be free when the integration spec runs (used by the mock app).
+# NTS integration tests (unified host)
+
+**Date:** 2026-03-17
+
+## Summary
+
+First integration tests for dynamo-nts were added to cover the unified host behaviour (static client, API base path, socket path, default 404 page).
+
+## Additions
+
+- **Integration mock:** [src/_modules/mock/app-integration-test.mock.ts](../src/_modules/mock/app-integration-test.mock.ts)  
+  `DyNTS_AppIntegrationTest_Mock` extends `DyNTS_AppWbMock_Mock`, runs without DB, and provides:
+  - `getAppParams()` with no `dbName`/`dbUri`
+  - `getPortSettings()` with `httpPort: 54536`, `socketPath: '/socket'`
+  - `getApiBasePath()` returning `'/api'`
+  - `getStaticClientSettings()` returning `root` from static property `integrationStaticRoot` (set by the spec), no `fallbackPath` (so 404 uses default HTML)
+
+- **Integration spec:** [src/_modules/socket/app-extended.integration.spec.ts](../src/_modules/socket/app-extended.integration.spec.ts)  
+  - Uses a temp dir for static files and starts the app in `beforeAll`; stops app and removes temp dir in `afterAll`.
+  - Timeout set to 15s for this suite.
+  - Tests: app starts (`started === true`), GET non-existent path → 404 + default “Page not found” HTML, GET `/index.html` → 200 + static content, GET `/api/test-0/test-base` and `/api/test-0/test-simple` → 200 with expected body.
+
+## Conventions
+
+- Same test style as existing NTS specs: Jasmine, `*.spec.ts`, run via `pnpm test` (build + jasmine).
+- Port **54536** must be free when the integration spec runs (used by the mock app).