chore: mikroorm v7 migration - #122

blueprint/iam-better-auth/auth.ts (1)

163-169: Consider batching both persist operations into a single flush for atomicity.

Currently, two separate flush operations occur. If the first succeeds but the second fails, an orphaned organization could exist without a user association. Combining them ensures both are committed together or neither is.

Additionally, on line 169, since userEntity was retrieved via em.findOne, it's already managed—persist() is unnecessary; flush() alone suffices.

♻️ Suggested refactor to batch operations

-                await em.persist(organization).flush();
+                em.persist(organization);

                 // Update user with organization
                 const userEntity = await em.findOne(User, { id: user.id });
                 if (userEntity) {
                   userEntity.organization = organization;
-                  await em.persist(userEntity).flush();
+                  await em.flush();
                 }

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/auth.ts` around lines 163 - 169, Batch the two
database changes into a single transaction by removing the intermediate flush
and performing one flush after both the organization and user updates are
applied: create and attach the organization entity (organization), fetch the
User via em.findOne(User, { id: user.id }) to get the managed userEntity, set
userEntity.organization = organization, and then call a single em.flush() (or
em.persist([organization, userEntity]) then em.flush()) so both inserts/updates
are committed together; also drop the unnecessary em.persist(userEntity) call
because the result of em.findOne is already managed.

framework/core/__test__/baseEntity.partialUpdate.integration.test.ts (2)

52-79: Consider adding updatedAt assertion to verify the timestamp was refreshed.

The performUpdate helper sets updatedAt: new Date() on every update, but this test (and the next three) doesn't verify the timestamp was actually changed from the original 2024-01-01 value. Adding an assertion like expect(updatedUser.updatedAt).not.toEqual(new Date('2024-01-01')) would confirm the update semantics are working as intended.

🤖 Prompt for AI Agents

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

In `@framework/core/__test__/baseEntity.partialUpdate.integration.test.ts` around
lines 52 - 79, The test "should preserve all fields when updating only email" is
missing an assertion that updatedAt was refreshed; update the test to check the
returned entity's updatedAt (from performUpdate) is different than the original
Date('2024-01-01') and/or is a recent Date (e.g.,
expect(updatedUser.updatedAt).not.toEqual(new Date('2024-01-01'))), referencing
updatedUser.updatedAt and performUpdate to validate the timestamp change after
the update.

---

1-6: File naming may be misleading: this is a unit test, not an integration test.

The file is named *.integration.test.ts but uses mocks exclusively rather than actual database connections. Integration tests typically exercise real infrastructure. Consider renaming to baseEntity.partialUpdate.unit.test.ts or, if true integration coverage is desired, use setupTestORM from @forklaunch/testing`` to test against a real database.

🤖 Prompt for AI Agents

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

In `@framework/core/__test__/baseEntity.partialUpdate.integration.test.ts` around
lines 1 - 6, The test file is misnamed as an integration test but only uses
mocks; either rename the file to baseEntity.partialUpdate.unit.test.ts and keep
the current mocked setup (so it is discovered as a unit test), or convert the
test into a true integration test by replacing mocks with a real ORM setup using
setupTestORM from `@forklaunch/testing` and exercising em.findOneOrFail +
em.assign; update any imports and test-runner patterns as needed to reflect the
new filename or the real-ORM setup.

blueprint/implementations/iam/base/services/user.service.ts (1)

124-130: Drop id from these populate hints.

Primary keys are always selected, and MikroORM uses populate for relations or lazy scalar properties. id is redundant here, and in the ['id', '*'] cases the '*' hint already covers the relation-loading intent on its own. (mikro-orm.io)

Also applies to: 142-148, 171-173

🤖 Prompt for AI Agents

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

In `@blueprint/implementations/iam/base/services/user.service.ts` around lines 124
- 130, Remove the redundant 'id' entry from the populate hints passed to
MikroORM's findOne/find calls in user.service (the calls that use
this.mappers.UserMapper.entity and (em ?? this.em).findOne or similar methods),
e.g., change populate arrays like ['id', 'organization'] or ['id', '*'] to just
['organization'] or ['*'] (or simply '*' where appropriate); ensure all three
occurrences flagged in the review are updated so populate only contains
relations/lazy scalars and not the primary key.

blueprint/sample-worker/domain/mappers/sampleWorker.mappers.ts (2)

1-12: Import ordering does not follow coding guidelines.

External dependencies (@mikro-orm/core) should come before Forklaunch framework packages (@forklaunch/blueprint-core, @forklaunch/core).

As per coding guidelines: "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages..."

🔧 Suggested import reordering

+import { EntityManager, wrap } from '@mikro-orm/core';
 import {
   boolean,
   number,
   schemaValidator,
   string
 } from '@forklaunch/blueprint-core';
 import { requestMapper, responseMapper } from '@forklaunch/core/mappers';
-import { EntityManager, wrap } from '@mikro-orm/core';
 import {
   SampleWorkerEventRecord,
   type ISampleWorkerEventRecord
 } from '../../persistence/entities/sampleWorkerRecord.entity';

🤖 Prompt for AI Agents

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

In `@blueprint/sample-worker/domain/mappers/sampleWorker.mappers.ts` around lines
1 - 12, Reorder the import statements so external dependencies come before
Forklaunch packages: move the `@mikro-orm/core` import (EntityManager, wrap) above
the `@forklaunch/blueprint-core` and `@forklaunch/core` imports; keep the
SampleWorkerEventRecord and ISampleWorkerEventRecord import (from
'../../persistence/entities/sampleWorkerRecord.entity') after the framework
packages as a local import. Ensure the import groups are ordered: external
(`@mikro-orm/core`), framework (`@forklaunch/blueprint-core` and `@forklaunch/core`),
then local entities (SampleWorkerEventRecord, ISampleWorkerEventRecord).

---

22-28: Redundant createdAt/updatedAt initialization.

The sqlBaseProperties (from @forklaunch/blueprint-core) already defines onCreate hooks for createdAt and updatedAt fields that automatically set new Date(). Manually passing these values is unnecessary.

♻️ Proposed simplification

       return em.create(SampleWorkerEventRecord, {
         ...dto,
         processed: false,
-        retryCount: 0,
-        createdAt: new Date(),
-        updatedAt: new Date()
+        retryCount: 0
       });

🤖 Prompt for AI Agents

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

In `@blueprint/sample-worker/domain/mappers/sampleWorker.mappers.ts` around lines
22 - 28, The object passed to em.create in sampleWorker.mappers.ts is
redundantly initializing createdAt and updatedAt even though sqlBaseProperties
provides onCreate hooks to set those timestamps; remove the createdAt and
updatedAt properties from the em.create(...) call that constructs
SampleWorkerEventRecord and leave processed and retryCount initialization intact
so the hooks from sqlBaseProperties handle timestamps automatically.

blueprint/billing-stripe/persistence/entities/checkoutSession.entity.ts (1)

1-8: Import ordering does not follow coding guidelines.

External dependencies (stripe) should come before Forklaunch framework packages (@forklaunch/blueprint-core, @forklaunch/implementation-billing-stripe).

As per coding guidelines: "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages..."

🔧 Suggested import reordering

 import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
+import Stripe from 'stripe';
 import { sqlBaseProperties } from '@forklaunch/blueprint-core';
 import {
   CurrencyEnum,
   PaymentMethodEnum
 } from '@forklaunch/implementation-billing-stripe/enum';
-import Stripe from 'stripe';
 import { StatusEnum } from '../../domain/enum/status.enum';

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/persistence/entities/checkoutSession.entity.ts`
around lines 1 - 8, Reorder the imports in checkoutSession.entity.ts to follow
the 7-layer guideline: move external dependency import Stripe from 'stripe'
above the Forklaunch framework imports (sqlBaseProperties from
'@forklaunch/blueprint-core' and CurrencyEnum/PaymentMethodEnum from
'@forklaunch/implementation-billing-stripe/enum'), keeping StatusEnum and
Mikro-ORM imports in their appropriate layers; ensure import groups are
separated and ordered as External dependencies first, then Forklaunch framework
packages, so symbols like Stripe, sqlBaseProperties, CurrencyEnum,
PaymentMethodEnum, StatusEnum, and defineEntity/p are unaffected.

blueprint/billing-stripe/persistence/entities/paymentLink.entity.ts (1)

1-8: Move stripe into the external-import block.

