@futdevpro/nts-dynamo 1.15.156 → 1.15.160

package/__documentations/2026-08-08-fr292-app-version-header.md

@@ -1,38 +0,0 @@
-# FR-292 (szerver-fél) — a deployolt app-verzió minden válasz headerében
-
-**Dátum:** 2026-08-08 · **Csomag:** `@futdevpro/nts-dynamo`
-
-> A teljes (kliens+szerver) leírás a kliens-oldalon:
-> `NPM-packages/dynamo-ngx/__documentations/2026-08-08-fr292-app-update-watch.md`.
-> Ez a lap csak a szerver-fél szerződését rögzíti.
-
-## Mit csinál
-
-Minden HTTP-válaszra rákerül a deployolt **app-verzió**:
-
-```
-X-App-Version: 01.15.460
-Access-Control-Expose-Headers: Content-Length, Content-Type, X-App-Version
-```
-
-A kliens (ngx-dynamo `DyNX_AppVersion_Interceptor`) ebből veszi észre, hogy a böngészőben
-**betöltött bundle elavult** — anélkül, hogy bárki pollingolna: a jelzés a már menő
-API-forgalmon utazik.
-
-## Szerződés / döntések
-
-- **Default: BEKAPCSOLVA.** Informatív header, se PII, se belső részlet. Kikapcsolás:
-  `DyNTS_global_settings.appVersionHeader = { enabled: false }`.
-- **A verzió hívásonként olvasódik** (getter, nem befagyasztott érték): a `systemVersion` az
-  app-params betöltésekor áll be, ami a middleware felszerelése UTÁN történik. Befagyasztva
-  örökre `unknown-version` maradna — pont a friss deployon hiányozna a jelzés.
-- **`unknown-version` esetén NINCS header.** Egy bizonytalan jelzés hamis „új verzió elérhető"
-  riasztást szülne a kliensen; inkább hallgatunk.
-- **A CORS expose-listához hozzáfűz, nem felülír** (idempotensen). Enélkül a cross-origin
-  kliens JS-e nem olvashatná ki a headert. Ezért a middleware a **CORS-mount UTÁN** települ
-  — `initOpenExpress` és `initSecureExpress` egyaránt.
-
-## Verifikáció
-
-`tsc` ✅ 0 hiba · unit ✅ **1634 spec, 0 failure** (ebből 8 új: expose-lista bővítés/idempotencia,
-ismeretlen verzió → nincs header de a lánc továbbmegy, hívásonkénti verzió-olvasás, egyedi header-név).

package/__documentations/2026-08-14-field-encryption-mongoose-document-spread.md

