@mrciphersmith/keryx 0.3.0 → 0.3.2

package/src/gdskills/bundled/stacks/nestjs/skills/nestjs-implementation/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: nestjs-implementation
+description: "Use when building or extending a NestJS module, controller, guard, interceptor, pipe, or exception filter -- choosing provider scope and registering a cross-cutting concern globally via APP_GUARD/APP_INTERCEPTOR/APP_PIPE/APP_FILTER, and keeping controllers thin with business rules delegated downstream. Scoped to authoring new behavior in an app that already boots; excludes selecting field-level checks on a request body, a finished-diff review pass, and diagnosing why an already-written module stops the app from starting."
+triggers:
+  - "add a new NestJS module for this feature"
+  - "wire this provider into the NestJS DI container"
+  - "implement a NestJS guard for this route"
+  - "register a global interceptor in NestJS"
+  - "create an exception filter for this NestJS app"
+  - "should this NestJS provider be request-scoped"
+  - "move this logic out of the controller into a dedicated provider"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# NestJS implementation (modules, providers, DI, request pipeline)
+
+Build or extend a NestJS module: controllers, services, and the
+guards/interceptors/pipes/filters that make up the request pipeline around
+them, wired through Nest's dependency injection. See `rules/patterns.mdc`
+for the module/provider design this skill applies, `rules/coding-style.mdc`
+for naming and typing, and `rules/security.mdc` for the AuthN/AuthZ and
+input-validation shape a new endpoint must satisfy. DTO decorator choice is
+the existing `nestjs-dto.mdc` rule's ground, not repeated here.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+Read the nearest existing feature module (a sibling `<feature>/` directory
+under `src/`) before writing a new one. Match its file-splitting convention
+(one module per feature vs. sub-modules), its DTO/validation setup, its
+exception-filter and guard registration style (global via `APP_GUARD`/
+`APP_FILTER` vs. per-controller `@UseGuards`), and its provider-scope
+choices. Do not introduce a different pattern in one module without a
+concrete reason stated in the change.
+
+### Step 2: Design the module shape
+
+- Identify what the new module owns: which controller(s), which
+  service(s), which providers a service needs (repository, HTTP client,
+  config).
+- Decide what the module needs to `import` from other feature modules, and
+  what it needs to `export` if another module will consume one of its
+  providers.
+- Default every new provider to the framework's default (Singleton) scope
+  unless it genuinely needs per-request state — see `rules/patterns.mdc`
+  on `Scope.REQUEST`'s real cost.
+
+### Step 3: Implement the controller-service split
+
+- The controller method: validate input via a typed DTO class (see the
+  existing `nestjs-dto.mdc` rule for the decorator set), call exactly one
+  service method for the actual work, and shape the response.
+- The service method: an explicit return type, business logic, and a typed
+  NestJS `HttpException` subclass (or a domain error the controller/filter
+  translates) on failure — never a controller that reaches into a
+  repository directly (see `rules/patterns.mdc`, "Controllers vs.
+  services").
+
+### Step 4: Add cross-cutting concerns at the right layer
+
+- A concern that applies to (nearly) every route in the app (auth, request
+  logging, response shaping) goes in a guard/interceptor/pipe registered
+  globally as an `APP_GUARD`/`APP_INTERCEPTOR`/`APP_PIPE`/`APP_FILTER`
+  provider in a module's `providers` array, not `app.useGlobalGuards()` on
+  the bootstrapped instance -- the `APP_*` token form keeps the provider
+  inside Nest's own DI graph so it can inject other providers (e.g. a
+  guard that injects `Reflector` or a `UsersService`).
+- A concern scoped to one controller or route goes on that controller/
+  method with `@UseGuards()`/`@UseInterceptors()`/`@UsePipes()`.
+- When a global guard protects most routes, mark the deliberate exceptions
+  with a custom decorator backed by `SetMetadata` and read via `Reflector`
+  in the guard (e.g. a `@Public()` decorator) rather than leaving some
+  controllers undecorated.
+
+### Step 5: Verify
+
+Run the project's own build/type-check/test scripts (see Verification
+below) and confirm the new module compiles into the app's DI graph with no
+`UnknownDependenciesException`/circular-dependency warning at startup --
+not just that `tsc` is clean.
+
+## Rules
+
+- Follow `rules/coding-style.mdc` for naming, file-per-role layout, and
+  typing; `rules/patterns.mdc` for module/provider/guard design; and
+  `rules/security.mdc` for what a new endpoint's validation and auth must
+  cover before it is considered done.
+- ALWAYS keep the controller thin: parse/validate, delegate to one service
+  call, shape the response.
+- ALWAYS register a cross-cutting concern once (globally via an `APP_*`
+  token, or via a reusable decorator), never copy-pasted into every
+  controller that needs it.
+- NEVER inject a `REQUEST`-scoped or `TRANSIENT` provider into a Singleton
+  provider -- it silently makes the Singleton request-scoped too (Nest
+  propagates scope up the injection graph) or throws at resolution time,
+  and either way defeats the point of a Singleton service.
+- NEVER put a repository/ORM call directly in a controller method.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just call the repository from the controller, it's one line" | It's untestable without the HTTP stack and duplicates the service's job the next time this logic is needed elsewhere |
+| "I'll decorate every controller with this guard instead of making it global" | Any new controller anyone adds later silently starts unprotected; a global `APP_GUARD` with an explicit `@Public()` opt-out fails safe instead |
+| "This provider doesn't need DI, I'll just `new` it inline in the service" | It bypasses testability via `overrideProvider` and any lifecycle hooks (`OnModuleInit`/`OnModuleDestroy`) the class relies on |
+| "I'll make this provider REQUEST-scoped just in case" | Request scope re-instantiates the whole injection subtree per request; only reach for it when per-request state is a genuine requirement |
+
+## Verification
+
+Do not report the implementation done until all of the following hold:
+
+- The project's build command (`nest build` or its `package.json`
+  equivalent) and `tsc --noEmit` both exit 0.
+- The app boots locally (or the project's e2e bootstrap test passes) with
+  no `UnknownDependenciesException`, circular-dependency warning, or
+  missing-export error at startup.
+- Every new/changed controller method that accepts user input has a
+  validated DTO and, where the endpoint should not be public, a guard --
+  either explicit or inherited from a global `APP_GUARD`.
+- No business logic or direct repository/ORM call was added to a
+  controller.
+- `git status` shows changes confined to the module(s) the feature
+  actually touches.

package/src/gdskills/bundled/stacks/nestjs/skills/nestjs-implementation/evals.json

@@ -0,0 +1,71 @@
+{
+  "triggers": {
+    "positive": [
+      "We're adding an invoices feature to our NestJS API -- I need the module scaffolding: a controller, a service, and the provider wired up.",
+      "I need to wire OrdersService into the DI container for this new module",
+      "Implement a NestJS guard that checks the JWT and only allows admins through",
+      "Every response from our NestJS app should get its duration logged automatically -- I need an interceptor wired in globally rather than per-controller.",
+      "Right now if anything throws in our NestJS app, the client gets the raw stack trace back in the response -- I want every uncaught error across the whole app to come back as a clean, generic error instead.",
+      "A NestJS provider I'm writing reads something off the incoming request -- should that make it request-scoped, or is the default singleton still fine?",
+      "Move this business logic out of the controller and into a proper service method"
+    ],
+    "negative": [
+      "Review this NestJS PR for missing DTO validation and N+1 queries in the repository layer",
+      "Fix this NestJS build error: Nest can't resolve dependencies of UsersService",
+      "Write @nestjs/testing unit tests for this NestJS service with a mocked repository",
+      "Add class-validator decorators to this DTO for the new signup endpoint",
+      "Implement a React component that displays the user's profile card",
+      "Fix this tsc module resolution error in a plain Node.js script with no framework"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "global-guard-with-public-escape-hatch",
+      "prompt": "I want to protect most routes in my NestJS app with a JWT auth guard, but let a few endpoints stay public. What's the right way to set this up?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer registers the auth guard globally as an APP_GUARD provider (not app.useGlobalGuards() on the bootstrapped instance) so it stays inside Nest's DI graph, and adds a custom metadata decorator (e.g. a Public() decorator built with SetMetadata) that the guard checks via Reflector to let specific routes opt out, rather than protecting routes one controller at a time.",
+          "pass_criteria": [
+            "Names registering the guard globally via the APP_GUARD provider token in a module's providers array, not app.useGlobalGuards() called on the app instance",
+            "Names creating a custom decorator (e.g. @Public()) built with SetMetadata, and reading that metadata inside the guard via Reflector to allow the exception"
+          ],
+          "fail_criteria": [
+            "Recommends decorating every protected controller individually with @UseGuards(...) instead of registering the guard globally -- naming @UseGuards for the few endpoints that need controller-specific behavior on top of the global guard is not this failure, only proposing it as the whole mechanism for making most routes protected"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Register the guard globally so it applies to every route by default, then carve out the public ones explicitly. Register it as an APP_GUARD provider (not app.useGlobalGuards() in main.ts) so it stays part of Nest's DI graph and can inject things like Reflector or a UsersService:\n\n@Module({\n  providers: [{ provide: APP_GUARD, useClass: JwtAuthGuard }],\n})\nexport class AppModule {}\n\nThen add a metadata-based escape hatch: a decorator built on SetMetadata, e.g.\n\nexport const IS_PUBLIC_KEY = 'isPublic';\nexport const Public = () => SetMetadata(IS_PUBLIC_KEY, true);\n\nand have JwtAuthGuard read that metadata with Reflector before enforcing auth:\n\ncanActivate(context: ExecutionContext) {\n  const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC_KEY, [\n    context.getHandler(),\n    context.getClass(),\n  ]);\n  if (isPublic) return true;\n  // ... normal auth check\n}\n\nNow every new controller is protected by default, and only routes explicitly marked @Public() opt out -- adding a new controller and forgetting to guard it can't silently leave it open.",
+        "known_wrong": "Easiest way: just add @UseGuards(JwtAuthGuard) to every controller that should be protected, and skip it on the couple of public ones. No need to touch app.module.ts at all, and you don't need any Reflector metadata stuff -- just remember which controllers need the decorator.",
+        "vague": "Set the guard up so it applies to most routes by default, and give the public ones a way to opt out of it.",
+        "subtle_wrong": "Call app.useGlobalGuards(new JwtAuthGuard()) in main.ts right after creating the app, that applies it to every route without touching each controller. For the public ones, just check the request path against an allow-list inside the guard's canActivate instead of a decorator, since that's simpler than wiring up SetMetadata."
+      }
+    },
+    {
+      "id": "request-scoped-into-singleton",
+      "prompt": "I have a small provider that reads the current user off the request (it's REQUEST-scoped). I want to inject it directly into UsersService, which is a plain singleton used all over the app. Is that fine to do as-is?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains that Nest propagates provider scope up the dependency graph, so injecting a REQUEST-scoped provider directly into UsersService makes UsersService itself request-scoped -- re-instantiated per request along with everything that depends on it -- and recommends not injecting the request-scoped dependency straight into the broadly-shared singleton, instead passing the needed value explicitly as an argument from a layer that is already request-scoped, or isolating the request-scoped need into its own narrow provider.",
+          "pass_criteria": [
+            "States that injecting the REQUEST-scoped provider into UsersService makes UsersService (and its own consumers) request-scoped too, because Nest propagates scope up the injection graph -- not an isolated, contained change",
+            "Recommends against injecting the request-scoped provider directly into the shared singleton, proposing instead to pass the needed value explicitly (e.g. as a method argument from the controller) or to isolate the request-scoped logic in a small dedicated provider instead of UsersService"
+          ],
+          "fail_criteria": [
+            "States or implies it is fine to inject the REQUEST-scoped provider into UsersService with no mention of the scope-propagation consequence for UsersService and its own consumers"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "No -- doing that directly will make UsersService itself request-scoped. Nest propagates provider scope up the dependency graph: once UsersService depends on a REQUEST-scoped provider, Nest has to re-instantiate UsersService (and everything downstream that injects UsersService) on every request instead of once. Since UsersService is used all over the app as a shared singleton, that's a much bigger behavioral and performance change than it looks like from the diff. Better options: pass the current user in explicitly as a method argument from the controller (which already has it from the guard-populated request), rather than injecting the REQUEST-scoped provider into UsersService at all; or, if several places genuinely need the current-user-aware behavior, pull that slice of logic into its own small REQUEST-scoped provider instead of adding the dependency to the shared singleton.",
+        "known_wrong": "Yeah that's fine, just inject it in the constructor like any other provider -- Nest's DI handles the wiring automatically so there's nothing special to worry about with the scopes being different.",
+        "vague": "Be careful with mixing scopes like that, it can cause unexpected behavior, so you might want to rethink the design a bit.",
+        "subtle_wrong": "It'll work at runtime since Nest resolves the dependency graph either way, but to keep things clean I'd just mark UsersService as @Injectable({ scope: Scope.REQUEST }) too so the scopes match up consistently -- that avoids any DI errors and keeps the code simple."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/nestjs/skills/nestjs-testing/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: nestjs-testing
+description: "Use when writing or debugging a NestJS test built through Nest's own testing-module builder: a unit test that swaps a provider's real dependency (a repository, an HTTP client) for a fake or mock double so the unit under test runs in isolation, or an e2e test that boots a real Nest application and drives it with supertest through the actual guard/pipe/filter pipeline. Scoped to a test compiled through Nest's own testing module; excludes picking field-level checks for a request body, authoring the feature itself, and a framework-agnostic unit test that never touches Nest's module system."
+triggers:
+  - "write unit tests for this NestJS provider"
+  - "replace a provider's real dependency with a fake in a NestJS unit test"
+  - "write an e2e test for this NestJS endpoint with supertest"
+  - "exercise this NestJS guard in isolation with an overridden Reflector"
+  - "the NestJS test module won't compile because a provider it needs is missing"
+  - "my NestJS e2e test suite leaves the process hanging after it finishes"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# NestJS testing (@nestjs/testing unit and e2e specs)
+
+Write or fix a NestJS unit or end-to-end test using `@nestjs/testing`'s
+module-compiled style: build the unit under test through a real (or
+overridden) Nest DI graph rather than hand-constructing it. See
+`rules/testing.mdc` for the full layout, mocking, and determinism
+conventions this skill applies.
+
+## Workflow
+
+### Step 1: Determine whether this is a unit or e2e test
+
+- **Unit**: exercising one provider (service, guard, interceptor, pipe) in
+  isolation, with its dependencies replaced by test doubles. Lives beside
+  the source as `<name>.spec.ts`.
+- **E2E**: exercising a real HTTP request through the full pipeline
+  (guards, pipes, interceptors, filters, controller, service). Lives under
+  `test/` as `<feature>.e2e-spec.ts`.
+
+If unsure which the request wants, default to a unit test for a single
+provider/class and an e2e test for "does this endpoint work end to end".
+
+### Step 2: Build the testing module
+
+Two equally valid ways to get a test double in, depending on how the module
+is assembled -- pick one, never both for the same provider:
+
+```typescript
+// (a) hand-assembled providers array (the common case for a focused unit
+// test): declare the mock directly, no override needed -- you already
+// control the whole providers list.
+const moduleRef = await Test.createTestingModule({
+  providers: [UsersService, { provide: UsersRepository, useValue: mockRepo }],
+}).compile();
+```
+
+```typescript
+// (b) importing a real module you don't want to hand-reassemble (an
+// e2e-style compile): `.overrideProvider(Token).useValue(...)` (or
+// `.useFactory`/`.useClass`) swaps ONE provider UsersModule already
+// declares, without rewriting the whole module's provider list yourself.
+const moduleRef = await Test.createTestingModule({ imports: [UsersModule] })
+  .overrideProvider(UsersRepository)
+  .useValue(mockRepo)
+  .compile();
+```
+
+Either way: never `new` the class under test directly with hand-built fakes
+when the test needs to prove the module's own DI wiring (exports,
+provider registration) actually resolves -- that's what
+`Test.createTestingModule` is for, and `new` skips it entirely. Never
+monkey-patch the compiled module's internals either. The same
+`.overrideGuard()`/`.overrideInterceptor()`/`.overridePipe()`/
+`.overrideFilter()` methods exist for testing a controller/module with one
+of those swapped out.
+
+### Step 3 (unit): Get the instance and assert
+
+```typescript
+const service = moduleRef.get(UsersService);
+```
+
+Assert against the service's own return value/thrown exception. Mock only
+at the injected-provider boundary (repository, HTTP client) -- not by
+stubbing a private method on the class under test.
+
+### Step 3 (e2e): Boot a real application and drive it with supertest
+
+```typescript
+const app = moduleRef.createNestApplication();
+await app.init();
+// ...
+await request(app.getHttpServer()).get('/users').expect(200);
+// ...
+await app.close();
+```
+
+Assert on HTTP status and response shape via `supertest`, not by reaching
+back into the service's return value -- the point of an e2e spec is that
+guards/pipes/filters actually ran. Always close the app (`afterAll(() =>
+app.close())`) to release DB connections and timers.
+
+### Step 4: Verify
+
+Run the project's unit and e2e test scripts (see Verification below) and
+confirm the new/changed spec fails without the fix and passes with it, and
+that no other spec started flaking or hanging (a common symptom of a
+missing `app.close()`).
+
+## Rules
+
+- Follow `rules/testing.mdc` for layout, mocking boundary, and determinism.
+- ALWAYS build the unit under test through `Test.createTestingModule(...)
+  .compile()`, not a hand-constructed instance.
+- ALWAYS call `app.close()` in `afterAll` for every e2e spec that calls
+  `createNestApplication()`.
+- NEVER delete or `.skip()` a failing spec to reach a green suite --
+  diagnose whether the source or the test's expectation is stale (same
+  rule as any build-fix skill) and fix that instead.
+- NEVER assert against a mocked provider's internal call count as the
+  entire test -- assert the actual behavior (return value, thrown
+  exception, HTTP response) the mock enables you to isolate.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just `new UsersService(mockRepo)` directly, it's simpler than the testing module" | Fine for a pure unit test of the service's own logic (NestJS's own docs show this too) -- wrong specifically when the test needs to prove the MODULE's own DI wiring (exports, provider registration, guard/pipe pipeline) actually resolves, since `new` bypasses that wiring entirely and can pass while the real module would fail to compile |
+| "I'll stub the private method that calls the repository instead of mocking the repository" | Reaches inside the unit under test instead of mocking its actual dependency boundary; couples the test to an implementation detail |
+| "This e2e spec is slow because of app.init()/app.close(), I'll skip close() to speed it up" | Leaks open DB connections/timers across spec files; a later suite hanging or flaking is the actual cost |
+| "This test keeps failing after my change, I'll just skip it for now" | Hides a real regression or a stale test expectation; determine which one it is and fix that, don't silence the signal |
+
+## Verification
+
+Do not report the test work done until all of the following hold:
+
+- The project's unit test script and (when e2e specs were touched) its
+  `test:e2e` script both pass.
+- Every `createNestApplication()` in a touched e2e spec has a matching
+  `app.close()`.
+- No dependency of the unit under test was replaced by monkey-patching or
+  hand-construction instead of `Test.createTestingModule`/`override*`.
+- No spec was deleted or `.skip()`-ed to reach green.
+- `git status` shows changes confined to the spec file(s) and, if the test
+  exposed a real bug, the source file(s) the fix required.

package/src/gdskills/bundled/stacks/nestjs/skills/nestjs-testing/evals.json

@@ -0,0 +1,69 @@
+{
+  "triggers": {
+    "positive": [
+      "I need a unit test for OrdersService that swaps in a fake for its Repository dependency instead of hitting the real database",
+      "How do I replace the payment gateway provider with a stub when testing this NestJS module, without making real API calls",
+      "I need to drive the real POST /users route through supertest against a fully bootstrapped NestJS app instance, hitting actual guards and pipes instead of mocking the controller directly.",
+      "I want to unit test a NestJS route guard that checks role metadata, but without booting the whole app -- just fake out whatever it pulls from Reflector.",
+      "My NestJS test throws saying a provider is missing when the test module tries to compile -- what's wrong with my test setup",
+      "My NestJS e2e test suite hangs and never exits after the run finishes, even though every test passes"
+    ],
+    "negative": [
+      "Fix this NestJS build error: Nest can't resolve dependencies of UsersService",
+      "Add a new NestJS module with a controller and service for invoices",
+      "Write plain Jest tests for a date-formatting utility function with no NestJS dependencies",
+      "Review this NestJS PR for missing DTO validation and N+1 queries",
+      "Write Vue component tests using Vue Test Utils and Vitest",
+      "Add class-validator decorators to this DTO for the new signup endpoint"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "mock-dependency-boundary",
+      "prompt": "I'm writing a unit test for UsersService, which depends on UsersRepository. What's the right way to set this up with @nestjs/testing?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer replaces UsersRepository with a test double -- via a { provide: UsersRepository, useValue/useFactory/useClass } entry in a hand-assembled Test.createTestingModule providers array, or via .overrideProvider(UsersRepository) on a module built from imports -- mocking at the injected-dependency boundary rather than stubbing an internal method of UsersService itself. A plain `new UsersService(fakeRepo)` is also an acceptable answer for testing the service's own logic in isolation, since NestJS's own docs show this pattern too, as long as UsersRepository itself (not an internal method) is what gets faked.",
+          "pass_criteria": [
+            "States that UsersRepository should be replaced with a test double -- either declared directly in a Test.createTestingModule providers array, via .overrideProvider(UsersRepository), or passed as a plain fake to `new UsersService(fakeRepo)` -- rather than by stubbing a private/internal method on UsersService"
+          ],
+          "fail_criteria": [
+            "Recommends stubbing or spying on a private/internal method of UsersService itself (e.g. the method that calls the repository) instead of faking UsersRepository at its own boundary, regardless of which construction approach is used"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Build UsersService with UsersRepository replaced by a fake, mocking at the repository boundary rather than reaching inside UsersService itself:\n\nconst moduleRef = await Test.createTestingModule({\n  providers: [\n    UsersService,\n    { provide: UsersRepository, useValue: mockRepo },\n  ],\n}).compile();\n\nconst service = moduleRef.get(UsersService);\n\nThat exercises the same DI resolution the real app uses. A plain `const service = new UsersService(mockRepo);` works just as well here too, since this is testing UsersService's own logic in isolation, not the module's DI wiring -- either way, the fake stands in for UsersRepository, not for a method inside UsersService. Then assert against UsersService's own return values or thrown exceptions using the mock's canned responses.",
+        "known_wrong": "Just call the real UsersService with the real UsersRepository wired up as-is, and let the test hit whatever backing store UsersRepository actually uses in this environment -- no mock needed, it'll just use the same repository the app does at runtime.",
+        "vague": "Set the test up so UsersRepository is replaced with something fake, so you can test UsersService's logic on its own.",
+        "subtle_wrong": "Use Test.createTestingModule with just UsersService in providers, then inside the test call jest.spyOn(service, 'findUserRecord') (the private method that talks to the repository) and mock its return value directly -- that way you don't need to bother wiring up a UsersRepository provider override at all."
+      }
+    },
+    {
+      "id": "e2e-hanging-suite",
+      "prompt": "My NestJS e2e test suite finishes but the process hangs and I have to Ctrl+C it. What's the likely cause and the right fix?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies a missing app.close() call as the likely cause -- an e2e spec that calls moduleRef.createNestApplication()/app.init() but never closes the app leaks open resources like DB connections and timers -- and fixes it by calling app.close() in an afterAll hook, rather than forcing the test runner to exit.",
+          "pass_criteria": [
+            "Identifies a missing app.close() (after createNestApplication()/app.init()) as the likely cause of the hang, naming that it leaks open resources such as DB connections or timers",
+            "States the concrete fix: call app.close() inside an afterAll hook for every e2e spec that created the app"
+          ],
+          "fail_criteria": [
+            "Recommends forcing the test runner to exit (e.g. a force-exit flag or calling process.exit in the test) as the fix instead of closing the application properly"
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "That's almost always a missing app.close(). An e2e spec that does moduleRef.createNestApplication() and app.init() but never closes the app leaves open handles behind -- DB connections, timers, anything the app opened during bootstrap -- and the test runner can't exit cleanly because those handles are still alive. Fix it by closing the app once the spec file is done:\n\nafterAll(async () => {\n  await app.close();\n});\n\nCheck every e2e spec file that calls createNestApplication() has a matching close in its afterAll, not just the one you're currently debugging -- it's easy for one spec file to have it and a newer one to be missing it.",
+        "known_wrong": "That's just Jest being slow to exit sometimes, nothing to actually fix -- add --forceExit to the test script in package.json and it'll stop hanging. A lot of NestJS projects run with forceExit anyway.",
+        "vague": "Something is probably still open after the tests finish, so you'd want to make sure everything gets cleaned up properly at the end.",
+        "subtle_wrong": "Likely an open DB connection somewhere. Rather than chasing down which spec is missing the cleanup, just add --detectOpenHandles --forceExit to the e2e test script -- forceExit will make the process exit regardless, and detectOpenHandles at least tells you what's open if you want to look into it later."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/nextjs-nuxt/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "honest gate (flow 318, T13): every skill fails the trigger-accuracy check with real same-pack/cross-pack collisions (falsePositive implementation 3/6, testing 4/6, code-review 3/6, build-fix 1/6, upgrade-migration 3/6) -- see src/gdskills/bundled/stacks/nextjs-nuxt/governance/eval.json and the flow 318 journal for the root cause (the same-pack-siblings-never-block selection rule against a 5-skill meta-framework pack sharing heavy vocabulary, plus the negation-unaware scorer indexing this pack's own disclaimer clauses as positive vocabulary). Stays experimental; no generated agent pair."
+}