stripe should be grouped with the other third-party imports above the @forklaunch/* imports instead of sitting between framework and local-domain 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 `@blueprint/billing-stripe/persistence/entities/paymentLink.entity.ts` around
lines 1 - 8, The import for Stripe is in the wrong group; move the line "import
Stripe from 'stripe'" into the external-dependencies block so it sits with other
third-party imports above the `@forklaunch/`* imports in paymentLink.entity.ts;
update the import ordering to follow the project 7-layer convention (external
dependencies before Forklaunch framework imports) so the Stripe symbol is
grouped with other external imports.

blueprint/implementations/billing/base/services/paymentLink.service.ts (1)

188-190: Keep mapper access out of services.

Lines 189, 204, and 219 couple service persistence directly to mapper internals (this.mappers.*.entity). Prefer injecting/using persistence entities or repositories at the service boundary instead.

As per coding guidelines, "Use mappers only in controllers to transform entities to DTOs for external API responses; never use mappers in service layers."

Also applies to: 203-205, 218-220

🤖 Prompt for AI Agents

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

In `@blueprint/implementations/billing/base/services/paymentLink.service.ts`
around lines 188 - 190, The service is directly referencing mapper internals
(e.g., this.mappers.PaymentLinkMapper.entity) when calling persistence methods
(this.em.upsert in paymentLink creation and similar calls around lines using
other mappers); remove mapper usage from the service by injecting the
appropriate persistence boundary (an Entity class or a repository/DAO) into the
service constructor and replace calls like
this.em.upsert(this.mappers.PaymentLinkMapper.entity, ...) with
this.em.upsert(PaymentLinkEntity, ...) or repository.upsert(...). Keep mappers
only for controller-level DTO transformations (e.g., use PaymentLinkMapper in
controllers), and update the service constructor and usages for any other
mappers referenced (e.g., the mappers used at the other occurrences) to use the
injected entity/repository instead.

blueprint/billing-stripe/domain/mappers/checkoutSession.mappers.ts (1)

1-4: Reorder imports to match repository layering.

External deps should come before Forklaunch framework imports in this file.

♻️ Suggested import order

-import { schemaValidator } from '@forklaunch/blueprint-core';
-import { requestMapper, responseMapper } from '@forklaunch/core/mappers';
 import { EntityManager, wrap } from '@mikro-orm/core';
 import Stripe from 'stripe';
+import { schemaValidator } from '@forklaunch/blueprint-core';
+import { requestMapper, responseMapper } from '@forklaunch/core/mappers';

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/domain/mappers/checkoutSession.mappers.ts` around
lines 1 - 4, The import block is not ordered per the 7-layer guideline: move
external dependencies before Forklaunch framework imports—specifically place
Stripe and `@mikro-orm/core` (EntityManager, wrap) import lines above the
'@forklaunch/...' imports (schemaValidator and requestMapper/responseMapper) so
the file imports read: external deps (Stripe, `@mikro-orm/core`), then Forklaunch
framework packages (`@forklaunch/`...), then any remaining local imports.

blueprint/implementations/billing/stripe/domain/types/plan.mapper.types.ts (1)

1-1: Remove unused EntityManager import.

EntityManager is imported but not used in this file. Only EntitySchema is referenced in the type definitions.

🧹 Suggested fix

-import { EntityManager, EntitySchema } from '@mikro-orm/core';
+import { EntitySchema } from '@mikro-orm/core';

🤖 Prompt for AI Agents

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

In `@blueprint/implementations/billing/stripe/domain/types/plan.mapper.types.ts`
at line 1, Remove the unused EntityManager import from the module import line so
only EntitySchema is imported from '@mikro-orm/core'; locate the import that
currently reads "import { EntityManager, EntitySchema } from '@mikro-orm/core';"
and change it to import only EntitySchema, and confirm there are no remaining
references to EntityManager in this file (plan.mapper.types.ts).

blueprint/implementations/billing/base/domain/types/paymentLink.mapper.types.ts (1)

1-1: Remove unused EntityManager import.

EntityManager is imported but not used in this type definition file. Only EntitySchema is needed here.

🧹 Proposed fix

-import { EntityManager, EntitySchema } from '@mikro-orm/core';
+import { EntitySchema } from '@mikro-orm/core';

🤖 Prompt for AI Agents

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

In
`@blueprint/implementations/billing/base/domain/types/paymentLink.mapper.types.ts`
at line 1, The file imports EntityManager and EntitySchema but only uses
EntitySchema; remove the unused EntityManager import from the import statement
so it reads only import { EntitySchema } from '@mikro-orm/core'; update any
linter/TS errors by saving the file and running the project's type/lint checks;
target the import line containing "EntityManager, EntitySchema" to perform this
cleanup.

blueprint/billing-stripe/domain/mappers/plan.mappers.ts (2)

54-55: Use API-oriented serialization instead of toPOJO() here.

toPOJO() is MikroORM's cache-oriented serializer: it keeps hidden properties and ignores populate/fields hints. In a responseMapper, that makes it easy to over-serialize provider/internal data compared with wrap(entity).toObject() or serialize(). I see the same swap in the other migrated response mappers too, so I'd update them consistently. (mikro-orm.io)

♻️ Proposed fix

-      const baseData = wrap(entity).toPOJO();
+      const baseData = wrap(entity).toObject();

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/domain/mappers/plan.mappers.ts` around lines 54 -
55, The toDto response mapper is using MikroORM's cache-oriented serializer via
wrap(entity).toPOJO(), which can over-serialize hidden/provider data; change
that to use the API-oriented serializer (e.g. wrap(entity).toObject() or
entity.serialize()) in the toDto implementation (the async toDto function that
currently does const baseData = wrap(entity).toPOJO()) and update the same
pattern in other response mappers to ensure populate/fields hints and hidden
properties are respected.

---

3-5: Reorder the external imports above the Forklaunch packages.

@mikro-orm/core and stripe belong in the external-dependency layer, so they should be grouped before the @forklaunch/* imports in this file.
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/domain/mappers/plan.mappers.ts` around lines 3 - 5,
Reorder the import groups so external dependencies come before internal
Forklaunch packages: move the imports for EntityManager and wrap from
'@mikro-orm/core' and Stripe from 'stripe' above the import of Plan and IPlan
(from '../../persistence/entities/plan.entity'); ensure imports for
EntityManager, wrap, Stripe appear in the external-dependency section and the
Plan/IPlan import remains in the local persistence section to follow the 7-layer
ordering.

blueprint/billing-base/domain/mappers/billingPortal.mappers.ts (1)

3-7: Move the external import block above @forklaunch/*.

@mikro-orm/core should sit before the Forklaunch packages here to match the repository's import-layering rule.
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/domain/mappers/billingPortal.mappers.ts` around lines
3 - 7, The import ordering violates the repository layering rule: move the
external dependency import "import { EntityManager, wrap } from
'@mikro-orm/core';" above the Forklaunch package imports so external deps come
before "@forklaunch/*" packages; update the top of the file so the
EntityManager/wrap import appears first, followed by the BillingPortal and
IBillingPortal import lines (referencing the symbols EntityManager, wrap,
BillingPortal, IBillingPortal to locate the change).

blueprint/billing-base/domain/mappers/paymentLink.mappers.ts (1)

3-7: Reorder the imports to keep external deps above @forklaunch/*.

The new @mikro-orm/core import is currently in the Forklaunch layer instead of the external-dependency layer.
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/domain/mappers/paymentLink.mappers.ts` around lines 3
- 7, Reorder the top imports in paymentLink.mappers.ts so external dependencies
(e.g., the `@mikro-orm/core` import that provides EntityManager and wrap) appear
above any Forklaunch or framework imports and before local persistence imports;
specifically move the "import { EntityManager, wrap } from '@mikro-orm/core';"
to the external-deps group above the import of PaymentLink and IPaymentLink from
'../../persistence/entities/paymentLink.entity' so the file follows the 7-layer
import ordering.

blueprint/iam-base/domain/mappers/permission.mappers.ts (1)

3-7: Move the external import block above @forklaunch/*.

The new @mikro-orm/core import should be grouped before the Forklaunch packages to keep the file in the repo's 7-layer import order.
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/domain/mappers/permission.mappers.ts` around lines 3 - 7,
Reorder the imports so external packages (e.g., import { EntityManager, wrap }
from '@mikro-orm/core') appear before any `@forklaunch/`* framework imports to
follow the repo's 7-layer ordering; specifically move the '@mikro-orm/core'
import block above the Forklaunch package imports and keep the local persistence
import (Permission, IPermission from
'../../persistence/entities/permission.entity') in its current local-persistence
position. Ensure EntityManager and wrap remain imported from '@mikro-orm/core'
and Permission/IPermission remain from
'../../persistence/entities/permission.entity'.

cli/src/core/static_analysis/mapper_generator.rs (1)

118-119: Generate DTO serializers, not cache snapshots.

MikroORM documents toPOJO() as the cache-oriented representation: it keeps hidden properties and ignores populate/fields hints. Baking that into every generated response mapper will silently widen generated API payloads as entities evolve. (mikro-orm.io)

Suggested template change

-    toDto: async (entity: I{}{}) => {{
-      return wrap(entity).toPOJO();
+    toDto: async (entity: I{}{}) => {{
+      return wrap(entity).serialize();
     }}

🤖 Prompt for AI Agents

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

In `@cli/src/core/static_analysis/mapper_generator.rs` around lines 118 - 119, The
generated mapper currently returns the MikroORM cache snapshot via
wrap(entity).toPOJO() inside the toDto function; replace that with a
serialization method that produces DTOs (e.g. wrap(entity).toObject() or
entity.toJSON()) so population/field hints and hidden/private properties are
respected and you don't bake cache internals into responses; update the toDto
implementation (symbol: toDto) to call wrap(entity).toObject() (or equivalent
with appropriate options) and return that result instead of toPOJO().

blueprint/billing-stripe/persistence/entities/billingPortal.entity.ts (1)

1-3: Import ordering: External dependencies should precede @forklaunch packages.

Per coding guidelines, external dependencies (layer 2) should come before Forklaunch framework packages (layer 3). The stripe import should be moved up.

♻️ Reorder imports

 import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
+import Stripe from 'stripe';
 import { sqlBaseProperties } from '@forklaunch/blueprint-core';
-import Stripe from 'stripe';

As per coding guidelines: "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages..."

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/persistence/entities/billingPortal.entity.ts` around
lines 1 - 3, The imports in billingPortal.entity.ts are out of the prescribed
order: move the external Stripe import (Stripe) above the Forklaunch package
import (sqlBaseProperties from '@forklaunch/blueprint-core') so external
dependencies come before framework packages; preserve the existing imports for
defineEntity, p, InferEntity and keep single-line imports unchanged otherwise so
only the import ordering is altered.

blueprint/iam-base/domain/mappers/role.mappers.ts (1)

14-18: Manual timestamps may be redundant with sqlBaseProperties hooks.

The sqlBaseProperties defines onCreate hooks for both createdAt and updatedAt. Setting them manually here is redundant for creation, though not harmful. Consider removing the manual assignment for consistency with other entity creation patterns that rely on the hooks.

♻️ Optional: Remove redundant timestamp assignment

      return em.create(Role, {
-        ...dto,
-        createdAt: new Date(),
-        updatedAt: new Date()
+        ...dto
      });

🤖 Prompt for AI Agents

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

In `@blueprint/iam-base/domain/mappers/role.mappers.ts` around lines 14 - 18, The
em.create call for Role is manually setting createdAt and updatedAt which
duplicates the sqlBaseProperties onCreate hooks; remove the explicit createdAt
and updatedAt properties from the object passed to em.create in role.mappers.ts
(leave ...dto) so the sqlBaseProperties onCreate handlers set those timestamps
automatically, ensuring consistency with other entity creation patterns using
Role and the existing onCreate hooks.

blueprint/iam-better-auth/domain/mappers/organization.mappers.ts (1)

1-10: Import ordering: External dependencies should precede @forklaunch packages.

Per coding guidelines, @mikro-orm/core (layer 2) should come before @forklaunch/blueprint-core and @forklaunch/core (layer 3).

♻️ Reorder imports

+import { EntityManager, wrap } from '@mikro-orm/core';
 import { schemaValidator } from '@forklaunch/blueprint-core';
 import { requestMapper, responseMapper } from '@forklaunch/core/mappers';
-import { EntityManager, wrap } from '@mikro-orm/core';
 import { OrganizationStatus } from '../../domain/enum/organizationStatus.enum';

As per coding guidelines: "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages..."

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/domain/mappers/organization.mappers.ts` around
lines 1 - 10, The import block violates the project's import-order rule:
external packages must come before `@forklaunch` packages; reorder the imports so
that external dependency imports (e.g., EntityManager, wrap from
`@mikro-orm/core`) appear before the `@forklaunch` packages (schemaValidator from
'@forklaunch/blueprint-core' and requestMapper/responseMapper from
'@forklaunch/core/mappers'); keep related local imports together
(OrganizationStatus, Organization, IOrganization, OrganizationSchemas,
UserMapper) and preserve existing named imports (EntityManager, wrap,
schemaValidator, requestMapper, responseMapper, OrganizationStatus,
Organization, IOrganization, OrganizationSchemas, UserMapper) so only the
grouping/order changes.

blueprint/billing-stripe/persistence/entities/plan.entity.ts (1)

1-8: Import ordering: External dependencies should precede @forklaunch packages.

Per coding guidelines, stripe (layer 2) should come before @forklaunch/blueprint-core and @forklaunch/implementation-billing-stripe (layers 3-4).

♻️ Reorder imports

 import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
+import Stripe from 'stripe';
 import { sqlBaseProperties } from '@forklaunch/blueprint-core';
 import {
   BillingProviderEnum,
   CurrencyEnum,
   PlanCadenceEnum
 } from '@forklaunch/implementation-billing-stripe/enum';
-import Stripe from 'stripe';

As per coding guidelines: "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages..."

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/persistence/entities/plan.entity.ts` around lines 1
- 8, Reorder the imports so external dependency Stripe comes before the
`@forklaunch` packages: move the "import Stripe from 'stripe';" line above the
imports from '@mikro-orm/core', '@forklaunch/blueprint-core', and
'@forklaunch/implementation-billing-stripe/enum'; keep the grouped imports
(defineEntity, p, InferEntity), sqlBaseProperties, and the enums
(BillingProviderEnum, CurrencyEnum, PlanCadenceEnum) together and unchanged
otherwise to satisfy the layer ordering rule.

blueprint/iam-base/persistence/entities/organization.entity.ts (1)

1-4: Import ordering: Local persistence should precede local domain.

Per coding guidelines, local persistence (layer 5) should come before local domain (layer 6). The User entity import should precede the OrganizationStatus enum import.

♻️ Reorder imports

 import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
 import { sqlBaseProperties } from '@forklaunch/blueprint-core';
-import { OrganizationStatus } from '../../domain/enum/organizationStatus.enum';
 import { User } from './user.entity';
+import { OrganizationStatus } from '../../domain/enum/organizationStatus.enum';

As per coding guidelines: "Organize imports in 7 layers: ... (5) Local persistence, (6) Local domain..."

🤖 Prompt for AI Agents

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

In `@blueprint/iam-base/persistence/entities/organization.entity.ts` around lines
1 - 4, Reorder the imports so local persistence comes before local domain: move
the User import (symbol: User from './user.entity') to appear before the
OrganizationStatus import (symbol: OrganizationStatus from
'../../domain/enum/organizationStatus.enum'); ensure the other imports
(defineEntity, p, InferEntity and sqlBaseProperties) remain in their current
relative positions and update only the import order to match the 7-layer
convention.

blueprint/billing-base/persistence/entities/paymentLink.entity.ts (1)

13-13: ⚠️ Potential issue | 🔴 Critical

Add .array() to the paymentMethods enum field.

The paymentMethods field is defined as a scalar enum, but the seed data (paymentMethods: [PaymentMethodEnum.CREDIT_CARD]) and the Stripe variant (blueprint/billing-stripe/persistence/entities/paymentLink.entity.ts at line 15) both expect it to be an array. This mismatch will cause serialization failures.

🐛 Proposed fix

-    paymentMethods: p.enum(() => PaymentMethodEnum),
+    paymentMethods: p.enum(() => PaymentMethodEnum).array(),

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/persistence/entities/paymentLink.entity.ts` at line
13, The paymentMethods field in paymentLink.entity.ts is defined as a scalar
enum (paymentMethods: p.enum(() => PaymentMethodEnum)) but should be an array to
match seed data and the Stripe variant; change the field to use .array(), i.e.
paymentMethods: p.enum(() => PaymentMethodEnum).array(), and verify any
associated type annotations or serializers that consume PaymentMethodEnum arrays
still accept an array shape.

cli/src/templates/router/domain/mappers/{{camel_case_name}}.mappers.ts (1)

6-8: ⚠️ Potential issue | 🔴 Critical

Worker template still references em without importing or receiving it.

In the is_worker branch, the EntityManager import is excluded (line 7) and the em parameter is removed from toEntity (line 17), but em.create(...) is still called on line 18. Generated worker mappers will fail to compile.

🛠️ Proposed fix - Option 1: Always include EntityManager

 import {
   requestMapper,
   responseMapper
 } from '@forklaunch/core/mappers';
 import { schemaValidator } from '@{{app_name}}/core';
-import { wrap } from '@mikro-orm/core';{{^is_worker}}
-import { EntityManager } from '@mikro-orm/{{database}}';{{/is_worker}}
+import { wrap } from '@mikro-orm/core';
+import { EntityManager } from '@mikro-orm/{{database}}';
 import { {{camel_case_name}}{{`#is_worker`}}Event{{/is_worker}}Record, type {{pascal_case_name}}{{`#is_worker`}}Event{{/is_worker}}Record } from '../../persistence/entities/{{camel_case_name}}{{`#is_worker`}}Event{{/is_worker}}Record.entity';
 import { {{pascal_case_name}}RequestSchema, {{pascal_case_name}}ResponseSchema } from '../schemas/{{camel_case_name}}.schema';

And update the function signature:

-    toEntity: async (dto{{^is_worker}}, em: EntityManager{{/is_worker}}) => {
+    toEntity: async (dto, em: EntityManager) => {

Also applies to: 17-24

🤖 Prompt for AI Agents

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

In `@cli/src/templates/router/domain/mappers/`{{camel_case_name}}.mappers.ts
around lines 6 - 8, The worker template's mapper still calls em.create(...) but
the EntityManager import and em parameter were removed in the is_worker branch,
causing compile failures; fix by either re-introducing the EntityManager import
and adding an EntityManager parameter (em) to the toEntity function signature so
em.create(...) is valid, or modify toEntity to construct the
{{camel_case_name}}Record directly (e.g., new {{camel_case_name}}Record(...))
and stop using em; update the import for {{camel_case_name}}Record and the
toEntity function in the {{camel_case_name}}.mappers.ts template accordingly so
the worker build compiles.

blueprint/sample-worker/mikro-orm.config.ts (1)

58-58: ⚠️ Potential issue | 🟠 Major

forceUtcTimezone: false remains risky here.

This is the same unresolved timezone-handling concern previously flagged for this file.

MikroORM v7 docs: is forceUtcTimezone enabled by default, and what does setting false change?

🤖 Prompt for AI Agents

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

In `@blueprint/sample-worker/mikro-orm.config.ts` at line 58, The config currently
sets forceUtcTimezone: false which risks inconsistent timezone handling; change
it to forceUtcTimezone: true (or remove the explicit setting to rely on MikroORM
v7 default if you confirm the default is UTC) inside the exported config object
in mikro-orm.config.ts, and add a brief comment referencing the MikroORM v7 docs
about UTC behavior so the choice is explicit and verifiable.

blueprint/iam-better-auth/persistence/entities/organization.entity.ts (1)

14-14: ⚠️ Potential issue | 🟠 Major

Restore uniqueness on subscription to preserve data integrity.

subscription lost its uniqueness constraint here, which allows duplicate external subscription IDs across organizations.

Suggested fix

-    subscription: p.string(),
+    subscription: p.string().unique(),

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/persistence/entities/organization.entity.ts` at
line 14, The subscription field on the Organization entity lost its uniqueness
constraint; update the organization entity so the subscription property is
declared as unique again (e.g., change subscription: p.string() to subscription:
p.string().unique() or add unique: true depending on the schema builder used) in
organization.entity.ts, and regenerate/apply the corresponding migration so the
DB enforces uniqueness for external subscription IDs.

blueprint/billing-base/persistence/entities/checkoutSession.entity.ts (1)

13-13: ⚠️ Potential issue | 🟠 Major

paymentMethods should be persisted as an enum array, not a scalar.

Line 13 defines paymentMethods as a single enum value, but the base seed data and Stripe checkout session entity both use an array shape. This creates inconsistent persistence/type behavior across implementations.

🐛 Proposed fix

-    paymentMethods: p.enum(() => PaymentMethodEnum),
+    paymentMethods: p.enum(() => PaymentMethodEnum).array(),

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/persistence/entities/checkoutSession.entity.ts` at
line 13, paymentMethods is currently defined as a scalar enum but must be stored
as an array to match seed data and Stripe entity; update the field definition
for paymentMethods to use the ORM's enum-array construct (e.g., the array
wrapper for p.enum) so it persists an array of PaymentMethodEnum values, and
adjust any TypeScript typing or entity validators to reflect
PaymentMethodEnum[]; locate the paymentMethods property and replace the scalar
enum usage with the enum-array form referencing PaymentMethodEnum.

framework/ws/CHANGELOG.md (1)

17-17: Normalize changelog wording for clarity/searchability.

Consider standardizing this line to match proper product naming and imperative style (e.g., “Update packages and migrate to MikroORM v7”).

🤖 Prompt for AI Agents

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

In `@framework/ws/CHANGELOG.md` at line 17, Change the changelog entry "update
packages and update to mikro orm v7" to standardized, imperative and properly
capitalized wording such as "Update packages and migrate to MikroORM v7" so
product name and intent are clear and searchable; locate the exact changelog
line text and replace it with the updated phrasing.

framework/ws/package.json (1)

48-48: Be cautious with the @typescript/native-preview dev build.

The pinned version 7.0.0-dev.20260316.1 is a pre-release package published on 2026-03-16. While exact pinning prevents instability, this dev version may introduce breaking changes or bugs. Verify that CI/build pipelines remain stable with this package before merging.

🤖 Prompt for AI Agents

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

In `@framework/ws/package.json` at line 48, The dependency
"@typescript/native-preview": "7.0.0-dev.20260316.1" is a pre-release dev build
and may introduce instability; update the package.json entry (the
"@typescript/native-preview" dependency) to either a stable release or a less
rigid spec (e.g., point to the official stable semver or use a caret/tilde)
and/or add a CI check that runs full build/tests against this version before
merging so the pipeline confirms no breakages; alternatively, pin this dev build
in a separate branch or document the risk in the PR so maintainers explicitly
approve using this pre-release.

framework/express/CHANGELOG.md (2)

17-17: Use consistent capitalization for "MikroORM".

The proper product name is "MikroORM" (with capital M and O). The file contains inconsistent references: "mikro orm" (line 17), "mikroorm" (line 40), and "mikro-orm" (line 89). Using the correct capitalization improves professionalism and clarity.

📝 Suggested fix

-- update packages and update to mikro orm v7
+- update packages and update to MikroORM v7

🤖 Prompt for AI Agents

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

In `@framework/express/CHANGELOG.md` at line 17, The CHANGELOG entry uses
inconsistent capitalization for the product name (e.g., "mikro orm", "mikroorm",
"mikro-orm"); update all occurrences to the correct product casing "MikroORM"
(replace each literal instance of "mikro orm", "mikroorm", and "mikro-orm" with
"MikroORM") so the changelog is consistent and professional.

---

7-7: Consider adding more specific details to the changelog entry.

The description "package upgrades" is generic. Users benefit from more specific information about what was upgraded or why, especially if there are breaking changes or important improvements.

🤖 Prompt for AI Agents

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

In `@framework/express/CHANGELOG.md` at line 7, The changelog entry "package
upgrades" is too vague—replace that single line with a brief bulleted list under
the same entry explaining which packages were upgraded and their new versions
(e.g., rails 6.1.4 → 6.1.5), call out any breaking changes or required
migrations, include links or PR/commit references for each upgrade and note any
important behavioral or performance improvements; update the header or
subheading around the "package upgrades" line so readers can quickly see scope
and impact.

blueprint/implementations/worker/database/consumers/databaseWorker.consumer.ts (1)

1-7: Reorder imports to match the repository layering rule.

Line 7 places an external dependency after Forklaunch imports; move @mikro-orm/core above @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
`@blueprint/implementations/worker/database/consumers/databaseWorker.consumer.ts`
around lines 1 - 7, Reorder the import groups so external packages come before
Forklaunch packages: move the `@mikro-orm/core` import (EntityManager, EntityName)
above the `@forklaunch` imports; keep WorkerConsumer, WorkerEventEntity,
WorkerFailureHandler, and WorkerProcessFunction imports together after the
external dependency to satisfy the 7-layer rule.

cli/src/core/static_analysis/mapper_generator.rs (1)

312-321: Tests updated correctly, consider adding assertions for new patterns.

The tests are correctly updated with the database parameter. Consider adding assertions to verify the MikroORM v7 specific patterns:

• entity: userRecord (entity constant usage)
• wrap(entity).toPOJO() (new POJO conversion)
• @mikro-orm/postgresql (database-specific import)

Example additional assertions

assert!(result.contains("entity: userRecord"));
assert!(result.contains("wrap(entity).toPOJO()"));
assert!(result.contains("@mikro-orm/postgresql"));

🤖 Prompt for AI Agents

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

In `@cli/src/core/static_analysis/mapper_generator.rs` around lines 312 - 321, The
test for MapperGenerator::generate_mapper_file was updated for the database
parameter but is missing assertions for MikroORM v7 patterns; update the test
(around the MapperGenerator::new / generate_mapper_file usage and the result
variable) to also assert that the generated output contains the entity constant,
POJO conversion, and DB-specific import by adding assertions that
result.contains("entity: userRecord"), result.contains("wrap(entity).toPOJO()"),
and result.contains("@mikro-orm/postgresql").

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

1-12: Reorder imports to match repository layer ordering.

Lines 1-12 currently place Forklaunch imports before external dependencies. Move external imports (@mikro-orm/*, dotenv) above @forklaunch/* imports.

♻️ Proposed import reorder

-import { number, schemaValidator, string } from '@forklaunch/blueprint-core';
-import {
-  createConfigInjector,
-  getEnvVar,
-  Lifetime
-} from '@forklaunch/core/services';
 import { Migrator } from '@mikro-orm/migrations';
 // import { MongoDriver } from '@mikro-orm/mongodb';
 // import { MySqlDriver } from '@mikro-orm/mysql';
 import { Platform, TextType, Type } from '@mikro-orm/core';
 import { defineConfig } from '@mikro-orm/postgresql';
 import dotenv from 'dotenv';
 // import { SqliteDriver } from '@mikro-orm/sqlite';
+import { number, schemaValidator, string } from '@forklaunch/blueprint-core';
+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-better-auth/mikro-orm.config.ts` around lines 1 - 12, Reorder
the import block so external dependencies come before Forklaunch packages: move
imports from "@mikro-orm/core", "@mikro-orm/postgresql",
"@mikro-orm/migrations", and "dotenv" above the imports from
"@forklaunch/blueprint-core" and "@forklaunch/core/services"; keep the existing
import specifiers (Platform, TextType, Type, defineConfig, Migrator, dotenv) and
retain the Forklaunch imports (number, schemaValidator, string,
createConfigInjector, getEnvVar, Lifetime) together after the external group to
follow the repository's 7-layer ordering.

blueprint/implementations/iam/base/domain/types/user.mapper.types.ts (1)

10-10: Consider stronger typing for EntitySchema<any>.

The entity: EntitySchema<any> field uses any, which loses type safety. Consider parameterizing this with the mapper's entity type for stronger compile-time guarantees:

 export type UserMappers<
   MapperEntities extends UserEntities,
   MapperDomains extends UserDtos
 > = {
   UserMapper: {
-    entity: EntitySchema<any>;
+    entity: EntitySchema<MapperEntities['UserMapper']>;
     toDto: (
       entity: MapperEntities['UserMapper']
     ) => Promise<MapperDomains['UserMapper']>;
   };
   // ... similar changes for other mappers
 };

This would ensure the entity field matches the entity type used in toDto/toEntity methods. However, if EntitySchema constraints make this impractical, the current approach is acceptable.

Also applies to: 16-16, 24-24

🤖 Prompt for AI Agents

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

In `@blueprint/implementations/iam/base/domain/types/user.mapper.types.ts` at line
10, The field declaration entity: EntitySchema<any> in user.mapper.types.ts is
too loose; update the type to parameterize EntitySchema with the mapper's
concrete entity type (e.g., EntitySchema<TEntity> or a generic type parameter on
the mapper interface) so the entity field aligns with the types used by
toDto/toEntity; adjust the mapper type definition (and any generic type
parameters on the mapper interface/class) so the same TEntity is used for
EntitySchema<T> and the toDto/toEntity signatures, or if EntitySchema
constraints prevent this, add a constrained generic or type alias to improve
safety while preserving compatibility.

blueprint/iam-base/persistence/entities/permission.entity.ts (1)

1-2: Import order should follow coding guidelines.

External dependencies should be imported before forklaunch packages. As per coding guidelines: "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages..."

♻️ Suggested fix

-import { sqlBaseProperties } from '@forklaunch/blueprint-core';
-import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
+import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
+import { sqlBaseProperties } from '@forklaunch/blueprint-core';

🤖 Prompt for AI Agents

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

In `@blueprint/iam-base/persistence/entities/permission.entity.ts` around lines 1
- 2, The import order is reversed: move external dependencies before forklaunch
packages so imports follow the 7-layer guideline; specifically reorder the two
imports so the '@mikro-orm/core' import (defineEntity, p, InferEntity) appears
above the '@forklaunch/blueprint-core' import (sqlBaseProperties), preserving
the same imported symbols and formatting in permission.entity.ts.

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

24-26: Import placement should follow the repository layering convention.

Move these external MikroORM imports into the external dependency layer (before Forklaunch framework 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 `@blueprint/billing-stripe/registrations.ts` around lines 24 - 26, The MikroORM
imports (ForkOptions, EntityManager, MikroORM) and other external packages like
Stripe should be reordered into the external dependency layer before any
Forklaunch framework imports; update the import block in registrations.ts so
that imports for ForkOptions, EntityManager, MikroORM, and Stripe appear with
the other external dependencies (layer 2) ahead of any Forklaunch framework
package imports to conform to the 7-layer import ordering convention.

blueprint/sample-worker/mikro-orm.config.ts (1)

1-11: Import layering is out of order.

Please place external dependencies before Forklaunch package imports in this file.

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/sample-worker/mikro-orm.config.ts` around lines 1 - 11, The imports
in mikro-orm.config.ts are layered incorrectly; reorder them so external
dependencies come before Forklaunch packages and local persistence is in its
proper layer: move dotenv and all `@mikro-orm/`* and `@mikro-orm/postgresql` and
`@mikro-orm/migrations` and Platform/TextType/Type imports to the
external-dependencies block at the top, then place the Forklaunch imports
(createConfigInjector, getEnvVar, Lifetime from '@forklaunch/core/services' and
number/schemaValidator/string from '@forklaunch/blueprint-core') after them, and
keep the local persistence import (import * as entities from
'./persistence/entities') in its local persistence layer; ensure import grouping
follows the seven-layer guideline and no lines are removed, only reordered.

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

1-7: Reorder imports to match repository layering rules.

Current import order mixes Forklaunch and external layers; please group by the mandated 7-layer sequence.

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 - 7,
Reorder the imports in mikro-orm.config.ts to follow the 7-layer rule: place
Node built-ins first (none here), then external deps (dotenv,
`@mikro-orm/`{{database}},
`@mikro-orm/migrations`{{`#is_mongo`}}-mongodb{{/is_mongo}}, and if present
`@mikro-orm/core`), then Forklaunch framework packages (createConfigInjector,
getEnvVar, Lifetime from '@forklaunch/core/services'), then cross-module imports
(number, SchemaValidator, string from '@{{app_name}}/core'), then local
persistence (import * as entities from './persistence/entities'), followed by
local domain and same-directory (none here); ensure you keep existing named
symbols (createConfigInjector, getEnvVar, Lifetime, Migrator, SchemaValidator,
defineConfig, dotenv, entities) and only change ordering, not the import text
itself.

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

1-14: Please align imports with the required 7-layer order.

This segment currently mixes layer ordering (Forklaunch packages before externals).

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/mikro-orm.config.ts` around lines 1 - 14, The import
statements in mikro-orm.config.ts are out of the project's 7-layer order;
reorder them so external dependencies (e.g., dotenv, `@mikro-orm/`*,
`@mikro-orm/postgresql`, `@mikro-orm/core`) appear before Forklaunch framework
packages (e.g., `@forklaunch/core/services`, `@forklaunch/blueprint-core`), then
cross-module imports, then local persistence imports (./persistence/entities).
Adjust the current import block to place dotenv and all `@mikro-orm` imports
first, then createConfigInjector/getEnvVar/Lifetime and
number/schemaValidator/string, and finally the local entities import so the file
adheres to the required layer order.

blueprint/iam-base/persistence/entities/organization.entity.ts (1)

1-2: Import layers are out of order.

Place external dependencies before Forklaunch package imports.

♻️ Suggested import order

-import { sqlBaseProperties } from '@forklaunch/blueprint-core';
 import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
+import { sqlBaseProperties } from '@forklaunch/blueprint-core';

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/persistence/entities/organization.entity.ts` around lines
1 - 2, The imports are ordered incorrectly: place external dependencies before
Forklaunch package imports by moving the '@mikro-orm/core' import above
'@forklaunch/blueprint-core'; update the import section so external symbols
(defineEntity, p, InferEntity) are imported first and then sqlBaseProperties
from '@forklaunch/blueprint-core' follows—ensure you reference the existing
identifiers (defineEntity, p, type InferEntity, sqlBaseProperties) so the module
resolution and usage in organization.entity.ts remain unchanged.

blueprint/implementations/iam/base/services/organization.service.ts (1)

1-15: Import order should place external dependencies before Forklaunch packages.

Move @mikro-orm/core into the external import group above 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 `@blueprint/implementations/iam/base/services/organization.service.ts` around
lines 1 - 15, Reorder the import statements so external dependencies (e.g., the
'@mikro-orm/core' import that provides EntityManager and FilterQuery) appear in
the external-dependencies group before the Forklaunch framework packages
(imports from '@forklaunch/*'); update the import order around
evaluateTelemetryOptions/MetricsDefinition/OpenTelemetryCollector/TelemetryOptions
and OrganizationService/CreateOrganizationDto/UpdateOrganizationDto to follow
the 7-layer convention so '@mikro-orm/core' is placed above the Forklaunch
imports and the rest of the file remains unchanged.

blueprint/iam-better-auth/domain/mappers/organization.mappers.ts (1)

1-4: Adjust import grouping to match repository layering rules.

@mikro-orm/core imports should be grouped in the external dependency layer before Forklaunch package 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 `@blueprint/iam-better-auth/domain/mappers/organization.mappers.ts` around
lines 1 - 4, Reorder the imports so external dependencies come before Forklaunch
packages: move the two imports from '@mikro-orm/core' (wrap and EntityManager)
above the Forklaunch imports (schemaValidator from '@forklaunch/blueprint-core'
and requestMapper/responseMapper from '@forklaunch/core/mappers'), keeping the
same named symbols (wrap, EntityManager, schemaValidator, requestMapper,
responseMapper) and grouping imports by their layers per repository rules.

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

1-13: Normalize import layering in config file.

External dependencies (@mikro-orm/*, dotenv) should be listed before Forklaunch framework 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 `@blueprint/iam-base/mikro-orm.config.ts` around lines 1 - 13, Reorder the
imports so external dependencies come before Forklaunch framework imports: move
all `@mikro-orm/`* and dotenv imports (defineConfig, Platform, TextType, Type from
'@mikro-orm/postgresql' and Migrator from '@mikro-orm/migrations' plus dotenv)
above the Forklaunch imports (createConfigInjector, getEnvVar, Lifetime from
'@forklaunch/core/services' and number, schemaValidator, string from
'@forklaunch/blueprint-core'), keep cross-module and local imports (entities
from './persistence/entities') after those; ensure the import symbols referenced
in this file (defineConfig, Migrator, dotenv, createConfigInjector, getEnvVar,
Lifetime, number, schemaValidator, string, entities) remain unchanged and
correctly ordered to follow the 7-layer guideline.

blueprint/billing-stripe/persistence/entities/checkoutSession.entity.ts (1)

1-8: Reorder imports to match the 7-layer import policy.

stripe is an external dependency and should be grouped with other external imports before Forklaunch package imports.

♻️ Suggested import order

 import { defineEntity, p, type InferEntity } from '@mikro-orm/core';
+import Stripe from 'stripe';
 import { sqlBaseProperties } from '@forklaunch/blueprint-core';
 import {
   CurrencyEnum,
   PaymentMethodEnum
 } from '@forklaunch/implementation-billing-stripe/enum';
-import Stripe from 'stripe';
 import { StatusEnum } from '../../domain/enum/status.enum';

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/persistence/entities/checkoutSession.entity.ts`
around lines 1 - 8, Reorder the import statements to follow the 7-layer policy:
move the external dependency import "Stripe" (the Stripe symbol) into the
external-dependencies group and place it before the Forklaunch framework imports
such as "sqlBaseProperties" and the Forklaunch implementation imports
"CurrencyEnum" and "PaymentMethodEnum"; keep framework/core imports
("defineEntity", "p", "InferEntity" from `@mikro-orm/core`) in their proper layer
and leave local domain import "StatusEnum" where it belongs, ensuring the final
order groups node built-ins (if any), then external (Stripe), then Forklaunch
framework packages, cross-module/local persistence/domain, and same-directory
imports.

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

23-24: Reorder imports to match the required 7-layer import structure.

Line 23 and Line 24 are external dependencies and should be placed before Forklaunch framework package imports.

♻️ Suggested import ordering fix

+import { ForkOptions } from '@mikro-orm/core';
+import { EntityManager, MikroORM } from '@mikro-orm/postgresql';
 import {
   number,
   optional,
   schemaValidator,
   SchemaValidator,
   string
 } from '@forklaunch/blueprint-core';
@@
-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 23 - 24, The import
statements in registrations.ts are out of the required 7-layer order: move the
external dependency imports (the symbols ForkOptions from '@mikro-orm/core' and
EntityManager, MikroORM from '@mikro-orm/postgresql') to appear before any
Forklaunch framework package imports so they sit in layer (2) External
dependencies; ensure subsequent imports adhere to layers (3)–(7) so the file
follows the project's import ordering guideline.

blueprint/iam-better-auth/registrations.ts (1)

25-26: Adjust import ordering to comply with the required layer sequence.

Line 25 and Line 26 are external imports and should appear before Forklaunch framework imports.

♻️ Suggested import ordering fix

+import { ForkOptions } from '@mikro-orm/core';
+import { EntityManager, MikroORM } from '@mikro-orm/postgresql';
 import {
   array,
   ExpressApplicationOptions,
   number,
   optional,
@@
-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/iam-better-auth/registrations.ts` around lines 25 - 26, Move the
external imports "ForkOptions" from '@mikro-orm/core' and "EntityManager,
MikroORM" from '@mikro-orm/postgresql' to appear before any Forklaunch framework
package imports in registrations.ts so the import order follows the 7-layer
guideline (1 Node built-ins, 2 External dependencies, 3 Forklaunch framework
packages, ...). Locate the current import lines that reference ForkOptions,
EntityManager, and MikroORM and reorder them to be in the External dependencies
group (immediately after any node: built-ins and before any framework imports),
keeping the existing import specifiers intact.

blueprint/iam-better-auth/auth.ts (1)

1-9: Reorder imports to match the repository’s 7-layer import policy.

External dependencies (@mikro-orm/core, better-auth) should come before Forklaunch package imports in this block.

♻️ Suggested import reordering

-import { mikroOrmAdapter } from '@forklaunch/better-auth-mikro-orm-fork';
-import { Metrics } from '@forklaunch/blueprint-monitoring';
-import { OpenTelemetryCollector } from '@forklaunch/core/http';
 import { MikroORM } from '@mikro-orm/core';
 import { betterAuth, BetterAuthOptions } from 'better-auth';
 import { jwt, openAPI } from 'better-auth/plugins';
+import { getEnvVar } from '@forklaunch/common';
+import { mikroOrmAdapter } from '@forklaunch/better-auth-mikro-orm-fork';
+import { Metrics } from '@forklaunch/blueprint-monitoring';
+import { OpenTelemetryCollector } from '@forklaunch/core/http';
-import { getEnvVar } from '@forklaunch/common';
 import { organization as organizationEntity } from './persistence/entities/organization.entity';
 import { user as userEntity } from './persistence/entities/user.entity';

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-better-auth/auth.ts` around lines 1 - 9, Reorder the import
block in auth.ts to follow the repository 7-layer policy: move external
dependencies (e.g., MikroORM from '@mikro-orm/core', betterAuth and its plugins
from 'better-auth' and 'better-auth/plugins') above Forklaunch package imports
(e.g., '@forklaunch/better-auth-mikro-orm-fork',
'@forklaunch/blueprint-monitoring', '@forklaunch/core/http',
'@forklaunch/common'); keep local persistence imports (organizationEntity,
userEntity) after cross-module/Forklaunch imports and preserve existing named
symbols (mikroOrmAdapter, Metrics, OpenTelemetryCollector, MikroORM, betterAuth,
BetterAuthOptions, jwt, openAPI, getEnvVar, organizationEntity, userEntity) so
references remain valid.

blueprint/iam-base/persistence/seed.data.ts (1)

5-6: Inconsistent import pattern for Permission.

Organization, Role, and User are imported from the barrel './entities', but Permission is imported directly from './entities/permission.entity'. For consistency, import all entity types from the barrel.

♻️ Suggested fix

-import { Organization, Role, User } from './entities';
-import { Permission } from './entities/permission.entity';
+import { Organization, Permission, Role, User } from './entities';

🤖 Prompt for AI Agents

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

In `@blueprint/iam-base/persistence/seed.data.ts` around lines 5 - 6, The imports
are inconsistent: Organization, Role, and User come from the barrel './entities'
while Permission is imported directly from './entities/permission.entity';
update the import statements so Permission is also imported from the barrel (add
Permission to the existing import list that includes Organization, Role, User
and remove the direct './entities/permission.entity' import) to keep a
consistent import pattern across the seed.data file.

blueprint/implementations/billing/base/domain/types/plan.mapper.types.ts (1)

21-21: Consider tightening the EntitySchema<any> type.

Using EntitySchema<any> loses type safety. If the mapper's entity type is known (e.g., via MapperEntities), consider typing it more precisely, such as EntitySchema<MapperEntities['PlanMapper']>.

🤖 Prompt for AI Agents

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

In `@blueprint/implementations/billing/base/domain/types/plan.mapper.types.ts` at
line 21, The property declaration uses EntitySchema<any> which erases type
information; change the type of the entity property (named "entity") to a more
specific generic, e.g., EntitySchema<MapperEntities['PlanMapper']> (or the
appropriate MapperEntities key for this mapper) so the Plan mapper preserves
strong typing; update any imports/types (MapperEntities) and adjust usages in
the Plan mapper to match the new generic.

blueprint/billing-stripe/domain/mappers/paymentLink.mappers.ts (1)

48-57: Consider adding description to update assignments.

If the update schema supports modifying description, it should be included in the conditional assignments for consistency with other fields.

♻️ Proposed addition

       em.assign(entity, {
         ...(dto.amount !== undefined && { amount: dto.amount }),
         ...(dto.paymentMethods !== undefined && {
           paymentMethods: dto.paymentMethods
         }),
         ...(dto.currency !== undefined && { currency: dto.currency }),
+        ...(dto.description !== undefined && { description: dto.description }),
         ...(dto.status !== undefined && { status: dto.status }),
         ...(providerFields !== undefined ? { providerFields } : {}),
         updatedAt: new Date()
       });

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/domain/mappers/paymentLink.mappers.ts` around lines
48 - 57, The update block in paymentLink.mappers.ts omits description from
conditional assignments; if the update DTO supports changing description, add a
conditional spread similar to amount/currency/status (e.g., ...(dto.description
!== undefined && { description: dto.description })) inside the em.assign call so
description is updated when present, keeping providerFields and updatedAt
unchanged.

blueprint/billing-base/domain/mappers/subscription.mappers.ts (1)

1-4: Import order should follow repository layering.

Move @mikro-orm/core imports above @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 `@blueprint/billing-base/domain/mappers/subscription.mappers.ts` around lines 1
- 4, Reorder the imports so external dependency imports from "@mikro-orm/core"
(wrap, EntityManager) appear before the Forklaunch framework package imports
(schemaValidator from "@forklaunch/blueprint-core" and
requestMapper/responseMapper from "@forklaunch/core/mappers"); update the import
block in subscription.mappers.ts to place the "@mikro-orm/core" lines above the
"@forklaunch/*" lines to comply with the repository's 7-layer import ordering
convention.

blueprint/billing-base/domain/mappers/paymentLink.mappers.ts (1)

1-4: Please reorder imports by the defined layering.

External dependencies (@mikro-orm/core) should come before @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 `@blueprint/billing-base/domain/mappers/paymentLink.mappers.ts` around lines 1
- 4, Reorder the import statements so external dependencies come before
Forklaunch framework packages: place the two imports from '@mikro-orm/core'
(wrap, EntityManager) above the '@forklaunch/*' imports (schemaValidator,
requestMapper, responseMapper); follow the project's 7-layer convention (node:
built-ins, external deps, forklaunch packages, cross-module, local persistence,
local domain, same directory) and keep the existing symbols (schemaValidator,
requestMapper, responseMapper, wrap, EntityManager) unchanged.

blueprint/billing-base/domain/mappers/billingPortal.mappers.ts (1)

1-4: Reorder imports to match the 7-layer import convention.

@mikro-orm/core (external dependency) should be placed before @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 `@blueprint/billing-base/domain/mappers/billingPortal.mappers.ts` around lines
1 - 4, Reorder the import block to follow the 7-layer convention by moving the
external dependency imports from '@mikro-orm/core' (wrap, EntityManager) above
the Forklaunch framework imports; specifically group and place the imports for
wrap and EntityManager from '@mikro-orm/core' before schemaValidator from
'@forklaunch/blueprint-core' and requestMapper/responseMapper from
'@forklaunch/core/mappers' so external dependencies come before `@forklaunch/`*
packages.

blueprint/billing-stripe/domain/mappers/subscription.mappers.ts (1)

1-11: Import groups are not in the required order.

@mikro-orm/core and stripe (external deps) should be placed before @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 `@blueprint/billing-stripe/domain/mappers/subscription.mappers.ts` around lines
1 - 11, The import groups are out of order; reorder the top imports so external
dependencies (Stripe and `@mikro-orm/core` symbols: Stripe, wrap, EntityManager)
come before Forklaunch framework packages (schemaValidator, requestMapper,
responseMapper), then keep cross-module/local imports (subscription entity,
PartyEnum, SubscriptionSchemas) afterwards; specifically move the Stripe import
and the two `@mikro-orm/core` imports above the `@forklaunch/`* imports and ensure
the final order follows the seven-layer guideline.

blueprint/billing-stripe/persistence/entities/plan.entity.ts (1)

1-8: Reorder imports to satisfy layering rules.

stripe is an external dependency and should be grouped with external imports before @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 `@blueprint/billing-stripe/persistence/entities/plan.entity.ts` around lines 1
- 8, Reorder the top-level imports in plan.entity.ts so external dependencies
come before Forklaunch framework packages: move the Stripe import (Stripe) to
the external dependencies group above the `@forklaunch/`* imports (e.g., above
sqlBaseProperties and the `@forklaunch/implementation-billing-stripe` enums) while
keeping imports from `@mikro-orm/core` and other external libs in their proper
external layer; ensure the final order follows the 7-layer rule (external before
Forklaunch framework) and preserve existing named imports (defineEntity, p,
InferEntity, sqlBaseProperties, BillingProviderEnum, CurrencyEnum,
PlanCadenceEnum).

blueprint/billing-stripe/domain/mappers/billingPortal.mappers.ts (1)

1-9: Import grouping is still out of order for this TS file.

External deps (@mikro-orm/core, stripe) should be placed before @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 `@blueprint/billing-stripe/domain/mappers/billingPortal.mappers.ts` around
lines 1 - 9, The import block is misordered: move external dependencies (Stripe
and `@mikro-orm/core` symbols like "wrap" and "EntityManager") ahead of Forklaunch
framework imports (e.g., "schemaValidator", "requestMapper", "responseMapper")
and keep local entity imports ("billingPortal" and "BillingPortal") after those;
specifically reorder so Stripe and `@mikro-orm/core` imports appear before the
`@forklaunch/`* imports while preserving the same imported symbols ("wrap",
"EntityManager", "Stripe", "schemaValidator", "requestMapper", "responseMapper",
"billingPortal", "BillingPortal").

blueprint/sample-worker/domain/mappers/sampleWorker.mappers.ts (1)

1-13: Align import groups with the 7-layer ordering rule.

External imports from @mikro-orm/core should be grouped before Forklaunch package 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 `@blueprint/sample-worker/domain/mappers/sampleWorker.mappers.ts` around lines
1 - 13, The import groups are out of order; move external imports from
`@mikro-orm/core` (wrap, EntityManager) above Forklaunch framework imports
(requestMapper, responseMapper, boolean, number, schemaValidator, string) so
they follow the 7-layer ordering rule. Reorder the import block so external
dependencies (`@mikro-orm/core` — wrap, EntityManager) come before Forklaunch
packages (`@forklaunch/core` mappers and `@forklaunch/blueprint-core` validators)
and keep the local persistence import (sampleWorkerEventRecord,
SampleWorkerEventRecord) after those; preserve existing identifiers and spacing
while only changing the order.

blueprint/sample-worker/services/sampleWorker.service.ts (1)

1-10: Reorder imports to match the repository’s 7-layer import structure.

External dependencies (@mikro-orm/core) should be grouped before Forklaunch package 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 `@blueprint/sample-worker/services/sampleWorker.service.ts` around lines 1 -
10, The imports in sampleWorker.service.ts are misordered against the 7-layer
rule: move the external dependency EntityManager import from '@mikro-orm/core'
so it appears before all Forklaunch package imports (the various `@forklaunch/`...
producers and types). Reorder so the import for EntityManager comes immediately
after any node: built-ins (none here) and before the Forklaunch framework
imports (BullMqWorkerProducer, BullMqWorkerOptions, DatabaseWorkerProducer,
DatabaseWorkerOptions, KafkaWorkerProducer, KafkaWorkerOptions,
RedisWorkerProducer, RedisWorkerOptions), preserving their relative order and
keeping the local interface import SampleWorkerService in the
local-domain/same-directory position as per the guideline.

blueprint/sample-worker/registrations.ts (1)

1-40: Reorder imports to keep external dependencies above Forklaunch imports.

@mikro-orm/* imports should be in the external dependency group before @forklaunch/*.

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/sample-worker/registrations.ts` around lines 1 - 40, The import
block places `@mikro-orm/`* imports after `@forklaunch/`*; move the external
dependency imports (MikroORM, EntityManager, ForkOptions and
mikroOrmOptionsConfig references from `@mikro-orm/core` and `@mikro-orm/postgresql`)
up into the external-dependencies group so they appear before all `@forklaunch/`*
imports (keeping node built-ins first, then external, then Forklaunch packages).
Locate the lines importing MikroORM, EntityManager, ForkOptions and
mikroOrmOptionsConfig and cut/paste them above the first `@forklaunch` import
group, preserving existing relative ordering within each group and keeping local
mikro-orm.config import with external group.

blueprint/billing-stripe/domain/mappers/checkoutSession.mappers.ts (2)

1-9: Adjust import ordering to follow the repository layering rules.

@mikro-orm/core / stripe (external deps) should come before @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 `@blueprint/billing-stripe/domain/mappers/checkoutSession.mappers.ts` around
lines 1 - 9, The imports are out of the repository's 7-layer ordering: move
external dependencies (the Stripe and `@mikro-orm/core` imports for Stripe, wrap,
EntityManager) above the Forklaunch framework imports (schemaValidator from
'@forklaunch/blueprint-core' and requestMapper/responseMapper from
'@forklaunch/core/mappers'), keeping the local persistence imports
(checkoutSession, CheckoutSession) after cross-module imports; update the import
block so Stripe and "@mikro-orm/core" appear before the '@forklaunch/*' imports
while preserving the existing symbols (wrap, EntityManager, Stripe,
schemaValidator, requestMapper, responseMapper, checkoutSession,
CheckoutSession).

---

23-35: Remove manual timestamp assignment; MikroORM lifecycle hooks already handle these fields.

The sqlBaseProperties define createdAt with onCreate() and updatedAt with onCreate() + onUpdate() hooks, which MikroORM processes automatically in em.create() and em.assign(). Manually setting these fields in both mappers (lines 33–34, 67) bypasses those hooks and duplicates the lifecycle logic.

Let MikroORM manage timestamps:

• For create: Remove createdAt and updatedAt from the object passed to em.create()
• For update: Remove updatedAt from the object passed to em.assign()

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/domain/mappers/checkoutSession.mappers.ts` around
lines 23 - 35, The mapper is manually setting createdAt and updatedAt which
overrides MikroORM lifecycle hooks; remove createdAt and updatedAt from the
object passed to em.create(...) in checkoutSession mapper and remove updatedAt
from the object passed to em.assign(...) in the update mapper so MikroORM's
onCreate()/onUpdate() handlers in sqlBaseProperties can manage timestamps
automatically (locate uses of em.create and em.assign in
checkoutSession.mappers.ts and delete the createdAt/updatedAt assignments).

blueprint/iam-better-auth/persistence/entities/organization.entity.ts (1)

13-13: ⚠️ Potential issue | 🟠 Major

Restore uniqueness on subscription to preserve 1:1 external ID mapping.

Line 13 currently allows duplicate non-null subscription IDs, which regresses the prior invariant (also still unique in blueprint/iam-base/persistence/entities/organization.entity.ts, lines 5-17).

Suggested fix

-    subscription: p.string().nullable(),
+    subscription: p.string().unique().nullable(),

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/persistence/entities/organization.entity.ts` at
line 13, The subscription field lost its uniqueness constraint and should be
made unique again to preserve the 1:1 external ID mapping; update the
organization entity's subscription property (subscription:
p.string().nullable()) to include the unique constraint (e.g., subscription:
p.string().nullable().unique()) so non-null subscription values remain unique
across records.

blueprint/iam-base/domain/mappers/user.mappers.ts (1)

21-23: ⚠️ Potential issue | 🟡 Minor

Fail fast when an organization ID is provided but missing.

On Line 22, em.findOne(...) can return null, which silently accepts an invalid dto.organization. This should throw when the client explicitly sends an organization ID.

Suggested diff

         organization: dto.organization
-          ? await em.findOne(Organization, { id: dto.organization })
+          ? await em.findOneOrFail(Organization, { id: dto.organization })
           : null,

🤖 Prompt for AI Agents

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

In `@blueprint/iam-base/domain/mappers/user.mappers.ts` around lines 21 - 23, When
dto.organization is provided the mapper currently awaits
em.findOne(Organization, { id: dto.organization }) but silently allows a null
result; change the logic to fetch into a local variable (e.g., const
organization = await em.findOne(Organization, { id: dto.organization })) and if
dto.organization is set and organization is null throw an explicit error
(BadRequest or domain-specific error) instead of assigning null; then use that
organization variable in the object mapping so an invalid organization ID fails
fast.

blueprint/billing-stripe/persistence/entities/paymentLink.entity.ts (1)

20-20: ⚠️ Potential issue | 🟠 Major

Keep providerFields nullable in the Stripe payment-link schema.

This still looks unresolved from the earlier review. The base payment-link entity keeps this field nullable, so Line 20 makes the Stripe variant stricter and can reject rows that are persisted before provider data is attached. Please verify the generated migration and fixtures before merge.

🛠️ Proposed fix

-    providerFields: p.json<Stripe.PaymentLink>()
+    providerFields: p.json<Stripe.PaymentLink>().nullable()

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/persistence/entities/paymentLink.entity.ts` at line
20, The Stripe payment-link entity's providerFields (defined as providerFields:
p.json<Stripe.PaymentLink>()) is currently non-nullable but must be nullable to
match the base payment-link entity; change the providerFields schema in
paymentLink.entity.ts to accept null (make it nullable) so pre-persisted rows
without provider data are not rejected, then regenerate and verify the migration
and fixtures to ensure no breaking schema changes.

blueprint/billing-stripe/persistence/entities/stripeWebhookEvent.entity.ts (1)

1-2: Reorder imports to match the repository’s layer order.

Line 1-2 currently place a Forklaunch package import before an external dependency. Swap these two imports so external dependencies come first.

Proposed diff

-import { sqlBaseProperties } from '@forklaunch/blueprint-core';
 import { defineEntity, p } from '@mikro-orm/core';
+import { sqlBaseProperties } from '@forklaunch/blueprint-core';

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/persistence/entities/stripeWebhookEvent.entity.ts`
around lines 1 - 2, Reorder the import statements so external dependencies come
before Forklaunch framework packages: move the import of defineEntity and p from
'@mikro-orm/core' to be the first import and keep the import of
sqlBaseProperties from '@forklaunch/blueprint-core' after it; this affects the
top of stripeWebhookEvent.entity.ts where the symbols sqlBaseProperties,
defineEntity, and p are imported.

framework/hyper-express/CHANGELOG.md (1)

7-7: Consider more descriptive changelog entries.

Similar to framework/internal/CHANGELOG.md, several changelog entries here are vague ("Another fix", "mapper fix", "package upgrades"). More descriptive entries would improve the changelog's usefulness for tracking changes across versions.

Also applies to: 29-29, 51-51

🤖 Prompt for AI Agents

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

In `@framework/hyper-express/CHANGELOG.md` at line 7, Replace vague changelog
lines (e.g., the entries "Another fix", "mapper fix", and "package upgrades")
with specific, actionable descriptions that explain what was changed, why, and
any migration or impact notes; update the corresponding entries in
framework/hyper-express/CHANGELOG.md so each release line mentions the affected
component or file, the bug/feature addressed, and any required user actions,
mirroring the style used in framework/internal/CHANGELOG.md.

framework/internal/CHANGELOG.md (1)

7-7: Consider more descriptive changelog entries.

Several patch change descriptions are quite vague ("Another fix", "mapper fix", "package upgrades"). While the format is correct, more specific descriptions would help users and maintainers understand what changed in each version—for example, what was fixed, which mappers were affected, or what the package upgrades addressed.

Also applies to: 25-25, 43-43

🤖 Prompt for AI Agents

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

In `@framework/internal/CHANGELOG.md` at line 7, Replace vague changelog lines
like the literal text "Another fix" with a concise, specific entry that states
what was changed, the affected component or mapper (e.g., "auth-mapper",
"sql-parser"), the user-visible impact, and an optional reference to the
PR/issue number; update each occurrence (including the other lines noted) to
follow this pattern so readers can immediately understand what was fixed and
where.

framework/validator/CHANGELOG.md (1)

7-7: Consider more descriptive changelog entries.

Like the other changelog files in this PR, these entries ("Another fix", "mapper fix", "package upgrades") could be more specific to help users understand the nature of each patch release.

Also applies to: 23-23, 39-39

🤖 Prompt for AI Agents

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

In `@framework/validator/CHANGELOG.md` at line 7, Replace vague changelog lines
like "Another fix", "mapper fix", and "package upgrades" with concise,
descriptive entries that state what was changed, why, and any relevant PR/ticket
numbers; for example, update the "Another fix" entry to specify the bug or
behavior corrected, change "mapper fix" to describe which mapper or mapping
logic was altered, and expand "package upgrades" to list key packages and
versions updated plus any breaking changes or migration notes so users can
understand the impact.

blueprint/iam-better-auth/persistence/entities/teamMember.entity.ts (1)

6-10: Consider adding a unique constraint on (teamId, userId).

For a team membership entity, you may want to prevent duplicate memberships where the same user is added to the same team multiple times. MikroORM v7 schema-based definitions support unique constraints that could enforce this at the database level.

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/persistence/entities/teamMember.entity.ts` around
lines 6 - 10, The TeamMember entity currently defines properties
(...sqlBaseProperties, teamId, userId) but lacks a uniqueness constraint to
prevent duplicate (teamId, userId) rows; update the entity schema in
teamMember.entity.ts to add a unique constraint/index on the composite keys
(teamId, userId) using MikroORM v7 schema-based definitions (e.g., add
uniqueConstraints or indexes at the entity level) so the database enforces one
membership per user per team. Ensure the constraint references the existing
property names teamId and userId and is applied alongside sqlBaseProperties.

blueprint/sample-worker/package.json (1)

18-18: Verify tsgo and @typescript/native-preview are suitable for your use case before relying on this build chain.

The build script uses tsgo (Microsoft's native Go-based TypeScript compiler) from the @typescript/native-preview package (version 7.0.0-dev.20260320.1). While the core compiler pipeline is functional, declaration emit and JS emit are still in progress, and watch mode is prototype-only. These tools are officially in public preview and not feature-complete, so test thoroughly in your environment before using in production workflows.

Also applies to: 80-80

blueprint/iam-better-auth/package.json (1)

44-50: Remove unused database driver dependencies from hard dependencies.

Lines 44–50 install all four MikroORM drivers (mongodb, mysql, postgresql, sqlite) as hard dependencies. However, only @mikro-orm/postgresql is actively imported in the codebase—the other three drivers are commented out in mikro-orm.config.ts and never used. Move mongodb, mysql, and sqlite drivers to optionalDependencies or peerDependencies to reduce the install footprint and security surface.

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/package.json` around lines 44 - 50, The
package.json currently lists all four MikroORM drivers as hard dependencies
which bloats installs; remove "@mikro-orm/mongodb", "@mikro-orm/mysql", and
"@mikro-orm/sqlite" from dependencies and move them into either
optionalDependencies or peerDependencies instead, leaving only
"@mikro-orm/postgresql" (and core/migrations/seeder) as runtime dependencies;
update the package.json entries for those three packages accordingly and ensure
any code comments in mikro-orm.config.ts that reference them remain unchanged so
installs no longer pull unused drivers.

blueprint/iam-better-auth/persistence/entities/user.entity.ts (1)

9-9: Use .onCreate() instead of .default() for schema-only defineEntity runtime defaults.

The emailVerified field is non-nullable without a default, which could cause runtime errors. For MikroORM v7 schema-only defineEntity usage, .onCreate() is the recommended approach for runtime defaults rather than .default():

-    emailVerified: p.boolean(),
+    emailVerified: p.boolean().onCreate(() => false),

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/persistence/entities/user.entity.ts` at line 9, The
emailVerified property in the defineEntity schema is non-nullable but currently
lacks a runtime default; replace the current schema default usage with a runtime
on-create hook: update the emailVerified field inside defineEntity (symbol:
emailVerified) to use .onCreate(() => false) so new User entities get a false
value at runtime per MikroORM v7 schema-only patterns, ensuring the field is
initialized and avoiding null errors.

blueprint/iam-base/domain/mappers/role.mappers.ts (1)

79-85: Consider using em.findOneOrFail for consistency.

RoleEntityMapper uses em.findOne with a manual null check and error throw, while other mappers in this file use em.findOneOrFail. Using the built-in method would be more consistent and slightly more concise.

♻️ Proposed refactor

 export const RoleEntityMapper = requestMapper({
   schemaValidator,
   schema: RoleSchemas.UpdateRoleSchema,
   entity: Role,
   mapperDefinition: {
     toEntity: async (dto, em: EntityManager) => {
-      const foundRole = await em.findOne(Role, dto.id);
-      if (!foundRole) {
-        throw new Error('Role not found');
-      }
-      return foundRole;
+      return em.findOneOrFail(Role, dto.id);
     }
   }
 });

🤖 Prompt for AI Agents

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

In `@blueprint/iam-base/domain/mappers/role.mappers.ts` around lines 79 - 85, In
RoleEntityMapper.toEntity replace the manual lookup-and-null-check pattern
(await em.findOne(Role, dto.id) + if (!foundRole) throw) with the built-in
EntityManager method by calling await em.findOneOrFail(Role, dto.id) and
removing the explicit null check/throw to match the other mappers and keep
behavior consistent.

blueprint/iam-base/persistence/entities/user.entity.ts (1)

21-21: Remove stale commented-out type export.

This dead comment is misleading during the migration and references user with incorrect casing.

Suggested diff

-// export type User = InferEntity<typeof user>;

🤖 Prompt for AI Agents

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

In `@blueprint/iam-base/persistence/entities/user.entity.ts` at line 21, Remove
the stale commented-out type export "export type User = InferEntity<typeof
user>;" from user.entity.ts: delete this dead comment (it references the
incorrect symbol casing `user`) so there is no misleading commented code; if a
type alias is still needed use the correct exported entity name when adding a
proper export elsewhere.

blueprint/iam-better-auth/auth.ts (1)

17-35: Verify role permission differentiation is intentional.

Currently, owner, admin, editor, and system roles all have identical permissions (PLATFORM_READ + PLATFORM_WRITE), while only viewer differs with just PLATFORM_READ. If this is placeholder configuration, consider adding a TODO comment; otherwise, the roles effectively provide no differentiation beyond viewer vs. non-viewer.

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/auth.ts` around lines 17 - 35, The role definitions
(ownerRole, adminRole, editorRole, systemRole) all use the same permission set
via ac.newRole with PERMISSIONS.PLATFORM_READ and PERMISSIONS.PLATFORM_WRITE,
making them indistinguishable from each other (only viewerRole differs); either
update each role to the intended distinct permission sets (e.g., add admin-only
or owner-only permissions, remove write for viewer-like roles, etc.) by editing
the ac.newRole calls for ownerRole/adminRole/editorRole/systemRole to reflect
the correct PERMISSIONS constants, or add a clear TODO comment above these
definitions stating this is a placeholder and permissions will be differentiated
later so reviewers know it’s intentional.

blueprint/iam-better-auth/domain/services/surfacing.service.ts (2)

35-47: Redundant database query in surfacePermissions.

surfacePermissions calls surfaceRole (line 39), which internally calls getActiveOrganizationId. Since surfacePermissions already calls getActiveOrganizationId on line 36, the same query executes twice per invocation.

♻️ Proposed fix to eliminate duplicate query

   async surfacePermissions(userId: string): Promise<string[]> {
     const activeOrganizationId = await this.getActiveOrganizationId(userId);
     if (!activeOrganizationId) return [];

-    const role = await this.surfaceRole(userId);
+    const member = await this.em.findOne(Member, {
+      userId,
+      organizationId: activeOrganizationId
+    });
+    const role = member?.role;
     if (!role) return [];

     const orgRoles = await this.em.find(OrganizationRole, {
       organizationId: activeOrganizationId,
       role
     });
     return orgRoles.map((r) => r.permission);
   }

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/domain/services/surfacing.service.ts` around lines
35 - 47, surfacePermissions is performing getActiveOrganizationId twice because
it calls surfaceRole which also calls getActiveOrganizationId; change
surfaceRole to accept an optional organizationId parameter (e.g.,
surfaceRole(userId: string, organizationId?: string)) and update its
implementation to skip calling getActiveOrganizationId when organizationId is
provided; then call surfaceRole(userId, activeOrganizationId) from
surfacePermissions and keep the existing em.find(OrganizationRole, {
organizationId: activeOrganizationId, role }) mapping to permissions so the
duplicate query is eliminated.

---

9-22: Consider handling multiple active sessions edge case.

The query orders by createdAt: 'DESC' and returns the first match, but a user could theoretically have multiple non-expired sessions with different activeOrganizationId values. This behavior (using the most recently created session) should be documented or reconsidered if the intent is to use the most recently used session.

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/domain/services/surfacing.service.ts` around lines
9 - 22, getActiveOrganizationId currently returns the activeOrganizationId from
the most recently created non-expired Session (em.findOne on Session with
orderBy: { createdAt: 'DESC' }), which can be wrong if multiple non-expired
sessions have different activeOrganizationId values; update the logic in
getActiveOrganizationId to either (a) order by the last-used/updated timestamp
(e.g. use a lastUsedAt/updatedAt field instead of createdAt in the em.findOne
orderBy), or (b) fetch all matching sessions (em.find) and deterministically
resolve conflicts (prefer most recent lastUsedAt, or prefer server-stored
primary session), and add a short comment in
surfacing.service.getActiveOrganizationId documenting the chosen tie-breaker
(referencing Session, em.findOne/em.find, activeOrganizationId, createdAt,
expiresAt).

blueprint/iam-better-auth/persistence/entities/organizationRole.entity.ts (1)

4-12: Consider adding indexes for query performance.

The SurfacingService queries OrganizationRole by organizationId and role together (see surfacing.service.ts lines 42-45). Without an index, these queries may perform full table scans as the data grows.

♻️ Proposed fix to add composite index

 export const OrganizationRole = defineEntity({
   name: 'OrganizationRole',
   properties: {
     ...sqlBaseProperties,
     organizationId: p.string(),
     role: p.string(),
     permission: p.string()
-  }
+  },
+  indexes: [
+    { properties: ['organizationId', 'role'] }
+  ]
 });

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/persistence/entities/organizationRole.entity.ts`
around lines 4 - 12, The OrganizationRole entity lacks an index on
organizationId+role which causes queries in SurfacingService (which query by
organizationId and role) to scan the table; update the defineEntity call for
OrganizationRole to add a composite index on the organizationId and role
properties (non-unique) so those queries use the index — modify the
OrganizationRole definition (where defineEntity and properties are declared) to
include an indexes/indices array with fields ['organizationId','role'] (or the
equivalent index option for the entity builder you’re using).

blueprint/iam-better-auth/__test__/test-utils.ts (1)

61-130: Extract the repeated fixture literals into shared constants.

The same UUIDs, role name, and permission slugs are copied across the seed graph and the expected responses. One typo will silently disconnect the fixture or leave the mocks out of sync on the next RBAC rename. Hoist them into shared constants, or reuse the created entity ids/values when building the related records and mock payloads.

♻️ Example refactor

+const TEST_ORGANIZATION_ID = '123e4567-e89b-12d3-a456-426614174001';
+const TEST_USER_ID = '123e4567-e89b-12d3-a456-426614174000';
+const TEST_ROLE = 'admin';
+const TEST_PERMISSIONS = ['platform_read', 'platform_write'] as const;
+
   em.create(Organization, {
-    id: '123e4567-e89b-12d3-a456-426614174001',
+    id: TEST_ORGANIZATION_ID,
     ...
   });
 
   em.create(User, {
-    id: '123e4567-e89b-12d3-a456-426614174000',
+    id: TEST_USER_ID,
     ...
   });
 
   em.create(Member, {
-    organizationId: '123e4567-e89b-12d3-a456-426614174001',
-    userId: '123e4567-e89b-12d3-a456-426614174000',
-    role: 'admin',
+    organizationId: TEST_ORGANIZATION_ID,
+    userId: TEST_USER_ID,
+    role: TEST_ROLE,
     ...
   });

export const mockRoleResponse = [{ name: TEST_ROLE }];
export const mockPermissionResponse = TEST_PERMISSIONS.map((slug) => ({ slug }));

Also applies to: 134-139

🤖 Prompt for AI Agents

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

In `@blueprint/iam-better-auth/__test__/test-utils.ts` around lines 61 - 130, The
test seeds use repeated literal UUIDs, role names and permission slugs across
entity creation (Organization, User, Member, OrganizationRole, Session) and in
the mock/expected responses; extract those into shared constants (e.g.
TEST_ORG_ID, TEST_USER_ID, TEST_MEMBER_ID, TEST_SESSION_ID, TEST_ROLE,
TEST_PERMISSIONS) and reference those constants when calling em.create for
Organization, User, Member, OrganizationRole and Session and when constructing
the mock role/permission responses so the IDs and slugs are defined once and
reused (also update the related mock payloads mentioned around the later mock
block that uses the same literals).

blueprint/billing-base/persistence/entities/paymentLink.entity.ts (1)

1-2: Reorder this import pair to keep external packages first.

Line 1 currently places @forklaunch/blueprint-core above the external MikroORM import. @mikro-orm/core should stay in the external-dependency block before @forklaunch/*.
As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages"

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/persistence/entities/paymentLink.entity.ts` around
lines 1 - 2, Reorder the import statements so external dependency
`@mikro-orm/core` comes before the internal `@forklaunch` package: move "import {
defineEntity, p } from '@mikro-orm/core';" above "import { sqlBaseProperties }
from '@forklaunch/blueprint-core';" while keeping the imported symbols
(sqlBaseProperties, defineEntity, p) unchanged.

blueprint/billing-stripe/persistence/entities/subscription.entity.ts (1)

1-4: Reorder this import block to keep external dependencies first.

Lines 1-4 place @forklaunch/* above @mikro-orm/core and stripe. The external imports should be grouped above the Forklaunch and local imports.
As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages"

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/persistence/entities/subscription.entity.ts` around
lines 1 - 4, Reorder the import block so external packages appear before
Forklaunch packages: move the imports for defineEntity and p from
'@mikro-orm/core' and Stripe from 'stripe' above the imports from
'@forklaunch/*' (sqlBaseProperties and BillingProviderEnum); keep intra-group
ordering stable and preserve all imported symbols (sqlBaseProperties,
BillingProviderEnum, defineEntity, p, Stripe) and existing import syntax.

blueprint/billing-base/persistence/entities/subscription.entity.ts (1)

1-2: Reorder this import pair to keep external packages first.

Line 1 currently places @forklaunch/blueprint-core above the external MikroORM import. @mikro-orm/core should stay in the external-dependency block before @forklaunch/*.
As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages"

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/persistence/entities/subscription.entity.ts` around
lines 1 - 2, The import ordering is reversed: move the external MikroORM import
before the Forklaunch package so external deps come first; specifically swap the
two import statements so "import { defineEntity, p } from '@mikro-orm/core';"
appears above "import { sqlBaseProperties } from '@forklaunch/blueprint-core';"
(these symbols help you find the lines to change) to comply with the 7-layer
import ordering rule.

blueprint/billing-stripe/persistence/entities/checkoutSession.entity.ts (1)

1-7: Keep stripe in the external import block.

Lines 1-7 currently split external imports around the @forklaunch/* import. @mikro-orm/core and stripe should sit together above the Forklaunch and local imports.
As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages"

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/persistence/entities/checkoutSession.entity.ts`
around lines 1 - 7, The import grouping is incorrect: move the external
dependency import "Stripe" so that the Stripe import (Stripe) sits with the
other external imports (where defineEntity and p from '@mikro-orm/core' are
imported) above the Forklaunch/local imports; leave sqlBaseProperties,
CurrencyEnum and PaymentMethodEnum imports in the Forklaunch block. Ensure
imports are ordered so external libs (e.g., defineEntity, p, Stripe) appear
before `@forklaunch/`* imports.

blueprint/billing-stripe/persistence/entities/paymentLink.entity.ts (1)

1-7: Keep stripe in the external import block.

Lines 1-7 currently split external imports around the @forklaunch/* import. @mikro-orm/core and stripe should sit together above the Forklaunch and local imports.
As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages"

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/persistence/entities/paymentLink.entity.ts` around
lines 1 - 7, Reorder the import block so external dependencies stay together:
move the Stripe import so it sits with the other external imports (e.g.,
alongside "defineEntity" and "p" from '@mikro-orm/core') and keep Forklaunch
packages (sqlBaseProperties from '@forklaunch/blueprint-core' and
CurrencyEnum/PaymentMethodEnum from
'@forklaunch/implementation-billing-stripe/enum') in the Forklaunch section;
update the top of paymentLink.entity.ts to group external imports (including
Stripe) before the Forklaunch imports to match the 7-layer import guideline.

blueprint/billing-base/persistence/entities/checkoutSession.entity.ts (1)

1-2: Reorder this import pair to keep external packages first.

Line 1 currently places @forklaunch/blueprint-core above the external MikroORM import. @mikro-orm/core should stay in the external-dependency block before @forklaunch/*.
As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages"

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/persistence/entities/checkoutSession.entity.ts` around
lines 1 - 2, Import order is inverted: move external dependency imports before
Forklaunch packages by swapping the two import lines in
checkoutSession.entity.ts so the `@mikro-orm/core` import (bringing in
defineEntity, p) appears in the external-dependency block above the
`@forklaunch/blueprint-core` import (bringing in sqlBaseProperties); update the
file so imports follow the project's 7-layer ordering with external packages
first.

blueprint/billing-stripe/persistence/entities/plan.entity.ts (1)

1-8: Reorder the imports so externals come first.

@mikro-orm/core and stripe should sit ahead of the @forklaunch/* imports here.

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/persistence/entities/plan.entity.ts` around lines 1
- 8, The import ordering is incorrect; move external dependencies before
Forklaunch packages so `@mikro-orm/core` (defineEntity, p) and stripe (Stripe) are
listed ahead of `@forklaunch/`* imports (sqlBaseProperties, BillingProviderEnum,
CurrencyEnum, PlanCadenceEnum) to follow the 7-layer guideline—reorder the
import block so external libs come first, then the `@forklaunch` framework
imports, keeping the same named imports intact.

blueprint/billing-stripe/domain/mappers/checkoutSession.mappers.ts (2)

1-7: Reorder the imports to match the repo layers.

@mikro-orm/core and stripe should be grouped before the @forklaunch/* imports in this file.

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/domain/mappers/checkoutSession.mappers.ts` around
lines 1 - 7, Reorder the import block so external libs come before internal
framework packages: move the Stripe and MikroORM imports (symbols Stripe,
EntityManager, InferEntity, wrap) to appear before the `@forklaunch` imports
(schemaValidator, requestMapper, responseMapper). Keep local persistence and
domain imports (CheckoutSession, StatusEnum, CheckoutSessionSchemas) after the
framework imports, preserving their relative order; ensure imports follow the
repo's 7-layer convention: external dependencies (Stripe, `@mikro-orm/core`),
Forklaunch framework (`@forklaunch/`*), then local persistence (CheckoutSession),
local domain (StatusEnum), and same-directory schemas (CheckoutSessionSchemas).

---

19-30: Let sqlBaseProperties own these timestamps.

This entity also inherits createdAt and updatedAt, so writing them in both mapper paths duplicates the lifecycle logic and makes future timestamp changes easy to miss in one branch.

Also applies to: 49-52

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/domain/mappers/checkoutSession.mappers.ts` around
lines 19 - 30, The mapper is explicitly setting createdAt and updatedAt in
em.create(CheckoutSession, ...) which duplicates the lifecycle timestamps that
should come from sqlBaseProperties; remove createdAt and updatedAt from both
mapper branches and instead spread or include sqlBaseProperties (or the
object/value returned by sqlBaseProperties) into the em.create payload so the
entity's inherited timestamps are owned by sqlBaseProperties rather than the
mapper.

blueprint/billing-stripe/domain/mappers/plan.mappers.ts (2)

1-6: Reorder the imports to match the repo layers.

@mikro-orm/core and stripe should be grouped before the @forklaunch/* imports in this file.

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/domain/mappers/plan.mappers.ts` around lines 1 - 6,
Reorder the import statements so external dependencies come before Forklaunch
packages: move the "@mikro-orm/core" imports (EntityManager, InferEntity, wrap)
and the "stripe" import (Stripe) to be grouped directly after other external
libraries, and place the "@forklaunch/*" imports (schemaValidator from
'@forklaunch/blueprint-core' and requestMapper/responseMapper from
'@forklaunch/core/mappers') after them; keep local persistence import (Plan) and
local domain import (PlanSchemas) following that, preserving their existing
relative order and symbols (schemaValidator, requestMapper, responseMapper,
EntityManager, InferEntity, wrap, Stripe, Plan, PlanSchemas).

---

18-26: Don’t coerce billingProvider to null.

Plan now declares billingProvider as required, so Line 26's || null fallback only hides a missing-input problem until persistence. Passing dto.billingProvider through unchanged keeps the mapper aligned with the entity contract.

♻️ Proposed fix

-        billingProvider: dto.billingProvider || null,
+        billingProvider: dto.billingProvider,

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/domain/mappers/plan.mappers.ts` around lines 18 -
26, The mapper is coercing billingProvider to null despite Plan requiring it; in
the em.create call that constructs Plan (the mapping block where Plan is created
from dto), remove the fallback "|| null" and pass dto.billingProvider directly
(i.e., change billingProvider: dto.billingProvider || null to billingProvider:
dto.billingProvider) so the mapper honors the Plan entity contract and surfaces
missing input instead of hiding it.

blueprint/billing-stripe/persistence/seed.data.ts (1)

1-16: Reorder these imports to keep the layers consistent.

@mikro-orm/core and stripe should be grouped with the external dependencies before the @forklaunch/* and local 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 `@blueprint/billing-stripe/persistence/seed.data.ts` around lines 1 - 16,
Reorder the import groups so external libs come first: move the imports for
external symbols (InferEntity, RequiredEntityData from '@mikro-orm/core' and
Stripe from 'stripe') into the external-dependencies group before the Forklaunch
and local imports; then keep the Forklaunch package imports
(BillingProviderEnum, CurrencyEnum, PaymentMethodEnum, PlanCadenceEnum from
'@forklaunch/implementation-billing-stripe/enum') next, followed by
cross-module/local domain and persistence imports (PartyEnum, StatusEnum, and
entity imports CheckoutSession, PaymentLink, Plan, Subscription). Ensure the
seven-layer ordering rule is followed and the same symbol names are preserved.

blueprint/billing-stripe/domain/mappers/billingPortal.mappers.ts (1)

1-5: Reorder the imports to match the repo layers.

@mikro-orm/core and stripe should be grouped before the @forklaunch/* imports in this file.

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/domain/mappers/billingPortal.mappers.ts` around
lines 1 - 5, Imports in billingPortal.mappers.ts are out of the required layered
order: move external deps (Stripe and `@mikro-orm/core`) before Forklaunch
framework packages (`@forklaunch/`*). Reorder so that the Stripe import (Stripe)
and MikroORM imports (EntityManager, InferEntity, wrap from '@mikro-orm/core')
appear above the `@forklaunch` imports (schemaValidator from
'@forklaunch/blueprint-core' and requestMapper/responseMapper from
'@forklaunch/core/mappers'), keeping the BillingPortal local persistence import
in its existing local persistence position; update import grouping only — do not
change imported symbols or usage in functions/classes in this file.

blueprint/billing-base/persistence/seed.data.ts (1)

15-25: Keep these seed payloads typed against the entity shape.

Removing the satisfies RequiredEntityData<...> checks here drops the compile-time guard that catches seed drift during the v7 migration. blueprint/billing-stripe/persistence/seed.data.ts already uses RequiredEntityData<InferEntity<typeof ...>>; keeping the same constraint here would surface renamed or newly required fields before seeding.

Also applies to: 40-54, 70-70

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/persistence/seed.data.ts` around lines 15 - 25, The
seed payloads (e.g., the paymentLink object) were left untyped, removing the
compile-time guard that ensures the seed matches the entity shape; re-add the
TypeScript constraint by annotating each seed object with satisfies
RequiredEntityData<InferEntity<typeof PaymentLink>> (using the same pattern as
blueprint/billing-stripe/persistence/seed.data.ts) so the compiler will catch
renamed or required fields, and apply the same change to the other seed payloads
mentioned (around lines 40-54 and line 70).

blueprint/billing-base/domain/mappers/subscription.mappers.ts (1)

1-4: Reorder imports to match the repository layers.

@mikro-orm/core should sit in the external-dependency group above the @forklaunch/* imports.

As per coding guidelines, **/*.{ts,tsx,js,jsx}: Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, ...`

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/domain/mappers/subscription.mappers.ts` around lines 1
- 4, The import order in subscription.mappers.ts is incorrect: move the external
dependency import from `@mikro-orm/core` (EntityManager, InferEntity, wrap) above
the `@forklaunch/`* imports so external-dependency layer precedes Forklaunch
framework packages; update the import block accordingly while keeping the same
imported symbols (schemaValidator, requestMapper, responseMapper, EntityManager,
InferEntity, wrap, Subscription) and preserving existing usage in the file.

