@aurorajs.dev/catalyst-cli 1.1.3 → 2.0.0

package/dist/templates/frontend/packages/iam/src/app/domains/admin/apps/iam/role/features/role-form.component.ts

@@ -83,6 +83,14 @@ import { type IamRole } from '@src/src/app/aurora.types';
           }
         </hlm-field>
         <hlm-field class="col-span-12 pt-9 md:col-span-3">
+          <!-- No 'for' on the label: hlm-switch registers the BrnLabelable that BrnLabel
+               reads for [attr.for], and the label also wraps the switch so BrnSwitch finds
+               it via closest(label). A static 'for' would WIN over that binding and could
+               then disagree with the id the switch really renders. -->
+          <!-- has-data-checked:bg-transparent cancels the tint that HlmFieldLabel paints
+               when a checkable control inside it is on. Spartan means that as a card
+               affordance; a switch row does not want it. Neutralized here instead of in
+               the vendored directive, so a Spartan update cannot silently bring it back. -->
           <label
             class="flex items-center has-data-checked:bg-transparent dark:has-data-checked:bg-transparent"
             hlmFieldLabel
@@ -96,7 +104,15 @@ import { type IamRole } from '@src/src/app/aurora.types';
           </label>
         </hlm-field>
 
-        <hlm-field class="col-span-12 pt-9 md:col-span-3">
+        <hlm-field class="col-span-12 pt-9 md:col-span-9">
+          <!-- No 'for' on the label: hlm-switch registers the BrnLabelable that BrnLabel
+               reads for [attr.for], and the label also wraps the switch so BrnSwitch finds
+               it via closest(label). A static 'for' would WIN over that binding and could
+               then disagree with the id the switch really renders. -->
+          <!-- has-data-checked:bg-transparent cancels the tint that HlmFieldLabel paints
+               when a checkable control inside it is on. Spartan means that as a card
+               affordance; a switch row does not want it. Neutralized here instead of in
+               the vendored directive, so a Spartan update cannot silently bring it back. -->
           <label
             class="flex items-center has-data-checked:bg-transparent dark:has-data-checked:bg-transparent"
             hlmFieldLabel
@@ -117,6 +133,18 @@ export class RoleFormComponent {
   // inputs
   readonly initial = input<IamRole | null>(null);
   readonly mode = input.required<'new' | 'edit'>();
+  // createOnly (add-create-only-property-semantics): distinct from `mode`,
+  // which stays the ROUTE/presentation mode — it drives the verb and title
+  // upstream (view-frame.eta, the detail shell's breadcrumb) and is
+  // untouched by this input. `transportMode`, when bound, is the mode this
+  // save actually travels as. The two diverge on an embedded-i18n
+  // aggregate's "create the first translation of an EXISTING row" route
+  // (`new/:id/:langId`): the route mode is 'new', but the row already
+  // exists, so the save goes out as an update. Optional and always
+  // declared (like `mode`) — falls back to `mode()` wherever the caller has
+  // nothing different to report, which is every non-i18n or table-strategy
+  // caller.
+  readonly transportMode = input<'new' | 'edit'>();
 
   // outputs
   readonly save = output<IamRole>();

package/dist/templates/frontend/packages/iam/src/app/domains/admin/apps/iam/role-account/data-access/role-account.graphql.ts

@@ -52,6 +52,7 @@ export const iamRoleAccountFields: TypedDocumentNode<IamRoleAccountFieldsFragmen
       dApplicationCodes
       dPermissions
       dTenants
+      hasAddChildTenants
       meta
     }
   }

package/dist/templates/frontend/packages/iam/src/app/domains/admin/apps/iam/tenant/data-access/tenant.graphql.ts

@@ -63,6 +63,7 @@ export const iamTenantFields: TypedDocumentNode<IamTenantFieldsFragment, unknown
       dApplicationCodes
       dPermissions
       dTenants
+      hasAddChildTenants
       meta
     }
     createdAt

package/dist/templates/frontend/packages/iam/src/app/domains/admin/apps/iam/tenant/features/tenant-form.component.ts

@@ -87,8 +87,15 @@ import { type IamTenant } from '@src/src/app/aurora.types';
             </hlm-field-error>
           }
         </hlm-field>
-
         <hlm-field class="col-span-12 pt-9 md:col-span-12">
+          <!-- No 'for' on the label: hlm-switch registers the BrnLabelable that BrnLabel
+               reads for [attr.for], and the label also wraps the switch so BrnSwitch finds
+               it via closest(label). A static 'for' would WIN over that binding and could
+               then disagree with the id the switch really renders. -->
+          <!-- has-data-checked:bg-transparent cancels the tint that HlmFieldLabel paints
+               when a checkable control inside it is on. Spartan means that as a card
+               affordance; a switch row does not want it. Neutralized here instead of in
+               the vendored directive, so a Spartan update cannot silently bring it back. -->
           <label
             class="flex items-center has-data-checked:bg-transparent dark:has-data-checked:bg-transparent"
             hlmFieldLabel