@@ -1,124 +0,0 @@
-# 🔴 `DyNTS_FieldEncryption_Util._transform` spread-elte a Mongoose-Documentet — a lista-endpointok burkot adtak vissza
-
-**Dátum:** 2026-08-14 · **Kérő:** `BFR-MASTERPROMPTER-027` · **Súlyosság:** high (funkcionálisan törött lista-UI)
-
----
-
-## 1. A hiba
-
-```ts
-// field-encryption.util.ts — ELŐTTE
-const result: any = Array.isArray(value) ? [ ...(value as any[]) ] : { ...(value as any) };
-```
-
-Egy mongoose-**Document** adatai **nem saját mezők** — a belső `_doc`-ban ülnek. Ezért a `{ ...doc }`
-a **belső burkot** másolja (`$__`, `$isNew`, `_doc`), és az eredmény **már nem Document**, tehát a
-`JSON.stringify` sem hívja a `toJSON()`-ját. A kliens így ezt kapja:
-
-```json
-[{ "$__": {...}, "$isNew": false, "_doc": { "_id": "…", "name": "…" } }]
-```
-
-`_id` a legfelső szinten **nincs** → a fogyasztó minden id-alapú művelete elhasal.
-
-### Élesben mért bizonyíték (`test.master-prompter.hu`, 2026-08-14)
-
-| endpoint | státusz | első elem KULCSAI | `_id` |
-|---|---|---|---|
-| `GET /api/flow/flow/get/:userId/:flowId` (egyedi) | 200 | `_id`, `userId`, `ownerId`, `name`, … | ✅ |
-| `GET /api/flow/flow/get-all-my/:userId` (**lista**) | 200 | **`$__`, `$isNew`, `_doc`** | ❌ **undefined** |
-
-Kliens-oldali tünet: a lista-kártyák linkje `/editor/undefined`, a törlés
-`DyNX_ApiService call "deleteFlow" ERROR: missing pathParam: "flowId"` dialógussal állt meg.
-
----
-
-## 2. Miért CSAK a lista tört el — a mért aszimmetria
-
-A `DyNTS_DBService` **egyedi** olvasásai már ma is `toObject()`-tel adnak vissza sima objektumot
-(`getDataById`, `getDataByDependencyId`, `findByIdAndUpdate`, `findOneAndUpdate`, `createData`).
-A **lista/find metódusok NYERS Documentet** adnak tovább — kimérve **11 db**:
-
-`getDataListByIds` · `getDataListByDependencyId` · `getDataListByDependencyIds` · `getAll` ·
-`getDeletedDataList` · `trueDeleteAllData` · `searchData` · `findOne` · `find` · `findWithPaging` ·
-(`findLeanBatched` — ez `.lean()`-nel már sima objektumot ad)
-
-Titkosítás **nélkül** ez ártalmatlan: a nyers Document a `res.send`-en át a `toJSON()`-nal helyesen
-szerializálódik. `encrypt: true` mező esetén viszont a read-post-processor (`stringifyDataId` →
-`decryptDoc` → `_transform`) **spread-eli** a Documentet, és ezzel elrontja.
-
----
-
-## 3. A javítás
-
-```ts
-// UTÁNA
-const plain: any = this._toPlainIfDocument(value);
-const result: any = Array.isArray(plain) ? [ ...(plain as any[]) ] : { ...(plain as any) };
-```
-
-`_toPlainIfDocument` a `$__` **saját mező** + `toJSON` függvény kettősével azonosít egy Documentet
-(pontosan az, ami a hibás payloadba kiszivárgott — mongoose-import nélküli, pontos diszkriminátor),
-és `toJSON()`-t hív rá.
-
-**Miért itt, és nem a 11 DB-metódusban:**
-1. Ez az **egy pont** mind a 11 utat rendezi.
-2. A 11 metódus visszatérési **típusát** megváltoztatni (Document → sima objektum) **minden modell
-   minden fogyasztóját** érintené. Az itteni javítás viszont **csak az `encrypt: true` modelleket**
-   érinti — ahol a `_transform` amúgy is **már ma is** sima (csak **rossz**) objektumot ad vissza.
-   ⇒ **a változás nem tud elrontani olyat, ami ma működik.**
-3. `toJSON()` (nem `toObject()`): a titkosítás bevezetése ELŐTT a nyers Document a `res.send`-en át a
-   `JSON.stringify` → `toJSON()` úton szerializálódott — ez adja vissza **ugyanazt a kimeneti alakot**
-   (schema-transzformok, virtuals, `__v` együtt).
-
----
-
-## 4. 🔴 BLAST-RADIUS — a flotta érintettsége
-
-A defekt akkor él, ha **mind a három** teljesül: (a) a modellnek van `encrypt: true` mezője ·
-(b) a `FDP_CORE_DBCONTENT_CRYPT_KEY` be van állítva (kulcs nélkül a `decryptDoc` korán visszatér) ·
-(c) az olvasás **lista-metóduson** megy.
-
-| Projekt | Modell | Titkosított mezők | Állapot |
-|---|---|---|---|
-| **master-prompter** | `flow` | `flowSteps.prompt` | 🔴 **élesben igazoltan törött** |
-| **master-prompter** | `flow-run` | `results`, `sourceFlow`, `flowRunValues.value` | 🔴 ugyanaz az osztály |
-| **adventor** | `campaign` | `storyState`, `memory`, `epilogue` | ⚠️ ugyanaz az osztály — élesben nem mérve |
-| **adventor** | `generation` | `content`, `prompt` | ⚠️ ugyanaz az osztály — élesben nem mérve |
-| **fdp-token-service** | `token-purchase` | `requestIp`, `euVatNumber` (PII) | ⚠️ ugyanaz az osztály — élesben nem mérve |
-| **fdp-token-service** | `manual-invoice` | `realID`, `title`, `fullName`, `companyName`, … | ⚠️ ugyanaz az osztály — élesben nem mérve |
-
-⇒ **6 modell, 3 projekt.** A master-prompteren kívül egyik sincs élesben visszamérve — ezeket a
-projektek `nts-dynamo`-bumpja után kell ellenőrizni (a lista-endpointjaik `_id`-t adnak-e).
-A `manual-invoice` és a `token-purchase` külön figyelmet érdemel: számlázási/PII adat.
-
-> **Miért nem tűnt fel eddig:** a szerver **200**-at ad, a válasz JSON-ként **érvényes** — csak épp a
-> burkot tartalmazza. A UI „üresnek"/működésképtelennek látszik, de sehol nincs hibajelzés.
-> Az MP-ben azért derült ki, mert az `e2e-feature` step (a 30m→60m timeout-emelés után) **most futott
-> le először végig**.
-
----
-
-## 5. Kontroll-mérés — VALÓDI mongoose-Documenttel
-
-A regresszió-őr **szándékosan nem mockkal** dolgozik: a hiba pont abból eredt, hogy a Document adatai
-nem saját mezők — egy kézzel gyártott mock ezt a jellemzőt nem hordozza, tehát a mock-alapú teszt
-**akkor is zöld maradna**, ha a hiba visszakerülne. DB-kapcsolat nem kell: a `new Model({...})`
-offline is valódi Documentet ad.
-
-| Eset | A fix nélkül |
-|---|---|
-| a visszafejtett eredmény sima objektum (nincs `$__`/`$isNew`/`_doc`) | ❌ `Expected [ '$__', '_doc' ] not to contain '$__'` |
-| az `_id` megmarad | ❌ `az _id elveszett a transzform során: Expected undefined to be defined` |
-| a JSON-szerializált alak a valódi adatot adja | ❌ `… not to contain '_doc'` |
-| Document-**tömb** (lista-alak) minden eleme sima objektum, `_id`-vel | ❌ `… not to contain '_doc'` |
-| **összesen** | ❌ **4 FAILED** → javítva: ✅ **1644 specs, 0 failures** |
-
-A mezők helyes visszafejtését is asszertáljuk Documenten (top-level + beágyazott tömb-elem).
-
----
-
-## 6. Adopció
-
-`@futdevpro/nts-dynamo` bump minden érintett szerver-projektben (master-prompter, adventor,
-fdp-token-service), majd a lista-endpointok visszamérése (`_id` jelen van-e a válaszban).

