@futdevpro/nts-dynamo 1.15.154 → 1.15.156

package/README.md

@@ -28,26 +28,26 @@ Dynamo-NTS simplifies complex system definitions by abstracting common backend i
 - **Axios Usage**: HTTP client requests to external APIs are standardized through `DyNTS_ApiService` with `DyNTS_ApiCall_Params` configuration (simplifies Axios request setup, error handling, and response management)
 - **Discord.js / Slack / Teams Bot Development**: Platform-agnostic bot framework through `DyNTS_Bot_MessagingProvider_ServiceBase` and bot modules (simplifies Discord.js, Slack, and Teams bot development with unified interfaces)
 - **OpenAI / AI Provider Integration**: AI/LLM operations including chat, embeddings, and vector search are abstracted through `DyNTS_AI_Provider_ServiceBase` and provider implementations (simplifies OpenAI SDK usage and enables multi-provider architecture)
-- **Location Tracking**: IP-based geolocation through `geoip-lite` is integrated into the usage tracking module (simplifies location data collection from HTTP requests)
-
-This parameterization approach eliminates boilerplate code and provides a consistent, type-safe interface for all backend operations. Instead of learning multiple library APIs and their configuration patterns, developers work with unified Dynamo-NTS parameter objects that handle the underlying complexity.
-
-### Content-free process diagnostics
-
-`DyNTS_App` projects bootstrap failures, unhandled promise rejections, database connection/runtime failures,
-HTTP/HTTPS server errors, routing failures and Express fallbacks through the versioned
-`dynts-safe-diagnostic/1` contract before framework-owned logging or error forwarding. The public allowlist is
-limited to `contractVersion`, `code`, `stage`, `causeType`, `fingerprint` and `status`. Raw error messages,
-stacks, rejected promises, requests and database URIs are excluded. The fingerprint is derived only from the
-allowlisted classification, never from raw failure content.
-
-Consumers can use `DyNTS_SafeDiagnostic_ControlService.project()` when they need the same deterministic
-projection without logging, `report()` for safe framework logging, and `toError()` when a content-free
-`DyFM_Error` must cross an existing error-handler boundary. See
-[`__documentations/2026-08-22-content-free-process-error-boundary.md`](./__documentations/2026-08-22-content-free-process-error-boundary.md)
-for the normative boundary and verification matrix.
-
-## Table of Contents
+- **Location Tracking**: Optional, local-only IP geolocation through `geoip-lite`; addresses are not sent to an external service or written to logs by Dynamo-NTS
+
+This parameterization approach eliminates boilerplate code and provides a consistent, type-safe interface for all backend operations. Instead of learning multiple library APIs and their configuration patterns, developers work with unified Dynamo-NTS parameter objects that handle the underlying complexity.
+
+### Content-free process diagnostics
+
+`DyNTS_App` projects bootstrap failures, unhandled promise rejections, database connection/runtime failures,
+HTTP/HTTPS server errors, routing failures and Express fallbacks through the versioned
+`dynts-safe-diagnostic/1` contract before framework-owned logging or error forwarding. The public allowlist is
+limited to `contractVersion`, `code`, `stage`, `causeType`, `fingerprint` and `status`. Raw error messages,
+stacks, rejected promises, requests and database URIs are excluded. The fingerprint is derived only from the
+allowlisted classification, never from raw failure content.
+
+Consumers can use `DyNTS_SafeDiagnostic_ControlService.project()` when they need the same deterministic
+projection without logging, `report()` for safe framework logging, and `toError()` when a content-free
+`DyFM_Error` must cross an existing error-handler boundary. See
+[`__documentations/2026-08-22-content-free-process-error-boundary.md`](./__documentations/2026-08-22-content-free-process-error-boundary.md)
+for the normative boundary and verification matrix.
+
+## Table of Contents
 
 - [Installation](#installation)
 - [Quick Start](#quick-start)
@@ -98,10 +98,14 @@ These dependencies are only required when using specific modules:
 
 - **Socket Module**: `socket.io` - Real-time communication (simplified through Dynamo-NTS socket services)
 - **Email Service**: `nodemailer` - Email sending (simplified through Dynamo-NTS email services)
-- **Usage Module**: `geoip-lite` and `@types/geoip-lite` - IP geolocation (simplified through Dynamo-NTS usage module)
+- **Usage Module**: `geoip-lite` and `@types/geoip-lite` - optional, local-only IP geolocation. The provider is loaded only when a lookup is requested. Without it, lookup methods return `null` and the rest of Dynamo-NTS remains usable. The supported secure `geoip-lite` line requires Node.js 24 or newer.
 - **Bot Module (Discord)**: `discord.js` - Discord bot development (simplified through Dynamo-NTS bot module)
 - **AI Module (OpenAI)**: `openai` - OpenAI API integration (simplified through Dynamo-NTS AI module)
 
+The GeoIP lookup itself does not transmit or log an address. Calling the Usage module can persist the
+request address and derived location in the consumer's own data store. Consumers enabling that capability
+must define the applicable lawful basis, user-facing transparency, access controls, retention and deletion.
+
 Install module-specific dependencies as needed:
 
 ```bash
@@ -112,7 +116,7 @@ pnpm add socket.io
 pnpm add nodemailer
 
 # For Usage module
-pnpm add geoip-lite @types/geoip-lite
+pnpm add geoip-lite@^2.0.3 @types/geoip-lite@^1.4.4
 
 # For Bot module (Discord)
 pnpm add discord.js

package/__documentations/2026-08-22-bfr-ctm-018-content-free-endpoint-errors.md

@@ -0,0 +1,54 @@
+# BFR-CTM-018 — content-free endpoint error boundary
+
+**Date:** 2026-08-22
+**Status:** implemented and package-verified; consumer adoption is recorded by the requesting project
+**Target:** `@futdevpro/nts-dynamo`
+**Contract:** `dynts-safe-diagnostic/1`
+
+## Measured defect
+
+The shared `DyNTS_Endpoint_Params` error path constructed framework logs from route identity, path parameter
+values, raw `Error.message`, stack location and a request snapshot. The snapshot included URL, query, request
+metadata, header keys, IP address and an authorization-header shape. A plain error and a consumer global-handler
+rejection were also passed directly to Dynamo loggers. The primary raw log was unconditional, so disabling
+application API-error logging did not close the disclosure path.
+
+The same execution function declared a second local `issuer` variable inside the request callback. It shadowed
+the issuer captured by the error path, so a failing endpoint forwarded `undefined` rather than the resolved
+account identity to the consumer global handler.
+
+## Implemented Bedrock response
+
+- Added the closed `endpoint` safe-diagnostic stage.
+- Projected constructor, issuer-resolution, task/pre-process, consumer-handler, secondary-handler and circulation
+  failures through `DyNTS_SafeDiagnostic_ControlService`.
+- Removed framework-owned raw message, stack, route, request and response-preview logging from endpoint failures.
+- Removed mutation of caller errors with `endpointInfo` and `requestDebug` snapshots.
+- Wrapped plain failures with a static internal message and the immutable safe diagnostic while retaining the
+  existing public endpoint error-code shape and validated HTTP status behavior.
+- Sanitized and bounded developer-owned system and endpoint identifiers used in the compatibility error code.
+- Preserved raw failure/request access only for the explicitly installed application global handler; a rejection
+  from that handler is itself projected before logging.
+- Removed the issuer shadow so the resolved account identity reaches the application-owned error persistence
+  boundary.
+
+Normal successful-request logging is outside this change. Its existing request-param, body and response fields
+remain explicit caller-controlled options. This BFR makes the error path content-free regardless of those options
+or detailed logging mode.
+
+## Verification evidence
+
+- TypeScript production build: passed.
+- Focused BFR canary regression: 1/1 passed.
+- Full Jasmine package regression: 1750 specs, 0 failures, 146 explicit pending specs.
+- Package ESLint: 0 errors; the repository retains its pre-existing warning baseline.
+- Canary matrix: raw error message, secondary handler stack/token, workbook/sheet value, URL, query, header,
+  authorization value and path parameter are absent from every captured Dynamo logger call and from the client
+  response. The 503 status, safe diagnostic and resolved issuer are asserted.
+- Import validator baseline: 80 findings in 74 pre-existing files; the modified endpoint and safe-diagnostic files
+  introduce no import finding.
+- Naming validator baseline: 100 findings in 67 pre-existing files. The endpoint class carries its existing public
+  naming findings; this compatible security fix does not rename that public API.
+
+The validator baselines are reported as measured debt, not as green evidence. No unrelated mass rename or import
+rewrite is bundled into this security BFR.

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

@@ -1,91 +1,111 @@
-# 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.
-
+# 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. |
+## Endpoint error integration
+
+`DyNTS_Endpoint_Params` applies the same projection at every framework-owned endpoint failure boundary. The
+primary task or pre-process failure, issuer-resolution failure, consumer global-handler rejection, secondary
+error-handler failure and circulation-resolution failure are classified with stable uppercase codes and the
+closed `endpoint` stage. Detailed logging mode does not bypass this projection.
+
+The endpoint boundary does not append route values, path parameters, URL, query, request body, headers, auth
+header shape, error message, stack or nested error content to logs or `additionalContent`. A plain native failure
+is converted to a client-safe `DyFM_Error` with a static internal message, the established
+`<SYSTEM>|DyNTS-EPP-<endpointName>` public code shape and the projected diagnostic. Developer-owned system and
+endpoint code parts are bounded and reduced to the established identifier alphabet. Conventional numeric HTTP
+status fields remain supported without inspecting message or stack.
+
+The raw failure and request remain available to the explicitly installed consumer global handler because that
+handler is the application-owned persistence boundary. If it rejects, the rejection is projected before any
+framework log. The resolved issuer is now carried through the error path rather than being shadowed by a local
+variable, so account-level attribution remains intact.
+
+## 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. |
+| Endpoint runtime test | Error, handler, token, workbook, URL, query, header and path canaries are absent from every endpoint log and client response. |
 | 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.
+| Full package regression | Build and complete Jasmine suite remain green; validator findings are measured and reported, never hidden. |
+
+## 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/build/_collections/app-version-header.util.d.ts

@@ -1,42 +1,42 @@
-import * as Express from 'express';
-/**
- * FR-292 (2026-08-08) — a DEPLOYOLT app-verzió kiírása MINDEN válasz headerébe.
- *
- * **Miért kell:** a böngészőben nyitva hagyott SPA a memóriájában tartja a bundle-t, és a
- * deploy után is a RÉGI kódot futtatja, amíg a felhasználó újra nem tölt. Ez nem elméleti:
- * egy órákig nyitva hagyott dashboard-fülön hiányzó gombokat / régi viselkedést mutat, és
- * a felhasználó (jogosan) azt hiszi, hogy a funkció nincs kész.
- *
- * Az itteni megoldás **nem polling**: a szerver minden válaszra ráteszi a saját deployolt
- * app-verzióját, a kliens pedig a MÁR MEGLÉVŐ hívásaiból olvassa ki (ngx oldalon a
- * `DyNX_AppVersion_Interceptor`). Nulla extra kérés, nulla extra terhelés — a jelzés
- * „ingyen" utazik azon, ami úgyis megy.
- *
- * **CORS:** cross-origin kliens csak akkor OLVASHATJA a headert, ha az szerepel az
- * `Access-Control-Expose-Headers`-ben. Ezért a middleware a meglévő értékhez HOZZÁFŰZ
- * (nem felülír) — ezért kell a CORS-mount UTÁN felszerelni.
- */
-/** A deployolt app-verziót hordozó response-header neve (a kliens ezt olvassa). */
-export declare const DYNTS_APP_VERSION_HEADER: string;
-/**
- * Kiszámolja az `Access-Control-Expose-Headers` ÚJ értékét úgy, hogy a meglévő listát
- * megtartja és a verzió-headert csak akkor fűzi hozzá, ha még nincs benne (idempotens).
- *
- * Tiszta függvény: Express nélkül unit-tesztelhető.
- *
- * @param currentValue a válaszon MÁR beállított érték (a CORS-middleware-től), ha van
- * @param headerName a hozzáfűzendő header neve
- */
-export declare function DyNTS_resolveExposeHeaders(currentValue: string | undefined, headerName: string): string;
-/**
- * Express-middleware, ami minden válaszra ráteszi a deployolt app-verziót.
- *
- * A verziót FÜGGVÉNYKÉNT kapja (nem értékként), mert a `DyNTS_global_settings.systemVersion`
- * az app-params betöltésekor áll be — egy induláskor kiolvasott érték `unknown-version`
- * maradhatna örökre.
- *
- * @param getAppVersion a deployolt app-verziót visszaadó getter
- * @param headerName felülírható header-név (default: `X-App-Version`)
- */
-export declare function DyNTS_createAppVersionHeaderMiddleware(getAppVersion: () => string | undefined, headerName?: string): Express.RequestHandler;
+import * as Express from 'express';
+/**
+ * FR-292 (2026-08-08) — a DEPLOYOLT app-verzió kiírása MINDEN válasz headerébe.
+ *
+ * **Miért kell:** a böngészőben nyitva hagyott SPA a memóriájában tartja a bundle-t, és a
+ * deploy után is a RÉGI kódot futtatja, amíg a felhasználó újra nem tölt. Ez nem elméleti:
+ * egy órákig nyitva hagyott dashboard-fülön hiányzó gombokat / régi viselkedést mutat, és
+ * a felhasználó (jogosan) azt hiszi, hogy a funkció nincs kész.
+ *
+ * Az itteni megoldás **nem polling**: a szerver minden válaszra ráteszi a saját deployolt
+ * app-verzióját, a kliens pedig a MÁR MEGLÉVŐ hívásaiból olvassa ki (ngx oldalon a
+ * `DyNX_AppVersion_Interceptor`). Nulla extra kérés, nulla extra terhelés — a jelzés
+ * „ingyen" utazik azon, ami úgyis megy.
+ *
+ * **CORS:** cross-origin kliens csak akkor OLVASHATJA a headert, ha az szerepel az
+ * `Access-Control-Expose-Headers`-ben. Ezért a middleware a meglévő értékhez HOZZÁFŰZ
+ * (nem felülír) — ezért kell a CORS-mount UTÁN felszerelni.
+ */
+/** A deployolt app-verziót hordozó response-header neve (a kliens ezt olvassa). */
+export declare const DYNTS_APP_VERSION_HEADER: string;
+/**
+ * Kiszámolja az `Access-Control-Expose-Headers` ÚJ értékét úgy, hogy a meglévő listát
+ * megtartja és a verzió-headert csak akkor fűzi hozzá, ha még nincs benne (idempotens).
+ *
+ * Tiszta függvény: Express nélkül unit-tesztelhető.
+ *
+ * @param currentValue a válaszon MÁR beállított érték (a CORS-middleware-től), ha van
+ * @param headerName a hozzáfűzendő header neve
+ */
+export declare function DyNTS_resolveExposeHeaders(currentValue: string | undefined, headerName: string): string;
+/**
+ * Express-middleware, ami minden válaszra ráteszi a deployolt app-verziót.
+ *
+ * A verziót FÜGGVÉNYKÉNT kapja (nem értékként), mert a `DyNTS_global_settings.systemVersion`
+ * az app-params betöltésekor áll be — egy induláskor kiolvasott érték `unknown-version`
+ * maradhatna örökre.
+ *
+ * @param getAppVersion a deployolt app-verziót visszaadó getter
+ * @param headerName felülírható header-név (default: `X-App-Version`)
+ */
+export declare function DyNTS_createAppVersionHeaderMiddleware(getAppVersion: () => string | undefined, headerName?: string): Express.RequestHandler;
 //# sourceMappingURL=app-version-header.util.d.ts.map

package/build/_collections/app-version-header.util.js

@@ -1,67 +1,67 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.DYNTS_APP_VERSION_HEADER = void 0;
-exports.DyNTS_resolveExposeHeaders = DyNTS_resolveExposeHeaders;
-exports.DyNTS_createAppVersionHeaderMiddleware = DyNTS_createAppVersionHeaderMiddleware;
-/**
- * FR-292 (2026-08-08) — a DEPLOYOLT app-verzió kiírása MINDEN válasz headerébe.
- *
- * **Miért kell:** a böngészőben nyitva hagyott SPA a memóriájában tartja a bundle-t, és a
- * deploy után is a RÉGI kódot futtatja, amíg a felhasználó újra nem tölt. Ez nem elméleti:
- * egy órákig nyitva hagyott dashboard-fülön hiányzó gombokat / régi viselkedést mutat, és
- * a felhasználó (jogosan) azt hiszi, hogy a funkció nincs kész.
- *
- * Az itteni megoldás **nem polling**: a szerver minden válaszra ráteszi a saját deployolt
- * app-verzióját, a kliens pedig a MÁR MEGLÉVŐ hívásaiból olvassa ki (ngx oldalon a
- * `DyNX_AppVersion_Interceptor`). Nulla extra kérés, nulla extra terhelés — a jelzés
- * „ingyen" utazik azon, ami úgyis megy.
- *
- * **CORS:** cross-origin kliens csak akkor OLVASHATJA a headert, ha az szerepel az
- * `Access-Control-Expose-Headers`-ben. Ezért a middleware a meglévő értékhez HOZZÁFŰZ
- * (nem felülír) — ezért kell a CORS-mount UTÁN felszerelni.
- */
-/** A deployolt app-verziót hordozó response-header neve (a kliens ezt olvassa). */
-exports.DYNTS_APP_VERSION_HEADER = 'X-App-Version';
-/** Az `Access-Control-Expose-Headers` header neve — hogy ne szórjuk el string-literálként. */
-const EXPOSE_HEADERS_HEADER = 'Access-Control-Expose-Headers';
-/**
- * Kiszámolja az `Access-Control-Expose-Headers` ÚJ értékét úgy, hogy a meglévő listát
- * megtartja és a verzió-headert csak akkor fűzi hozzá, ha még nincs benne (idempotens).
- *
- * Tiszta függvény: Express nélkül unit-tesztelhető.
- *
- * @param currentValue a válaszon MÁR beállított érték (a CORS-middleware-től), ha van
- * @param headerName a hozzáfűzendő header neve
- */
-function DyNTS_resolveExposeHeaders(currentValue, headerName) {
-    if (!currentValue) {
-        return headerName;
-    }
-    const alreadyExposed = currentValue
-        .split(',')
-        .some((entry) => entry.trim().toLowerCase() === headerName.toLowerCase());
-    return alreadyExposed ? currentValue : `${currentValue}, ${headerName}`;
-}
-/**
- * Express-middleware, ami minden válaszra ráteszi a deployolt app-verziót.
- *
- * A verziót FÜGGVÉNYKÉNT kapja (nem értékként), mert a `DyNTS_global_settings.systemVersion`
- * az app-params betöltésekor áll be — egy induláskor kiolvasott érték `unknown-version`
- * maradhatna örökre.
- *
- * @param getAppVersion a deployolt app-verziót visszaadó getter
- * @param headerName felülírható header-név (default: `X-App-Version`)
- */
-function DyNTS_createAppVersionHeaderMiddleware(getAppVersion, headerName = exports.DYNTS_APP_VERSION_HEADER) {
-    return (_req, res, next) => {
-        const appVersion = getAppVersion();
-        // Ismeretlen verziónál NEM írunk headert: egy `unknown-version` jelzés rosszabb a
-        // semminél — a kliens „új verzió van" hamis riasztást adna belőle.
-        if (appVersion && appVersion !== 'unknown-version') {
-            res.setHeader(headerName, appVersion);
-            res.setHeader(EXPOSE_HEADERS_HEADER, DyNTS_resolveExposeHeaders(res.getHeader(EXPOSE_HEADERS_HEADER)?.toString(), headerName));
-        }
-        next();
-    };
-}
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DYNTS_APP_VERSION_HEADER = void 0;
+exports.DyNTS_resolveExposeHeaders = DyNTS_resolveExposeHeaders;
+exports.DyNTS_createAppVersionHeaderMiddleware = DyNTS_createAppVersionHeaderMiddleware;
+/**
+ * FR-292 (2026-08-08) — a DEPLOYOLT app-verzió kiírása MINDEN válasz headerébe.
+ *
+ * **Miért kell:** a böngészőben nyitva hagyott SPA a memóriájában tartja a bundle-t, és a
+ * deploy után is a RÉGI kódot futtatja, amíg a felhasználó újra nem tölt. Ez nem elméleti:
+ * egy órákig nyitva hagyott dashboard-fülön hiányzó gombokat / régi viselkedést mutat, és
+ * a felhasználó (jogosan) azt hiszi, hogy a funkció nincs kész.
+ *
+ * Az itteni megoldás **nem polling**: a szerver minden válaszra ráteszi a saját deployolt
+ * app-verzióját, a kliens pedig a MÁR MEGLÉVŐ hívásaiból olvassa ki (ngx oldalon a
+ * `DyNX_AppVersion_Interceptor`). Nulla extra kérés, nulla extra terhelés — a jelzés
+ * „ingyen" utazik azon, ami úgyis megy.
+ *
+ * **CORS:** cross-origin kliens csak akkor OLVASHATJA a headert, ha az szerepel az
+ * `Access-Control-Expose-Headers`-ben. Ezért a middleware a meglévő értékhez HOZZÁFŰZ
+ * (nem felülír) — ezért kell a CORS-mount UTÁN felszerelni.
+ */
+/** A deployolt app-verziót hordozó response-header neve (a kliens ezt olvassa). */
+exports.DYNTS_APP_VERSION_HEADER = 'X-App-Version';
+/** Az `Access-Control-Expose-Headers` header neve — hogy ne szórjuk el string-literálként. */
+const EXPOSE_HEADERS_HEADER = 'Access-Control-Expose-Headers';
+/**
+ * Kiszámolja az `Access-Control-Expose-Headers` ÚJ értékét úgy, hogy a meglévő listát
+ * megtartja és a verzió-headert csak akkor fűzi hozzá, ha még nincs benne (idempotens).
+ *
+ * Tiszta függvény: Express nélkül unit-tesztelhető.
+ *
+ * @param currentValue a válaszon MÁR beállított érték (a CORS-middleware-től), ha van
+ * @param headerName a hozzáfűzendő header neve
+ */
+function DyNTS_resolveExposeHeaders(currentValue, headerName) {
+    if (!currentValue) {
+        return headerName;
+    }
+    const alreadyExposed = currentValue
+        .split(',')
+        .some((entry) => entry.trim().toLowerCase() === headerName.toLowerCase());
+    return alreadyExposed ? currentValue : `${currentValue}, ${headerName}`;
+}
+/**
+ * Express-middleware, ami minden válaszra ráteszi a deployolt app-verziót.
+ *
+ * A verziót FÜGGVÉNYKÉNT kapja (nem értékként), mert a `DyNTS_global_settings.systemVersion`
+ * az app-params betöltésekor áll be — egy induláskor kiolvasott érték `unknown-version`
+ * maradhatna örökre.
+ *
+ * @param getAppVersion a deployolt app-verziót visszaadó getter
+ * @param headerName felülírható header-név (default: `X-App-Version`)
+ */
+function DyNTS_createAppVersionHeaderMiddleware(getAppVersion, headerName = exports.DYNTS_APP_VERSION_HEADER) {
+    return (_req, res, next) => {
+        const appVersion = getAppVersion();
+        // Ismeretlen verziónál NEM írunk headert: egy `unknown-version` jelzés rosszabb a
+        // semminél — a kliens „új verzió van" hamis riasztást adna belőle.
+        if (appVersion && appVersion !== 'unknown-version') {
+            res.setHeader(headerName, appVersion);
+            res.setHeader(EXPOSE_HEADERS_HEADER, DyNTS_resolveExposeHeaders(res.getHeader(EXPOSE_HEADERS_HEADER)?.toString(), headerName));
+        }
+        next();
+    };
+}
 //# sourceMappingURL=app-version-header.util.js.map

package/build/_collections/archive-service-registry.const.d.ts

@@ -1,16 +1,16 @@
-import type { DyFM_DataModel_Params, DyFM_Metadata } from '@futdevpro/fsm-dynamo';
-import type { DyNTS_ArchiveDataService } from '../_services/base/archive-data.service';
-/**
- * Az archive-service osztály runtime-registry-je (BFR-AM-012 — körkörös-import feloldás).
- *
- * A `DyNTS_DataService.getArchiveDataService()` default-implementációja a
- * `DyNTS_ArchiveDataService`-t példányosítaná — de az `archive-data.service` maga a
- * `data.service`-ből örököl, így a KÖZVETLEN value-import futásidejű require-ciklust okozna
- * („Class extends value undefined"). A regisztráció fordítva folyik: az `archive-data.service`
- * modul-inicializáláskor IDE teszi be a saját konstruktorát (a registry-nek nincs runtime-importja
- * → nincs ciklus), a base data-service pedig innen olvassa.
- */
-export declare const DyNTS_archiveServiceRegistry: {
-    ArchiveDataService?: new <T extends DyFM_Metadata>(data: T, dataParams: DyFM_DataModel_Params<T>, issuer: string) => DyNTS_ArchiveDataService<T>;
-};
+import type { DyFM_DataModel_Params, DyFM_Metadata } from '@futdevpro/fsm-dynamo';
+import type { DyNTS_ArchiveDataService } from '../_services/base/archive-data.service';
+/**
+ * Az archive-service osztály runtime-registry-je (BFR-AM-012 — körkörös-import feloldás).
+ *
+ * A `DyNTS_DataService.getArchiveDataService()` default-implementációja a
+ * `DyNTS_ArchiveDataService`-t példányosítaná — de az `archive-data.service` maga a
+ * `data.service`-ből örököl, így a KÖZVETLEN value-import futásidejű require-ciklust okozna
+ * („Class extends value undefined"). A regisztráció fordítva folyik: az `archive-data.service`
+ * modul-inicializáláskor IDE teszi be a saját konstruktorát (a registry-nek nincs runtime-importja
+ * → nincs ciklus), a base data-service pedig innen olvassa.
+ */
+export declare const DyNTS_archiveServiceRegistry: {
+    ArchiveDataService?: new <T extends DyFM_Metadata>(data: T, dataParams: DyFM_DataModel_Params<T>, issuer: string) => DyNTS_ArchiveDataService<T>;
+};
 //# sourceMappingURL=archive-service-registry.const.d.ts.map

package/build/_collections/archive-service-registry.const.js

@@ -1,15 +1,15 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.DyNTS_archiveServiceRegistry = void 0;
-/**
- * Az archive-service osztály runtime-registry-je (BFR-AM-012 — körkörös-import feloldás).
- *
- * A `DyNTS_DataService.getArchiveDataService()` default-implementációja a
- * `DyNTS_ArchiveDataService`-t példányosítaná — de az `archive-data.service` maga a
- * `data.service`-ből örököl, így a KÖZVETLEN value-import futásidejű require-ciklust okozna
- * („Class extends value undefined"). A regisztráció fordítva folyik: az `archive-data.service`
- * modul-inicializáláskor IDE teszi be a saját konstruktorát (a registry-nek nincs runtime-importja
- * → nincs ciklus), a base data-service pedig innen olvassa.
- */
-exports.DyNTS_archiveServiceRegistry = {};
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DyNTS_archiveServiceRegistry = void 0;
+/**
+ * Az archive-service osztály runtime-registry-je (BFR-AM-012 — körkörös-import feloldás).
+ *
+ * A `DyNTS_DataService.getArchiveDataService()` default-implementációja a
+ * `DyNTS_ArchiveDataService`-t példányosítaná — de az `archive-data.service` maga a
+ * `data.service`-ből örököl, így a KÖZVETLEN value-import futásidejű require-ciklust okozna
+ * („Class extends value undefined"). A regisztráció fordítva folyik: az `archive-data.service`
+ * modul-inicializáláskor IDE teszi be a saját konstruktorát (a registry-nek nincs runtime-importja
+ * → nincs ciklus), a base data-service pedig innen olvassa.
+ */
+exports.DyNTS_archiveServiceRegistry = {};
 //# sourceMappingURL=archive-service-registry.const.js.map