Add Angular 21 and NestJS tech preset to installation wizard#569
Open
Silvino-Miranda wants to merge 10 commits intoSynkraAI:mainfrom
Open
Add Angular 21 and NestJS tech preset to installation wizard#569Silvino-Miranda wants to merge 10 commits intoSynkraAI:mainfrom
Silvino-Miranda wants to merge 10 commits intoSynkraAI:mainfrom
Conversation
Silvino-Miranda
requested review from
Pedrovaleriolopez and
oalanicolas
as code owners
|
@Silvino-Miranda is attempting to deploy a commit to the Pedro Valério Lopez's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdded a new "angular-nestjs" tech preset and registered it: new preset Markdown file, entity registry updated (entityCount → 746, metadata.lastUpdated), install-manifest updated (file_count → 1091, hashes/sizes), and the installer wizard selection extended with the new preset option; local permissions config expanded. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Welcome to aiox-core! Thanks for your first pull request.
What happens next?
- Automated checks will run on your PR
- A maintainer will review your changes
- Once approved, we'll merge your contribution!
PR Checklist:
- Tests pass (
npm test) - Linting passes (
npm run lint) - Commit messages follow Conventional Commits
Thanks for contributing!
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.aiox-core/install-manifest.yaml (1)
1-3:⚠️ Potential issue | 🟡 MinorManifest metadata mismatch—regenerate with
npm run generate:manifest.The manifest entry for
angular-nestjs.mdlists a file size of 22,621 bytes, but the actual file is 21,910 bytes. The hash matches correctly, but the stale size metadata indicates the manifest was not properly regenerated. Runnpm run generate:manifestto update both hash and size entries.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/install-manifest.yaml around lines 1 - 3, The manifest metadata for angular-nestjs.md has a stale file size; regenerate the install manifest by running the generate script so size and hash entries are recalculated: run the project script (npm run generate:manifest) to update the entry for angular-nestjs.md and commit the updated .aiox-core/install-manifest.yaml so the size (and hash if changed) match the actual file.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aiox-core/data/entity-registry.yaml:
- Around line 14088-14110: The "angular-nestjs" registry entry is using hard
`dependencies` for scaffold modules (auth, user, jwt) which creates incorrect
graph edges; update the "angular-nestjs" entry to move those items from
`dependencies` into a `plannedDeps` list, remove them from `dependencies`, and
add the missing structural fields `externalDeps` and `lifecycle` consistent with
the `nextjs-react` preset pattern so the IDS loader treats them as planned
scaffold targets rather than concrete registry links.
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 185-203: The code currently stores JWTs in localStorage within the
login/logout flows (see methods login, logout and the key 'access_token'), which
encourages an XSS-sensitive default; update the implementation to use a safer
default or clearly mark it as an example: either switch to setting an HttpOnly
cookie from the server (remove client-side localStorage.setItem/removeItem usage
and rely on cookie-based auth) or, if keeping a client-side token example,
replace direct localStorage usage with a clearly documented, opt-in alternative
(e.g., a TokenStorageService abstraction used by login/logout instead of
localStorage) and add a comment in login/logout explaining the security
trade-offs. Ensure references to 'access_token', login(), and logout() are
updated accordingly.
- Line 355: Several fenced code blocks in angular-nestjs.md (the tree and prompt
example blocks that are currently just ``` ) are missing language identifiers;
update each triple-backtick fence for the tree and prompt examples to use a
plain-text language tag (e.g., ```text or ```plaintext) so markdownlint MD040 is
satisfied—search for the untagged fences labeled as the "tree" output and the
"prompt" example blocks and replace the opening ``` with ```text (or
```plaintext) for each occurrence noted in the comment.
- Around line 271-279: In canActivate, guard against missing request.user before
accessing user.role: after retrieving requiredRoles and the request via
context.switchToHttp().getRequest(), check that request.user exists and return
false if it's absent; then perform the roles check with
requiredRoles.includes(user.role). This change in canActivate (the reflector
usage and the request = context.switchToHttp().getRequest() block) prevents a
thrown error when JwtAuthGuard wasn't applied.
- Around line 90-113: The AuthModule example uses ConfigService in
JwtModule.registerAsync but does not import or register ConfigModule; update the
AuthModule to import ConfigModule and reference ConfigService for DI: add
ConfigModule (e.g., ConfigModule.forRoot() or ConfigModule) to the Module
imports array and include ConfigService in the inject array already used by
JwtModule.registerAsync so JwtModule.registerAsync can resolve the ConfigService
dependency; ensure imports include ConfigModule and that AuthModule
providers/exports remain unchanged (AuthModule, JwtModule.registerAsync,
ConfigService, ConfigModule).
- Around line 236-239: The onSubmit example uses an unsafe cast "as any";
replace it with a concrete type (e.g., define an interface LoginDto or
LoginCredentials with the expected fields) and pass that type to auth.login (for
example: const payload = this.form.getRawValue() as LoginDto; await
this.auth.login(payload)); also update the exception filter snippet to avoid "as
any" by accepting unknown, narrowing it with a type guard or instanceof checks
and mapping to a known Error/HttpException type before accessing properties;
reference the onSubmit method and the exception filter code when making these
changes so copied snippets demonstrate proper typing instead of using any.
- Around line 42-73: The shared TypeScript interfaces LoginRequestDto,
LoginResponseDto and UserDto are erased at runtime and won't work with NestJS
ValidationPipe for `@Body`() parameters; update the doc to either (a) add backend
DTO classes (e.g., LoginRequestDtoClass) that implement/extend the shared
interfaces and include class-validator decorators like `@IsString/`@IsEmail so
controllers using ValidationPipe can validate requests, or (b) explicitly state
that the shown interfaces are type-only and must be paired with separate
decorated NestJS DTO classes used in controllers; reference LoginRequestDto,
LoginResponseDto, UserDto, ValidationPipe and `@Body`() so readers know where to
apply the fix.
---
Outside diff comments:
In @.aiox-core/install-manifest.yaml:
- Around line 1-3: The manifest metadata for angular-nestjs.md has a stale file
size; regenerate the install manifest by running the generate script so size and
hash entries are recalculated: run the project script (npm run
generate:manifest) to update the entry for angular-nestjs.md and commit the
updated .aiox-core/install-manifest.yaml so the size (and hash if changed) match
the actual file.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c4801c36-0d98-4a8d-86b0-d1e8dd70fc6b
📒 Files selected for processing (4)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yamlpackages/installer/src/wizard/questions.js
Contributor
|
Solid contribution, @Silvino-Miranda! Angular 21 + NestJS is a popular enterprise stack and this preset fills a real gap in the wizard options. Implementation quality: The preset file is thorough — 711 lines covering 5 design patterns, project structure, coding standards, and testing strategy. I like that you followed the existing Specific observations:
One suggestion: The preset metadata lists Another minor thing: The Clean PR overall — good to merge once the Zod/class-validator clarification is addressed. Well done! |
github-actions
Bot
added
area: agents
There was a problem hiding this comment.
♻️ Duplicate comments (6)
.aiox-core/data/tech-presets/angular-nestjs.md (5)
271-279:⚠️ Potential issue | 🟠 MajorGuard against a missing
request.userbefore readingrole.If someone uses
@Roles()withoutJwtAuthGuardon a route, accessinguser.roleon line 279 will throw and turn an auth failure into a 500 error. Returningfalsewhenuseris absent keeps the guard safe to reuse.🛡️ Suggested fix
canActivate(context: ExecutionContext): boolean { const requiredRoles = this.reflector.getAllAndOverride<string[]>('roles', [ context.getHandler(), context.getClass(), ]); if (!requiredRoles) return true; const { user } = context.switchToHttp().getRequest(); - return requiredRoles.includes(user.role); + return !!user && requiredRoles.includes(user.role); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 271 - 279, The canActivate method reads user.role without checking that request.user exists; update canActivate (and the reflector.getAllAndOverride usage) to first get the request via context.switchToHttp().getRequest(), then if request.user is missing return false instead of accessing user.role, otherwise proceed to check requiredRoles.includes(user.role) so missing JwtAuthGuard won’t cause a 500.
236-239:⚠️ Potential issue | 🟡 MinorRemove
as anyto comply with the preset's own "Noany" rule.Line 238 uses
as anyto cast the form value, which directly violates the coding standard on line 478: "Noany: Useunknown+ type guard ou tipos explícitos."Since these snippets are likely to be copied directly, they should demonstrate proper typing instead of the escape hatch they're meant to avoid.
🔧 Suggested fix
Define a concrete type for the login form:
+interface LoginFormValue { + email: string; + password: string; +} + async onSubmit(): Promise<void> { if (this.form.invalid) return; - await this.auth.login(this.form.getRawValue() as any); + const credentials = this.form.getRawValue() as LoginFormValue; + await this.auth.login(credentials); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 236 - 239, Remove the unsafe "as any" in onSubmit; define a concrete type/interface (e.g. LoginForm { email: string; password: string; }) and ensure the FormGroup is typed or the value is asserted to that type before calling auth.login so auth.login receives a properly typed payload; update the form declaration (or use a typed local variable assigned from this.form.getRawValue()) and call auth.login(payload) instead of casting with as any in the onSubmit method.
90-113:⚠️ Potential issue | 🟠 MajorAdd missing
ConfigModuleandConfigServiceimports to theAuthModuleexample.The example uses
ConfigServiceon lines 102–106 without importing it or registeringConfigModulein the imports array. As written, dependency injection will fail at runtime.🔧 Suggested fix
import { Module } from '@nestjs/common'; +import { ConfigModule, ConfigService } from '@nestjs/config'; import { JwtModule } from '@nestjs/jwt'; import { AuthController } from './auth.controller'; import { AuthService } from './auth.service'; import { UserRepository } from './repositories/user.repository'; import { JwtStrategy } from './strategies/jwt.strategy'; `@Module`({ imports: [ + ConfigModule, JwtModule.registerAsync({ useFactory: (config: ConfigService) => ({ secret: config.get('JWT_SECRET'), signOptions: { expiresIn: '1h' }, }), inject: [ConfigService], }), ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 90 - 113, The AuthModule example uses ConfigService in JwtModule.registerAsync but never imports or registers it; fix by importing ConfigModule and ConfigService from '@nestjs/config' at the top of the file and adding ConfigModule to the `@Module` imports array alongside JwtModule.registerAsync so ConfigService is available for injection into the useFactory for JwtModule.registerAsync (update the import list and the imports: [...] entry in AuthModule).
185-203:⚠️ Potential issue | 🟠 MajorAvoid making
localStoragethe default JWT storage pattern.Using
localStoragefor auth tokens (lines 191, 200) bakes an XSS-sensitive default into a "best practices" preset. For this kind of guidance, prefer HttpOnly cookies or explicitly call out that this is a trade-off example rather than the recommended default.Consider either:
- Switch to HttpOnly cookies set from the server (remove client-side
localStorage.setItem/removeItemand rely on cookie-based auth with credentials)- Or, if keeping a client-side token example, introduce a
TokenStorageServiceabstraction and add a prominent comment explaining the security trade-offsThis prevents developers from inadvertently introducing XSS vulnerabilities by copying the example directly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 185 - 203, The preset currently writes and removes JWTs directly via localStorage in the login() and logout() flows (localStorage.setItem / removeItem), which bakes an XSS-sensitive pattern into the example; update the example to avoid this by either (A) removing client-side token persistence in login() / logout() and relying on server-set HttpOnly cookies with fetch/http requests using credentials, or (B) introduce a TokenStorageService abstraction used by login() and logout() (e.g., TokenStorageService.setToken/getToken/removeToken) and add a prominent comment above the service and inside login()/logout() documenting the security trade-offs and recommending HttpOnly cookies for production. Ensure references to localStorage.setItem and removeItem are removed or delegated to the new service and that router.navigate calls remain unchanged.
42-73:⚠️ Potential issue | 🟠 MajorShow how shared interfaces integrate with NestJS request validation.
Pattern 1 presents shared TypeScript interfaces for the contract layer (lines 52-69). However, NestJS requires DTOs decorated with
class-validatordecorators for theValidationPipeto validate@Body()parameters at runtime. TypeScript interfaces are erased at compile time and cannot carry decorators.The comment on line 71 mentions "NestJS backend usa class-validator com o mesmo shape" but doesn't demonstrate how. To align with your validation rule (line 476), either:
Add a backend DTO example that implements or extends the shared interface and includes
class-validatordecorators:// backend/src/features/auth/dto/login-request.dto.ts import { IsEmail, IsString, MinLength } from 'class-validator'; import { LoginRequestDto as ILoginRequest } from '@shared/contracts/auth.contract'; export class LoginRequestDto implements ILoginRequest { `@IsEmail`() email: string; `@IsString`() `@MinLength`(8) password: string; }Or explicitly state that the shared interfaces are for typing only and must be paired with separate decorated NestJS DTO classes used in controllers.
This prevents readers from copying the interface directly into controllers, where validation would silently fail.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 42 - 73, The shared interfaces (e.g., LoginRequestDto, LoginResponseDto, UserDto in shared/contracts/auth.contract.ts) cannot be used for NestJS runtime validation because interfaces are erased; add a backend DTO class (e.g., a class LoginRequestDto in your backend DTO folder) that implements the shared interface and add class-validator decorators (IsEmail, IsString, MinLength, etc.) to each property, then reference that decorated DTO in controllers' `@Body`() parameters (with ValidationPipe enabled), or alternatively update the doc to explicitly state that shared interfaces are typing-only and must be paired with separate decorated NestJS DTO classes for runtime validation..aiox-core/data/entity-registry.yaml (1)
14088-14110:⚠️ Potential issue | 🟠 MajorMove scaffold modules from
dependenciestoplannedDeps, and add missing structural fields.Lines 14101-14104 currently model scaffold targets as hard dependencies, which can create incorrect registry edges. This entry is also missing
externalDeps,plannedDeps, andlifecycle.Suggested fix
angular-nestjs: path: .aiox-core/data/tech-presets/angular-nestjs.md layer: L3 type: data purpose: >- 'Arquitetura otimizada para aplicações fullstack com Angular 21 (Signals, Standalone Components) no frontend e NestJS (Modular, DI, Guards) no backend' keywords: - angular - nestjs - tech - preset usedBy: [] - dependencies: - - auth - - user - - jwt + dependencies: [] + externalDeps: [] + plannedDeps: + - auth + - user + - jwt + lifecycle: experimental adaptability: score: 0.5 constraints: [] extensionPoints: []🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/entity-registry.yaml around lines 14088 - 14110, The angular-nestjs registry entry incorrectly lists scaffold targets (auth, user, jwt) under dependencies; update the angular-nestjs block to move those module names from the dependencies field into a new plannedDeps array, and add the missing structural fields externalDeps (empty array if none) and lifecycle (e.g., an object or array consistent with other entries) so the entry includes externalDeps, plannedDeps, and lifecycle; ensure the existing adaptability and checksum/lastVerified fields remain unchanged and that the dependencies field only contains true runtime/package dependencies, not scaffolding targets.
🧹 Nitpick comments (1)
.aiox-core/data/tech-presets/angular-nestjs.md (1)
23-23: Clarify when to use Zod versus class-validator.The metadata lists Zod as a core technology (line 23), and the tech stack table mentions both class-validator for backend DTOs (line 427) and Zod for shared validation (line 428). However, all concrete examples throughout the preset use class-validator decorators (
@IsString(),@IsEmail(), etc.). This creates ambiguity for developers implementing the preset.To prevent confusion, add a brief note in the Tech Stack section or Coding Standards explaining:
- Use class-validator for NestJS DTO validation in controllers (as shown in examples)
- Use Zod for runtime schema validation in shared contracts or Angular forms where class-validator decorators cannot be used
This aligns with the reviewer's suggestion and helps developers understand the complementary roles of each library.
Also applies to: 427-428
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md at line 23, Add a short clarifying note to the Tech Stack or Coding Standards section explaining when to use class-validator versus Zod: specify that class-validator should be used for NestJS DTO validation in controllers (e.g., DTOs using `@IsString`, `@IsEmail` decorators) and that Zod should be used for runtime/shared schema validation (e.g., shared contracts or Angular form/runtime validation where decorators aren’t applicable); reference both "class-validator" and "Zod" by name so readers can map the guidance to the existing tech stack entries.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.aiox-core/data/entity-registry.yaml:
- Around line 14088-14110: The angular-nestjs registry entry incorrectly lists
scaffold targets (auth, user, jwt) under dependencies; update the angular-nestjs
block to move those module names from the dependencies field into a new
plannedDeps array, and add the missing structural fields externalDeps (empty
array if none) and lifecycle (e.g., an object or array consistent with other
entries) so the entry includes externalDeps, plannedDeps, and lifecycle; ensure
the existing adaptability and checksum/lastVerified fields remain unchanged and
that the dependencies field only contains true runtime/package dependencies, not
scaffolding targets.
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 271-279: The canActivate method reads user.role without checking
that request.user exists; update canActivate (and the
reflector.getAllAndOverride usage) to first get the request via
context.switchToHttp().getRequest(), then if request.user is missing return
false instead of accessing user.role, otherwise proceed to check
requiredRoles.includes(user.role) so missing JwtAuthGuard won’t cause a 500.
- Around line 236-239: Remove the unsafe "as any" in onSubmit; define a concrete
type/interface (e.g. LoginForm { email: string; password: string; }) and ensure
the FormGroup is typed or the value is asserted to that type before calling
auth.login so auth.login receives a properly typed payload; update the form
declaration (or use a typed local variable assigned from
this.form.getRawValue()) and call auth.login(payload) instead of casting with as
any in the onSubmit method.
- Around line 90-113: The AuthModule example uses ConfigService in
JwtModule.registerAsync but never imports or registers it; fix by importing
ConfigModule and ConfigService from '@nestjs/config' at the top of the file and
adding ConfigModule to the `@Module` imports array alongside
JwtModule.registerAsync so ConfigService is available for injection into the
useFactory for JwtModule.registerAsync (update the import list and the imports:
[...] entry in AuthModule).
- Around line 185-203: The preset currently writes and removes JWTs directly via
localStorage in the login() and logout() flows (localStorage.setItem /
removeItem), which bakes an XSS-sensitive pattern into the example; update the
example to avoid this by either (A) removing client-side token persistence in
login() / logout() and relying on server-set HttpOnly cookies with fetch/http
requests using credentials, or (B) introduce a TokenStorageService abstraction
used by login() and logout() (e.g.,
TokenStorageService.setToken/getToken/removeToken) and add a prominent comment
above the service and inside login()/logout() documenting the security
trade-offs and recommending HttpOnly cookies for production. Ensure references
to localStorage.setItem and removeItem are removed or delegated to the new
service and that router.navigate calls remain unchanged.
- Around line 42-73: The shared interfaces (e.g., LoginRequestDto,
LoginResponseDto, UserDto in shared/contracts/auth.contract.ts) cannot be used
for NestJS runtime validation because interfaces are erased; add a backend DTO
class (e.g., a class LoginRequestDto in your backend DTO folder) that implements
the shared interface and add class-validator decorators (IsEmail, IsString,
MinLength, etc.) to each property, then reference that decorated DTO in
controllers' `@Body`() parameters (with ValidationPipe enabled), or alternatively
update the doc to explicitly state that shared interfaces are typing-only and
must be paired with separate decorated NestJS DTO classes for runtime
validation.
---
Nitpick comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Line 23: Add a short clarifying note to the Tech Stack or Coding Standards
section explaining when to use class-validator versus Zod: specify that
class-validator should be used for NestJS DTO validation in controllers (e.g.,
DTOs using `@IsString`, `@IsEmail` decorators) and that Zod should be used for
runtime/shared schema validation (e.g., shared contracts or Angular form/runtime
validation where decorators aren’t applicable); reference both "class-validator"
and "Zod" by name so readers can map the guidance to the existing tech stack
entries.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f67e35ff-defe-4e2a-82a4-cb9ab8eaeb58
📒 Files selected for processing (4)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yamlpackages/installer/src/wizard/questions.js
vegasandre
approved these changes
Apr 12, 2026
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.aiox-core/data/tech-presets/angular-nestjs.md (1)
23-23: Clarify when to use Zod vs class-validator.The metadata lists
Zodas a core technology (line 23), and the tech stack table shows both Zod for "Schemas compartilhados" and class-validator for "Validação de DTOs" (lines 427-428). However, code examples exclusively useclass-validatordecorators.Consider adding a brief note explaining:
- Use class-validator with NestJS
ValidationPipefor runtime request validation- Use Zod for shared schema definitions in
/shared/contracts/or Angular form validationThis aligns with the reviewer feedback in the PR comments.
Also applies to: 427-428
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md at line 23, Update the Angular/NestJS tech preset to clarify when to use Zod vs class-validator: add a short note near the core tech list and the tech stack table stating that class-validator (used with NestJS ValidationPipe) should be used for runtime request/DTO validation in Nest controllers while Zod is intended for shared schema definitions (e.g., /shared/contracts/) and can also be used for Angular form validation; reference the terms "Zod", "class-validator", "ValidationPipe", and the shared contracts path so readers can find the examples and existing decorator-based DTO code.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Line 23: Update the Angular/NestJS tech preset to clarify when to use Zod vs
class-validator: add a short note near the core tech list and the tech stack
table stating that class-validator (used with NestJS ValidationPipe) should be
used for runtime request/DTO validation in Nest controllers while Zod is
intended for shared schema definitions (e.g., /shared/contracts/) and can also
be used for Angular form validation; reference the terms "Zod",
"class-validator", "ValidationPipe", and the shared contracts path so readers
can find the examples and existing decorator-based DTO code.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 991379f6-fa6a-4548-9175-79e669b1ac67
📒 Files selected for processing (4)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yamlpackages/installer/src/wizard/questions.js
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/installer/src/wizard/questions.js
- .aiox-core/data/entity-registry.yaml
Silvino-Miranda
added a commit
to Silvino-Miranda/aios-core
that referenced
this pull request
Apr 16, 2026
…nkraAI#569) - AC1: Fix entity-registry structure — move auth/user/jwt to plannedDeps, add externalDeps/lifecycle fields - AC2: Replace localStorage JWT storage with HttpOnly cookie pattern + security warning - AC3: Remove 'as any' casts — use LoginRequestDto cast and typed object destructuring - AC4: Add ConfigModule import to AuthModule (required for ConfigService injection) - AC5: Add NestJS DTO classes (LoginDto, UserResponseDto) with class-validator decorators alongside shared interfaces - AC6: Add null guard in RolesGuard before accessing user.role - AC7: Add Zod usage example (envSchema) to clarify Zod vs class-validator separation of concerns Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Silvino-Miranda
added a commit
to Silvino-Miranda/aios-core
that referenced
this pull request
Apr 16, 2026
…and package-lock - entity-registry: IDS hook updated checksum and lastUpdated after PR SynkraAI#569 fixes - settings.local.json: add auto-approved tool permissions from this session - package-lock.json: update after npm install (node_modules were missing) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Silvino-Miranda
added a commit
to Silvino-Miranda/aios-core
that referenced
this pull request
Apr 16, 2026
…nkraAI#569) - class-validator: NestJS request body DTOs, required by ValidationPipe (class-based, survives runtime) - Zod: shared schema parsing for env vars and API response shapes, NOT for ValidationPipe (erased at runtime) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
.aiox-core/data/tech-presets/angular-nestjs.md (1)
397-397:⚠️ Potential issue | 🟡 MinorAdd language identifiers to remaining plain-text fenced blocks.
These fences still fail MD040 and should be tagged (e.g.,
text).Also applies to: 589-589, 676-676, 696-696
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md at line 397, Several fenced code blocks in .aiox-core/data/tech-presets/angular-nestjs.md use plain triple-backtick fences with no language tag, causing MD040 warnings; update each plain ``` fenced block (the ones shown as just ``` in the diff) to include a language identifier (e.g., use ```text). Apply the same change to the other occurrences noted in the comment so every plain-text fenced block is tagged with a language identifier.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 59-62: The LoginResponseDto declares a cookie-based auth response
containing only user, but AuthService methods (e.g., AuthService.login,
AuthService.register or any method that currently returns
accessToken/refreshToken) still return token fields; update those methods to
return the same shape as LoginResponseDto (user only) and move token handling to
HttpOnly cookie setting (e.g., set cookies on the response object) so the
service/controller returns a user-only payload; ensure all other occurrences
noted (the other AuthService/response snippets) are changed to match
LoginResponseDto.
- Around line 89-99: The UserResponseDto snippet uses `@IsEmail`() but the import
list from 'class-validator' only includes IsString, IsUUID, IsIn; update the
import statement to include IsEmail so the decorator is available (modify the
import that contains IsString/IsUUID/IsIn to also import IsEmail) and ensure
UserResponseDto still exports correctly.
---
Duplicate comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Line 397: Several fenced code blocks in
.aiox-core/data/tech-presets/angular-nestjs.md use plain triple-backtick fences
with no language tag, causing MD040 warnings; update each plain ``` fenced block
(the ones shown as just ``` in the diff) to include a language identifier (e.g.,
use ```text). Apply the same change to the other occurrences noted in the
comment so every plain-text fenced block is tagged with a language identifier.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 3510dacb-28a8-4ad6-a195-f96864a2e9c9
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yaml.claude/settings.local.json
✅ Files skipped from review due to trivial changes (1)
- .claude/settings.local.json
🚧 Files skipped from review as they are similar to previous changes (1)
- .aiox-core/data/entity-registry.yaml
There was a problem hiding this comment.
♻️ Duplicate comments (3)
.aiox-core/data/tech-presets/angular-nestjs.md (3)
89-99:⚠️ Potential issue | 🟠 MajorImport mismatch:
@IsEmail()is used but not imported.Line 98 uses
@IsEmail(), but Line 89 does not importIsEmailfromclass-validator. This snippet won’t compile when copied.Suggested fix
-import { IsString, IsUUID, IsIn } from 'class-validator'; +import { IsEmail, IsIn, IsString, IsUUID } from 'class-validator';#!/bin/bash # Verify decorator usage/import mismatch in the preset snippet rg -n "IsEmail|class-validator" .aiox-core/data/tech-presets/angular-nestjs.md -C2🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 89 - 99, The UserResponseDto snippet uses the `@IsEmail`() decorator but the import list at the top does not include IsEmail; update the import from class-validator to include IsEmail (alongside IsString, IsUUID, IsIn) so the decorator is properly resolved for the UserResponseDto class and the snippet compiles.
397-455:⚠️ Potential issue | 🟡 MinorAdd language identifiers to fenced code blocks (MD040).
The fences starting at Lines 397, 589, 676, and 696 are untyped. Add
text/plaintextto keep markdownlint clean.Suggested fix
-``` +```text ... -``` +```Also applies to: 589-597, 676-681, 696-701
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 397 - 455, The Markdown file contains untyped fenced code blocks showing the project tree; update each opening fence (the triple backticks that precede the ASCII tree blocks) to include a language identifier such as text or plaintext so markdownlint rule MD040 is satisfied. Locate the untitled fences around the ASCII project tree (the blocks that start with the three backticks before the tree diagram) and change them to start with ```text (or ```plaintext) for each occurrence reported in the comment.
59-62:⚠️ Potential issue | 🟠 MajorAuth response contract is inconsistent across snippets.
Lines 59-62 define cookie-based
LoginResponseDtowithuseronly, but Lines 176-179 still returnaccessToken,refreshToken, andexpiresIn. This creates implementation drift in a copy-paste preset.Suggested fix (cookie-based flow)
- const payload = { sub: user.id, email: user.email, role: user.role }; return { - accessToken: this.jwtService.sign(payload), - refreshToken: this.jwtService.sign(payload, { expiresIn: '7d' }), - expiresIn: 3600, user: { id: user.id, email: user.email, name: user.name, role: user.role }, };Also applies to: 168-180
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 59 - 62, The auth response contract is inconsistent: LoginResponseDto is defined for cookie-based auth (only user) but another snippet still returns accessToken, refreshToken, and expiresIn; update the implementation to match the cookie-based contract by removing accessToken, refreshToken, and expiresIn from the login response and ensure the login handler (e.g., AuthController.login or whatever function returns the login payload) only returns the UserDto inside LoginResponseDto and relies on HttpOnly cookie setting for tokens; also update any related DTO/comments to reflect the cookie-based flow so all snippets consistently use LoginResponseDto with only the user field.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 89-99: The UserResponseDto snippet uses the `@IsEmail`() decorator
but the import list at the top does not include IsEmail; update the import from
class-validator to include IsEmail (alongside IsString, IsUUID, IsIn) so the
decorator is properly resolved for the UserResponseDto class and the snippet
compiles.
- Around line 397-455: The Markdown file contains untyped fenced code blocks
showing the project tree; update each opening fence (the triple backticks that
precede the ASCII tree blocks) to include a language identifier such as text or
plaintext so markdownlint rule MD040 is satisfied. Locate the untitled fences
around the ASCII project tree (the blocks that start with the three backticks
before the tree diagram) and change them to start with ```text (or ```plaintext)
for each occurrence reported in the comment.
- Around line 59-62: The auth response contract is inconsistent:
LoginResponseDto is defined for cookie-based auth (only user) but another
snippet still returns accessToken, refreshToken, and expiresIn; update the
implementation to match the cookie-based contract by removing accessToken,
refreshToken, and expiresIn from the login response and ensure the login handler
(e.g., AuthController.login or whatever function returns the login payload) only
returns the UserDto inside LoginResponseDto and relies on HttpOnly cookie
setting for tokens; also update any related DTO/comments to reflect the
cookie-based flow so all snippets consistently use LoginResponseDto with only
the user field.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 78065d39-a308-457e-91a7-3c11e344aea9
📒 Files selected for processing (2)
.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- .aiox-core/install-manifest.yaml
Silvino-Miranda
added a commit
to Silvino-Miranda/aios-core
that referenced
this pull request
Apr 16, 2026
…ular-nestjs preset Reviewer suggestion (nikolasdehor, PR SynkraAI#569): monorepo layout with shared/contracts/ is designed to be extensible — score of 0.5 was too conservative. Added extensionPoints: shared/contracts/ and backend/src/features/. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Silvino-Miranda
added a commit
to Silvino-Miranda/aios-core
that referenced
this pull request
Apr 16, 2026
…ynkraAI#569) - Fix auth response shape: service now sets HttpOnly cookie and returns {user} only - Add logout endpoint in controller to clear cookie - Add missing IsEmail to class-validator imports in UserResponseDto - Add language identifiers to 4 fenced code blocks (MD040 compliance) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Author
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
.aiox-core/data/entity-registry.yaml (1)
14101-14109:⚠️ Potential issue | 🟠 MajorKeep scaffold targets out of
dependencies.
auth,user, andjwtare still modeled as concretedependencieseven though this entry already treats them asplannedDeps. That makes this preset diverge from the siblingnextjs-reactpattern and can create misleading registry edges for modules that are only intended scaffold targets.Suggested fix
- dependencies: - - auth - - user - - jwt + dependencies: [] externalDeps: [] plannedDeps: - auth - user - jwt🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/entity-registry.yaml around lines 14101 - 14109, Remove scaffold-only targets from the concrete dependencies list: delete "auth", "user", and "jwt" from the dependencies array and leave them only in plannedDeps (keep externalDeps as-is) so this preset matches the sibling nextjs-react pattern and avoids creating real registry edges for scaffold targets.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 653-656: The test calls service.login with a single argument but
the real method signature is login(dto, res); update the unit test to import
Response (from 'express'), create a mock Response object (e.g. const res = {
cookie: jest.fn(), status: jest.fn().mockReturnThis(), json: jest.fn() } as
unknown as Response), pass that res into service.login (service.login({ email:
'x@x.com', password: '123' }, res)), and keep the existing userRepo.findByEmail
mock and the expect(...).rejects.toThrow assertion; this will allow the test to
compile and correctly exercise the login(dto, res) path.
- Around line 674-679: Test setup for TestBed.configureTestingModule only
imports HttpClientTestingModule but AuthService uses inject(Router), so tests
will fail without a Router provider; update the TestBed configuration (the call
to TestBed.configureTestingModule around where service =
TestBed.inject(AuthService) and http = TestBed.inject(HttpTestingController) are
set) to provide a Router by either adding RouterTestingModule to imports or
adding a providers entry that supplies a mock Router (e.g., provide Router with
a minimal useValue/mock) so TestBed can resolve the Router when constructing
AuthService.
---
Duplicate comments:
In @.aiox-core/data/entity-registry.yaml:
- Around line 14101-14109: Remove scaffold-only targets from the concrete
dependencies list: delete "auth", "user", and "jwt" from the dependencies array
and leave them only in plannedDeps (keep externalDeps as-is) so this preset
matches the sibling nextjs-react pattern and avoids creating real registry edges
for scaffold targets.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 36724b61-4442-484c-a2ec-6555a11299d7
📒 Files selected for processing (3)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yaml
…angular-nestjs tech preset
…nkraAI#569) - AC1: Fix entity-registry structure — move auth/user/jwt to plannedDeps, add externalDeps/lifecycle fields - AC2: Replace localStorage JWT storage with HttpOnly cookie pattern + security warning - AC3: Remove 'as any' casts — use LoginRequestDto cast and typed object destructuring - AC4: Add ConfigModule import to AuthModule (required for ConfigService injection) - AC5: Add NestJS DTO classes (LoginDto, UserResponseDto) with class-validator decorators alongside shared interfaces - AC6: Add null guard in RolesGuard before accessing user.role - AC7: Add Zod usage example (envSchema) to clarify Zod vs class-validator separation of concerns Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…and package-lock - entity-registry: IDS hook updated checksum and lastUpdated after PR SynkraAI#569 fixes - settings.local.json: add auto-approved tool permissions from this session - package-lock.json: update after npm install (node_modules were missing) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…nkraAI#569) - class-validator: NestJS request body DTOs, required by ValidationPipe (class-based, survives runtime) - Zod: shared schema parsing for env vars and API response shapes, NOT for ValidationPipe (erased at runtime) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ular-nestjs preset Reviewer suggestion (nikolasdehor, PR SynkraAI#569): monorepo layout with shared/contracts/ is designed to be extensible — score of 0.5 was too conservative. Added extensionPoints: shared/contracts/ and backend/src/features/. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ynkraAI#569) - Fix auth response shape: service now sets HttpOnly cookie and returns {user} only - Add logout endpoint in controller to clear cookie - Add missing IsEmail to class-validator imports in UserResponseDto - Add language identifiers to 4 fenced code blocks (MD040 compliance) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ynkraAI#569) - Restore plannedDeps, externalDeps, lifecycle, score:0.7 and extensionPoints in entity-registry (reverted by IDS hook during rebase) - Add RouterTestingModule to Angular TestBed (AuthService uses inject(Router)) - Add Response mock to NestJS login() test (method signature requires dto + res)
Author
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 5
♻️ Duplicate comments (1)
.aiox-core/data/tech-presets/angular-nestjs.md (1)
631-656:⚠️ Potential issue | 🟠 MajorImport the Express
Responsetype in the NestJS test snippet.The test now passes
mockRes, butResponseis still not imported. In Node/TS projects this can either fail or resolve to the wrong global fetchResponsetype.Suggested fix
import { Test, TestingModule } from '@nestjs/testing'; import { JwtService } from '@nestjs/jwt'; +import { Response } from 'express'; import { AuthService } from './auth.service'; import { UserRepository } from './repositories/user.repository';#!/bin/bash # Verify the test snippet references Response without importing it from express. sed -n '629,657p' .aiox-core/data/tech-presets/angular-nestjs.md🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 631 - 656, The test passes a mockRes typed as Response but Response is not imported; update the imports at the top of the test file to import the Express Response type (so the mockRes = { cookie: ... } is correctly typed), e.g., add an import for Response from 'express' alongside Test/TestingModule/JwtService, then keep the mockRes cast (as unknown as Response) and re-run the tests to verify the type resolution for service.login and userRepo usage remains correct.
🧹 Nitpick comments (1)
.aiox-core/data/tech-presets/angular-nestjs.md (1)
279-307: UseNonNullableFormBuilderto avoid casting nullable form values.
FormBuilder.group()creates nullable controls by default, sogetRawValue() as LoginRequestDtobypasses type-safety. This preset promotes type-safety, so useNonNullableFormBuilderinstead.Suggested refactor
-import { ReactiveFormsModule, FormBuilder, Validators } from '@angular/forms'; +import { ReactiveFormsModule, NonNullableFormBuilder, Validators } from '@angular/forms'; @@ - private readonly fb = inject(FormBuilder); + private readonly fb = inject(NonNullableFormBuilder); @@ - await this.auth.login(this.form.getRawValue() as LoginRequestDto); + await this.auth.login(this.form.getRawValue());🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 279 - 307, The form uses nullable controls and casts getRawValue to LoginRequestDto; switch to NonNullableFormBuilder to make controls non-nullable: replace the FormBuilder import with NonNullableFormBuilder, change the injected fb instance type to inject(NonNullableFormBuilder) (or type the fb variable as NonNullableFormBuilder), and ensure the form definition on LoginComponent uses that fb so its form group controls are non-nullable; then update onSubmit to call this.auth.login(this.form.getRawValue()) without the unsafe "as LoginRequestDto" cast.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 169-172: The login method calls this.verifyPassword(dto.password,
user.passwordHash) but verifyPassword is missing; add an async
verifyPassword(password: string, hash: string): Promise<boolean> method on the
same class (or mark it with a clear TODO) that uses a real verifier (e.g.,
bcrypt.compare or argon2.verify) and returns true/false, ensure the appropriate
import (bcrypt or argon2) is added and that the login method awaits the result;
alternatively, add a TODO stub with the same signature that throws or returns
false so consumers know to implement it.
- Around line 267-271: In logout(), wait for the backend logout call to complete
and handle errors before clearing local state and navigating: replace the
fire-and-forget this.http.post('/api/auth/logout', ..., { withCredentials: true
}).subscribe() with logic that awaits or subscribes to the response (e.g., use
firstValueFrom or subscribe with next/error), only call this._user.set(null) and
this.router.navigate(['/login']) on success, and handle/log errors (and decide
whether to still clear state) in the error handler; refer to the logout() method
and the HTTP POST to '/api/auth/logout' to locate where to make this change.
- Around line 514-519: The install instructions are missing the `@nestjs/config`
dependency required by the AuthModule which imports ConfigModule and
ConfigService; update the backend install step to include `@nestjs/config` (add it
to the npm install command that installs `@nestjs/jwt` etc.) so the
ConfigModule/ConfigService imports resolve correctly.
- Around line 541-547: Update the "Critical Rules" item about
DTOs/class-validator to state that decorating DTOs with `@IsString()`,
`@IsEmail()`, etc. must be paired with registering Nest's `ValidationPipe`
(globally or on the route) so validation actually runs; mention `ValidationPipe`
by name and reference the DTO/shared contracts convention (`/shared/contracts/`)
so readers know to enable `ValidationPipe` when using the DTO classes.
- Around line 140-143: The ConfigModule usage in the AuthModule is missing
startup validation for JWT_SECRET, so update ConfigModule.forRoot(...) to
include the validationSchema (as shown near the existing schema) or modify the
JwtModule registration factory (useFactory in the AuthModule) to assert the
presence of config.get<string>('JWT_SECRET') and throw an error if undefined;
specifically locate the ConfigModule.forRoot call and add the validationSchema
option, or inside the useFactory for JwtModule (which receives ConfigService)
check JWT_SECRET and throw a descriptive error so the app fails at startup
instead of at first token operation.
---
Duplicate comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 631-656: The test passes a mockRes typed as Response but Response
is not imported; update the imports at the top of the test file to import the
Express Response type (so the mockRes = { cookie: ... } is correctly typed),
e.g., add an import for Response from 'express' alongside
Test/TestingModule/JwtService, then keep the mockRes cast (as unknown as
Response) and re-run the tests to verify the type resolution for service.login
and userRepo usage remains correct.
---
Nitpick comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 279-307: The form uses nullable controls and casts getRawValue to
LoginRequestDto; switch to NonNullableFormBuilder to make controls non-nullable:
replace the FormBuilder import with NonNullableFormBuilder, change the injected
fb instance type to inject(NonNullableFormBuilder) (or type the fb variable as
NonNullableFormBuilder), and ensure the form definition on LoginComponent uses
that fb so its form group controls are non-nullable; then update onSubmit to
call this.auth.login(this.form.getRawValue()) without the unsafe "as
LoginRequestDto" cast.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: a657f30a-d7c0-4893-976a-443af96204b5
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yaml.claude/settings.local.jsonpackages/installer/src/wizard/questions.js
🚧 Files skipped from review as they are similar to previous changes (3)
- .claude/settings.local.json
- .aiox-core/install-manifest.yaml
- .aiox-core/data/entity-registry.yaml
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
📋 Description
Add Angular 21 + NestJS as a new tech preset option in the AIOX installation wizard. This enables developers using Angular (Signals, Standalone Components) on the frontend and NestJS on the backend to get architecture patterns, project structure, coding standards, and testing strategies tailored to their stack.
🎯 AIOX Story Reference
Story ID: N/A (community contribution)
Story File: N/A
Sprint: N/A
Acceptance Criteria Addressed
New angular-nestjs option appears in the Tech Preset wizard question
Preset file follows the existing _template.md structure
Includes 5 design patterns, project structure, tech stack, coding standards, testing strategy
🔗 Related Issue
N/A
📦 Type of Change
🐛 Bug fix (non-breaking change which fixes an issue)
✨ New feature (non-breaking change which adds functionality)
💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
📚 Documentation update
🔧 Refactoring (no functional changes)
⚡ Performance improvement
🧪 Test update
🎯 Scope
Core framework (aiox-core/)
Squad (squads)
Tools (tools/)
Documentation (docs)
CI/CD (.github)
Other: ________________
📝 Changes Made
Added angular-nestjs choice to getTechPresetQuestion() in questions.js
Created angular-nestjs.md (22KB) with:
5 Design Patterns: Contract (Shared DTOs), NestJS Module, Angular Signals + Service, NestJS Guard + Decorator, Builder (Tests)
Project Structure: Monorepo layout with frontend/, backend/, shared/contracts/
Tech Stack: Angular 21, NestJS 11+, Prisma, class-validator, Angular Material, Jest, Playwright
Coding Standards: Standalone Components, Signals over BehaviorSubject, inject() over constructor DI, Guards for auth
Testing Strategy: NestJS TestingModule + Angular HttpClientTestingModule templates
Patterns to Avoid: NgModules, BehaviorSubject, logic in controllers, any types
🧪 Testing
All existing tests pass
Manual testing completed
Added tests for new functionality
Tested on multiple platforms (if applicable)
Test Results
📸 Screenshots (if applicable)
N/A — CLI wizard change (new list option added).
✅ Checklist⚠️ Skipped (missing @eslint/js dep in local env)
My code follows the project's style guidelines
I have performed a self-review of my code
I have commented my code, particularly in hard-to-understand areas
I have updated the documentation accordingly
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published
🔒 Security
I have reviewed my code for security vulnerabilities
I have not introduced any new security issues
I have checked for sensitive data exposure
🐰 CodeRabbit Review
No CRITICAL issues found
No HIGH severity issues blocking merge
All CodeRabbit suggestions addressed or documented
📊 Quality Gates
Check Status
Lint
TypeCheck ✅ Passed
Tests ✅ 24/27 passed (3 pre-existing failures)
Coverage ⏳ Pending
CodeRabbit ⏳ Pending
📖 Documentation
Updated README.md (if needed)
Updated CHANGELOG.md
Updated API documentation (if applicable)
Added code comments (if applicable)
👥 Reviewers
@SynkraAI
🚀 Deployment Notes
No migration needed. Non-breaking addition — new preset option is additive only.
Summary by CodeRabbit
New Features
Documentation
Chores