package/__documentations/2026-08-18-artifact-compiler.md

@@ -1,46 +0,0 @@
-# Dynamo NTS in-memory artifact compiler
-
-**Contract:** `dynts-artifact-compiler/1`
-
-**Release candidate:** `@futdevpro/nts-dynamo@1.15.144`
-
-## Purpose
-
-The artifact compiler turns one already policy-validated TypeScript program into a self-contained JavaScript bundle
-for a classic browser Worker. It is a shared build capability, not a sandbox, an authorization layer or a source
-policy validator. Consumers must validate source before compilation and execute the output inside an independently
-enforced runtime boundary.
-
-## Guarantees
-
-- source is supplied through an in-memory virtual entry;
-- output uses the asynchronous esbuild API with `bundle:true`, `platform:'browser'`, `format:'iife'` and
-  `write:false`;
-- no sourcemap, embedded source content, legal comment file, plugin supplied by the caller or filesystem output;
-- the TypeScript AST is traversed before bundling, so unused imports cannot disappear through tree-shaking before
-  policy evaluation;
-- only caller-allowlisted static package roots resolve from the supplied absolute dependency directory;
-- relative, absolute, re-export, import-equals, `require()` and dynamic `import()` module loads fail closed;
-- transitive modules resolve only through the installed dependency graph;
-- source and output byte limits, allowlist cardinality, package names and path fields have absolute Bedrock
-  ceilings;
-- success returns exactly one JavaScript output with SHA-256 metadata;
-- errors return stable codes and optional line/column only, never esbuild message text, source excerpt or path.
-
-The output is deterministic for the same source, settings, installed lock graph, platform and compiler version. The
-consumer must therefore version and checksum the compiler version and dependency lock together with the bundle.
-
-## Security boundary
-
-esbuild's own documentation explicitly states that esbuild is not a sandbox. This module never executes generated
-code, and successful compilation must not be interpreted as permission to run it. Direct relative/absolute, Node,
-HTTP or non-allowlisted imports fail because only package roots in `allowedPackages` can resolve from the virtual
-entry. Trusted allowed packages may resolve their own installed transitive graph.
-
-## Verification
-
-The eight focused Bedrock specs cover deterministic output, a real bundled dependency, non-allowlisted imports,
-all supported static and dynamic module-load syntax, content-free syntax diagnostics, invalid request contracts and
-source/output budgets. Company Toolmaker is the first direct consumer under `BFR-CTM-008`. The request was
-initially recorded as `BFR-CTM-007`, but that identifier already belonged to the atomic Mongo transaction boundary;
-the correction preserves both trace histories.