@@ -109,6 +116,18 @@ export class TenantFormComponent {
   // inputs
   readonly initial = input<IamTenant | null>(null);
   readonly mode = input.required<'new' | 'edit'>();
+  // createOnly (add-create-only-property-semantics): distinct from `mode`,
+  // which stays the ROUTE/presentation mode — it drives the verb and title
+  // upstream (view-frame.eta, the detail shell's breadcrumb) and is
+  // untouched by this input. `transportMode`, when bound, is the mode this
+  // save actually travels as. The two diverge on an embedded-i18n
+  // aggregate's "create the first translation of an EXISTING row" route
+  // (`new/:id/:langId`): the route mode is 'new', but the row already
+  // exists, so the save goes out as an update. Optional and always
+  // declared (like `mode`) — falls back to `mode()` wherever the caller has
+  // nothing different to report, which is every non-i18n or table-strategy
+  // caller.
+  readonly transportMode = input<'new' | 'edit'>();
 
   // outputs
   readonly save = output<IamTenant>();

package/dist/templates/frontend/packages/iam/src/app/domains/admin/apps/iam/tenant-account/data-access/tenant-account.graphql.ts

@@ -53,6 +53,7 @@ export const iamTenantAccountFields: TypedDocumentNode<IamTenantAccountFieldsFra
         dApplicationCodes
         dPermissions
         dTenants
+        hasAddChildTenants
         meta
       }
     }

package/dist/templates/frontend/packages/o-auth/public/i18n/o-auth/en.json

@@ -95,4 +95,4 @@
     "ScopeDetailsDescription": "Fill in the scope information.",
     "Title": "Scopes"
   }
-}
+}

package/dist/templates/frontend/packages/o-auth/public/i18n/o-auth/es.json

@@ -96,4 +96,4 @@
     "ScopeDetailsDescription": "Rellena la información del scope.",
     "Title": "Scopes"
   }
-}
+}

package/dist/templates/frontend/packages/o-auth/src/app/domains/admin/apps/o-auth/application/features/application-form.component.ts

@@ -4,7 +4,7 @@
  */
 import { Component, input, linkedSignal, output } from '@angular/core';
 import { form, FormField, maxLength, required, submit } from '@angular/forms/signals';
-import { ValidationMessagePipe } from '@aurora';
+import { AuroraPasswordInput, HlmPasswordStrength, ValidationMessagePipe } from '@aurora';
 import { provideTranslocoScope, TranslocoDirective } from '@jsverse/transloco';
 import { HlmFieldImports } from '@spartan-ng/helm/field';
 import { HlmInputImports } from '@spartan-ng/helm/input';
@@ -20,6 +20,8 @@ import { type OAuthApplication } from '@src/src/app/aurora.types';
     HlmFieldImports,
     HlmInputImports,
     HlmSwitchImports,
