fix: Tenant ID Filter Tightening - #141

framework/testing/CHANGELOG.md (1)

3-8: ⚠️ Potential issue | 🟠 Major

Same semantic versioning concern as in framework/common/CHANGELOG.md.

The "Encryptor required on redis and s3" entry carries the same semantic versioning concern as noted in the framework/common changelog review. If this makes a previously optional parameter mandatory, it should be a major version bump rather than a patch.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/testing/CHANGELOG.md` around lines 3 - 8, The changelog entry
"Encryptor required on redis and s3" under header "## 1.2.6" appears to describe
a breaking change (making an optional parameter mandatory); change the release
header from "## 1.2.6" to a major bump (e.g., "## 2.0.0") and mark the entry as
a Breaking Change (or move it to a "Breaking Changes" section), or alternatively
revise the entry to state that the encryptor remains optional if you intend a
patch—update the header and the entry text accordingly so the version and
wording correctly reflect whether the change is breaking.

blueprint/interfaces/worker/CHANGELOG.md (1)

3-20: Consider using more specific patch notes for traceability.

Entries like “upgrade packages” / “package bumps” make it harder to map release intent later. A short list of key bumped packages or affected modules would improve auditability.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@blueprint/interfaces/worker/CHANGELOG.md` around lines 3 - 20, The CHANGELOG
entries under headings like "## 1.0.13", "## 1.0.12", and "## 1.0.11" are too
generic ("upgrade packages", "package bumps"); update each release note to list
the specific packages or modules updated (e.g., package names and new versions),
include any important affected components or breaking changes, and optionally
reference PR/issue numbers for traceability so future readers can map intent to
changes.

blueprint/interfaces/billing/CHANGELOG.md (1)

3-20: Changelog format is consistent; consider adding concrete change detail.

The version blocks are correctly structured. Optional improvement: mention specific package/version deltas to make regressions easier to trace.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@blueprint/interfaces/billing/CHANGELOG.md` around lines 3 - 20, The changelog
entries for the version headers (e.g., "## 1.0.13", "## 1.0.12", "## 1.0.11")
are too generic; update each version block to list concrete changes by naming
the packages and their new versions (or the semver delta) and a short note on
impact (e.g., "bumped lodash 4.17.21 -> 4.17.22: patch security fix"), so
readers can trace regressions easily.

blueprint/billing-base/registrations.ts (1)

1-27: Reorder imports to match the required layering.

Line 1-27 places external dependencies (@mikro-orm/*) after Forklaunch framework imports. Please move external imports above the @forklaunch/* group.

♻️ Suggested import-order adjustment

+import { ForkOptions } from '@mikro-orm/core';
+import { EntityManager, MikroORM } from '@mikro-orm/postgresql';
 import {
   number,
   optional,
   schemaValidator,
   SchemaValidator,
   string
 } from '@forklaunch/blueprint-core';
 import { Metrics, metrics } from '@forklaunch/blueprint-monitoring';
 import { OpenTelemetryCollector } from '@forklaunch/core/http';
 import { FieldEncryptor } from '@forklaunch/core/persistence';
@@
-import { ForkOptions } from '@mikro-orm/core';
-import { EntityManager, MikroORM } from '@mikro-orm/postgresql';

As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, (4) Cross-module imports, (5) Local persistence, (6) Local domain, (7) Same directory".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@blueprint/billing-base/registrations.ts` around lines 1 - 27, Imports in
registrations.ts are out of the mandated layering: external packages
(`@mikro-orm/core`, `@mikro-orm/postgresql`) are listed after Forklaunch framework
imports; reorder imports so external dependencies appear before any
`@forklaunch/`* imports. Locate the import block at the top of registrations.ts
(symbols to find: imports of MikroORM, EntityManager, ForkOptions) and move
those external imports (e.g., from '@mikro-orm/core' and
'@mikro-orm/postgresql') up above the group of `@forklaunch/`* imports, keeping
the rest of the groups intact and preserving existing relative order within each
layer.

framework/infrastructure/redis/__test__/redisTtlCache.test.ts (1)