package/__documentations/2026-08-18-mongo-transaction-control-service.md

@@ -1,82 +0,0 @@
-# Mongo transaction control service
-
-**Date:** 2026-08-18  
-**Status:** implemented and verified  
-**Bedrock capability:** atomic multi-document MongoDB business operation
-
-## Purpose
-
-`DyNTS_MongoTransaction_ControlService` provides one reusable Dynamo NTS transaction boundary for consumers
-that must persist related state and audit records atomically. The first consumer is Company Toolmaker's
-approval-gated pipeline lifecycle, where a state transition and its immutable transition event must either both
-commit or both remain absent.
-
-The primitive owns transaction lifecycle and safety policy. It deliberately does not own a consuming product's
-business rules, collection schemas, idempotency contract or authorization decisions.
-
-## Contract
-
-The caller supplies:
-
-- a non-empty, diagnostic-only `transactionName`;
-- a non-empty `issuer`;
-- an optional positive safe-integer `maxCommitTimeMs`;
-- an asynchronous task receiving the active Mongoose `ClientSession`.
-
-The service:
-
-1. validates settings before allocating a session;
-2. creates exactly one Mongoose session;
-3. executes the task through `ClientSession.withTransaction`;
-4. uses `snapshot` read concern, `majority` write concern and `primary` read preference;
-5. returns the committed task value, including a legitimate `undefined` task value through an internal wrapper;
-6. always attempts session cleanup after a session was created;
-7. fails closed when no committed result is returned.
-
-Every MongoDB read or write participating in the atomic operation must explicitly receive the callback's
-session. Starting a transaction does not automatically attach the session to unrelated model calls.
-
-Mongoose may invoke the transaction task more than once when retrying a transient transaction error. The task
-must therefore keep all mutations inside the MongoDB transaction and must not send messages, call external
-mutation endpoints or perform any other non-transactional side effect. Such work belongs after a successful
-commit and requires its own idempotency contract.
-
-## Stable failures and data minimization
-
-| Code | Meaning |
-|---|---|
-| `DyNTS|MONGO_TRANSACTION|SETTINGS_INVALID` | Required settings are absent or invalid. |
-| `DyNTS|MONGO_TRANSACTION|COMMIT_TIME_INVALID` | Commit budget is not a positive safe integer. |
-| `DyNTS|MONGO_TRANSACTION|SESSION_FAILED` | A MongoDB session could not be created. |
-| `DyNTS|MONGO_TRANSACTION|NO_COMMIT_RESULT` | The transaction callback produced no committed wrapper result. |
-| `DyNTS|MONGO_TRANSACTION|FAILED` | Transaction execution or commit failed. |
-
-Failure objects include only the transaction name and the JavaScript error class name. The original error
-message, stack, database payload and task input are not copied into the stable error, preventing accidental
-sensitive-data disclosure. Cleanup warnings likewise log only the transaction name and error class name.
-
-## Deployment requirement
-
-MongoDB multi-document transactions require a replica set or a sharded cluster. Production and integration-test
-deployments using this primitive must therefore provide a transaction-capable MongoDB topology. A standalone
-MongoDB process must fail the operation rather than silently degrading to non-atomic writes.
-
-## Verification
-
-The focused Jasmine suite covers successful commit and result forwarding, shared-session forwarding,
-transaction failure sanitization, pre-session validation, invalid commit-budget rejection, session-creation
-failure, missing commit result, cleanup failure tolerance and singleton access.
-
-Measured on 2026-08-18:
-
-- focused suite: 8 specs, 0 failures;
-- complete package suite: 1,653 specs, 0 failures, 146 explicitly pending specs;
-- TypeScript build: passed;
-- changed-file ESLint: passed without findings;
-- package-wide ESLint: completed with the repository's pre-existing warning baseline;
-- import validator: blocked by the existing Dynamo ESLint v9 flat-config incompatibility in unrelated files;
-- naming validator: reports the repository's existing 6,400-finding baseline in 230 files.
-
-The two convention-validator baselines are not introduced by this capability. The changed source files pass the
-direct ESLint gate, and the full compiler and regression suite are green. Repairing the repository-wide
-validator baseline is separate technical-debt work and must not be represented as completed by this change.