+    AuroraPasswordInput,
+    HlmPasswordStrength,
   ],
   providers: [provideTranslocoScope('o-auth')],
   template: `
@@ -76,7 +78,7 @@ import { type OAuthApplication } from '@src/src/app/aurora.types';
         </hlm-field>
         <!-- #region customizations -->
         @if (mode() === 'new') {
-          <hlm-field class="col-span-12 md:col-span-12">
+          <hlm-field class="col-span-12 md:col-span-6">
             <label hlmFieldLabel>
               {{ t('o-auth.application.Secret') }}
               <span
@@ -86,11 +88,12 @@ import { type OAuthApplication } from '@src/src/app/aurora.types';
                 *
               </span>
             </label>
-            <input
-              id="secret"
-              [attr.aria-required]="mode() === 'new'"
+            <aurora-password-input
+              [inputId]="'secret'"
               [formField]="signalForm.secret"
-              hlmInput
+              [showPasswordLabel]="t('ShowPassword')"
+              [hidePasswordLabel]="t('HidePassword')"
+              [generatePasswordLabel]="t('GeneratePassword')"
             />
             @for (error of signalForm.secret().errors(); track error.kind) {
               <hlm-field-error [validator]="error.kind">
@@ -98,9 +101,23 @@ import { type OAuthApplication } from '@src/src/app/aurora.types';
               </hlm-field-error>
             }
           </hlm-field>
+          <div class="col-span-12 md:col-span-6">
+            <au-hlm-password-strength
+              [password]="signalForm.secret().value()"
+              [rules]="passwordRules"
+            />
+          </div>
         }
         <!-- #endregion customizations -->
-        <hlm-field class="col-span-12 pt-9 md:col-span-3">
+        <hlm-field class="col-span-12 pt-9 md:col-span-6">
+          <!-- No 'for' on the label: hlm-switch registers the BrnLabelable that BrnLabel
+               reads for [attr.for], and the label also wraps the switch so BrnSwitch finds
+               it via closest(label). A static 'for' would WIN over that binding and could
+               then disagree with the id the switch really renders. -->
+          <!-- has-data-checked:bg-transparent cancels the tint that HlmFieldLabel paints
+               when a checkable control inside it is on. Spartan means that as a card
+               affordance; a switch row does not want it. Neutralized here instead of in
+               the vendored directive, so a Spartan update cannot silently bring it back. -->
           <label
             class="flex items-center has-data-checked:bg-transparent dark:has-data-checked:bg-transparent"
             hlmFieldLabel
@@ -121,6 +138,18 @@ export class ApplicationFormComponent {
   // inputs
   readonly initial = input<OAuthApplication | null>(null);
   readonly mode = input.required<'new' | 'edit'>();
+  // createOnly (add-create-only-property-semantics): distinct from `mode`,
+  // which stays the ROUTE/presentation mode — it drives the verb and title
+  // upstream (view-frame.eta, the detail shell's breadcrumb) and is
+  // untouched by this input. `transportMode`, when bound, is the mode this
+  // save actually travels as. The two diverge on an embedded-i18n
+  // aggregate's "create the first translation of an EXISTING row" route
+  // (`new/:id/:langId`): the route mode is 'new', but the row already
+  // exists, so the save goes out as an update. Optional and always
+  // declared (like `mode`) — falls back to `mode()` wherever the caller has
+  // nothing different to report, which is every non-i18n or table-strategy
+  // caller.
+  readonly transportMode = input<'new' | 'edit'>();
 
   // outputs
   readonly save = output<OAuthApplication>();
@@ -152,6 +181,13 @@ export class ApplicationFormComponent {
     required(path.secret, { when: () => this.mode() === 'new' });
     maxLength(path.secret, 255);
   });
+  protected readonly passwordRules = {
+    minLength: 8,
+    digit: true,
+    specialCharacter: true,
+    lowerCase: true,
+    upperCase: true,
+  };
 
   submit(): void {
     submit(this.signalForm, async () => {

package/dist/templates/frontend/packages/o-auth/src/app/domains/admin/apps/o-auth/application/features/application-list.component.ts

@@ -265,8 +265,7 @@ export default class ApplicationListComponent {
 
   constructor() {
     const seed = this.route.snapshot.data['pagination'] as
-      | DataTableData<OAuthApplication>
-      | undefined;
+      DataTableData<OAuthApplication> | undefined;
     if (seed) this.paginated.seed(seed);
   }
 

package/dist/templates/frontend/packages/o-auth/src/app/domains/admin/apps/o-auth/authorization-code/features/authorization-code-form.component.ts

@@ -4,7 +4,7 @@
  */
 import { Component, input, linkedSignal, output } from '@angular/core';
 import { form, FormField, maxLength, required, submit } from '@angular/forms/signals';
-import { DateTimePicker, toWireDateTime, ValidationMessagePipe } from '@aurora';
+import { DateTimePicker, ValidationMessagePipe } from '@aurora';
 import { provideTranslocoScope, TranslocoDirective } from '@jsverse/transloco';
 import { HlmFieldImports } from '@spartan-ng/helm/field';
 import { HlmInputImports } from '@spartan-ng/helm/input';
@@ -75,7 +75,6 @@ import { type OAuthAuthorizationCode } from '@src/src/app/aurora.types';
             </hlm-field-error>
           }
         </hlm-field>
-
         <hlm-field class="col-span-12 md:col-span-12">
           <label hlmFieldLabel>
             {{ t('o-auth.authorization-code.CodeChallenge') }}
@@ -128,6 +127,14 @@ import { type OAuthAuthorizationCode } from '@src/src/app/aurora.types';
         </hlm-field>
 
         <hlm-field class="col-span-12 pt-9 md:col-span-5">
+          <!-- No 'for' on the label: hlm-switch registers the BrnLabelable that BrnLabel
+               reads for [attr.for], and the label also wraps the switch so BrnSwitch finds
+               it via closest(label). A static 'for' would WIN over that binding and could
+               then disagree with the id the switch really renders. -->
+          <!-- has-data-checked:bg-transparent cancels the tint that HlmFieldLabel paints
+               when a checkable control inside it is on. Spartan means that as a card
+               affordance; a switch row does not want it. Neutralized here instead of in
+               the vendored directive, so a Spartan update cannot silently bring it back. -->
           <label
             class="flex items-center has-data-checked:bg-transparent dark:has-data-checked:bg-transparent"
             hlmFieldLabel
@@ -148,6 +155,18 @@ export class AuthorizationCodeFormComponent {
   // inputs
   readonly initial = input<OAuthAuthorizationCode | null>(null);
   readonly mode = input.required<'new' | 'edit'>();
+  // createOnly (add-create-only-property-semantics): distinct from `mode`,
+  // which stays the ROUTE/presentation mode — it drives the verb and title
+  // upstream (view-frame.eta, the detail shell's breadcrumb) and is
+  // untouched by this input. `transportMode`, when bound, is the mode this
+  // save actually travels as. The two diverge on an embedded-i18n
+  // aggregate's "create the first translation of an EXISTING row" route
+  // (`new/:id/:langId`): the route mode is 'new', but the row already
+  // exists, so the save goes out as an update. Optional and always
+  // declared (like `mode`) — falls back to `mode()` wherever the caller has
+  // nothing different to report, which is every non-i18n or table-strategy
+  // caller.
+  readonly transportMode = input<'new' | 'edit'>();
 
   // outputs
   readonly save = output<OAuthAuthorizationCode>();
@@ -176,7 +195,7 @@ export class AuthorizationCodeFormComponent {
       scopes: init?.scopes ?? null,
       codeChallenge: init?.codeChallenge ?? '',
       codeChallengeMethod: init?.codeChallengeMethod ?? '',
-      expiresAt: toWireDateTime(init?.expiresAt),
+      expiresAt: init?.expiresAt ?? null,
       isUsed: init?.isUsed ?? false,
     };
   });

package/dist/templates/frontend/packages/o-auth/src/app/domains/admin/apps/o-auth/authorization-code/features/authorization-code-list.component.ts

@@ -276,8 +276,7 @@ export default class AuthorizationCodeListComponent {
 
   constructor() {
     const seed = this.route.snapshot.data['pagination'] as
-      | DataTableData<OAuthAuthorizationCode>
-      | undefined;
+      DataTableData<OAuthAuthorizationCode> | undefined;
     if (seed) this.paginated.seed(seed);
   }
 

package/dist/templates/frontend/packages/o-auth/src/app/domains/admin/apps/o-auth/o-auth.routes.ts

@@ -3,12 +3,12 @@
  * @source cliter/o-auth
  */
 import type { Routes } from '@angular/router';
-import { accessTokenListResolver } from './access-token/data-access/access-token.resolvers';
-import { applicationListResolver } from './application/data-access/application.resolvers';
-import { authorizationCodeListResolver } from './authorization-code/data-access/authorization-code.resolvers';
-import { clientListResolver } from './client/data-access/client.resolvers';
-import { refreshTokenListResolver } from './refresh-token/data-access/refresh-token.resolvers';
-import { scopeListResolver } from './scope/data-access/scope.resolvers';
+import { accessTokenListResolver } from './access-token/data-access';
+import { applicationListResolver } from './application/data-access';
+import { authorizationCodeListResolver } from './authorization-code/data-access';
+import { clientListResolver } from './client/data-access';
+import { refreshTokenListResolver } from './refresh-token/data-access';
+import { scopeListResolver } from './scope/data-access';
 
 export const oAuthRoutes: Routes = [
   {

package/dist/templates/monorepo/.backlog/config.yml

@@ -17,6 +17,9 @@ labels:
     "lane:frontier",
     "path:direct",
     "path:sdd",
+    "mode:headless",
+    "mode:supervised",
+    "board:graph",
   ]
 definition_of_done:
   - "Scoped tests pass with the command declared in the task"

package/dist/templates/monorepo/.claude/agents/jd-fix-agent.md

@@ -1,8 +1,8 @@
 ---
 name: jd-fix-agent
 description: >
-  Surgical fix agent for judgment-day protocol. Applies only confirmed fixes
-  from the verdict synthesis. Triggered by the orchestrator after judges agree on issues.
+  Applies only the fixes the orchestrator verified against the code. Triggered
+  by the orchestrator after severe findings are verified.
 model: sonnet
 tools: Read, Edit, Write, Glob, Grep, Bash
 ---
@@ -12,21 +12,24 @@ provided in the delegate prompt exactly.
 
 ## Rules
 - Do NOT use the Task/Agent tool. Do NOT delegate further.
-- Fix ONLY the confirmed issues listed in the delegate prompt.
+- Fix ONLY the verified issues listed in the delegate prompt.
 - Do NOT refactor beyond what is strictly needed to fix each issue.
 - Do NOT change code that was not flagged.
 - After each fix, note: file changed, line changed, what was done.
-- Treat the round as one bounded correction transaction composed of atomic work units tied only to confirmed ledger IDs.
+- Treat the round as one bounded correction transaction composed of atomic work units tied only to verified ledger IDs.
 - For each work unit, record its focused test result, runtime evidence or justified `N/A`, and independent rollback boundary.
 - Return a summary: ## Fixes Applied - [file:line] — {what was fixed}
-- At the end, include: **Skill Resolution**: {injected|fallback-registry|fallback-path|none} — {details}
+- At the end, include:
+
+skill_resolution: <paths-injected | fallback-registry | fallback-footer | none>
+status: <completed | needs-guidance>
 
 ## Review ledger contract (fix agent role)
 
 This agent does NOT run the first-pass review sweep and does NOT emit a findings ledger — that is the judge role's job, not this agent's.
 
-**Read the persisted ledger.** Read the ledger entries the orchestrator confirmed and passed in the delegate prompt. Apply only those confirmed fixes.
+**Read the persisted ledger.** Read the ledger entries the orchestrator verified and passed in the delegate prompt. Apply only those verified fixes.
 
-**Update status, do not add rows.** After fixing a confirmed entry, set that entry's `status` to `fixed`. Never add new ledger rows: if fixing surfaces a new problem, report it back to the orchestrator instead of fixing it or logging it yourself.
+**Update status, do not add rows.** After fixing a verified entry, set that entry's `status` to `fixed`. Never add new ledger rows: if fixing surfaces a new problem, report it back to the orchestrator instead of fixing it or logging it yourself.
 
-**Execution mode.** This agent receives confirmed findings from the parent orchestrator, applies only those atomic work units, and hands control back. Only the parent may launch the scoped re-judgment, within the native two-round Judgment Day budget.
+**Execution mode.** This agent receives verified findings from the parent orchestrator, applies only those atomic work units, and hands control back. Only the parent may launch the scoped re-judgment, within the native two-round Judgment Day budget.

package/dist/templates/monorepo/.claude/agents/jd-judge-a.md

@@ -16,7 +16,7 @@ provided in the delegate prompt exactly.
 - Do NOT modify any code — your job is ONLY to find problems.
 - Be thorough and adversarial. Assume the code has bugs until proven otherwise.
 - Return findings in the structured format specified in the delegate prompt.
-- At the end, include: **Skill Resolution**: {injected|fallback-registry|fallback-path|none} — {details}
+- Judge against the acceptance criteria given in the delegate prompt; a requirement with no covering code or test is a finding.
 
 ## Review ledger contract
 
@@ -24,13 +24,18 @@ You are a read-only adversarial reviewer. Inspect only the immutable target name
 
 Report only real, user-impacting defects. Every severe finding must state whether the candidate introduced, behavior-activated, or worsened the behavior and cite changed-hunk, differential-test, candidate-created-path, or before/after proof. Mark unchanged defects pre-existing or base-only; use unknown when causality cannot be proved.
 
-Use BLOCKER | CRITICAL | WARNING | SUGGESTION. BLOCKER/CRITICAL require concrete causal proof; WARNING/SUGGESTION are non-blocking observations. Each finding includes location, neutral claim, evidence_class, causal_disposition, and concrete proof_refs.
+Use BLOCKER | CRITICAL | WARNING | SUGGESTION; for WARNING, the claim text starts with `(real)` or `(theoretical)`. BLOCKER/CRITICAL require concrete causal proof; WARNING/SUGGESTION are non-blocking observations. Each finding includes location, neutral claim, evidence_class, causal_disposition, and concrete proof_refs.
 
 Return one JSON object and no prose. Use exactly this native result shape:
 
 {"findings":[{"location":"path:line","severity":"CRITICAL","claim":"observable incorrect behavior","evidence_class":"deterministic","causal_disposition":"introduced","proof_refs":["concrete proof"]}],"evidence":["what was inspected"]}
 
-The only allowed top-level fields are findings and evidence, and the only allowed finding fields are location, severity, claim, evidence_class, causal_disposition, and proof_refs. Never emit summary, skill_resolution, or any other unknown field. Keep orchestration metadata outside the native result JSON; evidence contains only genuine inspection evidence.
+The only allowed top-level fields are findings and evidence, and the only allowed finding fields are location, severity, claim, evidence_class, causal_disposition, and proof_refs. Inside the JSON, emit ONLY `findings` and `evidence` — no `summary`, `skill_resolution`, or other unknown field. Keep orchestration metadata outside the native result JSON; evidence contains only genuine inspection evidence.
 
 Return {"findings":[],"evidence":["what was inspected"]} when clean.
 
+AFTER the JSON object, on two separate lines, emit the two contract lines `.claude/skills/catalyst-delegation/SKILL.md` requires:
+
+skill_resolution: <paths-injected | fallback-registry | fallback-footer | none>
+status: <completed | needs-guidance>
+

package/dist/templates/monorepo/.claude/agents/jd-judge-b.md

@@ -16,7 +16,7 @@ provided in the delegate prompt exactly.
 - Do NOT modify any code — your job is ONLY to find problems.
 - Be thorough and adversarial. Assume the code has bugs until proven otherwise.
 - Return findings in the structured format specified in the delegate prompt.
-- At the end, include: **Skill Resolution**: {injected|fallback-registry|fallback-path|none} — {details}
+- Judge against the acceptance criteria given in the delegate prompt; a requirement with no covering code or test is a finding.
 
 ## Review ledger contract
 
@@ -24,13 +24,18 @@ You are a read-only adversarial reviewer. Inspect only the immutable target name
 
 Report only real, user-impacting defects. Every severe finding must state whether the candidate introduced, behavior-activated, or worsened the behavior and cite changed-hunk, differential-test, candidate-created-path, or before/after proof. Mark unchanged defects pre-existing or base-only; use unknown when causality cannot be proved.
 
-Use BLOCKER | CRITICAL | WARNING | SUGGESTION. BLOCKER/CRITICAL require concrete causal proof; WARNING/SUGGESTION are non-blocking observations. Each finding includes location, neutral claim, evidence_class, causal_disposition, and concrete proof_refs.
+Use BLOCKER | CRITICAL | WARNING | SUGGESTION; for WARNING, the claim text starts with `(real)` or `(theoretical)`. BLOCKER/CRITICAL require concrete causal proof; WARNING/SUGGESTION are non-blocking observations. Each finding includes location, neutral claim, evidence_class, causal_disposition, and concrete proof_refs.
 
 Return one JSON object and no prose. Use exactly this native result shape:
 
 {"findings":[{"location":"path:line","severity":"CRITICAL","claim":"observable incorrect behavior","evidence_class":"deterministic","causal_disposition":"introduced","proof_refs":["concrete proof"]}],"evidence":["what was inspected"]}
 
-The only allowed top-level fields are findings and evidence, and the only allowed finding fields are location, severity, claim, evidence_class, causal_disposition, and proof_refs. Never emit summary, skill_resolution, or any other unknown field. Keep orchestration metadata outside the native result JSON; evidence contains only genuine inspection evidence.
+The only allowed top-level fields are findings and evidence, and the only allowed finding fields are location, severity, claim, evidence_class, causal_disposition, and proof_refs. Inside the JSON, emit ONLY `findings` and `evidence` — no `summary`, `skill_resolution`, or other unknown field. Keep orchestration metadata outside the native result JSON; evidence contains only genuine inspection evidence.
 
 Return {"findings":[],"evidence":["what was inspected"]} when clean.
 
+AFTER the JSON object, on two separate lines, emit the two contract lines `.claude/skills/catalyst-delegation/SKILL.md` requires:
+
+skill_resolution: <paths-injected | fallback-registry | fallback-footer | none>
+status: <completed | needs-guidance>
+

package/dist/templates/monorepo/.claude/hooks/__fixtures__/br-hr-regression-baseline.txt

@@ -125,13 +125,13 @@ Recordatorio: las reglas anteriores son **memoria + detector**, no enforcement.
 
 Detectadas 4 harness rules activas relacionadas con el prompt; mostrando las 3 más relevantes. Estas NO son memoria opcional: son CONSTRAINTS arquitectónicos que gobiernan lo que vas a tocar. El catálogo vive en `cliter/harness-rules/<topic>.md` (índice: `cliter/harness-rules-index.json`).
 
-## HR-BARRELS-003 — Importar activos por barrel (módulo o sub-barrel público), no por deep-path
+## HR-BARRELS-004 — Importar activos por barrel (módulo o sub-barrel público), no por deep-path
 
 | Campo     | Valor                                                                                                                                                                                                                          |
 | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Estado    | `active`                                                                                                                                                                                                                       |
 | Severidad | `informational`                                                                                                                                                                                                              |
-| Origen    | Sustituye a **HR-BARRELS-001** (`derogated` 2026-09-01): change `reduce-frontend-eager-payload`. El frontend `@aurora` deja de ser un barrel único y pasa a exponer, además del barrel raíz, un conjunto de sub-barrel aliases declarados explícitamente en `frontend/tsconfig.json` (`@aurora/components`, `@aurora/modules/health`, …). El resto del enunciado y de la matriz de casos de HR-BARRELS-001 se conserva sin cambios. |
+| Origen    | Sustituye a **HR-BARRELS-003** (`derogated` 2026-09-11): defecto de proceso detectado en revisión — la excepción por `import()` dinámico de rutas lazy (T-45) se había registrado editando EN SITIO el `### Enunciado` y la matriz de `### Casos exhaustivos` de HR-BARRELS-003 en vez de derogar y crear una regla nueva (convención 7 de `harness-rules-guard`). El resto del enunciado y de la matriz de casos de HR-BARRELS-003 se conserva sin cambios; esta regla añade el caso 10 (excepción por FORMA para `import()` dinámico) y lo declara explícitamente en el `### Enunciado`, para que el enunciado no contradiga su propia matriz de casos. |
 
 ### Enunciado
 