28-31: Add at least one encryption-enabled Redis round-trip test.

The cache instance at lines 28-31 sets disabled: true, so the encryption path is never exercised. Add a test with disabled: false to verify the encryption integration works end-to-end.

Example test addition

+  test('encryptor-enabled round trip', async () => {
+    const encryptedCache = new RedisTtlCache(
+      5000,
+      new OpenTelemetryCollector('test'),
+      { url: `redis://${container.getHost()}:${container.getMappedPort(6379)}` },
+      { enabled: true, level: 'info' },
+      {
+        encryptor: new FieldEncryptor('test-encryption-key-for-redis-tests'),
+        disabled: false
+      }
+    );
+
+    await encryptedCache.putRecord({ key: 'enc_key', value: { ok: true }, ttlMilliseconds: 1000 });
+    await expect(encryptedCache.readRecord('enc_key')).resolves.toMatchObject({
+      key: 'enc_key',
+      value: { ok: true }
+    });
+    await encryptedCache.disconnect();
+  });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/redis/__test__/redisTtlCache.test.ts` around lines
28 - 31, The current test uses FieldEncryptor with disabled: true so the
encryption path isn't exercised; add a new test in redisTtlCache.test.ts that
creates the cache with encryptor: new
FieldEncryptor('test-encryption-key-for-redis-tests') and disabled: false, then
perform an end-to-end round-trip: await cache.set('some-key', someValue, ttl)
and await cache.get('some-key') and assert the retrieved value equals the
original to verify encryption/decryption works; ensure the test cleans up
(flush/close) after itself.

framework/infrastructure/S3/__test__/s3ObjectStore.test.ts (1)

1-6: Normalize imports to node: prefix + required layer order.

Readable should be imported as a Node built-in (node:stream) and grouped before external/Forklaunch imports.

Suggested import normalization

+import { Readable } from 'node:stream';
+
 import { S3Client } from '@aws-sdk/client-s3';
+import { beforeEach, describe, expect, it, vi } from 'vitest';
+
 import { OpenTelemetryCollector } from '@forklaunch/core/http';
 import { FieldEncryptor } from '@forklaunch/core/persistence';
-import { Readable } from 'stream';
-import { beforeEach, describe, expect, it, vi } from 'vitest';
 import { S3ObjectStore } from '../index';

As per coding guidelines, “Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, (4) Cross-module imports, (5) Local persistence, (6) Local domain, (7) Same directory”.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/S3/__test__/s3ObjectStore.test.ts` around lines 1 -
6, Import ordering and source for Readable is incorrect: change the Readable
import to use the Node built-in with the node: prefix (import Readable from
'node:stream') and reorder imports so Node built-ins (Readable) come first, then
external deps (S3Client), then Forklaunch framework packages
(OpenTelemetryCollector, FieldEncryptor), and finally the local module import
(S3ObjectStore) to follow the project's 7-layer convention; update the import
statements around S3Client, OpenTelemetryCollector, FieldEncryptor, Readable,
and S3ObjectStore accordingly.

blueprint/iam-base/mikro-orm.config.ts (1)

1-15: Reorder imports to match the required layer sequence.

Current ordering places Forklaunch framework imports before external dependencies.

Suggested import ordering

-import { number, schemaValidator, string } from '@forklaunch/blueprint-core';
-
-import {
-  FieldEncryptor,
-  registerEncryptor
-} from '@forklaunch/core/persistence';
-import {
-  createConfigInjector,
-  getEnvVar,
-  Lifetime
-} from '@forklaunch/core/services';
 import { Migrator } from '@mikro-orm/migrations';
 import { defineConfig, Platform, TextType, Type } from '@mikro-orm/postgresql';
 import dotenv from 'dotenv';
+
+import { number, schemaValidator, string } from '@forklaunch/blueprint-core';
+import { FieldEncryptor, registerEncryptor } from '@forklaunch/core/persistence';
+import { createConfigInjector, getEnvVar, Lifetime } from '@forklaunch/core/services';
 import * as entities from './persistence/entities';

