@futdevpro/nts-dynamo 1.15.151 → 1.15.154

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

@@ -1,46 +1,46 @@
-# 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.
+# 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 +1,82 @@
-# 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.
+# 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 +1,132 @@
-# 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.
+# 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.