@@ -144,6 +144,15 @@ la superficie pública; los ficheros internos son detalle de implementación y n
 el import specifier de OTRO módulo. Si el activo no está expuesto, se AÑADE al `index.ts`
 correspondiente (del módulo o de un sub-barrel) y se importa por barrel.
 
+**Excepción por FORMA — `import()` dinámico**: el specifier de un `import('...')` con literal
+como target de una ruta lazy (típicamente `loadComponent`/`loadChildren` de una ruta Angular en un
+`*.routes.ts`) queda EXENTO de esta regla sea cual sea su profundidad — es el límite de
+code-splitting que Angular usa para emitir un chunk propio por ruta; enrutarlo por un barrel
+arrastraría el módulo entero al chunk, la regresión que esta regla existe para evitar. La excepción
+es de la FORMA del import (`import(...)` con literal), NUNCA del fichero: un `import ... from '...'`
+ESTÁTICO al mismo target, o en el mismo `*.routes.ts` (p.ej. un resolver), sigue siendo deep-path
+prohibido.
+
 Importar de un sub-barrel acotado en vez del barrel raíz no solo es válido: a veces es
 OBLIGATORIO. Ej.: los contratos de `@aurora/modules/authentication/domain/ports` (Symbols +
 interfaces, cero side-effects) se importan por ese sub-barrel para NO arrastrar el