As per coding guidelines, “Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, (4) Cross-module imports, (5) Local persistence, (6) Local domain, (7) Same directory”.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@blueprint/iam-base/mikro-orm.config.ts` around lines 1 - 15, The import
statements in mikro-orm.config.ts are out of the mandated 7-layer order:
external deps should come before Forklaunch framework packages and local
persistence; reorder the imports so they follow the layers: (1) Node built-ins
(if any), (2) external dependencies (dotenv, `@mikro-orm/`*), (3) Forklaunch
framework packages (`@forklaunch/core/`* and `@forklaunch/blueprint-core`), (4)
cross-module imports (createConfigInjector, getEnvVar, Lifetime references), (5)
local persistence (import * as entities), (6) local domain, (7) same-directory;
specifically move dotenv and { defineConfig, Platform, TextType, Type } from
'@mikro-orm/postgresql' and { Migrator } into the external block above the
Forklaunch imports (number, schemaValidator, string; FieldEncryptor,
registerEncryptor; createConfigInjector, getEnvVar, Lifetime) and keep the
entities import in the local persistence block so the file adheres to the
required import-layer ordering.

framework/core/__test__/fieldEncryptor.test.ts (2)

86-91: Misleading test description.

The test description says "unknown version prefix" but the ciphertext 'v2:abc:def:ghi' uses the valid v2: prefix. The test is actually validating that malformed ciphertext structure (invalid base64 segments) throws DecryptionError, not an unknown version prefix. Consider updating the description for clarity.

📝 Proposed fix for test description

-  it('should throw DecryptionError for unknown version prefix', () => {
+  it('should throw DecryptionError for malformed ciphertext structure', () => {
     const enc = new FieldEncryptor(MASTER_KEY);
     expect(() => enc.decrypt('v2:abc:def:ghi', 'tenant-a')).toThrow(
       DecryptionError
     );
   });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/core/__test__/fieldEncryptor.test.ts` around lines 86 - 91, The
test description is misleading: update the it(...) description for the test that
constructs new FieldEncryptor(MASTER_KEY) and calls
enc.decrypt('v2:abc:def:ghi', 'tenant-a') to state that it expects a
DecryptionError for malformed ciphertext/invalid base64 segments rather than
"unknown version prefix"; keep the assertion and DecryptionError check unchanged
so the test verifies decrypt throws for invalid ciphertext structure.

---

39-45: Duplicate test case.

This test (lines 39-45) tests the same behavior as lines 23-29 — both verify that the same plaintext encrypted under different tenant IDs yields different ciphertext. Consider removing one to avoid redundant test coverage.

🧹 Proposed fix to remove duplicate test

-  it('should produce different ciphertext for same plaintext with different tenants', () => {
-    const enc = new FieldEncryptor(MASTER_KEY);
-    const plaintext = 'same-data';
-    const ct1 = enc.encrypt(plaintext, 'tenant-a');
-    const ct2 = enc.encrypt(plaintext, 'tenant-b');
-    expect(ct1).not.toBe(ct2);
-  });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/core/__test__/fieldEncryptor.test.ts` around lines 39 - 45, Remove
the duplicate test that validates different ciphertexts for the same plaintext
under different tenants: locate the second test block with the description
"should produce different ciphertext for same plaintext with different tenants"
that instantiates FieldEncryptor with MASTER_KEY and calls
enc.encrypt(plaintext, 'tenant-a') and enc.encrypt(plaintext, 'tenant-b') (this
duplicates the earlier test around lines 23-29) and delete that redundant
it(...) block so only one test asserting ct1 !== ct2 remains.

cli/src/core/ast/infrastructure/redis.rs (1)

72-80: No action required — FieldEncryptor and ENCRYPTION_KEY are properly injected by parent transformations.

The FieldEncryptor import and ENCRYPTION_KEY environment variable are not registered within the redis.rs module functions themselves. However, this is by design: both transform_service_to_worker.rs and transform_registrations_ts.rs handle these injections separately for non-database workers before or after calling the redis utilities. The generated TypeScript code correctly includes both the import statement and environment configuration.

To improve maintainability, consider documenting that redis_ttl_cache_runtime_dependency() relies on the parent transformation to provide these prerequisites, or refactor to make the function more self-contained.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@cli/src/core/ast/infrastructure/redis.rs` around lines 72 - 80, The redis
module currently assumes FieldEncryptor import and ENCRYPTION_KEY are injected
by parent transforms; update redis_ttl_cache_runtime_dependency (or the factory
that constructs RedisTtlCache) to explicitly document this prerequisite and/or
make it self-contained by accepting an encryptor or encryptionKey parameter
(e.g., add an optional encryptor/ encryptionKey argument to
redis_ttl_cache_runtime_dependency and pass it into the factory that creates new
RedisTtlCache) and update the function signature and callers
(transform_service_to_worker.rs and transform_registrations_ts.rs) to provide
the dependency if present.