package/__documentations/2026-08-18-standalone-account-security-and-privacy-bedrock.md

@@ -1,132 +0,0 @@
-# Standalone account security and privacy Bedrock
-
-**Date:** 2026-08-18  
-**Status:** implemented and verified at package-contract level  
-**Packages:** `@futdevpro/nts-dynamo/account-security`, `@futdevpro/nts-dynamo/privacy-lifecycle`
-
-## Purpose and boundary
-
-This capability lets a Dynamo application own its identity and GDPR lifecycle without redirecting to, or
-depending on, a shared Fleet account. It is reusable Bedrock code, not a complete application account system.
-The consuming product remains responsible for typed persistence models, email delivery, organization and
-permission decisions, HTTP transport, secure browser credential handling, rate limiting, audit wiring and each
-product data-domain contributor.
-
-The modules deliberately expose direct Dynamo contracts. They do not add provider-swapping or replacement
-abstractions around Dynamo.
-
-## Account-security contract
-
-### Passwords
-
-`DyNTS_AccountPassword_ControlService` uses the versioned `dyn-scrypt-v1` format with a unique random salt,
-bounded scrypt parameters and timing-safe verification. It supports a SHA-256 common-password denylist and
-returns `needsRehash` when stored parameters differ from current policy. Malformed stored hashes and
-attacker-controlled work factors produce a safe negative result while still performing bounded dummy work.
-Passwords are never copied into errors.
-
-### Email verification and password reset
-
-`DyNTS_AccountChallenge_ControlService` issues opaque 256-bit-or-stronger credentials for two isolated purposes:
-email verification and password reset. Only SHA-256 token hashes enter persistence. Issuing a replacement
-atomically revokes its active predecessor for the same subject and purpose. Consumption must be a single
-compare-and-set operation that validates purpose, active state and expiry before marking the record consumed.
-Raw tokens are returned only once after successful persistence.
-
-Enumeration-neutral register/reset responses are an HTTP-boundary responsibility: the service must not reveal
-whether an email exists. The application must rate-limit issue and consume operations and deliver the raw token
-only through an approved out-of-band channel.
-
-### Sessions
-
-`DyNTS_AccountSession_ControlService` uses opaque random access and refresh credentials; no self-contained JWT is
-required. Only hashes are stored. An access credential resolves through an active server-side session, so
-logout, password change, account restriction and incident response can revoke it immediately.
-
-Refresh credentials are one-time ledger entries. Rotation uses an adapter-provided compare-and-set transaction.
-Reuse of an already consumed credential, including a concurrent rotation race, revokes the entire family. The
-user-safe session projection excludes subject, family and token hashes. The application decides authorization
-before calling individual or subject-wide revocation methods.
-
-The adapter contract is normative: session creation, token replacement and token-state changes must be atomic.
-An in-memory or multi-step production adapter would invalidate replay protection.
-
-## Privacy lifecycle contract
-
-### Data-subject requests
-
-`DyNTS_PrivacyLifecycle_ControlService` creates subject-, organization- and request-type-scoped idempotency
-hashes. The raw idempotency key is never stored. Each request has an explicit policy-supplied deadline and uses
-the following durable state family:
-
-`received → identity-verified → scoped → planned → executing → verifying → completed`
-
-Supported terminal/non-happy states are `partially-completed`, `rejected-with-reason`, `cancelled`,
-`failed-retryable` and `failed-terminal`. The current orchestrator produces `completed` or
-`partially-completed`; policy-specific rejection/cancellation/failure entry points remain consumer-owned until a
-shared cross-product transition contract is justified.
-
-Every registered contributor is ordered deterministically. Its durable `plan`, idempotent `execute` and
-read-only `verify` operations return content-free structured outcomes. Planning finishes and is persisted before
-the request enters `planned`; a planning failure becomes a resumable partial outcome without executing another
-domain against an incomplete plan set. Successful contributors are skipped on resume and failed contributors
-are retried. A retention result is valid only with an explicit matching basis code. Cross-subject reads return
-the same not-found response as an absent request.
-
-The consuming application must register contributors for identity, session, membership, pipelines/projects,
-agent sessions, artifacts, audit, support, subscription/billing and backup where those domains exist. Export
-contributors must generate machine-readable, checksummed, short-lived artifacts; erasure contributors must use
-hard delete by default and anonymize only where a documented retention basis requires it.
-
-### Legal acceptance and consent
-
-`DyNTS_PrivacyLedger_ControlService` keeps legal acceptance separate from optional-purpose consent. Legal records
-bind the subject to an exact document type, version and SHA-256 checksum. Consent is append-only and scoped by
-purpose and policy version; withdrawal creates a new event instead of mutating history. The ledger projection
-returns both full history and the latest decision per purpose.
-
-Adapters must enforce tenant/subject scoping and idempotency uniqueness. Document and privacy-notice content is
-not stored in these event records; the checksum binds the separately versioned canonical document.
-
-## Data-minimization and diagnostics
-
-- No password, bearer credential, challenge credential or raw idempotency key is persisted by these services.
-- Stable error messages contain no email address, token, password, file content, cell content or contributor
-  exception text.
-- Session context is intentionally pre-redacted: device label plus IP and user-agent hashes only.
-- Contributor outcomes carry codes, counts, checksums and retention basis, not exported personal data.
-- User-facing request, consent and legal-acceptance views omit idempotency hashes and request fingerprints;
-  those fields remain server-side persistence metadata.
-- Consumers must preserve this boundary in logs, audits, HTTP errors and analytics snapshots.
-
-## Required production integrations
-
-Before a product can claim production readiness, it must provide and test:
-
-1. transaction-safe MongoDB adapters for challenges, sessions, privacy requests and ledgers;
-2. normalized unique identity records and verified-email privilege gates;
-3. API rate limits for register, login, challenge issue/consume and refresh;
-4. a reviewed browser credential transport/storage threat model;
-5. organization membership and permission checks at every tenant-scoped route;
-6. all applicable DSAR contributors, export delivery expiry and backup restore/re-erasure procedure;
-7. content-redaction snapshots for logs, errors, analytics and audit events;
-8. automated feature and cross-feature user-journey E2E coverage including cleanup.
-
-## Verification
-
-Measured on 2026-08-18:
-
-- account password suite: 7 specs, 0 failures;
-- session suite: 10 specs, 0 failures;
-- one-time challenge suite: 5 specs, 0 failures;
-- privacy lifecycle suite: 7 specs, 0 failures;
-- privacy ledger suite: 5 specs, 0 failures;
-- complete package suite: 1,687 specs, 0 failures, 146 explicitly pending specs;
-- TypeScript build: passed;
-- changed-module ESLint: passed with zero warnings;
-- release tarball: local untracked `SKILLS.md` explicitly excluded by `.npmignore`;
-- package import validator: existing baseline, 82 findings in 76 files;
-- package naming validator: existing baseline, 101 findings in 68 files.
-
-The repository-wide convention findings predate this capability and are not represented as fixed. The new
-modules pass their direct compiler, lint and regression gates.

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

@@ -1,59 +0,0 @@
-# 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-bfr-ctm-018-content-free-endpoint-errors.md

@@ -1,54 +0,0 @@
-# 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,111 +0,0 @@
-# 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.
-
-## 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 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.