@@ -154,18 +163,7 @@ interfaces, cero side-effects) se importan por ese sub-barrel para NO arrastrar
 se importan directamente). Frontend: `@aurora` expone un **barrel raíz** (`from '@aurora'`) MÁS un
 conjunto de **sub-barrel aliases declarados explícitamente** en `frontend/tsconfig.json`
 (`@aurora/components`, `@aurora/modules/health`, …) — importar de un alias declarado es válido; un
-specifier que nombra un fichero de implementación sigue prohibido y, al no estar en esa tabla,
-simplemente NO RESUELVE. Y los BC bajo `app/domains/admin/apps/<bc>/<module>` y `<bc>/shared`
-(cada uno con su `index.ts`).
-
-La regla gobierna la **FORMA** del import, no su **legitimidad**: qué módulo puede importar de cuál
-lo siguen gobernando HR-BRIDGES-001 (cross-BC SOLO vía un port en `@bridges/`) y HR-MODULES-001.
-Usar la forma barrel NUNCA autoriza un import cross-BC que esas reglas prohíben.
-
-### Casos exhaustivos
-
-| #   | Situación                                                                                                            | ¿Permitido? | Acción correcta                                                                            |
-| --- | -------------------------------------------------------------------------------------------------------------------- | ----------- | -----------------------------------------------------------------
+specifier que nombra un fichero de implementación sigue prohibi
 
 ... (truncated)
 