cli/src/templates/project/service/mikro-orm.config.ts (1)

1-9: Reorder this import block to the standard 7 layers.

@mikro-orm/* and dotenv belong in the external-dependency layer and should come before the @forklaunch/* imports.

As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, (4) Cross-module imports, (5) Local persistence, (6) Local domain, (7) Same directory".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@cli/src/templates/project/service/mikro-orm.config.ts` around lines 1 - 9,
Reorder the import block to follow the 7-layer convention: place external
dependencies first (move imports for Migrator from '@mikro-orm/*', defineConfig
from '@mikro-orm/{{database}}', and dotenv) before the Forklaunch framework
imports; then keep Forklaunch framework packages (createConfigInjector,
getEnvVar, Lifetime from '@forklaunch/core/services' and
FieldEncryptor/registerEncryptor from '@forklaunch/core/persistence'); then
cross-module imports (number, SchemaValidator, string from
'@{{app_name}}/core'); followed by local persistence imports (import * as
entities from './persistence/entities'); ensure conditional imports like
Platform/TextType/Type remain in the same external layer when present, and
preserve relative ordering and blank lines between each of the 7 layers.

blueprint/billing-stripe/registrations.ts (1)

1-29: Reorder this import block to match the repo’s 7-layer convention.

@mikro-orm/* and stripe are external dependencies, so they should sit above the @forklaunch/* imports instead of below them.

As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, (4) Cross-module imports, (5) Local persistence, (6) Local domain, (7) Same directory".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@blueprint/billing-stripe/registrations.ts` around lines 1 - 29, Reorder the
import block to follow the repo’s 7-layer convention by moving external
dependencies (e.g., Stripe and `@mikro-orm/`* like Stripe from 'stripe' and {
ForkOptions } from '@mikro-orm/core' / { EntityManager, MikroORM } from
'@mikro-orm/postgresql') above the Forklaunch framework imports (those starting
with '@forklaunch/*'); keep the rest of the existing imports
(OpenTelemetryCollector, FieldEncryptor, ComplianceDataService,
createConfigInjector, StripeBillingPortalService, RedisTtlCache, etc.) in their
original relative order after the external deps so the file-level imports match
the repo guideline.

cli/src/templates/project/service/registrations.ts (2)

154-159: ENCRYPTION_KEY may be unused in some configurations.

Similar to the import, ENCRYPTION_KEY is always defined but only consumed when Redis cache, S3, or non-database workers are enabled. If none apply, this creates an unused config entry and requires an environment variable that won't be used.

Consider wrapping this configuration in the appropriate conditional blocks to avoid requiring unnecessary environment variables.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@cli/src/templates/project/service/registrations.ts` around lines 154 - 159,
ENCRYPTION_KEY is always registered via the ENCRYPTION_KEY binding
(Lifetime.Singleton, value: getEnvVar('ENCRYPTION_KEY')) even though it's only
needed when Redis cache, S3, or non-database workers are enabled; move or wrap
this registration in the same conditional blocks used for those features so the
container only defines ENCRYPTION_KEY when isRedisEnabled || isS3Enabled ||
isNonDbWorker (or equivalent flags) is true, ensuring
getEnvVar('ENCRYPTION_KEY') is only called/required when one of those features
is active.

---

12-13: Potential unused import in generated code.

FieldEncryptor is imported unconditionally but is only used when is_request_cache_needed, is_s3_enabled, or (is_worker && !is_database_worker) is true. If none of these conditions apply, the generated code will have an unused import.

Consider wrapping the import in a conditional:

{{`#is_encryption_needed`}}import { FieldEncryptor } from "@forklaunch/core/persistence";{{/is_encryption_needed}}

Where is_encryption_needed is derived from the relevant feature flags.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@cli/src/templates/project/service/registrations.ts` around lines 12 - 13, The
import of FieldEncryptor is unconditional in the template (registrations.ts) but
only used when request cache, S3, or worker-without-database features are
enabled; change the template to conditionally emit the import by adding a new
composite flag (e.g., is_encryption_needed) that is true when
is_request_cache_needed || is_s3_enabled || (is_worker && !is_database_worker),
then wrap the existing import line "import { FieldEncryptor } from
\"@forklaunch/core/persistence\";" in a mustache conditional block
({{`#is_encryption_needed`}}...{{/is_encryption_needed}}) so the import only
appears when FieldEncryptor is actually used.

framework/infrastructure/S3/index.ts (2)

116-124: Silent decryption failure may mask data corruption.

When decryption fails (e.g., wrong tenant key, corrupted ciphertext), the method silently returns the raw encrypted value. This could lead to downstream JSON parse errors or data integrity issues that are hard to diagnose.

Consider logging decryption failures or providing a configuration option to throw on decryption errors in non-production environments.

♻️ Proposed improvement

  private decryptBody(body: string): string {
    if (!this.encryptor || this.encryptionDisabled) return body;
    if (!isEncrypted(body)) return body;
    try {
      return this.encryptor.decrypt(body, getCurrentTenantId()) ?? body;
    } catch {
+     // Log decryption failure for debugging - this may indicate key mismatch or corruption
+     this.openTelemetryCollector.warn('S3 object decryption failed, returning raw value');
      return body;
    }
  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/S3/index.ts` around lines 116 - 124, The decryptBody
method currently swallows all decryption failures and returns the raw encrypted
payload; update decryptBody to catch errors from this.encryptor.decrypt and: 1)
log the error (including the tenant id from getCurrentTenantId() and the fact
the input was encrypted) using the module/logger used elsewhere so failures are
visible, and 2) make behavior configurable (e.g., an instance flag like
encryptionDisabled already exists or a new throwOnDecryptionError option) so in
non-production/tests the method re-throws the error instead of returning the raw
value; ensure you still check this.encryptor, encryptionDisabled, and
isEncrypted before attempting decryption and preserve the fallback to returning
body only when configured to do so.

---

154-160: ContentType mismatch: encrypted body stored as 'application/json'.

The body is now encrypted ciphertext (a string like v2:...), but ContentType is still set to 'application/json'. This is technically incorrect for encrypted data and could confuse debugging or S3 object inspection tools.

Consider using a custom content type or metadata to indicate encryption status.

♻️ Suggested fix

    const params: PutObjectCommandInput = {
      Bucket: this.bucket,
      Key: key,
      Body: body,
-     ContentType: 'application/json'
+     ContentType: this.encryptionDisabled ? 'application/json' : 'application/octet-stream',
+     Metadata: this.encryptionDisabled ? undefined : { encrypted: 'true' }
    };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/S3/index.ts` around lines 154 - 160, The S3 upload
currently sets ContentType to 'application/json' even though the body is
encrypted via encryptBody; update the PutObjectCommandInput construction in the
method that builds params (where encryptBody and const params are used) to
reflect encrypted content—e.g., set ContentType to a generic type like
'application/octet-stream' or a custom type such as
'application/vnd.<app>-encrypted' and add metadata flags (e.g., Metadata: {
encrypted: 'true', original-content-type: 'application/json' }) so callers and
tools know the object is encrypted and the original type is preserved.

framework/infrastructure/redis/index.ts (1)

87-102: Consistent with S3ObjectStore, but same silent failure concern.

The encryption/decryption helpers mirror the S3ObjectStore implementation, which is good for consistency. However, the same concern applies: silent decryption failures could mask issues.

Consider adding observability (logging/metrics) when decryption fails to aid debugging.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/redis/index.ts` around lines 87 - 102, The
decryptValue/encryptValue helpers currently swallow decryption errors; update
decryptValue (and optionally encryptValue) to emit observability when decryption
fails or when an unexpected condition occurs: capture the exception in
decryptValue and call the module logger/metrics (e.g., processLogger.error or a
provided logger/metrics client) with context including the function name
decryptValue, the tenant id from getCurrentTenantId(), and a safely redacted
snippet or indication of the value (use isEncrypted(value) to gate logging);
ensure you still return the original value on failure but record the error so
failures are observable. Reference encryptValue, decryptValue, isEncrypted,
encryptor, and getCurrentTenantId when locating the code to modify.

framework/core/__test__/complianceEventSubscriber.test.ts (1)

38-42: Consider isolating global encryptor state between tests.

registerEncryptor modifies module-level state (_encryptor). If other test files in the same test run also call registerEncryptor, there could be test pollution. Consider adding an afterEach or afterAll to reset the encryptor state, or exposing a clearEncryptor() helper for test cleanup.

♻️ Suggested cleanup pattern

+ import { registerEncryptor, clearEncryptor } from '../src/persistence/encryptedType';
+ // ... or add a clearEncryptor export if not available

  beforeEach(() => {
    const encryptor = new FieldEncryptor(MASTER_KEY);
    registerEncryptor(encryptor);
    encryptedType = new EncryptedType('string');
  });

+ afterEach(() => {
+   // Reset global state to prevent test pollution
+   registerEncryptor(undefined as any); // or clearEncryptor() if available
+ });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/core/__test__/complianceEventSubscriber.test.ts` around lines 38 -
42, Tests registerEncryptor in beforeEach which mutates module-level _encryptor
and can leak state across tests; add cleanup to reset that global after each
test by either calling an exported clearEncryptor() helper (implement and export
clearEncryptor that sets _encryptor = undefined) or invoking a provided reset
function in an afterEach/afterAll; update the test file (around the beforeEach
block where FieldEncryptor and EncryptedType are created) to call
clearEncryptor() in afterEach to isolate state between tests.

framework/core/src/persistence/encryptedType.ts (1)

153-169: Number deserialization could return NaN for corrupted data.

Number(value) returns NaN for non-numeric strings. If encrypted data is corrupted or decryption partially fails, this could silently produce NaN values in the application.

Consider adding validation:

♻️ Suggested validation

      case 'number':
-       return Number(value);
+       const num = Number(value);
+       if (Number.isNaN(num)) {
+         // Log warning for debugging
+         return null;
+       }
+       return num;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/core/src/persistence/encryptedType.ts` around lines 153 - 169, In
deserializeValue, when originalType === 'number' validate the parsed numeric
result instead of blindly returning Number(value); call Number(value), check for
isFinite/Number.isNaN (or Number.isFinite) and handle invalid parsing by
throwing or returning a safe fallback (e.g., null or the raw string) to avoid
silently producing NaN — update the number branch in deserializeValue to perform
this validation and return the chosen fallback or raise an error so callers
don't receive NaN.

framework/core/src/persistence/tenantFilter.ts (1)

37-42: Consider exporting setTenantContext middleware for automatic HTTP route protection.

The skip filtering behavior when args?.tenantId is falsy (lines 37-42) is intentional for startup, background jobs, and other non-request contexts. However, setTenantContext middleware in framework/core/src/http/middleware/request/tenantContext.middleware.ts is not exported from the http module's public API, so applications can't easily apply it to guarantee tenant context is set for protected/authenticated routes before queries execute.

For protected/authenticated routes, the middleware auto-returns 403 if tenantId is missing—preventing the fail-open scenario. Export this middleware and document its usage to ensure developers can leverage this built-in protection rather than manually managing tenant context in each handler.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/core/src/persistence/tenantFilter.ts` around lines 37 - 42, Export
the setTenantContext middleware from the http module's public API so
applications can easily apply it to protected routes; specifically, add a
re-export of the setTenantContext symbol (defined in
tenantContext.middleware.ts) from the http module's top-level/barrel export (the
http index that currently exposes middleware utilities) so consumers can import
it directly (e.g., from the http package) and apply it to authenticated routes
to auto-403 when args.tenantId is missing. Ensure the exported symbol name is
exactly setTenantContext and update any module export lists or index.ts/barrel
files accordingly.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

cli/src/core/ast/injections/inject_into_import_statement.rs (1)

32-32: Simplify string comparison by removing unnecessary Cow wrapping.

Both sides of the comparison are already &str, so the Cow::Borrowed wrapping adds noise without benefit.

♻️ Suggested simplification

-        if Cow::Borrowed(import.source.value.as_str()) != Cow::Borrowed(import_source_identifier) {
+        if import.source.value.as_str() != import_source_identifier {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@cli/src/core/ast/injections/inject_into_import_statement.rs` at line 32, The
comparison in inject_into_import_statement.rs uses unnecessary Cow::Borrowed
wrappers: replace the expression comparing
Cow::Borrowed(import.source.value.as_str()) !=
Cow::Borrowed(import_source_identifier) with a direct &str comparison between
import.source.value.as_str() and import_source_identifier (e.g.,
import.source.value.as_str() != import_source_identifier) so both sides are
plain &str values and the Cow wrapping is removed.

cli/src/release/manifest_generator.rs (1)

768-808: Consider logging a warning when compliance scanning fails during release.

The use of .ok().map() silently converts scan errors to None, resulting in compliance being omitted from the release manifest without any indication of failure. In contrast, cli/src/compliance/audit.rs (lines 98-105) logs a [WARN] message when scanning fails.

For a release workflow, silent omission of compliance data could mask issues that matter for compliance audits. Consider aligning the error handling with audit.rs:

♻️ Suggested change to add warning logging

-    // Scan compliance data from source code (never stored in manifest)
-    let compliance_data = scan_all_compliance(&modules_root).ok().map(
-        |(field_classifications, retention_policies)| {
+    // Scan compliance data from source code (never stored in manifest)
+    let compliance_data = match scan_all_compliance(&modules_root) {
+        Ok((field_classifications, retention_policies)) => {
             let compliance_config = manifest.compliance.as_ref();
             let mut entity_names: std::collections::BTreeSet<String> =
                 std::collections::BTreeSet::new();
             entity_names.extend(field_classifications.keys().cloned());
             entity_names.extend(retention_policies.keys().cloned());

             let entities: Vec<ReleaseEntityCompliance> = entity_names
                 .into_iter()
                 .map(|name| {
                     let fields = field_classifications
                         .get(&name)
                         .cloned()
                         .unwrap_or_default();
                     let retention = retention_policies.get(&name).map(|r| {
                         ReleaseRetentionConfig {
                             duration: r.duration.clone(),
                             action: r.action.clone(),
                         }
                     });
                     ReleaseEntityCompliance {
                         name,
                         fields,
                         retention,
                     }
                 })
                 .collect();

-            ReleaseComplianceData {
+            Some(ReleaseComplianceData {
                 entities,
                 data_residency: compliance_config
                     .map(|c| c.data_residency.clone())
                     .unwrap_or_default(),
                 secrets: compliance_config
                     .map(|c| c.secrets.clone())
                     .unwrap_or_default(),
-            }
-        },
-    );
+            })
+        }
+        Err(e) => {
+            eprintln!("[WARN] Failed to scan entity compliance metadata: {}", e);
+            None
+        }
+    };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@cli/src/release/manifest_generator.rs` around lines 768 - 808, The current
chain uses scan_all_compliance(&modules_root).ok().map(...) which silently
discards errors and omits compliance_data; change this to capture the Result
from scan_all_compliance and, on Err(e), emit a warning (e.g., tracing::warn! or
the crate's logger) that includes the error before proceeding so failures are
visible; keep the existing mapping logic for Ok((field_classifications,
retention_policies)) to construct ReleaseComplianceData and assign to
compliance_data, but ensure the Err branch logs the error and returns None (or
appropriate fallback) instead of swallowing it.