blueprint/billing-stripe/domain/mappers/subscription.mappers.ts (2)

67-73: Drop providerFields before emitting the DTO.

Line 69 spreads the internal providerFields column into the response and Line 72 adds stripeFields on top. Explicitly omit providerFields here so the mapper owns a single public field name.

♻️ Proposed fix

-      const data = wrap(entity).toPOJO();
+      const { providerFields: _providerFields, ...data } = wrap(entity).toPOJO();
       return {
         ...data,
         description: entity.description ?? undefined,
         endDate: data.endDate ?? undefined,
         stripeFields: entity.providerFields

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/domain/mappers/subscription.mappers.ts` around lines
67 - 73, The mapper currently spreads wrap(entity).toPOJO() which includes the
internal providerFields column and then adds stripeFields; change the return so
providerFields is omitted from the emitted DTO (e.g., remove providerFields from
data before spreading or build the returned object without providerFields) and
keep stripeFields populated from entity.providerFields; adjust the return around
variables data, entity, providerFields and stripeFields to ensure only
stripeFields is exposed.

---

1-5: Reorder the imports so externals come first.

@mikro-orm/core and stripe belong in the external-dependency layer and should be grouped above the @forklaunch/* imports.

As per coding guidelines, **/*.{ts,tsx,js,jsx}: Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, ...`

🤖 Prompt for AI Agents

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

In `@blueprint/billing-stripe/domain/mappers/subscription.mappers.ts` around lines
1 - 5, Reorder the import block so external dependencies come before internal
Forklaunch packages: move the `@mikro-orm/core` imports (EntityManager,
InferEntity, wrap) and the Stripe import (Stripe) to appear above the
`@forklaunch/`* imports (schemaValidator from '@forklaunch/blueprint-core' and
requestMapper/responseMapper from '@forklaunch/core/mappers'), keeping the
Subscription entity import last; ensure the same symbols (EntityManager,
InferEntity, wrap, Stripe, schemaValidator, requestMapper, responseMapper,
Subscription) are preserved and only the import order is changed to follow the
external-dependencies-first guideline.

blueprint/billing-base/domain/mappers/plan.mappers.ts (1)

1-4: Reorder imports to keep externals above @forklaunch/*.

Line 3 should be grouped with the external dependencies, not below the Forklaunch imports.

As per coding guidelines, **/*.{ts,tsx,js,jsx}: Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, ...`

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/domain/mappers/plan.mappers.ts` around lines 1 - 4,
The import order is incorrect: the MikroORM import (EntityData, EntityManager,
InferEntity, wrap from '@mikro-orm/core') must be grouped with external
dependencies above the Forklaunch packages; reorder the imports so external libs
(e.g., '@mikro-orm/core', other third-party imports) appear before the
'@forklaunch/*' imports (requestMapper/responseMapper and schemaValidator) to
match the 7-layer import organization.

blueprint/billing-base/domain/mappers/paymentLink.mappers.ts (1)

1-4: Move external imports above the Forklaunch imports.

Line 3 belongs in the external-dependency layer, so it should be grouped before the @forklaunch/* imports.

As per coding guidelines, **/*.{ts,tsx,js,jsx}: Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, ...`

🤖 Prompt for AI Agents

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

In `@blueprint/billing-base/domain/mappers/paymentLink.mappers.ts` around lines 1
- 4, The imports are not grouped correctly—external packages must appear before
Forklaunch packages; move the imports from external modules (e.g.,
EntityManager, InferEntity, wrap from '@mikro-orm/core') above the Forklaunch
imports (schemaValidator from '@forklaunch/blueprint-core' and
requestMapper/responseMapper from '@forklaunch/core/mappers') so external
dependencies are in the external-dependency layer and Forklaunch packages
follow; keep PaymentLink import (local persistence entity) in the application
layer after the framework imports.

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

2-5: Reorder imports to match the project’s 7-layer import policy.

@mikro-orm/core (external dependency) should be grouped before @forklaunch/* imports.

♻️ Proposed import reorder

 import { Schema } from '@forklaunch/validator';
 import { SchemaValidator, number, string } from '@forklaunch/validator/typebox';
-import { EntityManager, InferEntity, defineEntity, p } from '@mikro-orm/core';
+import { EntityManager, InferEntity, defineEntity, p } from '@mikro-orm/core';
 import { requestMapper, responseMapper } from '../src/mappers';

+import { EntityManager, InferEntity, defineEntity, p } from '@mikro-orm/core';
 import { Schema } from '@forklaunch/validator';
 import { SchemaValidator, number, string } from '@forklaunch/validator/typebox';
 import { requestMapper, responseMapper } from '../src/mappers';

As per coding guidelines, **/*.{ts,tsx,js,jsx}: “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/core/__test__/mapper.test.ts` around lines 2 - 5, Reorder the
import statements so external dependencies come before Forklaunch packages: move
the `@mikro-orm/core` import (EntityManager, InferEntity, defineEntity, p) above
the `@forklaunch/`* imports (Schema from '@forklaunch/validator' and
SchemaValidator, number, string from '@forklaunch/validator/typebox'), keeping
the local mappers import (requestMapper, responseMapper) last; ensure the
symbols EntityManager, InferEntity, defineEntity, p, Schema, SchemaValidator,
number, string, requestMapper, and responseMapper remain unchanged.