@@ -205,45 +203,59 @@ superficie de consumo y por tanto NO lleva `index.ts` de módulo; y NO existen b
 
 ... (truncated)
 
-## HR-BRIDGES-001 — Cross-BC ports y adapters viven en @bridges/
+## HR-BRIDGES-002 — Cross-BC ports y adapters viven en @bridges/, con relaciones de persistencia nombradas
 
 | Campo     | Valor                                                                                                 |
 | --------- | ----------------------------------------------------------------------------------------------------- |
 | Estado    | `active`                                                                                              |
 | Severidad | `blocking`                                                                                            |
-| Origen    | spec `openspec/specs/cross-bc-ports/spec.md` (convención formalizada); supersede `feedback_cross_bc_adapter_location.md`, que toleraba adapters en `@app/` |
+| Origen    | Replaces **HR-BRIDGES-001** (`derogated` 2026-09-13, task T-19). Core convention from spec `openspec/specs/cross-bc-ports/spec.md`, unchanged. The two named exceptions come from code measured on 2026-09-13: the `crossBcRelations` assembly point and its rationale in `backend/src/@config/drizzle/aurora-drizzle-schema.ts`, and the generated `domain/*.field-schema.ts` relation targets. |
 
 ### Enunciado
 
-Toda dependencia cross-BC se materializa bajo `backend/src/@bridges/<bc>/`, NUNCA bajo `@app/<bc>/`
-ni `@api/<bc>/`. `@bridges/<bc>/` es la cara externa del BC (los contratos cross-BC); `@app/<bc>/`
-es la interna (handlers, services, repositories). Juntos forman el BC completo. Gracias a esta
-separación, la regla **"ningún archivo bajo `@app/<bc>/` importa de otro `@app/<other-bc>/`"** pasa
-a ser ENFORCEABLE POR LINTER (un regex de una línea en eslint), algo imposible en la convención DDD
-canónica donde los adapters cross-BC viven en `@app` y violarían `@app → @app` por diseño. Aurora
-DIVERGE INTENCIONALMENTE del DDD literal de Evans/Vernon (que coloca el port con su consumer y el
-adapter con su supplier, ambos dentro del dominio): Catalyst, como meta-framework, trata la
-integración cross-BC como un concern separable y lo materializa en `@bridges/`.
+Every cross-BC **behavioral** dependency — one BC reading data from, or invoking an operation of,
+another BC — lives under `backend/src/@bridges/<bc>/`, NEVER under `@app/<bc>/` or `@api/<bc>/`. The
+consumer declares a port and injects it by token; the supplier implements the adapter.
+`@bridges/<bc>/` is the external face of the BC (its cross-BC contracts); `@app/<bc>/` is the internal
+face (handlers, services, repositories). Aurora deliberately diverges from literal Evans/Vernon DDD
+here: cross-BC integration is a separable concern, materialized in `@bridges/`.
+
+**Named exceptions — declarative persistence relations.** Only two places may express a relation
+between two BCs without a port, and only in this form:
+
+- **E1 — generated field-schemas.** A `@app/<bc>/**/domain/**/*.field-schema.ts` may import the
+  `domain/` of another BC, and nothing else from it, to describe a relation target for the Query DSL
+  eager-load.
+- **E2 — the relations assembly point.** Only `backend/src/@config/drizzle/aurora-drizzle-schema.ts`
+  declares Drizzle relations between BCs (`crossBcRelations`), and from `@app` it imports only each
+  BC's `@app/<bc>/<bc>.relations`. Drizzle RQB resolves relations once against the merged schema, so
+  this single point cannot be split per BC.
+
+Both exceptions exist only because every BC shares ONE Postgres database behind ONE Drizzle engine. A
+change that moves a BC to its own datastore invalidates E1 and E2 for that BC and must revisit them.
+
+**Enforcement mecánico — exactly what `backend/eslint.config.mjs` checks, no more.** It checks only
+imports whose target is under `@app/**` and whose specifier is a string literal (`import`,
+`export … from`, `import()`, `require()`); TypeScript `import x = require()` and a non-literal
+`import()` are not seen. Layers are matched by folder name.
+
+- A file under a folder named `application/`, `infrastructure/` or `domain/` inside `@app/<bc>`
+  (other than an E1 field-schema) imports nothing from another `@app/<other-bc>`.
+- An E1 field-schema imports from another `@app/<other-bc>` only its `domain/`.
+- The E2 assembly point imports from `@app` only a BC-root `*.relations.ts` module (the generated
+  `<bc>.relations`).
+
+**Declared limit — not an exemption.** The linter does NOT check the other files of `@app/<bc>/`
+(for example `shared/` and `<bc>.relations.ts`), anything under `@api/**` (including generated DTOs
+and `graphql.ts`), any other source file outside `@app/**` except the E2 assembly point (for example
+`@bridges/**` and the other `@config/` files), or any import whose target is under `@api/**` or
+`@bridges/**`. The first
+paragraph of this statement still applies to them, and review is its only enforcement. This rule
+makes no claim that they comply: a clean lint run proves nothing about them.
 
 ### Casos exhaustivos
 
-| #   | Situación                                                                                  | ¿Permitido? | Acción correcta                                                                                                       |
-| --- | ------------------------------------------------------------------------------------------ | ----------- | --------------------------------------------------------------------------------------------------------------------- |
-| 1   | Declarar un port para que un consumer BC lea datos de otro BC                               | SÍ          | `@bridges/<consumer-bc>/<feature>/ports/<thing>.port.ts` + `<thing>.token.ts` (Symbol DI co-localizado).              |
-| 2   | Implementar ese port (adapter)                                                              | SÍ          | `@bridges/<supplier-bc>/<module>/adapters/<thing>.adapter.ts`, nombrado con prefijo del **supplier**, `@Injectable()`. |
-| 3   | Colocar el port en `@app/<consumer>/shared/ports/` o el adapter en `@app/<supplier>/.../infrastructure/adapters/` | **NO**      | Moverlos a `@bridges/<bc>/<feature>/`. Esa ubicación rompe la regla `@app → @app` enforceable por linter.             |
-| 4   | Que un handler/módulo de `@app/<consumer>` importe directamente de `@app/<supplier>`        | **NO**      | Inyectar el port por token (`@Inject(TOKEN)`); la resolución la sirve `BridgesModule` (`@Global`).                    |
-
-> **Aclaración aditiva al caso 1 (no deroga, no cambia el resultado `SÍ`, no crea id nueva):**
-> cuando el BC lector es un **BC de capacidad de plataforma** (p.ej. `tools`, no un BC de dominio
-> par como `iam` u `o-auth`) y el contrato es **consumer-agnostic** (todo método discrimina al
-> llamante SOLO por un parámetro tipo `entityType`, y el DTO devuelto es un snapshot mínimo sin
-> proyección específica de un consumidor concreto), el puerto y su token PUEDEN vivir en el
-> territorio del **supplier** (`@bridges/<supplier-bc>/<feature>/ports/`) en vez del consumidor —
-> variante open-host / published-language. El caso 1 sigue siendo `SÍ` sin cambios: el puerto
-> sigue bajo `@bridges/`, sin ningún import `@app → @app`. Precedentes: `TOOLS_CUSTOM_FIELD_ENTITY_REGISTRAR`
-> (write port) y `TOOLS_KEY_VALUE_CONFIG`; ejemplo trabajado: `TOOLS_CUSTOM_FIELD_DEFINITION_READER`
-> (`@bridges/tools/custom-field/ports/`). Ver skill `catalyst-cross-boun
+| #   | Situación                                                                                  | ¿Permitido? | Acción correcta                                              
 
 ... (truncated)