@mrciphersmith/keryx 0.3.0 → 0.3.2

package/src/gdskills/bundled/stacks/angular/governance/eval.json

@@ -0,0 +1,1751 @@
+{
+  "schemaVersion": "1.0.0",
+  "reports": [
+    {
+      "schemaVersion": "1.0.0",
+      "skillId": "angular/angular-implementation",
+      "strictness": "high",
+      "trials": 10,
+      "triggerAccuracy": {
+        "truePositive": 1,
+        "falsePositive": 0,
+        "positives": 7,
+        "negatives": 7
+      },
+      "evidence": "authored",
+      "scenarios": [
+        {
+          "id": "trigger-positive-1",
+          "kind": "trigger-positive",
+          "prompt": "I need a new component in our Angular app that lists a user's past orders",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 0,
+          "passRate": 0,
+          "passAtK": 0,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-2",
+          "kind": "trigger-positive",
+          "prompt": "We need a service in our Angular app that wraps the orders HTTP endpoints -- how should it get HttpClient?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 0,
+          "passRate": 0,
+          "passAtK": 0,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-3",
+          "kind": "trigger-positive",
+          "prompt": "How should I hold this component's state in Angular so the template updates when it changes, without plain fields?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 0,
+          "passRate": 0,
+          "passAtK": 0,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-4",
+          "kind": "trigger-positive",
+          "prompt": "Build me a shipping-address form in Angular where every field is typed and validated",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-5",
+          "kind": "trigger-positive",
+          "prompt": "Only logged-in users should be able to open /account in our Angular app; anyone else goes back to /login",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 0,
+          "passRate": 0,
+          "passAtK": 0,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-6",
+          "kind": "trigger-positive",
+          "prompt": "This component re-renders the whole tree on every parent change -- how do I make it only update when its own signal input actually changes?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 0,
+          "passRate": 0,
+          "passAtK": 0,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-7",
+          "kind": "trigger-positive",
+          "prompt": "This Angular component still lives in an NgModule's declarations array -- I want it to stand on its own",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 0,
+          "passRate": 0,
+          "passAtK": 0,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-1",
+          "kind": "trigger-negative",
+          "prompt": "Create a new Vue component using the Composition API with <script setup>",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-2",
+          "kind": "trigger-negative",
+          "prompt": "Create a new React component that fetches and displays a user's order history",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-3",
+          "kind": "trigger-negative",
+          "prompt": "Write a TestBed spec that calls fixture.detectChanges and asserts the rendered template",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-4",
+          "kind": "trigger-negative",
+          "prompt": "Fix this ng build AOT compile error about a missing NgModule declaration",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-5",
+          "kind": "trigger-negative",
+          "prompt": "Review this Angular component's diff for RxJS subscription leaks",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-6",
+          "kind": "trigger-negative",
+          "prompt": "Fix this tsc type error in our Node.js backend service",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-7",
+          "kind": "trigger-negative",
+          "prompt": "Migrate this MobX store's observable state to use runInAction correctly",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "signal-input-not-input-decorator",
+          "kind": "behavior",
+          "prompt": "I'm adding a new standalone Angular component that receives an `order: Order` value as an input. The rest of this codebase uses signals throughout (signal(), computed(), input()). How should I declare and read this input?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 10,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "Declare it as a signal input with `input()` and read it as a signal in the class/template:\n\n```ts\nimport { Component, ChangeDetectionStrategy, input, computed } from '@angular/core';\nimport { Order } from './order.model';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `\n    <h2>{{ order().id }}</h2>\n    <p>Total: {{ formattedTotal() }}</p>\n  `,\n})\nexport class OrderSummaryComponent {\n  readonly order = input.required<Order>();\n\n  readonly formattedTotal = computed(() => this.order().total.toFixed(2));\n}\n```\n\nKey points:\n\n- `input()` returns an `InputSignal<T>` (writable via `input()`, read-only via `input.required<T>()` when there is no default). `input.required<Order>()` is the right choice if the parent must always pass `order`; otherwise `input<Order>()` gives a possibly-`undefined` value.\n- Read it by calling it: `this.order()` in the class, `order()` in the template. It is a function/signal, not a plain field — do not write `this.order` or `order` bare.\n- Derive anything from it with `computed()`, as above. Do not mutate other state or call HTTP inside `computed()`.\n- Do not redeclare a plain `@Input() order: Order` field alongside it — mixing styles in one component is the thing to avoid. Also don't shadow with a getter; keep `order` as the signal and read `this.order()`.\n- Pair it with `ChangeDetectionStrategy.OnPush`; reading `order()` in the template registers the dependency automatically, so an OnPush component updates when the parent changes the input, no extra wiring needed.\n- If the parent needs two-way binding (the child also emits an update), use `model<Order>()` instead, which is the writable-signal counterpart.\n\nFor an output alongside it, use `output<Order>()` (or `output<void>()`) rather than `@Output()` + `EventEmitter`, again for consistency with the codebase's signal style.",
+              "outputSha256": "ed7c773e3e5b1e5126d0c19947aae2181b0e66a33f163dd7c26e0a9a7a6fc41d",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` (explicit Order type param) and reads it as a function: `order().id` in template and `this.order().total` in computed. It explicitly warns against `this.order`/`order` bare and against a plain `@Input() order: Order` field, so no fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it with the signal-based `input()` function, not the `@Input()` decorator, since the rest of the codebase has moved to signals. That keeps the component consistent, makes the input itself reactive, and lets you derive values from it with `computed()` without any extra plumbing.\n\nBasic declaration:\n\n```ts\nimport { Component, ChangeDetectionStrategy, input, computed } from '@angular/core';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `\n    <h2>{{ order().id }}</h2>\n    <p>Total: {{ total().toFixed(2) }}</p>\n  `,\n})\nexport class OrderSummaryComponent {\n  readonly order = input.required<Order>();\n\n  readonly total = computed(() =>\n    this.order().lines.reduce((sum, l) => sum + l.price * l.quantity, 0)\n  );\n}\n```\n\nKey points:\n\n- **Type it explicitly.** `input.required<Order>()` gives you a required input whose signal type is `Signal<Order>`. If the order may legitimately be absent (e.g. it arrives asynchronously), use `input<Order | undefined>()` and handle the `undefined` in the template with `@if (order(); as order) { ... }` rather than reaching through a possibly-undefined value.\n- **Read it as a function call in TS and template.** `this.order()` in the class, `order()` in the template — never `this.order` as if it were the raw value. That call is what registers the reactive dependency, which is exactly what makes `OnPush` change detection work correctly here.\n- **Derive with `computed()`, don't mutate.** Anything you'd previously have done in `ngOnChanges` to recompute a display value should become a `computed()` that reads `this.order()`. If you find yourself wanting to transform the incoming `Order` into other state you own, use a `linkedSignal()`/`computed()` rather than assigning in an `ngOnChanges`-equivalent, so the derived value stays in sync automatically.\n- **Prefer `input()` over `@Input()` even for one input.** Mixing signal inputs and decorator inputs in the same component is the ceremony actually worth avoiding; a codebase that standardizes on `input()` gets a uniform mental model.\n- **Use `model()` if it needs to be writable.** If the child should be able to push a changed value back up, `model<Order>()` gives you a two-way-bound signal instead of an input plus a separate `output()`.\n\nOne caveat: if this component genuinely has to interoperate with a template that uses the old `@Input()` binding syntax somewhere the signal form can't reach (rare on a codebase already on signals), that's the only case to reconsider. Otherwise, matches-the-codebase wins — go with `input()`.",
+              "outputSha256": "a701dd3676670f559e111c3b92b07f9c282f00c90e7e69dfb67cb01796a0be8b",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Declares `readonly order = input.required<Order>();` with explicit Order type (pass 1), and reads it as a function: `order().id` in template, `this.order()` in computed (pass 2). No @Input() field recommended; @Input() only contrasted. No plain `this.order` property read."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it with the signal-based `input()` function and read it as a call in the template and in your class logic — it is a getter function, not a plain field.\n\n```ts\nimport { Component, ChangeDetectionStrategy, input, computed } from '@angular/core';\nimport { Order } from './order.model';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `\n    <h2>{{ order().id }}</h2>\n    <p>{{ total() }}</p>\n  `,\n})\nexport class OrderSummaryComponent {\n  readonly order = input.required<Order>();\n\n  readonly total = computed(() => this.order().lineItems.length);\n}\n```\n\nKey points:\n\n- **Type it explicitly**: `input<Order>()` / `input.required<Order>()`. The type argument is what gets referenced; don't fall back to an untyped `input()` with a cast.\n- **`input.required<Order>()` vs `input<Order>()`**: use `.required` when the parent must always bind it (this is the usual case for an `Order`); use plain `input<Order>()` only if there's a sensible absence, in which case its read type is `Order | undefined` and `computed`/template reads must handle `undefined`.\n- **Read it as a call**: `this.order()` in the class, `order()` in the template — not `this.order` / `order`. This is what registers the reactive dependency so an `OnPush` component re-renders correctly when the input changes. That's why OnPush is safe here and needs no extra wiring (see `rules/patterns.mdc`).\n- **Derive, don't mutate**: anything computed from the input (a total, a formatted date, a filtered list) belongs in a `computed()` that reads `this.order()`, keeping it pure — no HTTP calls or writes to other signals inside it.\n- **Setting it**: the parent binds a normal property binding (`[order]=\"order()\"`) and can also use it as the target of a two-way-style `model()` if the child needs to push changes back; a plain `input()` is one-way and read-only in the child.\n\nIf the surrounding codebase already uses `input()` elsewhere, match that exactly and follow the existing file-suffix convention (`.component.ts` vs plain `.ts`). Once wired in, verify with the project's `ng build` and lint scripts before calling it done.",
+              "outputSha256": "f5b36292c492bd5fa64ede25c513647fc627a09516b6a123b5c756efec621474",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` with explicit Order type (pass 1) and reads it as a call: `order().id` in template and `this.order().lineItems` in computed (pass 2). It explicitly warns against `this.order`/`order` plain access and never recommends @Input()."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it with `input.required<Order>()` (from `@angular/core`) as a field initializer, and read it as a signal call wherever you use it — including the template.\n\n```ts\nimport { ChangeDetectionStrategy, Component, computed, input } from '@angular/core';\nimport { Order } from './order.model';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `\n    <h2>{{ order().id }}</h2>\n    <p>Total: {{ order().total | currency }}</p>\n    <p>Items: {{ itemCount() }}</p>\n  `,\n})\nexport class OrderSummaryComponent {\n  readonly order = input.required<Order>();\n\n  // derive from the input signal; stays in sync automatically\n  readonly itemCount = computed(() => this.order().lineItems.length);\n}\n```\n\nKey points that match the signal-based conventions in the rest of this codebase:\n\n- **`input.required<T>()` vs `input<T>()`** — use `input.required<Order>()` because `order` must always be passed by the parent. That makes the type `InputSignal<Order>` (never `Order | undefined`) and Angular will error at the template/compile level if a parent forgets to bind it. If a missing value were legitimate, use `input<Order>()` and handle the `undefined` branch in a `computed()` or `@if`.\n\n- **Read it, don't unwrap it.** There is no decorator property named `order` — `order` is a function. Call `this.order()` in the class and `order()` in the template. In a template the call registers the signal read, so with `ChangeDetectionStrategy.OnPush` the component re-renders only when the input actually changes. Don't stash it into a plain field in `ngOnInit` — that breaks reactivity and reintroduces the \"stale input\" class of bug.\n\n- **Derive with `computed()`, never mutate the input.** Put any derivation (totals, filtered lists, formatting) in a `computed()` that reads `this.order()`. Keep it pure — no HTTP, no writes to other signals inside it.\n\n- **Bind from the parent as a normal property binding:**\n  ```ts\n  @Component({\n    selector: 'app-order-page',\n    standalone: true,\n    imports: [OrderSummaryComponent],\n    template: `@if (order(); as o) { <app-order-summary [order]=\"o\" /> }`,\n  })\n  export class OrderPageComponent {\n    readonly order = signal<Order | undefined>(undefined);\n  }\n  ```\n  Note `[order]=\"o\"`, not `[order]=\"order()\"` without a guard — bind the resolved value, and only render the child once you have one, so the required input contract holds.\n\n- **If the child needs to push a change back up**, use a paired `output<Order>()` rather than mutating the input object — inputs are one-way.\n\nTwo things to keep consistent with the rest of the codebase:\n\n1. If the surrounding components already use `input()` rather than `@Input()`, do not mix the two styles in the same component. A signal input should be consumed as a signal read everywhere in the class and template.\n2. No `ngOnChanges` handling is needed for this input — that lifecycle hook is for decorator-based inputs. With signal inputs you react in `computed()` or an `effect()` if you genuinely need a side effect (and effects are for side effects only, not for deriving display state).",
+              "outputSha256": "f04b4b8a85ac3f1d0f6a3dcf62c26c2beff492cb084cafdb2b358831f0ace92e",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` with explicit Order type (pass 1) and reads it as a function: `order().id` in template, `this.order().lineItems` in computed (pass 2). It explicitly warns against @Input() decorator and against stashing into a plain field, so no fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it as a signal input, not an `@Input()` decorator:\n\n```ts\nimport { Component, input, computed, ChangeDetectionStrategy } from '@angular/core';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `...`,\n})\nexport class OrderSummaryComponent {\n  // required signal input, explicitly typed\n  readonly order = input.required<Order>();\n}\n```\n\nKey points, matching a signals-throughout codebase:\n\n- **`input.required<Order>()`** for a mandatory input. Use `input<Order>()` (or `input(defaultValue)`) only if the value is genuinely optional. Always give the explicit type argument — don't rely on inference from a default.\n- **Read it by calling it**: in the class, `this.order()`; in the template, `order()` with parentheses. It is a function, not a field.\n- **Derive values with `computed()`**, not by reading the input eagerly:\n\n  ```ts\n  readonly total = computed(() =>\n    this.order().lines.reduce((sum, l) => sum + l.qty * l.unitPrice, 0)\n  );\n  ```\n\n  A `computed()` that reads `this.order()` re-evaluates whenever the parent passes a new `Order`. Never mutate or make HTTP calls inside it.\n- **Don't write to it.** Signal inputs are read-only in the component. If the child needs to emit a change back, use a separate `output()`; if the parent must be able to two-way bind, use `model()` instead of `input()`.\n- **Keep `OnPush`.** With the template reading `order()` (directly or through a `computed()`), the component registers that signal as a dependency, so it re-renders when the input changes without any extra wiring. Using `Default` here just causes needless re-checks.\n- **Only show the input once you're sure it's available.** `input.required()` throws if read before the parent binds it, so guard with `@if (order(); as o)` in the template or a `computed()` that tolerates it — don't reach for a non-null `!` on a required input in the template.\n\nOne consistency note: since this codebase is signals-throughout, don't mix an `@Input()` decorator for this one case. Mixed styles in a single component is the actual ceremony.",
+              "outputSha256": "9fcb0083f0a6bc750f07edfcdb6fded4aad4dba5445a822d062fbdf407100d5d",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` with explicit Order type (criterion 1) and reads it as a function: `this.order()` in class/computed and `order()` in template (criterion 2). It contrasts @Input() only to warn against it, and never reads as `this.order` property access."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it as a required signal input and read it as a signal (call it, like a function) everywhere you consume it — in the template, in `computed()`, and in `effect()`.\n\nDeclaration:\n\n```ts\nimport { Component, ChangeDetectionStrategy, input, computed } from '@angular/core';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  templateUrl: './order-summary.component.html',\n})\nexport class OrderSummaryComponent {\n  readonly order = input.required<Order>();\n\n  // derived state reads the input as a signal\n  readonly total = computed(() => this.order().lines.reduce((sum, l) => sum + l.price * l.qty, 0));\n}\n```\n\nKey points:\n\n- **`input.required<Order>()`** (not `@Input() order!: Order`) is the signal-based form. It's typed explicitly, so with `strictTemplates` on (check `angular.json`), passing the wrong shape from a parent is a compile error rather than a runtime surprise. Use `input<Order>()` (optional) only if the component genuinely works without it — and then handle `undefined` explicitly.\n- **Read it by calling it.** It's a `Signal<Order>`, so it's `this.order()` in TypeScript and `order()` in the template (`{{ order().id }}`), not `this.order` / `{{ order.id }}`. Reading it inside `computed()`/`effect()`/the template automatically registers the dependency, which is what makes `OnPush` work correctly with no manual `markForCheck()`.\n- **Keep `computed()` pure.** Derive totals, formatted labels, filtered line lists, etc. from `this.order()` in `computed()` — don't put side effects or HTTP calls there.\n- **Don't mutate the input.** `Order` is an object; if a child needs to change something, use a `model()` input or an `output()` event so the parent owns the state. If the object itself is being replaced by the parent with a new reference, signals will pick that up; mutating fields in place won't trigger reactivity.\n- **If the parent hasn't migrated yet**, a signal input can still be bound with the normal `[order]=\"currentOrder\"` syntax from a template — signal inputs work across the boundary. But don't mix styles *within* this component: everything signal-based, consistently.\n- **Teardown if you subscribe:** if you end up consuming `this.order()` inside an RxJS pipeline (e.g. `toObservable(this.order)` → HTTP), tear the subscription down with `takeUntilDestroyed()` or convert back with `toSignal()`.\n\nBefore writing it, glance at a couple of neighbouring components to confirm the file-suffix (`.component.ts` vs `.ts`), whether they use `@if`/`@for` vs `*ngIf`/`*ngFor`, and whether inputs are declared with `input()` or still `@Input()`. Match that convention — if the codebase is on signal inputs everywhere, `input.required<Order>()` is exactly right; if it's a mixed codebase, keep this new component internally consistent with the signal style the task asked for.",
+              "outputSha256": "b347b2fc83841d07ce9ae067d9a998e3130f2492c64d857ab463dd761606d510",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Declaration shown: `readonly order = input.required<Order>();` with explicit Order type. Reading shown by calling as function: `this.order()` in computed and `order()` in template (`{{ order().id }}`), explicitly contrasting with `this.order`/`{{ order.id }}`. No @Input() recommended; only mentioned to contrast."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it with the signal-based `input()` function rather than the `@Input()` decorator, since the rest of the codebase has already moved to signals:\n\n```ts\nimport { Component, ChangeDetectionStrategy, input } from '@angular/core';\n\n@Component({\n  selector: 'app-order-card',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `...`,\n})\nexport class OrderCardComponent {\n  // required input: caller must bind [order]\n  readonly order = input.required<Order>();\n}\n```\n\nKey points for your case:\n\n- `input()` is the signal-input API. Use `input.required<Order>()` because `order` is a mandatory value — this makes a missed binding a compile-time error under `strictTemplates`, rather than `undefined` at runtime. If it were optional, you'd write `input<Order>()` and get `Order | undefined`.\n- Do **not** name the field the same as a setter/getter input; the returned value is an `InputSignal<Order>`.\n- Read it like any other signal — `this.order()` returns the `Order`, not an observable or a plain field. In the template you call it too: `{{ order().id }}`.\n\n```ts\nreadonly total = computed(() => this.order().lines.reduce((sum, l) => sum + l.price * l.qty, 0));\n\ntoString(): string {\n  return `Order ${this.order().id}`; // note the ()\n}\n```\n\nReading `order()` inside a `computed()` registers the dependency automatically, so `OnPush` change detection will re-run when the parent passes a new `Order` — no `ngOnChanges` and no manual `markForCheck()`.\n\nIf the component should be able to emit a changed value back (e.g. it edits the order and the parent should see it), use `model()` instead of `input()` for a two-way-bindable signal input:\n\n```ts\nreadonly order = model.required<Order>();\n// parent: <app-order-card [(order)]=\"currentOrder\" />\n```\n\nFor a read-only input, stick with `input()`. Keep the type explicit (`input.required<Order>()`) — an untyped `input()` gives you `unknown` and defeats the point of matching the codebase's typed-signal style. And if a parent ever emits a new `Order` object reference, that flows through as a new signal value; there's no separate change-detection hook to wire up.",
+              "outputSha256": "d7eecb6bf299f03b1ff52cda874d4f62c0689c1476aa7404946a267dee371122",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` with explicit Order type (criterion 1) and reads it as a function: `this.order()`, `{{ order().id }}`, `this.order().lines` (criterion 2). It mentions @Input() only to contrast, not as the recommendation, and never reads `this.order` as a plain property."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it as a signal input on the component class, and read it as a function call in the template and in any `computed()`/`effect()` — it is not a plain property.\n\n```ts\nimport { Component, ChangeDetectionStrategy, input, computed } from '@angular/core';\nimport { Order } from './order.model';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `\n    <h2>{{ order().id }}</h2>\n    <p>{{ totalLabel() }}</p>\n  `,\n})\nexport class OrderSummaryComponent {\n  // Required, typed signal input\n  readonly order = input.required<Order>();\n\n  // Derived state reacts to the input automatically\n  readonly totalLabel = computed(() => `Total: ${this.order().total.toFixed(2)}`);\n}\n```\n\nThe points that matter here:\n\n**Use `input.required<Order>()` rather than `@Input() order!: Order`.** The signal form gives you compile-time enforcement that the binding is supplied, removes the need for a `!` definite-assignment assertion, and integrates with `OnPush` without extra wiring. Since the rest of the codebase is on signals, this also avoids mixing two input styles on the same component — a signal input inside a component that otherwise uses `@Input()` decorators (or vice versa) is the actual source of confusion, not the signal itself. If the input genuinely has a sensible default, use `input<Order>(defaultOrder)` and either name it to signal that (e.g. `defaultOrder`) or make it `input.required` and let callers bind explicitly — don't paper over a required input with a dummy default. Also give it an explicit type parameter; an untyped `input()` widens to `unknown` under `strictTemplates` and defeats the point.\n\n**Read it as `order()` everywhere, including in the template.** A signal input is a `Signal<Order>`, so it is a getter-like function, not a property. If you write `{{ order.id }}` you will be reading the signal object itself, not its value, and with `strictTemplates` that is a type error you should fix at the source rather than by loosening the setting. Inside the class, any `computed()` or `effect()` that depends on the input reads it the same way, and that read registers the dependency automatically — which is exactly why `OnPush` needs no manual `markForCheck()` or `ChangeDetectorRef` calls. Keep `computed()` bodies pure: derive from `this.order()`, don't fetch or mutate other signals inside them.\n\n**Don't reach for `set`/`mutate`.** A signal input is read-only from the component's perspective; it has no `.set()`. If a child needs to emit an edited value back to the parent, that's an `output()` (or a `model()` two-way binding) on the child, with the parent owning the state — not the input.\n\n**Naming and placement.** Match the project's file-suffix convention (the discovery step in the workflow: `.component.ts` vs. plain `.ts`) and keep the input as a `readonly` class field near the top of the class, alongside any sibling inputs, so the component's public surface is obvious at a glance.\n\n**If you consume it in an RxJS stream**, convert there rather than mixing paradigms: pipe the observable through `toSignal()` if you want a derived signal, or create any manual subscription with `takeUntilDestroyed()` so it has an explicit teardown. The input itself gives you no teardown concern — it's the subscriptions around it that do.\n\nOne thing to confirm against the codebase before you commit: check a few existing components to see whether they use `input()` or still use `@Input()` setter patterns, and match the dominant convention for this codebase rather than the newest idiom in isolation. If this file's neighbors use `@Input()`, the task likely calls for that style unless it explicitly asks for the signal migration — but given your description that the codebase uses signals throughout, `input.required<Order>()` is the right call here.",
+              "outputSha256": "2170e04fc5f3d1cb0db03c49482213f19105b313b4c630d3385a2d439cc3ee6a",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` with explicit Order type (pass 1) and reads it as `order()` in template (`{{ order().id }}`) and in computed (`this.order().total`) (pass 2). It recommends signal input, not @Input() decorator, and never reads as `this.order` property access, so no fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "Declare it as a signal input, not a decorator:\n\n```ts\nimport { Component, ChangeDetectionStrategy, input, computed } from '@angular/core';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `\n    <h2>{{ order().id }}</h2>\n    <p>{{ total() }}</p>\n  `,\n})\nexport class OrderSummaryComponent {\n  readonly order = input.required<Order>();\n\n  readonly total = computed(() =>\n    this.order().lineItems.reduce((sum, li) => sum + li.price * li.qty, 0)\n  );\n}\n```\n\nKey points:\n\n**Declare with `input.required<Order>()`**, not `input<Order>()`. The generic parameter gives you the explicit type the project convention requires, and `required` matches your description — the component must receive an `order`, so a missing binding should be a build-time template error rather than a silent `undefined` at runtime. If the input were genuinely optional you'd write `input<Order>()` and read `order()` as `Order | undefined` (or give it an initial value: `input<Order>(defaultOrder)`).\n\n**Read it as a call, `this.order()`, everywhere** — in the template, in `computed()`, in `effect()`, in methods. The signal input creates a getter function property; there is no plain `this.order` field. This is the single most common mistake when coming from `@Input()`: writing `this.order` and getting the function itself rather than the value.\n\n**Forget NgModule wiring entirely.** No `@Input()` decorator, no `imports` registration for the input, no `FormsModule`-style entry needed — `input()` is part of the core runtime. You still need `standalone: true` and to import any directives/pipes the template uses, but the input itself needs nothing.\n\n**Derive, don't mutate.** Any value computed from `order` should be a `computed()` reading `this.order()` inside it, as above. Do not write to a separate `signal()` in an `ngOnChanges`-style hook to mirror the input — that pattern is the decorator-era one signal inputs replace. `computed()` re-evaluates automatically whenever the parent rebinds `order`, no lifecycle hook required.\n\n**Keep the `computed()` pure.** The example above only reads `order()` and does arithmetic. If computing the total needed an HTTP call or another service, that belongs in an `effect()` or a subscription, not inside the `computed()` — see the patterns rule.\n\nTwo things to confirm against the rest of the codebase before you commit:\n\n- If the parent binds it, use the square-bracket signal binding and let the parent pass a signal or a plain value as the existing code does (`[order]=\"selectedOrder()\"` vs `[order]=\"selectedOrder\"` — check which the rest of the app uses).\n- If the project's existing components still use `@Input()` with signal-typed fields rather than `input()`, match that instead; the guidance here assumes the codebase has actually adopted `input()`, which you said it has.",
+              "outputSha256": "60106327734cac8bee36d18592a8fe45927fc21062e49b83efd3b7e7142acdd5",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` with explicit Order type (pass 1) and reads it as a call: `order().id` in template and `this.order()` in computed (pass 2). It explicitly warns against `this.order` plain access and `@Input()`, so no fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "Use a signal input, not an `@Input()` decorator — the codebase has already standardized on `input()`, and a lone decorator-based field in an otherwise signal component is exactly the inconsistency worth avoiding.\n\nDeclare it as a typed signal input on the class (field initializer, no constructor needed):\n\n```ts\nimport { Component, ChangeDetectionStrategy, input, computed } from '@angular/core';\n\n@Component({\n  selector: 'app-order-summary',\n  standalone: true,\n  templateUrl: './order-summary.component.html',\n  changeDetection: ChangeDetectionStrategy.OnPush,\n})\nexport class OrderSummaryComponent {\n  // required signal input, explicitly typed\n  readonly order = input.required<Order>();\n\n  // derive values from it with computed()\n  readonly total = computed(() =>\n    this.order().lineItems.reduce((sum, li) => sum + li.quantity * li.unitPrice, 0)\n  );\n\n  readonly isEmpty = computed(() => this.order().lineItems.length === 0);\n}\n```\n\nKey points:\n\n- **`input.required<Order>()`** makes it a mandatory input with the type `Order`. If the input is genuinely optional, use `input<Order | undefined>(undefined)` (or a default value) instead, but only when absence is a real, handled case.\n- **Read it by calling it**: `this.order()` in the class, `order()` in the template (no `this`). It's a function, not a field — `this.order` without the call would be the signal itself, a real and easy bug.\n- **Never write to it.** An input is read-only; for a value the component both receives and can change, use `model()` instead. Mutating an input signal would throw.\n- **Use `computed()` for anything derived** from the input (totals, flags, formatted values) rather than recomputing in the template or in a getter — keep those `computed()` bodies pure, no side effects or HTTP calls.\n- **Keep `OnPush`.** Because the template reads `order()` (and the computeds), Angular tracks the dependency and re-renders when the input changes — no manual change-detection wiring required.\n\nOne thing to confirm during Step 1 discovery rather than assume: check an existing component for whether the project suffixes signal inputs `readonly` and whether it uses `input()` vs `input.required()` for required inputs — match that exact style so your component reads like the rest of the codebase. If, contrary to the premise, some existing components still use `@Input()`, follow the surrounding file's convention for a small addition rather than converting them; the rule is consistency with siblings, and here the siblings are signal-based.\n\nIn the parent template you bind it normally — `[order]=\"currentOrder()\"` — and with `input.required` the compiler will flag any usage that omits it, which is the behavior you want.",
+              "outputSha256": "a7ac7d5bc6263ef2ea4ca3ce4d12b61feb69f843acd9e1a4c8251e949958742c",
+              "promptSha256": "a72e25154b64b3e727861ac692ce75a1a3b5577d5196e60821ad7d4c5f4bc2d3",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows `readonly order = input.required<Order>();` (explicit Order type) and reads it by calling: `this.order()` in computed bodies and `order()` in template. It explicitly warns against `this.order` plain access and against @Input() decorator, satisfying both pass criteria and avoiding both fail criteria."
+              },
+              "passed": true
+            }
+          ]
+        },
+        {
+          "id": "inject-inside-injection-context-only",
+          "kind": "behavior",
+          "prompt": "In an Angular component's ngOnInit, I need to call a service method inside a setTimeout callback. Should I call inject() right there inside the setTimeout callback to grab the service?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 10,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "No. `inject()` only works inside an injection context — during construction, a field initializer, or inside a factory function passed to `inject`/`runInInjectionContext`. A `setTimeout` callback is not an injection context, so calling `inject()` there throws at runtime with an error like \"inject() must be called from an injection context,\" not a compile-time error.\n\nThe correct pattern is to inject the dependency once, up front, and capture the resulting reference in the callback's closure:\n\n```ts\nexport class MyComponent implements OnInit {\n  private readonly myService = inject(MyService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.myService.doSomething();\n    }, 500);\n  }\n}\n```\n\nBecause the arrow function closes over `this`, `this.myService` is still the same instance when the timer fires — no second `inject()` call is needed (or legal).\n\nA few related notes worth applying in this same edit:\n\n- Prefer injecting at the field-initializer level rather than in `ngOnInit` itself. `ngOnInit` is not an injection context either, so `inject()` called directly in `ngOnInit` has the same problem. If you genuinely have a late-bound case where you must resolve a dependency after construction, use `runInInjectionContext` with a captured `Injector` — but that's for dynamic resolution, not for a plain service you already know you need.\n- If what you actually want is a service that internally delays work, put the `setTimeout` inside the service rather than the component — the service can inject what it needs at construction time and the component stays unaware of the timing.\n- If the delayed call is really \"do work after a period, tear down if the component is destroyed first,\" consider whether `setTimeout` is the right primitive at all versus an RxJS `timer(...).pipe(takeUntilDestroyed(this.destroyRef)).subscribe(...)`, which gives you an explicit teardown path rather than a dangling timer that fires after the component is gone.\n- If the callback ends up touching signals and you're on an older Angular without `takeUntilDestroyed`, keep the manual cleanup explicit rather than assuming the component dies before the timer fires.\n\nThe short version: inject once in the field initializer, use `this.` inside the arrow function, and don't try to re-enter the injection context from inside `setTimeout`.",
+              "outputSha256": "45d3789dd9a3198ddc08914417c19cfad5426ffb3a3fba21ba45b814965904b1",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (construction/field initializer/runInInjectionContext) and setTimeout callback is not one, throwing at runtime. It shows the concrete fix: `private readonly myService = inject(MyService);` field initializer, then `this.myService.doSomething()` inside the setTimeout arrow closure. No fail criterion: it never recommends calling inject() in the callback."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — do not call `inject()` inside the `setTimeout` callback. Injection contexts are not ambient.\n\n`inject()` only works when there is an active injection context: the constructor, a field initializer, a factory function passed to `useFactory`/providers, or code running inside `runInInjectionContext`. A `setTimeout` callback runs later, outside that context, so `inject()` throws `NG0203` (or the equivalent \"inject() must be called from an injection context\") at runtime — not at compile time, which makes it easy to ship and then fail on the first timer tick.\n\nThe correct pattern is to inject once, in the injection context, and capture the reference:\n\n```ts\n@Component({ /* ... */ })\nexport class MyComponent implements OnInit {\n  private readonly myService = inject(MyService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.myService.doSomething();\n    }, 500);\n  }\n}\n```\n\nThe arrow function closes over `this.myService`, so the callback still has the dependency without needing its own injection context. If you also need `inject()` for something the timer itself creates (a new `Injector`-scoped object, a `DestroyRef`, etc.), capture the `Injector` in the constructor/field initializer and call `injector.get(...)`, or wrap the callback body in `runInInjectionContext(this.injector, () => { ... })` — but for retrieving an existing service, the field initializer above is all you need.\n\nTwo related notes worth checking while you are in this code:\n\n- If `MyService` also has a `DestroyRef`-based `takeUntilDestroyed` or subscription cleanup, a bare `setTimeout` is not torn down when the component is destroyed. If the callback touches signals or subscriptions on a component that could be destroyed before the timer fires, prefer an RxJS timer (`timer(500).pipe(takeUntilDestroyed(this.destroyRef))`) or clear the timeout in `ngOnDestroy`, so the callback cannot run against a dead component.\n- If you are on a version where the component uses signal inputs/`OnPush`, the service call inside the callback is fine — just make sure any state it writes goes through a `signal` so the view updates.",
+              "outputSha256": "15ea7265e8e8e87fa6538195a74eba9613b3e95633712c1fb56a7f0e448f50cf",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in an injection context (constructor/field initializer/runInInjectionContext) and that a setTimeout callback runs outside it, throwing NG0203. It shows the concrete fix: `private readonly myService = inject(MyService);` field initializer, then `this.myService.doSomething()` inside the setTimeout closure. Also names runInInjectionContext with a captured Injector. No fail criterion."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — calling `inject()` inside the `setTimeout` callback will throw at runtime. `inject()` only works inside an injection context: the constructor/field-initializer of a class being constructed by DI, or inside a function passed to `runInInjectionContext()`. A `setTimeout` callback runs later, outside that context, so by the time it fires there's no active injector for `inject()` to read.\n\nThe fix is to grab the service once, in the injection context, and capture it in the closure:\n\n```ts\nexport class MyComponent implements OnInit {\n  private readonly myService = inject(MyService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.myService.doSomething();\n    }, 500);\n  }\n}\n```\n\nA field initializer (or constructor body) is an injection context, so `inject(MyService)` there is valid, and the arrow function closes over `this` / the captured service reference, which is still valid when the timeout fires.\n\nA few related notes worth flagging:\n\n- If for some reason you genuinely need to resolve a dependency lazily at callback time (rare — e.g. a token you can't resolve eagerly), use `runInInjectionContext` with an injector you captured earlier:\n  ```ts\n  private readonly injector = inject(Injector);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      runInInjectionContext(this.injector, () => {\n        const svc = inject(MyService);\n        svc.doSomething();\n      });\n    }, 500);\n  }\n  ```\n  But this is almost always unnecessary; prefer the eager capture above.\n- A bare `setTimeout` that calls into a service and then touches component state is a common way to leak: if the component is destroyed before the timer fires, the callback still runs against a dead component. If the delayed work can touch component state (signals, form values, etc.), prefer the RxJS route and take it down on destroy:\n  ```ts\n  private readonly destroyRef = inject(DestroyRef);\n\n  ngOnInit(): void {\n    timer(500)\n      .pipe(takeUntilDestroyed(this.destroyRef))\n      .subscribe(() => this.myService.doSomething());\n  }\n  ```\n  Or `toSignal(timer(500))` if you only need a signal-shaped value. Either way, never leave a subscription or a pending timer with no teardown path — see `rules/patterns.mdc`.\n- If the component uses `OnPush`, work kicked off from a `setTimeout` that writes to a plain field won't necessarily update the view; writing to a `signal()` will, because the template read of that signal registers the dependency. This is another reason to prefer signal state over plain mutable fields in this kind of deferred-callback code.\n\nSo: inject in the field initializer (or constructor), capture it, and let the `setTimeout` callback close over it — never call `inject()` inside the callback itself.",
+              "outputSha256": "994d026657c37419f2806263e88de80cbe849251bad990b3b945bcc6ec2f08c8",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (constructor/field initializer or runInInjectionContext) and throws in setTimeout callback. Shows concrete fix: `private readonly myService = inject(MyService);` field initializer, referenced via this.myService inside setTimeout. Also shows runInInjectionContext with captured `private readonly injector = inject(Injector);`. No fail criterion met."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — `inject()` only works inside an injection context, and a `setTimeout` callback is not one. If you call `inject(MyService)` inside that callback it will throw at runtime (`NG0203` / \"inject() must be called from an injection context\"), and the failure only surfaces when the timer fires, not at build time. So it's the worst kind of bug: invisible until that code path runs.\n\nThe correct pattern is to inject the service where you're still in an injection context — as a class field initializer or in the constructor — and then capture it in the closure:\n\n```ts\nexport class MyComponent implements OnInit {\n  private readonly myService = inject(MyService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.myService.doSomething();\n    }, 500);\n  }\n}\n```\n\nA few things worth noting alongside this:\n\n- Field initializers and the constructor both run inside an injection context, so `inject()` works in either. `ngOnInit` does **not** — it's already too late, which is why you can't just move the call there either.\n- The class field initializer form is preferred over the constructor here; it matches how the rest of the codebase should be doing DI and keeps the dependency declaration next to its use.\n- If this component is `OnPush` (it should be), the arrow function preserves `this`, so calling the service through `this.myService` is fine. Just don't switch to a `function() {}` callback, or `this` will be `undefined`.\n\nIf the reason you're reaching for `setTimeout` is really \"I need to wait for something async,\" consider whether an Observable piped through `takeUntilDestroyed()`, or a `toSignal()`-converted stream, is a better fit than a bare timer — a `setTimeout` that outlives the component is an easy leak, and the project's patterns expect torn-down subscriptions rather than fire-and-forget timers. If you genuinely need a deferred one-shot, keeping the service captured in the closure as above is the right call.",
+              "outputSha256": "8c87e9efd2f364d713b6d5188f2d715520d440df68c961160a52fff2f09a0f0b",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context and setTimeout callback is not one, will throw NG0203 (criterion 1). It shows the concrete fix: `private readonly myService = inject(MyService);` as a class field initializer, then references `this.myService` inside the setTimeout closure (criterion 2). No fail criterion: it never recommends calling inject() inside the callback."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — `inject()` only works when called during the component's construction phase, specifically while Angular is building the injector for that class (i.e., at field-initializer time or in the constructor body). It relies on being inside an \"injection context.\" A `setTimeout` callback runs later, outside that context, long after construction has finished. Calling `inject()` there will throw at runtime: something like \"inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function used with `runInInjectionContext`.\"\n\nNote the failure mode: this is a runtime error, not a compile-time one, so TypeScript and the build will happily accept it and it'll only blow up when the timer fires.\n\n## The right pattern\n\nInject the service in the class, then close over that already-injected reference inside your `setTimeout` callback:\n\n```ts\n@Component({ /* ... */ })\nexport class MyComponent implements OnInit {\n  private readonly myService = inject(MyService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      // myService is captured in this closure -- no inject() needed here\n      this.myService.doSomething();\n    }, 1000);\n  }\n}\n```\n\nThe closure captures the field, so the service is still available when the callback runs. Only `inject()` itself needs the injection context; using the already-resolved dependency does not.\n\n## If you genuinely have no constructor/field access\n\nThat's rare in a normal component, but if for some reason you must resolve a dependency at call-time rather than construction-time — a utility function, a callback passed deep into another module — use `runInInjectionContext`, passing the ambient injector:\n\n```ts\nngOnInit(): void {\n  const injector = inject(Injector); // captured at construction time\n  setTimeout(() => {\n    runInInjectionContext(injector, () => {\n      const myService = inject(MyService);\n      myService.doSomething();\n    });\n  }, 1000);\n}\n```\n\nBut for an ordinary component `ngOnInit`, this is overkill. The field-injection form in the first example is the idiom you want: `inject()` at the field initializer, then reference that field inside the `setTimeout` callback.\n\nOne related caution worth flagging: a `setTimeout` in a component that outlives the timer can still fire after the component is destroyed. If the callback touches component state or triggers subscriptions, guard it (clear the timer in `ngOnDestroy`, or use `takeUntilDestroyed` for any RxJS work it kicks off). The injection concern and the lifecycle concern are separate, but both bite in the same callback.",
+              "outputSha256": "e974f1fffe7be4a59b10cbc1b525ecd9301ce06bf0c2e6e3cc9a74e286abf612",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (field initializer/constructor), not in setTimeout, and will throw at runtime. Fix shown concretely: `private readonly myService = inject(MyService);` field, referenced via closure inside setTimeout. Also shows runInInjectionContext with `const injector = inject(Injector)` captured before setTimeout. No recommendation to call inject() inside the callback as a fix."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — calling `inject()` inside the `setTimeout` callback will throw at runtime. `inject()` only works within an injection context, which exists during construction/field initialization of the class (or inside an `inject()`-aware function called from that context), not inside an arbitrary callback that runs later.\n\nThe correct pattern is to inject the service once, in the constructor or as a field initializer, and then reference that already-resolved instance inside the callback:\n\n```ts\nexport class MyComponent implements OnInit {\n  private readonly myService = inject(MyService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.myService.doSomething();\n    }, 0);\n  }\n}\n```\n\nA few related notes:\n\n- The injected reference is captured by the closure, so there is no need to re-resolve it. Even if the dependency were async (say, a token backed by an `Observable`), you would inject the resolved dependency once and read its current value inside the callback, not call `inject()` there.\n- If the dependency is genuinely only needed conditionally at callback time, you still inject it up front and guard its use in the callback — do not defer the injection itself.\n- If this `setTimeout` is being used to escape change-detection timing rather than to genuinely schedule work later, prefer a signal/`computed`/`effect` or an RxJS operator instead. `setTimeout` inside `ngOnInit` is also a subscription-less async path, so if the callback ends up creating any long-lived subscription, make sure it has an explicit teardown (`takeUntilDestroyed()`, `async` pipe, or `toSignal()`).\n- Remember `setTimeout` callbacks run outside Angular's change detection in non-signal code, so if you mutate state the template depends on, make sure that state is signal-based (which schedules its own update) rather than a plain field relying on a normal CD pass.",
+              "outputSha256": "ef0e54948f3957ba61d2ed7a97a4808beac50d43dfe0c6a96c36b0086a839046",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (construction/field init), not in the setTimeout callback, and will throw. It shows the concrete fix: `private readonly myService = inject(MyService);` as a field initializer, then `this.myService.doSomething()` inside the setTimeout closure. No fail criterion met."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — don't call `inject()` inside the `setTimeout` callback. `inject()` only works while you're inside an injection context: during field initializers, the constructor, or a factory function invoked in one. By the time the `setTimeout` callback runs, that context is gone, and the call throws at runtime (not compile time), so you won't catch it until the timer fires.\n\nThe fix is to inject once, up front, and capture the result in the closure:\n\n```ts\nexport class MyComponent {\n  private readonly myService = inject(MyService); // injection context — fine\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.myService.doSomething(); // captured reference, no inject() here\n    }, 0);\n  }\n}\n```\n\nOr, if you prefer to keep everything local to `ngOnInit`, resolve the dependency before the callback:\n\n```ts\nngOnInit(): void {\n  const myService = this.myService; // or inject(MyService) here, still in ngOnInit's context?\n  setTimeout(() => myService.doSomething(), 0);\n}\n```\n\nOne caveat on that second form: `ngOnInit` itself is *not* an injection context by default. `inject()` works inside the constructor, field initializers, and factory functions called from those — not from lifecycle hooks unless Angular explicitly invokes the hook within one (it generally doesn't for user components). So the reliable version is the first one: inject at the field/constructor level, then use `this.myService` everywhere, including inside async callbacks.\n\nA couple of related notes for this shape of code:\n\n- If the service call is really just \"do something after the next tick / after a delay,\" consider whether `setTimeout` is the right primitive at all — Angular's `afterNextRender` or `afterRenderEffect` are purpose-built for post-render work and participate properly in the framework's scheduling.\n- If `doSomething()` returns an `Observable` and you're subscribing for its result (rather than fire-and-forget), don't leave the subscription dangling. Either convert once with `toSignal()` and read it from a `computed()`/template, or pipe the subscription through `takeUntilDestroyed()` so it tears down with the component.\n- If the callback needs to update state the template reads, write to a `signal()` rather than mutating a plain field, so `OnPush` change detection picks the change up without extra manual marking.\n\nSo: inject at the field-initializer level, capture it, and use the captured reference inside the `setTimeout` callback.",
+              "outputSha256": "95b343da745499e8f1015f25b65a3f4e01504d3061baa0a12367ab715f36c5b0",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (field initializers/constructor) and throws at runtime inside setTimeout. Shows concrete fix: `private readonly myService = inject(MyService);` field initializer, then `this.myService.doSomething()` inside the callback. No fail criterion: it explicitly warns against calling inject() in the callback."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — don't call `inject()` inside the `setTimeout` callback. `inject()` only works inside an injection context: a constructor, a field initializer, or a function explicitly run via `runInInjectionContext`. A `setTimeout` callback fires later, outside that context, so `inject()` there throws at runtime (typically `NG0203: inject() must be called from an injection context`). It's also not a compile-time error, which is why it's an easy mistake to ship and only hit in a specific timing path.\n\nThe correct pattern is to inject the dependency once, in the injection context, and capture the resulting instance in the closure:\n\n```ts\nexport class ExampleComponent implements OnInit {\n  private readonly exampleService = inject(ExampleService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.exampleService.doSomething();\n    });\n  }\n}\n```\n\nThe field initializer (or constructor) is the injection context; the arrow function keeps `this` bound so `this.exampleService` resolves to the already-injected instance when the timer fires.\n\nA few related points worth getting right while you're here:\n\n- If you're on a version with `ngOnInit` still present, note that the field initializer runs before `ngOnInit`, so there's no ordering problem — the service is available by the time the callback executes.\n- If the service is only ever needed inside that callback and nowhere else in the class, injecting it as a field is still correct; you just don't read it until the callback runs.\n- Wrap the `setTimeout` subscription semantics mentally with the RxJS rules: if this timer is actually driving async state, prefer `timer(...)` piped through `takeUntilDestroyed()` over a raw `setTimeout`, so the component's teardown cancels it rather than the callback firing against a destroyed component.\n- If you genuinely need to inject inside a deferred callback (rare, e.g. a dynamically created child needing an injector), use `Injector` captured up front and call `injector.get(Service)` — or `runInInjectionContext(injector, () => { ... })` — never bare `inject()`.\n\nSo: inject the service at the class level (or constructor), reference it through `this` inside the `setTimeout` callback.",
+              "outputSha256": "876247c18f97ede96e5cead3cb048101d09ce11c71572697cd89710c7dbd3b4b",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (constructor/field initializer/runInInjectionContext) and that calling it in setTimeout throws NG0203. It shows the concrete fix: `private readonly exampleService = inject(ExampleService);` field initializer, referenced via `this.exampleService` inside the setTimeout callback. No fail criterion: it never recommends calling inject() in the callback."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — that will throw at runtime. `inject()` only works when called inside an injection context, which is the constructor/field-initializer window, not inside an arbitrary callback that runs later. `setTimeout` defers execution outside that window, so calling `inject()` inside it fails with an error like \"inject() must be called from an injection context\" — and it fails at runtime, not compile time, so it can slip through a build.\n\nThe fix is to inject the dependency once, in the injection context, and capture it in the closure that `setTimeout` runs:\n\n```ts\n@Component({\n  selector: 'app-example',\n  standalone: true,\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `...`,\n})\nexport class ExampleComponent {\n  private readonly myService = inject(MyService); // injection context — fine\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      // myService is captured from the closure; do NOT inject() here\n      this.myService.doSomething();\n    }, 0);\n  }\n}\n```\n\nA few things worth noting given the skill's conventions:\n\n- Prefer a field initializer for the `inject()` call rather than putting it in the constructor body; both are injection contexts, but the field-initializer form is the idiomatic one and keeps the dependency visible at the top of the class.\n- Keep the injection consistent with the rest of the class — if other dependencies use `inject()`, don't mix in constructor-parameter injection for this one.\n- If what you actually want is debounce/delay behavior on an observable rather than a raw `setTimeout`, prefer RxJS (`debounceTime`, `delay`) piped into `toSignal()`, since it keeps the value in the reactive graph and avoids manual teardown concerns. A raw `setTimeout` in `ngOnInit` that outlives the component is a small leak unless you clear it in `ngOnDestroy`.\n- If the timeout is really just to defer until after view init, check whether `afterNextRender`/`afterRenderEffect` (current Angular) or `ngAfterViewInit` is the more direct expression of the intent — those keep you inside the Angular lifecycle rather than a bare timer.\n\nSo: inject at the field/constructor level, and let the `setTimeout` callback close over the injected reference.",
+              "outputSha256": "a78f5fbd96343b951c637609bdd5040ed11d8d8a3a0512919103764979142e4e",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (constructor/field initializer), not in setTimeout callback, and fails at runtime. Shows concrete fix: `private readonly myService = inject(MyService);` field initializer, then references `this.myService.doSomething()` inside the setTimeout closure. No fail criterion met."
+              },
+              "passed": true
+            },
+            {
+              "output": "No. `inject()` only works inside an injection context, which is a narrow window during class construction — specifically, before the constructor finishes running. A `setTimeout` callback fires later, after that window has closed, so calling `inject()` there will throw at runtime (`inject() must be called from an injection context`), and it will do so asynchronously, which makes it a confusing failure rather than a compile-time one.\n\nThe correct pattern is to inject the dependency once, at the field initializer or constructor level, and then capture that already-resolved reference in the closure:\n\n```ts\nexport class MyComponent implements OnInit {\n  private readonly myService = inject(MyService);\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      // `this.myService` was resolved during construction --\n      // the closure just uses it, no inject() call needed here.\n      this.myService.doSomething();\n    }, 1000);\n  }\n}\n```\n\nA few related points worth getting right in the same pass:\n\n- Don't reach for `Injector` and call `injector.get(MyService)` inside the callback either. That technically works, but it defeats the point of `inject()` and hides the dependency from the class's declared field list. Capture the service reference instead.\n- If the timing here is really \"do this after a short delay,\" consider whether RxJS expresses the intent more clearly than a raw `setTimeout` — e.g. `timer(1000).pipe(takeUntilDestroyed(this.destroyRef)).subscribe(...)` or, for a one-shot deferred action, `afterNextRender` / `queueMicrotask` depending on what the delay is actually for. The advantage is that a `setTimeout` scheduled in `ngOnInit` has no teardown path: if the component is destroyed before the timer fires, the callback still runs and may touch a destroyed component. An RxJS timer piped through `takeUntilDestroyed()` cleans itself up.\n- If you do keep the raw `setTimeout`, at minimum capture the handle and clear it in `ngOnDestroy` so a fast destroy doesn't leave the callback pending against a dead component.\n\nThe short version: inject in the constructor/field initializer, always; use the captured reference anywhere later, including callbacks.",
+              "outputSha256": "cd78b704929405a852c18b85a2aa9346297cde35e5200e7b11c07d23d6813cee",
+              "promptSha256": "83dc44b403c20cc9cb42fcef6794a8f692a0b94af6e6cf3629f9efa7a094ed3d",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states inject() only works in injection context (before constructor finishes) and calling it in setTimeout throws at runtime. It shows the concrete fix: `private readonly myService = inject(MyService);` field initializer, then referencing `this.myService` inside the setTimeout closure. No fail criterion: it explicitly warns against injector.get inside the callback."
+              },
+              "passed": true
+            }
+          ]
+        }
+      ],
+      "verdict": "fail",
+      "scope": "bundled",
+      "skillDigest": "348654f014e5a9651f4565ffd3d010d0fe37404aaadf26fa9ddfd479873f86c0",
+      "catalogDigest": "fd9b6a086f61a996f761a68f9e7a58cde1ce62e121f276d70bbef8e05e372f4b",
+      "judgePromptVersion": "2026-09-25.1",
+      "runner": "deepseek",
+      "model": "deepseek-chat",
+      "runnerPromptVersion": "2026-09-25.1",
+      "recordedAt": "2026-09-25T15:51:07.907Z",
+      "judge": "deepseek",
+      "judgeModel": "deepseek-chat"
+    },
+    {
+      "schemaVersion": "1.0.0",
+      "skillId": "angular/angular-testing",
+      "strictness": "high",
+      "trials": 10,
+      "triggerAccuracy": {
+        "truePositive": 6,
+        "falsePositive": 1,
+        "positives": 6,
+        "negatives": 6
+      },
+      "evidence": "authored",
+      "scenarios": [
+        {
+          "id": "trigger-positive-1",
+          "kind": "trigger-positive",
+          "prompt": "This Angular component reads its data through a signal input — what's the right TestBed setup to cover it with tests?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-2",
+          "kind": "trigger-positive",
+          "prompt": "This Angular service fires off a couple of HTTP requests — how do I mock them out with HttpTestingController for a proper spec?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-3",
+          "kind": "trigger-positive",
+          "prompt": "I need a fakeAsync TestBed spec for this Angular component that proves its debounced search waits the full delay before calling the service — how do I structure the tick() calls?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-4",
+          "kind": "trigger-positive",
+          "prompt": "Test this standalone Angular component's OnPush rendering when the input changes",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-5",
+          "kind": "trigger-positive",
+          "prompt": "In a TestBed spec for this component, what's the right way to swap out its injected OrdersService for a mock/fake?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-6",
+          "kind": "trigger-positive",
+          "prompt": "What's the best way to unit test whether this route guard's CanActivate correctly blocks a logged-out user, in Angular?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-1",
+          "kind": "trigger-negative",
+          "prompt": "Write Vitest component tests for this Vue component using Vue Test Utils",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-2",
+          "kind": "trigger-negative",
+          "prompt": "Write React Testing Library tests for this component's rendered list",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-3",
+          "kind": "trigger-negative",
+          "prompt": "Implement a new standalone Angular component that shows order history",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-4",
+          "kind": "trigger-negative",
+          "prompt": "Fix this ng build AOT compile error about a missing provider",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-5",
+          "kind": "trigger-negative",
+          "prompt": "Write a Playwright e2e test for the login flow in our Angular app",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 0,
+          "passRate": 0,
+          "passAtK": 0,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-6",
+          "kind": "trigger-negative",
+          "prompt": "Write unit tests for this Go struct's JSON marshaling using the standard testing package",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "setinput-not-direct-assignment",
+          "kind": "behavior",
+          "prompt": "I'm writing a TestBed spec for a standalone Angular component that has a signal input declared as `order = input.required<Order>();`. In the test, should I just set `component.order = someMockOrder` before calling detectChanges?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 10,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "No -- don't assign `component.order = someMockOrder`.\n\n`order` is a signal produced by `input.required<Order>()`. `component.order` is a `Signal<Order>` (a read-only `InputSignal`), not a plain writable property. Assigning to it directly is wrong for two reasons:\n\n1. **Type/write error.** `input()` returns a read-only signal; it isn't a settable field, so `component.order = ...` won't compile/bind the way you expect.\n2. **It skips Angular's input path.** Even if you bypassed the type system, you'd be writing the raw signal object, not driving Angular's actual input-binding mechanism. The component's real callers bind through the template/`setInput`, so a test that assigns the field directly can pass while a genuinely broken binding stays undetected.\n\n## Do this instead\n\nUse the fixture's `componentRef.setInput` and then run change detection:\n\n```ts\nconst fixture = TestBed.createComponent(MyComponent);\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n\n// now assert on the component, reading the signal as a function call...\nexpect(fixture.componentInstance.order()).toEqual(someMockOrder);\n\n// ...and/or on the rendered DOM\nconst el = fixture.nativeElement.querySelector('[data-testid=\"order-id\"]');\nexpect(el.textContent).toContain(someMockOrder.id);\n```\n\nKey points:\n\n- `fixture.componentRef.setInput('order', value)` sets the input through Angular's real input channel -- this is the supported replacement for direct assignment.\n- Read the signal with a call: `component.order()`, not `component.order`.\n- Call `fixture.detectChanges()` after `setInput` so the new value propagates into the view before you assert on the DOM.\n- If the component does async work in response to the input, `await fixture.whenStable()` before asserting on rendered markup.\n- `input.required` means the input must be set before the component is exercised -- a test that never calls `setInput` is testing an invalid configuration. Set it (once, via `setInput`) in each test or a shared setup.\n\nAlso check an existing spec in the same module for the project's conventions, and run the project's actual test command to confirm the spec passes.",
+              "outputSha256": "684dee1b51e6878a5a878e7b0aee18d495039a26ec4c035aebbb84ea10f2c9fb",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment 'skips Angular's input path' and is wrong, and shows `fixture.componentRef.setInput('order', someMockOrder)` followed by `fixture.detectChanges()`. No fail criterion: it explicitly warns against `component.order = someMockOrder`."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — don't assign `component.order = someMockOrder`. For a signal input declared as `order = input.required<Order>()`, you should set it through the fixture's componentRef:\n\n```ts\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n```\n\nHere's why direct field assignment is the wrong move, and the fallout you'd hit:\n\n- `input()` returns an `InputSignal`, which is a read-only signal. The signal's value is owned by Angular's input-binding machinery, not by a plain writable property on the instance. Assigning `component.order = ...` either fails to typecheck (it's an `InputSignal`, not a settable field) or, if you manage to shove a value in via a cast/`as any`, it bypasses the actual binding path Angular uses when a parent template writes `[order]=\"...\"`. That means your test can go green while the real binding is broken — exactly the failure mode the spec is supposed to catch.\n- `setInput` is the supported test-time entry point that goes through that binding path, including the timing/notification semantics that `input()`, `computed()` off it, and effect scheduling all rely on. Direct assignment skips all of it, so anything derived from `order` (a `computed`, an `effect`, an `@if` in the template reading `order()`) may not update the way it would in a running app.\n- `input.required` adds another trap on top: before any value is set, reading the signal throws. So a test that never calls `setInput` and instead pokes a field directly can appear to work while the \"required input was provided\" contract is never actually exercised.\n\nPractical shape of the test:\n\n```ts\nit('renders the order summary', () => {\n  const fixture = TestBed.createComponent(OrderCardComponent);\n  fixture.componentRef.setInput('order', mockOrder);\n  fixture.detectChanges();\n\n  const el = fixture.nativeElement.querySelector('[data-testid=\"summary\"]');\n  expect(el.textContent).toContain(mockOrder.id);\n});\n```\n\nA couple of related points so the spec is actually trustworthy:\n\n- Call `detectChanges()` (and `await fixture.whenStable()` if anything async — a resolved promise, a flushed request — feeds the DOM) *after* `setInput`, before asserting on rendered markup. If an assertion fails right after `setInput`, the fix is the missing `detectChanges()`/`whenStable()`, not deleting the assertion.\n- For inputs you want to vary across scenarios, `fixture.componentRef.setInput` again — it's fine to call it multiple times. If you're using `ComponentRef.setInput` on a host-style wrapper instead, the same principle holds: set through the binding API, never by writing the instance field.\n- If the component reads `order()` in a template expression or a `computed`, assert on what that renders/derives, not just on `fixture.componentInstance.order()` — checking the class field alone can pass even when the binding wasn't wired.\n\nSo: `componentRef.setInput('order', mockOrder)`, then `detectChanges()`, then assert on the DOM.",
+              "outputSha256": "12ab06af0d60826a1d31b29a23cdefe0d0c95717e9f6ca1f78e58d3e3c0d38fe",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment 'bypasses the actual binding path Angular uses' and is wrong, and shows `fixture.componentRef.setInput('order', someMockOrder);` followed by `fixture.detectChanges();` before DOM assertions. No fail criterion: it never recommends direct assignment."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — don't do that. Assigning `component.order = someMockOrder` is wrong on two counts here.\n\nFirst, `order` is a `Signal`, not a plain property. `input()` and `input.required()` return an `InputSignal` (a read-only function), so `component.order = ...` won't even compile/typecheck the way you expect — you can't assign to it. To read it in the component you call `order()`; you can't set it by assignment.\n\nSecond, even if it were assignable, direct field assignment bypasses Angular's input-binding path entirely. It doesn't go through the same mechanism a template binding (`[order]=\"...\"`) or a parent would use, so a spec that sets it that way can pass while the real binding is broken. The whole point of `setInput` is that it drives the actual input-binding path.\n\nSet it through the fixture's component ref instead:\n\n```ts\nconst fixture = TestBed.createComponent(OrderCardComponent);\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n\nexpect(fixture.nativeElement.querySelector('[data-testid=\"order-id\"]').textContent)\n  .toContain(someMockOrder.id);\n```\n\nKey points:\n\n- Use `fixture.componentRef.setInput('order', ...)`, not `fixture.componentInstance.order = ...`. `setInput` is the API that simulates a real input binding, including running `ngOnChanges`/signal-input notification on the correct path.\n- `setInput('order', ...)` must be called with the matching value type, and for an `input.required` the input must actually be provided before `detectChanges()` — otherwise Angular will throw the \"required input not provided\" error, which is another reason the direct-assignment shortcut is a trap: it hides that requirement.\n- If the parent passes other inputs too, set all of them via `setInput` before the first `detectChanges()`.\n- If the change should affect rendered DOM, call `fixture.detectChanges()` after `setInput`; if the component kicks off async work in response, `await fixture.whenStable()` before asserting on markup.\n\nOne caveat: `setInput` sets the input but does not itself trigger change detection, so don't assert on the DOM between `setInput` and `detectChanges()` and conclude the feature is broken — you're just missing the `detectChanges()` call.\n\nSo: `setInput` it is, never `component.order = ...`.",
+              "outputSha256": "c1aeced27b42cdc5408978d554716835073fe5fac538f1320439ccff2255bddd",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment 'bypasses Angular's input-binding path entirely' and 'won't even compile' (criterion 1), and shows the correct code: fixture.componentRef.setInput('order', someMockOrder) followed by fixture.detectChanges() (criterion 2). No fail criterion: it never recommends direct assignment."
+              },
+              "passed": true
+            },
+            {
+              "output": "No. Setting `component.order = someMockOrder` directly is the wrong move for a signal input, and it can make a broken binding look like it works.\n\n`order = input.required<Order>()` is a signal. Its value is owned by the input-binding machinery, not by a plain writable field on the component. Assigning to `component.order` either throws (you can't write to an `InputSignal`) or, where it compiles, replaces the signal consumer with something Angular's real binding path never touches — so your test can pass while the actual `[order]=\"...\"` binding on the template is broken.\n\nDo this instead:\n\n1. Create the fixture with `TestBed.createComponent(MyComponent)`.\n2. Set the input through the binding path: `fixture.componentRef.setInput('order', someMockOrder)`.\n3. Call `fixture.detectChanges()` (and `await fixture.whenStable()` if anything async resolves before you assert).\n4. Then assert on `fixture.nativeElement`/`debugElement.query(...)` or on `fixture.componentInstance`'s derived state.\n\nTwo related points from the workflow:\n\n- `input.required` means the input must be provided before the first `detectChanges()` that renders the binding; if you forget `setInput`, Angular will throw at change-detection time. That failure is the input contract doing its job — provide the mock rather than weakening the component.\n- If an assertion fails right after `setInput`, the cause is almost always a missing `detectChanges()`/`whenStable()` before the assertion, not a broken feature. Add the call; don't delete the check.\n\nSo: no direct field assignment. `fixture.componentRef.setInput('order', someMockOrder)`, then `detectChanges()`, then assert.",
+              "outputSha256": "b0ab4cf86d98b0d50f8dd9b64c7e96bf0491af8278554f1d54372ac402eb580e",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment is wrong: 'Setting component.order = someMockOrder directly is the wrong move... replaces the signal consumer with something Angular's real binding path never touches.' Shows correct call: 'fixture.componentRef.setInput('order', someMockOrder)' followed by 'fixture.detectChanges()'. No fail criterion met."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — don't assign the signal input's field directly.\n\n`order = input.required<Order>()` produces an `InputSignal`, and assigning `component.order = someMockOrder` bypasses Angular's input-binding path entirely. The setter for a signal input isn't a plain field write; the component's own template logic reads through the signal's getter, so setting the underlying signal by direct property assignment is not how a real parent's `[order]=\"...\"` binding delivers the value. That means a test written this way can pass while the actual binding path is broken, which defeats the point of testing the component through its public input contract.\n\nInstead, set it through the fixture's input mechanism:\n\n```ts\nconst fixture = TestBed.createComponent(OrderCardComponent);\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n```\n\nKey points for this shape of test:\n\n- Use `fixture.componentRef.setInput('order', ...)`, not `fixture.componentInstance.order = ...`. `setInput` goes through the same mechanism Angular uses for a real template binding, so it also correctly drives any input-observable/`input()` transformation and change detection.\n- Because it's `input.required<Order>()`, the input must be set before the first `detectChanges()` that renders the component's template — otherwise Angular throws about a required input not being provided. So set the input immediately after `createComponent` and before `detectChanges()`.\n- After setting the input, call `fixture.detectChanges()` before asserting on rendered DOM. If the component reacts to the input asynchronously (an effect, a resolved promise, an HTTP call), `await fixture.whenStable()` first.\n- If your test setup uses `TestBed.overrideComponent` (e.g. to swap a template or mock providers), configure that before `createComponent`, then set the input on the created fixture's `componentRef`.\n\nIf you find yourself wanting to set the input *after* an initial `detectChanges()`, that's fine — call `setInput` then `detectChanges()` again — but don't reach for direct field assignment as a shortcut to avoid the required-input error. The correct fix for that error is to set the input (via `setInput`) before the first change-detection pass.\n\nOne caveat on the mock itself: make sure `someMockOrder` is a fully-typed `Order`. A cast like `{} as Order` or `as any` will type-check but tends to produce confusing failures later when the template reads a field that isn't there; build a real (even if minimal) mock object, preferably in a shared factory or `beforeEach`, so multiple specs reuse the same shape.",
+              "outputSha256": "648dc571add1df5f168b592d6285d128b0a9d2f21574f2cbd8f7d578e3dee0de",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment 'bypasses Angular's input-binding path entirely' and 'don't assign the signal input's field directly' (criterion 1). It shows the correct code: fixture.componentRef.setInput('order', someMockOrder) followed by fixture.detectChanges() (criterion 2). No fail criterion: it never recommends direct field assignment."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — don't set `component.order = someMockOrder` directly.\n\nFor a signal input declared as `order = input.required<Order>()`, assign the value through the fixture's component ref:\n\n```ts\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n```\n\nWhy this matters: assigning the component instance's field directly is not the path Angular itself uses to deliver inputs. `componentRef.setInput(...)` goes through the input-binding machinery, so it actually exercises the code path a real parent template would — including the required-input check (`input.required` throws if it's read before being set). If you write `component.order = ...` by hand, you bypass that machinery entirely: the test can pass even when the real binding is misconfigured, a required input is never wired up, or the input name in the template doesn't match, because your assignment silently patches over it.\n\nA couple of related points:\n\n- `input.required<T>()` will throw if the input is read before it's set. So if you see an error like \"Input is required but no value is available yet,\" the fix is to call `setInput('order', ...)` before the first `detectChanges()` that renders the component, not to reach around it with a direct field assignment.\n- After `setInput`, you still need `fixture.detectChanges()` for the DOM to reflect the new value, and `await fixture.whenStable()` if anything downstream is async before you assert on rendered markup.\n- The same rule applies to any non-required signal input (`input<T>()` with a default) — set via `componentRef.setInput`, not direct assignment — so it's worth being consistent across the whole spec file.\n\nSo the shape of the test is:\n\n```ts\nconst fixture = TestBed.createComponent(MyComponent);\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n\nconst el = fixture.nativeElement.querySelector('[data-testid=\"order-total\"]');\nexpect(el.textContent).toContain('...');\n```\n\nBottom line: use `fixture.componentRef.setInput('order', someMockOrder)`, then `detectChanges()`. Never assign the instance field directly for a signal input.",
+              "outputSha256": "d3432fc1846bf9713b8ac54083aa5b08a3d6a69ccc704348e949ff3681f61bc9",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states directly that `component.order = someMockOrder` bypasses Angular's input-binding machinery and should not be used ('don't set ... directly', 'bypass that machinery entirely'). It shows the correct call `fixture.componentRef.setInput('order', someMockOrder)` followed by `fixture.detectChanges()` in code blocks. No fail criterion: it never recommends direct assignment."
+              },
+              "passed": true
+            },
+            {
+              "output": "No -- don't set `component.order = someMockOrder` directly. That assigns the field on the component instance, which bypasses Angular's actual input-binding path. A real parent template binding (`[order]=\"someMockOrder\"`) goes through the input's setter machinery, which is what marks the input as set, updates its internal signal state, and triggers the change-detection bookkeeping. Direct field assignment skips all of that, so your test can go green while the real binding path is broken -- exactly the class of bug the spec should be catching.\n\nDo this instead:\n\n1. Create the fixture: `const fixture = TestBed.createComponent(MyComponent);`\n2. Set the input through the fixture's component ref:\n   `fixture.componentRef.setInput('order', someMockOrder);`\n3. Then call `fixture.detectChanges()` before querying the DOM or asserting on rendered markup.\n\nA few related notes for this spec:\n\n- `setInput` is the supported way to drive both decorator-based and signal inputs (`input.required<Order>()`), and it's also the only way that works for an input never bound in the test host.\n- If anything in the component reacts asynchronously to the input (an `effect`, a resolved resource/promise), call `await fixture.whenStable()` after `setInput` and before asserting on the rendered DOM -- don't just add a bare `detectChanges()` and hope the effect has run.\n- If the component burns `HttpClient`, route the calls through `provideHttpClientTesting()` and assert with `HttpTestingController` (`expectOne(url).flush(...)`, then `verify()`), and if it depends on timers, wrap the test in `fakeAsync` and advance with `tick(<exact ms>)` rather than a real `setTimeout`.\n\nOne trap to watch for: if an assertion right after `setInput` (without `detectChanges`/`whenStable`) fails, that's the missing change-detection step, not broken feature behavior -- fix the missing call, don't delete the check.",
+              "outputSha256": "50fb1aba06e28053e17c9d621211743eedf193c51eeafd7d8aa06381b157fbf9",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment 'bypasses Angular's actual input-binding path' and should not be used (criterion 1). It shows the correct call `fixture.componentRef.setInput('order', someMockOrder);` followed by `fixture.detectChanges()` before asserting (criterion 2). No fail criterion: it never recommends direct field assignment."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — that's exactly the red-flag case. For a signal input like `order = input.required<Order>()`, you should set it through the fixture's input-binding path:\n\n```ts\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n```\n\nnot `component.order = someMockOrder`.\n\nThe reason: `order` is an `InputSignal`, not a writable plain field. Assigning to it directly either fails to compile/run (it's a readonly signal accessor) or, if you force it, bypasses the machinery Angular actually uses to deliver a bound value from a parent template. That means the test can pass while the real parent→child binding is broken, because you never exercised the path a real template binding takes. `componentRef.setInput(name, value)` is the API that drives that same binding mechanism, so an assertion after it is meaningful.\n\nTwo related points:\n\n- `order` is `input.required<Order>()`, so if nothing sets it before `detectChanges()`, Angular throws because the required input was never provided. Setting it via `setInput` before your first `detectChanges()` (or re-running `detectChanges()`) is what satisfies that requirement in the test — another reason direct assignment isn't equivalent.\n- If the component also does something async with the order (e.g. an HTTP lookup), pair the `setInput` + `detectChanges()` with `await fixture.whenStable()` (or `fakeAsync`/`tick` if timers are involved) before asserting on rendered DOM.\n\nSo the correct shape is:\n\n```ts\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n// assert on fixture.nativeElement / debugElement here\n```\n\nand if you find an assertion failing right after a direct assignment, the fix is almost always \"use `setInput` and call `detectChanges()`/`whenStable()`,\" not deleting the assertion.",
+              "outputSha256": "7888230ce7697c373ccc8433427eba040d02e4bf7d7f189d3f47d45cd4038f8c",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment 'component.order = someMockOrder' is wrong and bypasses Angular's real binding machinery ('bypasses the machinery Angular actually uses to deliver a bound value from a parent template'). It shows the correct call `fixture.componentRef.setInput('order', someMockOrder);` followed by `fixture.detectChanges();`. No fail criterion met."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — that's the exact anti-pattern. `order = input.required<Order>()` creates a signal input, and assigning `component.order = someMockOrder` does not go through Angular's input-binding path. In fact, for a signal input the property is a read-only `InputSignal` — assigning to it either fails to compile under `strictTemplates`/template type-checking or, at runtime, bypasses the binding machinery entirely (no input transform, no `ngOnChanges`-equivalent signaling, no mark-for-check propagation). You'd get a test that passes while the real parent→child binding is broken.\n\nSet it through the fixture instead:\n\n```ts\nconst fixture = TestBed.createComponent(MyComponent);\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n```\n\n`fixture.componentRef.setInput(...)` is the supported API for driving inputs from a test — it routes through the same binding mechanism a template binding uses. Then read the value back off `fixture.componentInstance.order()` (it's a signal, so call it) for direct class-level assertions.\n\nA few notes for this specific case:\n\n- **`input.required` has no default.** If the test constructs the component without ever calling `setInput('order', ...)`, reading `order()` throws rather than returning `undefined`. So every spec that touches the component must set it first — there's no \"leave it unset\" path to fall back on.\n- **Order of operations.** `setInput` first, then `detectChanges()`, then assert on rendered DOM via `fixture.debugElement.query(By.css('[data-testid=\"...\"]'))` or `fixture.nativeElement.querySelector(...)`. Use a stable `data-testid`/role selector rather than a styling class.\n- **Async inputs.** If the value you're setting is produced by something asynchronous (an HTTP response, a resolved promise), follow the `detectChanges` with `await fixture.whenStable()` before asserting on markup. For timer-dependent flows, prefer `fakeAsync` + `tick(<exact ms>)` over a real `setTimeout` so the test doesn't depend on wall-clock timing.\n- **If an assertion fails right after `setInput`**, the fix is the missing `detectChanges()`/`whenStable()` — not deleting the assertion or reverting to direct field assignment.\n\nAnd don't declare the spec done until the project's actual test command (`ng test` or whatever the `angular.json` test builder/config points at) passes with the new spec included, with no existing assertion weakened or skipped to get there.",
+              "outputSha256": "b08e00bd6411fc902d7fc759d548c06a0105dae5e4c2245776e81fe77c2e4dbb",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states assigning component.order = someMockOrder 'does not go through Angular's input-binding path' and calls it 'the exact anti-pattern.' It shows the correct call: fixture.componentRef.setInput('order', someMockOrder) followed by fixture.detectChanges(). No fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — don't assign `component.order = someMockOrder` directly. For a signal input declared as `order = input.required<Order>()`, set it through the fixture's component ref:\n\n```ts\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n```\n\nWhy this matters: `component.order` is an `InputSignal`, not a plain writable property. Directly assigning it either fails to typecheck (it's a readonly signal) or, if you cast around that, bypasses Angular's actual input-binding path — the same path a real parent template binding goes through. A test that assigns the field directly can pass even when the real `<my-component [order]=\"...\">` binding is broken, which defeats the purpose of the spec.\n\nNotes specific to your case:\n\n- Because it's `input.required<Order>()`, you *must* set it before the first `detectChanges()` that renders the component — Angular throws if a required input is read while still unset. So the order is: `createComponent` → `setInput('order', ...)` → `detectChanges()`.\n- `setInput` marks the input dirty and schedules change detection for that component, but you still need `detectChanges()` (or an `await fixture.whenStable()` in an async test) before asserting on the rendered DOM.\n- If the input feeds an async path (e.g. an effect that kicks off an HTTP call), follow `setInput` with `detectChanges()` then `await fixture.whenStable()`, and flush the request via `HttpTestingController` if applicable.\n\nSo the correct pattern for each test is:\n\n```ts\nconst fixture = TestBed.createComponent(MyComponent);\nfixture.componentRef.setInput('order', someMockOrder);\nfixture.detectChanges();\n// now assert on fixture.nativeElement / debugElement\n```\n\nIf a test needs to simulate the input *changing* after initial render (e.g. re-render on a new order), call `setInput` again followed by another `detectChanges()` rather than reassigning the field — that's the only way to exercise the same reactivity a parent binding would produce.",
+              "outputSha256": "3258c26681221018251dc2ac6cc24597dc27fe0c6e0dbf544aa8c28633837741",
+              "promptSha256": "15b8784aa8064949af92d2ef56b403562a68192c1abfb4223443e9e21dc3f057",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states direct assignment 'bypasses Angular's actual input-binding path' and should not be used, and shows `fixture.componentRef.setInput('order', someMockOrder);` followed by `fixture.detectChanges();`. No fail criterion holds."
+              },
+              "passed": true
+            }
+          ]
+        },
+        {
+          "id": "http-testing-controller-verify",
+          "kind": "behavior",
+          "prompt": "I'm testing an Angular service method that calls HttpClient.get() and returns the parsed response. I've set up HttpTestingController and flushed a mock response, and the assertion on the returned value passes. Is that test complete?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 10,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "No, the assertion passing on the returned value is not by itself proof the test is complete. A few things must also hold before you call it done:\n\n1. **Call `httpTestingController.verify()`.** After your assertions, call `httpTestingController.verify()` (typically in an `afterEach` or at the end of the test). This is what catches an *unexpected extra* request — e.g. a duplicate `HttpClient.get()` fired by a bug in the service. A test that only checks the response value can still pass green while the service has fired two requests instead of one. `verify()` fails the test if any request went unmatched.\n\n2. **Match the request, don't just flush anything.** Confirm you used `expectOne(url)` (or the right matcher) with the exact URL/params/headers the service is supposed to send. `expectOne` both asserts the request occurred and matches it; if the service hit the wrong URL, `expectOne` throws rather than silently passing.\n\n3. **Flush with a response shape that actually exercises the parsing.** If this is a typed `get<Order>()`, make sure your mock body resembles the real payload closely enough that \"the parsed response\" being asserted is meaningful — not just an object that happens to satisfy a loose check.\n\n4. **Handle the async settlement deterministically.** Whether the returned value is an Observable or Promise, the spec should either use `fakeAsync`/`tick` (if timers are involved) or await settlement (`await fixture.whenStable()` for components, subscription callbacks resolved before asserting for services) so the assertion isn't racing the request. Don't fall back to a real `setTimeout(...)` to wait.\n\n5. **Don't weaken existing checks.** No assertion in the surrounding suite should be deleted or loosened to make this pass.\n\nSo your minimum checklist for this service test: the value assertion **plus** `httpTestingController.verify()` **plus** an `expectOne` that matches the real request. If `verify()` is missing, add it — that's the most common gap in exactly the scenario you describe. Once `ng test` (or your configured runner) passes with `verify()` in place, the test is complete.",
+              "outputSha256": "01b8b013aa84769803450072e75633b6576e50774cfbc22d2ad1ef022b3e2008",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Point 1 explicitly says to call httpTestingController.verify() (in afterEach or end of test) to catch an unexpected extra request, e.g. a duplicate HttpClient.get() fired by a bug, and notes verify() fails if any request went unmatched. This satisfies both criteria: verify() required, and it checks requests beyond the one already asserted/flushed."
+              },
+              "passed": true
+            },
+            {
+              "output": "No, not quite. Passing the value assertion after a flush is necessary but not sufficient — the spec is complete only once you've also closed out the `HttpTestingController` contract.\n\nSpecifically:\n\n1. **Call `httpTestingController.verify()`.** This is the part that catches an unexpected *extra* request — e.g. the method accidentally firing `HttpClient.get()` twice, or a second call in an `ngOnInit`/subscription you didn't account for. Without `verify()`, a duplicated or stray request sitting unflushed goes undetected and your passing assertion hides the regression. Put it at the end of the test, or in an `afterEach`, so it runs for every spec.\n\n2. **Confirm you flushed exactly the request you meant to.** `expectOne(url)` (or a matcher on method/url/body) should be what produced the mock response, so a mismatch between the expected and actual request is itself the failure — not an after-the-fact assertion on the parsed value.\n\n3. **Match the assertion to the async boundary.** If the service returns an `Observable`/`Promise` the test subscribes/awaits, make sure the assertion runs *after* the response has actually been delivered (subscribe + assert inside the callback, or `await` the promise) — not in a way that could pass against a stale or initial value.\n\n4. **Pin down determinism if there's any timing involved.** If the method debounces, retries, or delays, wrap the test in `fakeAsync` and advance with `tick(<exact ms>)` rather than relying on real timers, so the spec isn't at the mercy of wall-clock/CI load.\n\nSo the minimal complete shape is: arrange → `expectOne(...).flush(mockResponse)` → assert the returned/parsed value → `httpTestingController.verify()`. Add the `fakeAsync`/`tick` layer only if the code under test actually involves timers.\n\nOne more thing worth checking: don't weaken or delete an existing assertion just to make the flush-and-verify flow pass — if an assertion fails, it's almost always a missing await/subscription or a genuine extra-request bug, not an assertion that should go.\n\nSince I can't run anything here, the thing to actually do before calling it done is run the project's real test command and confirm this spec — with `verify()` included — passes green.",
+              "outputSha256": "23cd93f5b097329ac9acbcf992ebd0b613fce394f8368397965b102a95afa414",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states test complete only after httpTestingController.verify() (point 1, 'Call httpTestingController.verify()', end of test or afterEach) and explains it catches an unexpected extra/duplicated/stray request beyond the one asserted with expectOne ('catches an unexpected extra request... duplicated or stray request sitting unflushed goes undetected'). No fail criterion met."
+              },
+              "passed": true
+            },
+            {
+              "output": "No, not yet — \"the assertion on the returned value passes\" is necessary but not sufficient. There are two gaps to close before this test is actually complete, and one of them is easy to skip precisely because the happy-path assertion already went green.\n\n## 1. You haven't verified the request side\n\n`expectOne(url).flush(mockResponse)` tells you *a* request matching that URL was made, but you should also assert **what** was sent, not just that *something* was:\n\n```ts\nconst req = httpTestingController.expectOne('https://api.example.com/orders/42');\nexpect(req.request.method).toBe('GET');\n// assert query params / headers / body if the service sets any:\n// expect(req.request.params.get('include')).toBe('items');\nreq.flush(mockOrders);\n```\n\nIf you called `expectOne(mockUrl)` with a URL that omits params or a base path the service actually appends, the match could be coincidental or the test could be asserting against the wrong call entirely. Pin down the full expected URL, the method, and any params/headers the method under test is responsible for.\n\n## 2. You almost certainly owe a `verify()` call\n\n```ts\nafterEach(() => {\n  httpTestingController.verify();\n});\n```\n\n`verify()` is what fails the test if the service fired an **extra, unexpected** request — the classic regression being a duplicate `HttpClient.get()` from a bug (e.g. a retry or a subscription that double-fires). Your value assertion would still pass in that case, because the *first* response is the one it inspected. `verify()` is the only thing that catches the stray request, so leaving it out lets that regression through silently.\n\nIf `verify()` runs in an `afterEach`, make sure `HttpTestingController` is obtained via `TestBed.inject(HttpTestingController)` *inside* the test or a `beforeEach` (so it's the same instance per test), not captured once at module scope.\n\n## 3. If the returned value is async, confirm the resolution was actually awaited\n\nCheck that the assertion runs *after* the observable/promise resolved — either the test is `async` and you `await` the service method's result, or (if timers/microtasks are involved) it's wrapped in `fakeAsync` and you `tick(<exact ms>)` before asserting. A passing assertion on a `Promise` is fine; a passing assertion on something you never actually awaited is a false green. Related: if this is a component (not a bare service), the DOM half of the check isn't done until you've called `fixture.detectChanges()` / `await fixture.whenStable()` — but you said service, so this is just a flag to confirm the microtask ordering is real.\n\n## What \"complete\" looks like\n\n```ts\nit('GETs the parsed order', async () => {\n  const promise = service.getOrder(42);\n\n  const req = httpTestingController.expectOne('https://api.example.com/orders/42');\n  expect(req.request.method).toBe('GET');\n  req.flush(mockOrders);\n\n  await expectAsync(promise).toBeResolvedTo(mockOrders);\n  httpTestingController.verify();\n});\n```\n\nSo: **the value assertion passing is the easy half.** Complete the test by (a) asserting on the request the service actually sent, (b) running `verify()` to catch extra requests, and (c) confirming the async result was genuinely awaited before you asserted. Only then is \"test complete\" a claim you can stand behind. I'd also run the project's real test command and confirm the spec is green there, not just in your head.",
+              "outputSha256": "194dcdb907ef424fb91e3c34d3aa5fd33b2cffcd9a70596532e0e8072d6cf293",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states verify() must be called (afterEach snippet and end-of-test snippet) to catch an extra/unexpected request, and explains it catches a stray duplicate request beyond the one expectOne/flush already asserted, since the value assertion would still pass. Both pass criteria concretely met; no fail criterion."
+              },
+              "passed": true
+            },
+            {
+              "output": "Not necessarily complete yet — the flushed response passing is only part of what this test needs to actually be trustworthy. Check these before calling it done:\n\n1. **Call `httpTestingController.verify()`.** This is the piece that catches an *unexpected extra* request — e.g. a bug that duplicates the `HttpClient.get()` call, or fires it against the wrong URL. Without `verify()`, a test that only asserts \"the response I expected came back\" will still pass even if the service made two requests, or made a stray request to a different endpoint that happened to also get flushed. Put `verify()` in your `afterEach` (or at the end of the test) so it runs unconditionally.\n\n2. **Assert on the request, not just the response.** `expectOne(url)` matching only the URL may not cover method/params/headers. If the SUT is expected to send query params, a request body, or an auth header, assert on `req.request.method`, `req.request.params`, etc., before flushing. Otherwise you're testing that *a* GET to that URL happened, not that the *correct* GET happened.\n\n3. **Confirm the return path is actually exercised.** If the service maps/transforms the response (e.g. `.pipe(map(res => res.data))`), make sure the mock response's shape would produce a *different* result if the transform were wrong or removed — a mock that coincidentally matches the post-transform shape can hide a broken map. Prefer a realistic wire-shaped fixture and assert the transformed output.\n\n4. **Cover the async determinism.** If the service or its caller involves timers, retries, or delays, drive that with `fakeAsync` + `tick(<exact ms>)` rather than real timers, so the test is deterministic in CI.\n\n5. **Consider the error path separately.** A single happy-path spec doesn't cover `HttpErrorResponse` handling (404/500 → the service's error branch, fallback value, or rethrow). If the service has meaningful error behavior, that's a second spec with `.error(new ProgressEvent('error'), { status: 500 })` or an `HttpErrorResponse`.\n\nSo: the passing assertion is necessary but not sufficient. The minimum gap is usually `verify()` plus asserting on the request itself. If the service has transform or error-handling logic, add specs for those too. Don't mark it done until `ng test` (or the configured runner) passes with the added `verify()` in place — that's the check most likely to surface a real defect the current spec is silently missing.",
+              "outputSha256": "0f58c7482e251db9927bf786c9e6b3522fbbd51a3f85a52c10dddcded2dacefb",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Point 1 explicitly says to call httpTestingController.verify() in afterEach or at test end, and explains it catches an unexpected extra request (duplicate get, wrong URL) that a response-only assertion would miss — satisfying both criteria. No fail criterion holds; it never says the test is complete."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — passing that one assertion isn't sufficient to call the test complete. A few things about this exact setup:\n\n1. **You must call `httpTestingController.verify()`.** This is the part people skip. `verify()` asserts that no *unexpected* requests are outstanding — i.e. it catches the case where your service fires the request twice, or fires an extra `HttpClient` call you didn't account for. Without it, a duplicated-request regression sails through silently. Put it at the end of the test (or, more commonly, in an `afterEach`).\n\n2. **Wrap the HTTP-dependent test in `fakeAsync` + `tick()` when anything is time-dependent.** If the service's `.get()` result is piped through a debounce, retry, `delay`, or any `timer`, the mock flush alone won't resolve the observable deterministically — advance virtual time with `tick(<exact ms>)` matching the real delay the code uses. Don't reach for a real `setTimeout`. If there's genuinely no timing involved, a plain async test with `await` is fine.\n\n3. **Check what the assertion actually asserts.** \"The returned value passes\" is weaker than it sounds — if the method returns an Observable, make sure you're asserting the *emitted value* (via `firstValueFrom`/`subscribe`/`flush`) and not just that a subscription was created. If it parses/transforms the response, assert against the transformed shape, not the raw mock.\n\n4. **Right test double for the right layer.** `HttpTestingController` (from `provideHttpClientTesting()`) belongs on a test that deliberately exercises and asserts the HTTP layer. If your goal is only to test the service's *own* logic above the HTTP boundary, injecting a spied `HttpClient` is preferable — otherwise you're coupling the test to URLs and verb details it doesn't care about.\n\n5. **Teardown.** Call `httpTestingController.verify()` and ensure the fixture/TestBed is cleaned up in `afterEach` if you share TestBed config across tests, so one test's outstanding request doesn't bleed into the next.\n\nBefore you report it done, the checklist:\n\n- The project's real test command (`ng test` or its configured equivalent) passes.\n- `verify()` runs — no leftover/unexpected request.\n- Timing-dependent paths use `fakeAsync`/`tick`, not wall-clock timers.\n- The assertion checks the actual emitted/parsed value, not just that a call happened.\n- No existing assertion was weakened or deleted to get it green.\n\nFix those and it's complete.",
+              "outputSha256": "a86499a381d5b44b849ac21e5471a4a69d5fb4a0941a5f998684db76aec8de0f",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states verify() must be called at end of test or in afterEach (points 1 and 5), and explains it catches unexpected/extra requests like the service firing twice, beyond the one already asserted/flushed (point 1: 'fires the request twice, or fires an extra HttpClient call you didn't account for'). No fail criterion: it explicitly says the test is not complete without verify()."
+              },
+              "passed": true
+            },
+            {
+              "output": "No, not necessarily. There are two common gaps in exactly this scenario:\n\n**1. You need to verify the request, not just the response.**\nFlushing a mock response and asserting the returned value only proves the service *parsed* a response correctly. It says nothing about what request was actually sent. A test like this will still pass if the service calls the wrong URL, drops a query param, sends the wrong method, or omits an auth header. Assert the outgoing request too, e.g.:\n\n```ts\nconst req = httpTestingController.expectOne('/api/orders?status=open');\nexpect(req.request.method).toBe('GET');\nexpect(req.request.headers.get('Authorization')).toBe('Bearer test-token');\nreq.flush(mockResponse);\n\n// ...then assert the parsed result\n```\n\nUsing `expectOne(url)` already checks the URL and that exactly one matching request occurred at that point, but it does not check the method, headers, or body unless you add the assertions.\n\n**2. You need `verify()` to catch unexpected extra requests.**\n`expectOne` matches one request at the moment you call it. If the service accidentally fires a *second* call (a common bug when the method is invoked from more than one place, or a subscription double-fires), `expectOne` won't necessarily catch it. `httpTestingController.verify()` at the end of the test — or in an `afterEach` — asserts that no outstanding, unmatched requests remain:\n\n```ts\nafterEach(() => {\n  httpTestingController.verify();\n});\n```\n\nWithout it, a duplicated HTTP call slips through silently.\n\n**Also worth checking before you call it done:**\n- **Error path.** Does the method handle non-2xx responses or network errors (mapping, fallback, rethrow)? A happy-path-only test leaves that untested. Add a case that flushes with an error (`req.flush('...', { status: 500, statusText: 'Server Error' })` or `req.error(new ProgressEvent('error'))`) and asserts the expected behavior.\n- **Async determinism.** If the method chains promises/observables, make sure you're awaiting stability (or using `fakeAsync`/`tick` if timers are involved) before the assertion, so the test isn't passing on a stale value.\n- **The real endpoint shape.** If you hand-wrote the response type, confirm it matches what the server actually returns; a mock that's more forgiving than the real API can hide a type/shape mismatch.\n\nSo: a passing value assertion is necessary but not sufficient. Add the request-shape assertions, `verify()`, and an error-path case, then run the project's actual test command to confirm.",
+              "outputSha256": "d0300a295f58bc7eddf44bf5fec0246ffb7154922cbf82d6af7c9e5a4607e204",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states verify() must be called at end of test or in afterEach (shows afterEach code) to catch unexpected extra requests, and explains expectOne matches one request at the moment called so a second/duplicated call slips through silently — i.e. verify() checks beyond the flushed request. No fail criterion met."
+              },
+              "passed": true
+            },
+            {
+              "output": "Not quite — a passing assertion on the returned value is necessary but not sufficient. Here's what to check before calling it done:\n\n**1. Call `httpTestingController.verify()`.** This is the most common omission. `expectOne(url).flush(mockResponse)` proves the request you expected happened, but it does not catch an *unexpected extra* request (e.g. a bug that fires the HTTP call twice, or a second call to a different URL). `verify()` fails the test if any request was made that wasn't matched by an `expectOne`/`expectNone`/`match`. Put it at the end of the test or in an `afterEach`. Without it, a duplicated-call regression sails through.\n\n**2. Assert the request itself, not just the result.** `flush` returns a `TestRequest`; before flushing you can assert on `req.request.method`, the URL, and `req.request.body`/params. If the service is supposed to POST a specific payload or append query params, a test that only checks the parsed return value would still pass if the service sent the wrong URL or the wrong body as long as your `expectOne` happened to match. Match on the exact URL (and params) so a wrong-endpoint bug fails.\n\n**3. Confirm the subscription actually completed.** If the method returns an Observable, your assertion needs to observe the emitted value (via `subscribe`, `firstValueFrom`, or a spy). If it returns a Promise (e.g. from `lastValueFrom`), you must `await` it — a test that asserts on a value that hasn't resolved yet is a false pass waiting to become flaky. Make sure the assertion genuinely runs after the value arrives, not on an unresolved promise.\n\n**4. Watch for error-path coverage.** If the service is supposed to handle an HTTP error (map it, rethrow, set an error state), flushing a success response doesn't exercise that. Worth a second test that flushes an error response with `req.flush(body, { status: 500, statusText: 'Server Error' })` (or `req.error(new ProgressEvent('error'))`).\n\n**5. Test isolation.** If the suite shares a `TestBed` across tests or the service is a singleton with cached state, make sure `verify()` runs per-test and the service/controller is reset between tests (`TestBed.inject` per test, or `afterEach(() => httpTestingController.verify())`).\n\nSo a complete version looks roughly like:\n\n```ts\nit('fetches and parses the response', () => {\n  let result: Thing[] | undefined;\n  service.getThings().subscribe(r => (result = r));\n\n  const req = httpTestingController.expectOne('/api/things');\n  expect(req.request.method).toBe('GET');\n  req.flush([{ id: 1 }]);\n\n  expect(result).toEqual([{ id: 1 }]);\n});\n\nafterEach(() => httpTestingController.verify());\n```\n\nBottom line: the assertion passing tells you the success path works for the response you flushed. Adding `verify()` and asserting on the outgoing request is what turns it from \"the happy path happened to work\" into \"the service makes exactly the call it should, and makes it only once.\"",
+              "outputSha256": "cae7d7de752219ec5510b26dba6762f4144d65ca4edbfec0cbe3d7dcff6bafd5",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states verify() must be called (end of test or afterEach) to catch an unexpected extra request, and explains expectOne/flush only proves the expected request happened while verify() catches unmatched requests (e.g. duplicated call). Concrete code shows afterEach(() => httpTestingController.verify()). No fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — the assertion passing is necessary but not sufficient. A test that flushes a mock response and asserts the returned value only proves your service handled *that* request. It says nothing about whether the service made the right number of requests, to the right URL, with the right method/params, or whether it leaks an extra request somewhere.\n\nTo consider the test complete, it needs to verify the request side too:\n\n1. **Assert the request shape, not just flush it.** Instead of (or in addition to) grabbing the request and flushing, assert on it:\n   ```ts\n   const req = httpTestingController.expectOne('/api/orders/42');\n   expect(req.request.method).toBe('GET');\n   // assert params/headers if the service is supposed to set them\n   req.flush(mockOrder);\n   ```\n   If the URL or method is wrong but you flushed whatever `expectOne` handed back, the test still passes while the real call is broken.\n\n2. **Call `httpTestingController.verify()`.** Do this at the end of the test or in an `afterEach`. This is the piece that catches an *unexpected extra* request (e.g. a duplicated `get` from a buggy `switchMap`, or a retry that shouldn't have fired). Without it, a second request silently sits unconsumed and the test goes green anyway.\n\n3. **Handle the async boundary deterministically.** If the method returns an `Observable`, confirm the subscription is actually triggered before you flush — an `HttpClient` request is only issued on subscribe, so if you're testing a `get`-returning method and only asserting after flushing, make sure something subscribed (the `expectOne` call itself will throw \"no matching request\" if nothing subscribed, which is a useful failure, but be deliberate about it). For a `Promise`-returning method, await it. If timers are involved, wrap in `fakeAsync` and use `tick(<exact ms>)` rather than a real `setTimeout`.\n\n4. **Check you're not asserting on a trivially-true value.** If the service just returns the response body unchanged, an assertion that the result equals `mockOrder` is nearly tautological — add an assertion about the request (URL/method) so the test also pins down *how* the service calls the backend.\n\nSo the minimum complete shape is: expectOne with a URL/method assertion → flush the mock → assert the returned value → `verify()`. Right now you have the middle two; add the surrounding two and it's done.",
+              "outputSha256": "814b8b7c83edb0fcfed43d68bbc0a7e7e995b2adf153da3c2abcdc99fbc93936",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states verify() must be called at end of test or in afterEach (point 2), and explains it catches an 'unexpected extra request' that would otherwise 'silently sit unconsumed' while the test goes green — i.e. requests beyond the flushed one. No fail criterion: it explicitly says the assertion passing is 'necessary but not sufficient'."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — passing that one assertion is not enough to call this test complete. The `HttpTestingController` setup gives you a second, independent obligation that a passing value assertion does not satisfy: verifying that no unexpected requests were made.\n\nConcretely, before you mark it done:\n\n**Call `httpTestingController.verify()`.** This is the whole reason `HttpTestingController` exists as opposed to a hand-rolled mock of `HttpClient`. Your `expectOne(url).flush(mock)` assertion only proves that *the request you anticipated* happened. It says nothing about a *second, unanticipated* request. If the service has a bug that fires the GET twice — say a duplicated subscription, a missing `shareReplay`, a retry that runs eagerly, or an effect that re-triggers — your single `expectOne` pairing with a flush can still pass, while `verify()` is exactly what flags the leftover unmatched request. Put it at the end of the test, or better, in an `afterEach`, so it runs even on paths you didn't explicitly assert.\n\n**Think about what \"returns the parsed response\" actually exercised.** If the method does any transformation of the raw body (mapping fields, `.pipe(map(...))`, unwrapping an envelope), assert on the *transformed* result, not just that some promise resolved. If you're only checking `expect(result).toBeTruthy()`, you're not testing the parse.\n\n**Check the async pattern.** If the method subscribes internally and the return value is delivered asynchronously, you need `await fixture.whenStable()` or `fakeAsync` + `tick()`, not a bare assertion that happens to line up with microtask ordering. A value assertion that passes today because of timing luck is a flake waiting for a slower CI machine.\n\n**Confirm you didn't mock away the thing under test.** `provideHttpClientTesting()` mocks the transport, not the service — good. But if you also stubbed the service's own dependencies with a hand-rolled HTTP double, you may be asserting against your mock's behavior rather than the real method.\n\nSo the minimal completion bar for a service HTTP test is: the request was expected, the response was flushed, the *parsed/transformed* return value is asserted, and `verify()` confirms there was nothing left over — all running through the project's real test command (`ng test` or whatever `angular.json` / `package.json` configures, since it may have been migrated to Jest/Vitest). If any of those is missing, the test isn't done, and I wouldn't report it as done.\n\nOne caveat on my own answer, since I have no tools here and can't see your file: I'm describing what a complete `HttpTestingController` test must contain in general. Whether your specific assertion is sufficient depends on whether the method transforms the response, and on your project's actual runner — both of which you'd need to check against the real source and an existing sibling spec.",
+              "outputSha256": "2b954ce65c02e1e3740aa658aef9ca217b90c880ac8f8b2cc2dc9fc228fff77c",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states 'Call httpTestingController.verify()' at end or in afterEach, and explains expectOne/flush only proves the anticipated request happened while verify() flags a 'second, unanticipated' leftover unmatched request (duplicated subscription, retry, etc.). Both pass criteria concretely met; no fail criterion."
+              },
+              "passed": true
+            },
+            {
+              "output": "No — passing the value assertion is necessary but not sufficient. Before calling that test done, check these:\n\n1. **`httpTestingController.verify()` runs.** After flushing your expected request, call `verify()` (at the end of the test or in an `afterEach`). That's what catches an *unexpected extra* request — e.g. a bug where the service fires two GETs, or fires one on a path you didn't assert. Without it, a duplicate or stray request passes silently. This is the most commonly skipped step.\n\n2. **You asserted on the *request*, not just the response.** `expectOne(url)` only validates the URL. If the method is supposed to send query params, headers (auth token, content type), or a specific HTTP verb, assert those on the `TestRequest` before flushing:\n   ```ts\n   const req = httpTestingController.expectOne('/api/orders?status=open');\n   expect(req.request.method).toBe('GET');\n   // inspect req.request.headers / params as appropriate\n   req.flush(mockResponse);\n   ```\n\n3. **Async plumbing is deterministic.** If the service maps/parses the response through a promise or operator that resolves on a microtask, make sure the assertion actually runs after that settles — either the return value is already resolved at assertion time (fine), or wrap in `fakeAsync` and `tick()`. Don't rely on real `setTimeout` timing. If a timer/delay is involved, advance it with `tick(<exact ms>)`.\n\n4. **You verified the parse/shape, not just \"not undefined.\"** Since the method \"returns the parsed response,\" assert on the meaningful fields of the parsed result — the property names and types the caller depends on — not merely that something came back. A regression that drops a field or changes casing should fail the test.\n\n5. **Error path is covered if the method has one.** If the service transforms or catches HTTP errors, add a test that flushes an error (`req.flush('msg', { status: 500, statusText: 'Server Error' })` or `req.error(new ErrorEvent(...))`) and asserts the method's behavior. Otherwise the happy path is green while the failure behavior is untested.\n\n6. **Test infrastructure is sound.** Confirm `provideHttpClientTesting()` (with `provideHttpClient()`) is in the TestBed providers so `HttpTestingController` is injected from the test backend and no real network is reachable.\n\nSo the minimal additions to make that test genuinely complete: assert the request shape before flush, and call `verify()` after. Then run the project's actual test command (`ng test` or its configured equivalent) and confirm it passes.",
+              "outputSha256": "e94c9355816b9ed3ed8f1d1041fe1171625da73c8265bbe565e02b48ca83e115",
+              "promptSha256": "95da459be88b2d191b810bc7bc755c5e6abe1114c9c4a360ac20eb358994a8b2",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Point 1 states verify() must be called at end of test or in afterEach, and explicitly says it catches an 'unexpected extra request' (e.g. service fires two GETs) that would otherwise 'pass silently' — satisfying both criteria. No fail criterion holds; the answer opens with 'No — passing the value assertion is necessary but not sufficient.'"
+              },
+              "passed": true
+            }
+          ]
+        }
+      ],
+      "verdict": "fail",
+      "scope": "bundled",
+      "skillDigest": "686d2457b0dd6aaaa247c6619927ba89de736f13f0edbaaf00ca93d1205e33b1",
+      "catalogDigest": "fd9b6a086f61a996f761a68f9e7a58cde1ce62e121f276d70bbef8e05e372f4b",
+      "judgePromptVersion": "2026-09-25.1",
+      "runner": "deepseek",
+      "model": "deepseek-chat",
+      "runnerPromptVersion": "2026-09-25.1",
+      "recordedAt": "2026-09-25T15:52:42.266Z",
+      "judge": "deepseek",
+      "judgeModel": "deepseek-chat"
+    },
+    {
+      "schemaVersion": "1.0.0",
+      "skillId": "angular/angular-code-review",
+      "strictness": "high",
+      "trials": 10,
+      "triggerAccuracy": {
+        "truePositive": 6,
+        "falsePositive": 0,
+        "positives": 6,
+        "negatives": 6
+      },
+      "evidence": "authored",
+      "scenarios": [
+        {
+          "id": "trigger-positive-1",
+          "kind": "trigger-positive",
+          "prompt": "Before I merge this Angular component, can you check whether any of its .subscribe() calls are missing takeUntilDestroyed or another teardown?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-2",
+          "kind": "trigger-positive",
+          "prompt": "Does this Angular pull request handle change detection correctly, or is it mutating an @Input array in place under OnPush?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-3",
+          "kind": "trigger-positive",
+          "prompt": "This Angular service pipes some HTML through DomSanitizer's bypassSecurityTrustHtml — can you check whether that's actually safe here?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-4",
+          "kind": "trigger-positive",
+          "prompt": "Take a look at where this Angular component calls inject() — are any of those calls happening outside a valid injection context?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-5",
+          "kind": "trigger-positive",
+          "prompt": "In this standalone Angular component, does the way its computed() signal is written look like an anti-pattern worth flagging in review?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-6",
+          "kind": "trigger-positive",
+          "prompt": "Check this Angular diff for mixing NgModule and standalone components before merge",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-1",
+          "kind": "trigger-negative",
+          "prompt": "Review this NestJS controller diff for DTO validation and guard usage",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-2",
+          "kind": "trigger-negative",
+          "prompt": "Review this MobX store diff for observable/action correctness",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-3",
+          "kind": "trigger-negative",
+          "prompt": "Review this React component diff for missing hook dependencies",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-4",
+          "kind": "trigger-negative",
+          "prompt": "Add retry and error handling to this Angular service's outgoing HTTP call chain",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-5",
+          "kind": "trigger-negative",
+          "prompt": "Write a TestBed spec asserting this Angular route guard blocks an unauthenticated user",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-6",
+          "kind": "trigger-negative",
+          "prompt": "Review this Node.js Express route diff for injection vulnerabilities",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "flag-subscription-without-teardown",
+          "kind": "behavior",
+          "prompt": "Reviewing this Angular component diff:\n\n```ts\nexport class OrderPanel implements OnInit {\n  private readonly orders = inject(OrdersService);\n  order?: Order;\n\n  ngOnInit() {\n    this.orders.watchOrder(this.orderId).subscribe(order => {\n      this.order = order;\n    });\n  }\n}\n```\n\nWhat, if anything, should be flagged?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 10,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "**Finding — missing subscription teardown (Component: `OrderPanel`, `ngOnInit`).**\n\n`this.orders.watchOrder(...).subscribe(...)` has no teardown path: no `takeUntilDestroyed()`, no `async` pipe (the value is assigned to a field, not rendered directly), and no `ngOnDestroy` unsubscribe. The subscription holds a live reference to this component instance for as long as `watchOrder` emits — it is not reclaimed just because the view is destroyed. If `watchOrder` is a long-lived stream (a watch/firehose, as the name suggests), every mount of this panel leaks another subscriber, and callbacks keep writing to a torn-down component's fields.\n\nFix: inject `DestroyRef` and pipe the stream, e.g.\n```ts\nprivate readonly destroyRef = inject(DestroyRef);\nthis.orders.watchOrder(this.orderId)\n  .pipe(takeUntilDestroyed(this.destroyRef))\n  .subscribe(order => { this.order = order; });\n```\n(`takeUntilDestroyed()` with no args is only valid when called in a constructor/field initializer injection context; inside `ngOnInit` pass an explicit `DestroyRef`.)\n\n**Second finding — change detection risk on `this.order` (conditional).**\n\nAssigning `this.order = order` replaces the reference, so an `OnPush` component will re-check correctly *for this property*. But that only helps if the template reads `order` in a way Angular's `OnPush` traversal observes. Flag as an open question, not a defect: if the surrounding template relies on `*ngIf=\"order\"` and the panel is `OnPush`, confirm the emission path actually triggers a check (a value from an out-of-band subscription callback will not by itself mark the component dirty once it leaves the \"first check\" state unless the source is zone-tracked or the component is signalled/marked). Recommend verifying `changeDetection` on this component and, if `OnPush`, that either the subscription is zone-ful or the component is explicitly marked for check / migrated to a signal.\n\n**Checked and clean:**\n\n- `inject(OrdersService)` is in a field initializer — valid injection context, no NG0203 risk.\n- No `DomSanitizer.bypassSecurityTrust*` calls in the diff.\n- No new `NgModule`/standalone declaration shown, so no mixing to flag; if `OrderPanel` is newly added, confirm it's declared/standalone consistently with the rest of the codebase (not determinable from this hunk).\n- No `computed()`/signals present.\n\nAlso note: `orderId` is referenced but not declared in this diff — if it's an `@Input`, `ngOnInit` will read it before inputs are guaranteed unless it's a signal input; worth confirming outside this snippet, but not a finding against the shown code.\n\nNo files were edited; this is a findings report only.",
+              "outputSha256": "47e96b25a7f6c5811e1a4a2861751fa0e45fc9cf56a3ee85713d93387c2c2808",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding explicitly states the .subscribe() has no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and calls it a leak. Concrete fix shown: inject DestroyRef and pipe takeUntilDestroyed(this.destroyRef). Report-only, no edits. Both pass criteria met; no fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "Findings for `OrderPanel`:\n\n1. **Untracked RxJS subscription — missing teardown (high severity).** The `.subscribe()` in `ngOnInit` has no teardown path: no `takeUntilDestroyed()`, no `async` pipe, no explicit `unsubscribe()` in an `ngOnDestroy`, and nothing else in this diff providing one. `watchOrder(...)` returns a live Observable, and the subscription holds a reference to this component instance until it is explicitly unsubscribed — it will not be reclaimed just because the component's view is destroyed. If `watchOrder` is a long-lived or repeating stream (the name suggests a watcher), this leaks one subscription per component instance for as long as the source emits. Fix: `this.orders.watchOrder(this.orderId).pipe(takeUntilDestroyed(this.destroyRef)).subscribe(...)` with `private readonly destroyRef = inject(DestroyRef)`, or expose the Observable to the template and use the `async` pipe instead.\n\n2. **Change detection risk on `this.order` (flag pending component metadata that isn't in the diff).** The diff does not show the `changeDetection` setting or the `@Component` decorator at all. If this component is declared `ChangeDetectionStrategy.OnPush` (common for a panel like this), assigning `this.order` is a reference replacement, so that part is fine — but any template expression that reaches into `order`'s *nested* mutable state, or any in-place mutation of the emitted `order` object elsewhere before assignment, would not trigger a re-check. Since the component metadata is outside the changed lines, verify it before clearing this: read the full component declaration, not just this hunk.\n\n3. **`inject()` call sites — clean.** Both `inject(OrdersService)` at the field initializer is inside a valid injection context (field initializers run during construction), so no NG0203 exposure here. Note `orderId` is referenced in `ngOnInit` but is not declared anywhere in this diff — confirm it is an `@Input()` set before `ngOnInit` runs, or the call will be made with `undefined`. That is outside this skill's framework-specific categories, but it is worth surfacing to the author.\n\n4. **Standalone/NgModule consistency — cannot be assessed from this diff.** The `@Component` decorator is not shown, so whether this component is standalone and whether it is declared in an `NgModule` cannot be checked. No finding either way; read the decorator to confirm it matches the surrounding codebase's convention.\n\n5. **Sanitization — no finding.** There is no `DomSanitizer` usage and no `bypassSecurityTrust*` call in this diff, so nothing to trace here.\n\n6. **Signals — no finding.** No `computed()` or signal usage is present in this diff.\n\nSummary: the one clear, actionable finding is the missing subscription teardown. The change-detection concern and the `orderId` declaration are both real but depend on code outside the changed lines — pull in the full `@Component` decorator and the class field declarations before finalizing, since a review of only these hunks can't rule either out.\n\nNo files were edited; this is a findings report only.",
+              "outputSha256": "761f8cf3c21291a339e1ca7bf0b1762c7412cf26a0ca86b87297b26aba48a590",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 explicitly states the .subscribe() in ngOnInit has no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and calls it a leak. It names concrete fixes: pipe(takeUntilDestroyed(this.destroyRef)) with inject(DestroyRef), or the async pipe. It reports findings only, editing no files, so no fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "Flagging this diff under `angular-code-review`:\n\n**Finding 1 (high severity) — untracked RxJS subscription, `OrderPanel.ngOnInit`**\n`this.orders.watchOrder(...).subscribe(...)` has no teardown path. There is no `takeUntilDestroyed()` in the pipe chain, no `async` pipe in the template, and no `ngOnDestroy` that unsubscribes. A live Observable subscription keeps its callback (and, through it, this component instance) referenced until it is explicitly unsubscribed — it is not cleaned up just because the component's view is destroyed and GC'd. If `watchOrder` emits more than once (the name suggests a live watcher, e.g. a Firestore `onSnapshot`, a websocket, or a long-lived store selector), this also keeps re-assigning `this.order` after the view is gone.\n\nFix: one of\n- `this.orders.watchOrder(this.orderId).pipe(takeUntilDestroyed(this.destroyRef)).subscribe(...)` with `private readonly destroyRef = inject(DestroyRef);` in the field initializers, or\n- expose the Observable (e.g. `order$ = this.orders.watchOrder(this.orderId);`) and consume it with the `async` pipe in the template, letting Angular handle the unsubscribe, or\n- keep the explicit `.subscribe()` and unsubscribe in `ngOnDestroy`.\n\n**Finding 2 (low severity) — `orderId` is referenced but never declared or sourced in this diff**\n`watchOrder(this.orderId)` uses a member that isn't shown as a field, a `@Input()`, or a route param read anywhere in the changed code. If it's an `@Input()` set after `ngOnInit` runs, the subscription in `ngOnInit` may fire with `undefined`; if it comes from an `ActivatedRoute` snapshot/paramMap, that wiring isn't visible. Worth confirming the value is available before `ngOnInit` runs — if not, the subscription should be keyed off an input setter or a route param stream (e.g. `switchMap` off `paramMap`) rather than read once in `ngOnInit`.\n\nNot flagged: `inject()` is used only in a field initializer (`private readonly orders = inject(OrdersService)`), which is a valid injection context, so no NG0203 concern. No `bypassSecurityTrust*`, no `OnPush` mutation issue visible, and no NgModule/standalone mixing in the shown lines.\n\nNo code was edited — findings only.",
+              "outputSha256": "698abe3c73fb0eb151e45f437ce51da0a1b9296fdf00f840280ae53dfbd3f22d",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 explicitly states the .subscribe() has 'no teardown path' (no takeUntilDestroyed, no async pipe, no ngOnDestroy) and calls it a leak risk. It names concrete fixes: takeUntilDestroyed(this.destroyRef) with inject(DestroyRef), async pipe via order$, or unsubscribe in ngOnDestroy. It reports findings only ('No code was edited'), so no fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "This diff has one real finding worth flagging:\n\n## Finding 1 (higher severity) — untracked RxJS subscription\n\n`ngOnInit` in `OrderPanel` calls `.subscribe(...)` on\n`this.orders.watchOrder(this.orderId)` with no teardown path. There is no\n`takeUntilDestroyed()`, no `async` pipe (the value is assigned to a plain\nfield, not a template-bound observable), and no `ngOnDestroy` unsubscribe.\n\nWhy it matters: a live subscription holds a reference to the component\ninstance and to the `orders` service's subscription machinery until it is\nexplicitly torn down. It is not reclaimed by GC just because the view is\ndestroyed. If the panel is mounted/unmounted repeatedly (route changes,\n`*ngIf` toggles, list of panels), each mount leaks another subscriber to\n`watchOrder`, and every emission then writes into a stale, destroyed\ncomponent.\n\nConcrete fix, pick one:\n\n- Add a destroy-scoped teardown:\n\n  ```ts\n  export class OrderPanel implements OnInit {\n    private readonly orders = inject(OrdersService);\n    private readonly destroyRef = inject(DestroyRef);\n    order?: Order;\n\n    ngOnInit() {\n      this.orders.watchOrder(this.orderId)\n        .pipe(takeUntilDestroyed(this.destroyRef))\n        .subscribe(order => { this.order = order; });\n    }\n  }\n  ```\n\n  (`takeUntilDestroyed()` with no argument only works inside an\n  injection context — i.e. a field initializer — so in `ngOnInit` you must\n  pass an injected `DestroyRef`, as above.)\n\n- Or expose the observable and let the template's `async` pipe own the\n  lifecycle: `order$ = this.orders.watchOrder(this.orderId)` plus\n  `@if (order$ | async; as order) { ... }`. This also removes the\n  manual `.subscribe()` entirely.\n\n## Things I checked and am *not* flagging\n\n- **`inject()` usage** — `inject(OrdersService)` is in a field\n  initializer, which is a valid injection context. No NG0203 risk here.\n- **Change detection** — the component does not declare `OnPush`, so the\n  `this.order = order` assignment outside a template-bound observable\n  will be picked up by default change detection. Note this is only\n  *because* it's `ChangeDetectionStrategy.Default`; if it were later\n  switched to `OnPush`, this assignment would need a `markForCheck()` or a\n  signal. Worth a heads-up, but not a defect in the current code.\n- **Sanitization** — no `DomSanitizer` / `bypassSecurityTrust*` calls in\n  the diff, so nothing to trace.\n- **Standalone/NgModule, `computed()` side effects** — no `NgModule`\n  declaration or `computed()` in this diff.\n\n## One thing I could not verify\n\n`this.orderId` is referenced but not declared or shown as an `@Input()` in\nthe diff. If `orderId` arrives asynchronously (e.g. set by a parent after\n`ngOnInit` runs), then `watchOrder(this.orderId)` may be started with an\nundefined id and never re-subscribed on change — that's a separate\ncorrectness question, but it's outside the Angular-framework checks this\nreview is scoped to and I don't have the surrounding component to confirm\nit.\n\n**Summary:** one higher-severity finding — the untracked subscription in\n`ngOnInit`. Per this review's contract, no files were edited; the fix\nabove is for the author or `angular-implementation` to apply.",
+              "outputSha256": "7ee5cc15152c47ab901debc08733318d6aff0c215746f8f8ade4df8573f592c7",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 explicitly states the .subscribe() in ngOnInit has 'no teardown path' — no takeUntilDestroyed, no async pipe, no ngOnDestroy — and calls it a leak. Concrete fixes shown: takeUntilDestroyed(this.destroyRef) piped in, and async pipe with order$. No fail criteria: it flags the issue and does not edit code (states no files were edited)."
+              },
+              "passed": true
+            },
+            {
+              "output": "Findings:\n\n**1. Untracked RxJS subscription — HIGH severity**\n`ngOnInit` (line ~5-7) calls `.subscribe(order => { this.order = order; })` with no teardown path. There is no `takeUntilDestroyed()`, no `async` pipe (it's an imperative subscribe, so the template can't use one here), and no `ngOnDestroy` with an explicit unsubscribe. The subscription stays live for the lifetime of the component and, because the callback closes over `this`, it keeps the component instance reachable after the view is destroyed. Each time this component is created the old subscription keeps firing writes into a dead component. Fix: pipe through `takeUntilDestroyed(this.destroyRef)` — since `inject(DestroyRef)` is available in the field initializer or constructor, e.g.:\n\n```ts\nprivate readonly destroyRef = inject(DestroyRef);\n// ...\nthis.orders.watchOrder(this.orderId)\n  .pipe(takeUntilDestroyed(this.destroyRef))\n  .subscribe(order => { this.order = order; });\n```\n\nor move the stream into a field and consume it with the `async` pipe.\n\n**2. `this.orderId` is referenced but never declared or sourced — HIGH severity**\nThe component has `orders` and `order` but no `orderId` field, `@Input()`, or route param read. As written this is a compile error, so the diff can't be building. If it was elided for brevity, note that the real source matters to correctness: if `orderId` is an `@Input` that can change, subscribing once in `ngOnInit` binds to the first value only — a `switchMap` off an input signal/observable would be needed. Flagging because the diff as shown is non-functional.\n\n**3. Change-detection correctness depends on an undeclared setting — cannot clear as-is, flag as a conditional**\nThe component has no `changeDetection` declaration shown. Assigning `this.order = order` replaces the reference, which is fine for `OnPush` — but only if this diff is complete. If a `changeDetection: ChangeDetectionStrategy.OnPush` exists on the decorator (not shown), the reassignment is fine, but the subscribe callback runs outside Angular's normal trigger zones only if the service emits from a zone-agnostic source; a `ChangeDetectorRef.markForCheck()` or a signal-based `order` would be the robust fix. Recommend the author confirm: (a) whether this is `OnPush`, and (b) whether `watchOrder` emits outside the Angular zone. If either is true, the plain assignment can leave the view stale. Preferred fix — make `order` a signal and set it via `order.set(order)`, which is `OnPush`-safe regardless.\n\n**Non-findings (checked, clean):**\n- `inject(OrdersService)` is in a field initializer — a valid injection context, not flagged.\n- No `DomSanitizer.bypassSecurityTrust*` calls, so no sanitization concern.\n- No `NgModule`/standalone mixing introduced by this diff.\n- No `computed()` with side effects.\n\n**Priority order:** #1 and #2 block the diff; #3 needs an answer from the author before merge. No files were edited — this is a findings report only.",
+              "outputSha256": "4e552984ac71212b77a45ce45404d6fb0a58e837bf96bb495cd729094c673101",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding #1 explicitly flags the .subscribe() in ngOnInit as having no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and calls it a leak risk, then names concrete fixes: piping through takeUntilDestroyed(this.destroyRef) with code shown, or consuming via the async pipe. It reports findings only, editing no files, so no fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "Flagging the diff as-is. Two findings, one high severity:\n\n**1. High — untracked RxJS subscription (`ngOnInit`)**\n\n```ts\nthis.orders.watchOrder(this.orderId).subscribe(order => {\n  this.order = order;\n});\n```\n\n`watchOrder` is presumably a long-lived Observable (a \"watch\" API strongly implies it pushes multiple values over time, not a one-shot HTTP response that completes). The subscription has no teardown path:\n\n- No `takeUntilDestroyed()` in the pipe.\n- No `async` pipe in the template (this is an imperative `subscribe`).\n- No `ngOnDestroy` unsubscribing.\n\nWhy it matters: the subscription holds a live reference to the component instance and its callback until the Observable completes or errors. A `watchOrder` stream that only ends when the order is deleted, or never, keeps the component (and its `this.order` captured in the closure) alive past view destruction, and keeps executing `this.order = order` on a destroyed component. This is a genuine leak, not a \"GC will catch it\" situation — the Observable source holds the subscriber, not the other way around.\n\nFix — add `takeUntilDestroyed()` (requires the component to be in an injection context; `ngOnInit` field/DI context is fine, or pass `inject(DestroyRef)` explicitly):\n\n```ts\nthis.orders.watchOrder(this.orderId)\n  .pipe(takeUntilDestroyed())\n  .subscribe(order => { this.order = order; });\n```\n\nOr expose the stream and bind it with the `async` pipe in the template, which handles teardown automatically.\n\n**2. Medium/context-dependent — no `OnPush` + untracked `orderId` input**\n\nI can't see from this hunk whether `orderId` is an `@Input`. If it is (a setter or bound input), then this code has a second problem independent of the leak: `ngOnInit` reads `this.orderId` exactly once. If `orderId` changes while the component is alive, the subscription is never re-established and the panel silently shows the old order.\n\nIf `orderId` is an input, the fix is to make the source stream reactive rather than capturing it once — e.g. an input-setter or `input()` signal feeding `switchMap` into `watchOrder`, so a changed id cancels the old stream and subscribes to the new one. Worth confirming before flagging as a defect rather than a note.\n\n**Not flagged**\n\n- No `OnPush`/in-place-mutation issue — `this.order = order` replaces the reference, so even a future `OnPush` switch is fine here.\n- No `inject()` misuse — `inject(OrdersService)` is a field initializer, a valid injection context. `ngOnInit` calling `inject()` would be a problem, but it doesn't.\n- No `bypassSecurityTrust*` calls in this diff.\n- No standalone/NgModule question visible here.\n\nNo edits made — this is a findings report for the author to apply.\n\nOne thing I'd want from the author to firm up finding #2: is `orderId` an `@Input`, and does it ever change after init? That determines whether it's a defect or just a note.",
+              "outputSha256": "c86d30c0faf82ac0babd663a926ec4acbb9094b02e3de85702a88b4fdf1882c7",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding #1 explicitly flags the .subscribe() in ngOnInit as having no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and calls it a genuine leak. It names concrete fixes: piping through takeUntilDestroyed() with code shown, and the async pipe. It reports findings without editing code ('No edits made'). No fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "Findings, in severity order.\n\n**1. Untracked RxJS subscription (higher severity).** `this.orders.watchOrder(this.orderId).subscribe(...)` in `ngOnInit` has no teardown path. There is no `takeUntilDestroyed()`, no `async` pipe, and no `ngOnDestroy` unsubscribe shown. The subscription holds a live reference to the component (and to `this.order`) until something explicitly unsubscribes it; GC will not collect it just because the view is destroyed. If `watchOrder` emits repeatedly over the lifetime of a long-lived stream, you also leak each emission into a dead component.\n\nFix: pipe `takeUntilDestroyed(this.destroyRef)` (injecting `DestroyRef`, since `takeUntilDestroyed()` without an argument only works in a constructor/field-initializer injection context) —\n\n```ts\nprivate readonly destroyRef = inject(DestroyRef);\n\nngOnInit() {\n  this.orders\n    .watchOrder(this.orderId)\n    .pipe(takeUntilDestroyed(this.destroyRef))\n    .subscribe(order => { this.order = order; });\n}\n```\n\nNote the DI constraint that interacts with this: `takeUntilDestroyed()` called with no argument must run inside an injection context, which `ngOnInit` is *not*. So either pass `this.destroyRef` explicitly as above, or move the subscription setup into a field initializer / constructor.\n\n**2. Not flagged here, but worth confirming outside the diff.** `orderId` is referenced but not shown being defined or sourced. If it's a component input or route param, confirm it's set before `ngOnInit` runs (inputs are, route params may not be — that would be a separate correctness bug, not an Angular-framework finding per se). Similarly, `this.order` being mutated with a plain property assignment is fine for default change detection, but if this component is actually declared `OnPush` (not visible in this hunk — `@Component` metadata is outside the diff), reassigning the property reference is correct; if instead the service were handing back a mutated-in-place object, that would be a flagged OnPush issue. As written, the assignment replaces the reference, so no change-detection finding applies.\n\nOther categories — `inject()` usage (both `inject()` calls are field initializers, valid injection context), `bypassSecurityTrust*` (none present), standalone/NgModule consistency, and signal purity (no signals present) — produce no findings in this diff.\n\nNo code was edited; this is a findings report only. The subscription teardown is a one-line-adjacent fix but should be applied by the author or via angular-implementation, not during review.",
+              "outputSha256": "6f4d4be180ceca3ee1ab6322f3d2f97afd14464f62b3e293b777b29d389c7798",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 explicitly says the .subscribe() in ngOnInit has no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and calls it a leak. It names the concrete fix: pipe takeUntilDestroyed(this.destroyRef) with injected DestroyRef, showing the code. It reports rather than edits ('No code was edited; this is a findings report only')."
+              },
+              "passed": true
+            },
+            {
+              "output": "Two findings here — one high, one conditional.\n\n**1. Untracked subscription (higher severity).** `this.orders.watchOrder(this.orderId).subscribe(...)` in `ngOnInit` has no teardown path. There's no `takeUntilDestroyed()`, no `async` pipe (it's subscribed in the component body, not the template), and no `ngOnDestroy` with an unsubscribe/`Subject` teardown. `watchOrder` returns a stream; given the name it is presumably long-lived (a live watch, not a one-shot HTTP call), so this subscription will stay alive and keep writing to `this.order` after the component view is gone. The fix: pipe through `takeUntilDestroyed(this.destroyRef)` — injecting `DestroyRef` via `inject()` and applying it in `ngOnInit` (the `takeUntilDestroyed()` operator needs an explicit `DestroyRef` when used outside an injection context, which `ngOnInit` is), or move to the `async` pipe.\n\n**2. `OnPush` + in-place field assignment (conditional).** The handler does `this.order = order`, which replaces the reference — that's fine if this component is default change detection, and it's also fine under `OnPush` **provided** the emission is tied to a signal/observable Angular can track. But a raw `.subscribe()` callback assignment is not a tracked update. If `OrderPanel` is declared `ChangeDetectionStrategy.OnPush` (which the diff doesn't show — this is the caveat, the `changeDetection` setting is outside the changed lines), a plain field write inside a subscribe callback won't itself schedule a re-check, and the template will go stale. So this can't be cleared without reading the component decorator. If it is `OnPush`, the fix is to drive the value from a signal (`toSignal(...)`) or otherwise mark for check, rather than a bare assignment. If it's default CD, this is not a finding on its own.\n\nWhat I would **not** flag here: no `inject()` misuse — `inject(OrdersService)` is a field initializer, a valid injection context. No `bypassSecurityTrust*` call. No `NgModule`/standalone mixing or signal anti-patterns in this diff.\n\nNote I have not read the declaration of this class or `OrdersService`, so both findings rest on what the diff shows: finding 1 is determinable from this snippet alone, finding 2 needs the `changeDetection` setting to confirm. Per this skill's scope, the report stops there — no edits applied; the `takeUntilDestroyed` fix is left for the author or `angular-implementation` to make.",
+              "outputSha256": "31b4c35ec46b1bbeeaea93a359274ee6554c300b5819c4bf157f95f9c7b79c51",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 explicitly says the .subscribe() in ngOnInit has no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and calls it a leak risk. It names concrete fixes: pipe through takeUntilDestroyed(this.destroyRef) with injected DestroyRef, or move to the async pipe. It reports rather than edits, and does not claim no issues."
+              },
+              "passed": true
+            },
+            {
+              "output": "Findings, in severity order:\n\n**1. Untracked RxJS subscription (high severity).** `this.orders.watchOrder(this.orderId).subscribe(...)` has no teardown path. No `takeUntilDestroyed()`, no `async` pipe, no explicit unsubscribe in an `ngOnDestroy`, and the component doesn't implement `OnDestroy` at all. The subscription holds a live reference for as long as the source emits; it is not cleaned up by GC when the component view is destroyed. Every time this component is created and destroyed (route change, `*ngIf` toggle, panel open/close), another subscription is left behind, and each stale callback writes to the captured `this` of a dead component instance. Fix: add `private readonly destroyRef = inject(DestroyRef);` (or use the `takeUntilDestroyed()` operator's no-arg form inside the injection context of the field/constructor) and pipe `.pipe(takeUntilDestroyed(this.destroyRef))` before `.subscribe(...)`. Alternatively convert `order` to a signal fed by `toSignal(this.orders.watchOrder(this.orderId), ...)`, which manages teardown itself.\n\n**2. `OnPush` mutation concern (medium severity, conditional).** Check the `@Component` metadata — it isn't in this diff. If this component uses `ChangeDetectionStrategy.OnPush`, then `this.order = order` replaces the reference, which *will* trigger a re-check, so this particular assignment is fine. But if the template also reads nested/mutated state off `order`, or if `watchOrder` emits the *same* object reference mutated in place, that later emission will not re-render under `OnPush`. Worth confirming the emission semantics of `watchOrder` before clearing it.\n\n**3. `inject()` at field initializer — actually valid (no finding).** `private readonly orders = inject(OrdersService);` is a field initializer, which is a valid injection context. Not an NG0203 issue. Calling `inject()` inside the `ngOnInit` body would be a problem, but that's not what's happening here.\n\n**4. `orderId` source (low severity / clarify).** `this.orderId` is referenced in `ngOnInit` but not declared in this diff. If it's an `@Input()`, note the lifecycle ordering: `ngOnInit` runs once, after the first input binding, so an input-driven `orderId` is fine for this `ngOnInit`-based subscription. But if `orderId` can change after init, the watcher won't re-subscribe — a `ngOnChanges` handler or an input `set`ter (or a signal-based `effect`) would be needed. If it can't change, no issue.\n\n**5. No `DomSanitizer.bypassSecurityTrust*` calls present.** Nothing to check here.\n\n**6. No `NgModule`/standalone mixing in this diff.** The decorator metadata isn't shown, so I can't confirm `standalone`, but there is no `NgModule` declaration in the changed lines and no cross-boundary component/directive/pipe addition to flag.\n\n**7. Signals / `computed()`:** not used in this component, so nothing to flag.\n\nBottom line: the one thing that must be fixed before merge is the unmanaged subscription in `#1`. `#2` and `#4` are \"confirm before clearing\" items that depend on metadata and on how `watchOrder` and `orderId` behave.\n\nNo files were edited — this is a findings report only.",
+              "outputSha256": "ef96adcbc7ad5c5f0ffc3a3ee0f5c453a8c368ef898efec5fb5bad275b460612",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding #1 explicitly flags the .subscribe() as having no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and names concrete fixes: piping .pipe(takeUntilDestroyed(this.destroyRef)) and converting to toSignal(). It reports findings only, editing no files, so no fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "Two things should be flagged in this diff, both in the `ngOnInit` body.\n\n**1. Untracked RxJS subscription (higher severity).**\n\n`this.orders.watchOrder(this.orderId).subscribe(...)` has no teardown path:\n\n- There is no `takeUntilDestroyed()` in the pipe.\n- The result is not stored and consumed via the `async` pipe.\n- There is no `ngOnDestroy` with an explicit `unsubscribe()`.\n\n`watchOrder` is presumably a long-lived stream (the name implies it keeps watching), so every time this component is created the subscription stays alive and holds a live reference back to this component instance. It does not get cleaned up by garbage collection just because the view is gone — the Observable's subscriber list keeps the callback (and therefore `this`) reachable for as long as the source keeps emitting. If the component is created repeatedly (routing, list rendering, etc.), this also accumulates duplicate subscriptions.\n\nConcrete fix — either:\n\n```ts\nngOnInit() {\n  this.orders.watchOrder(this.orderId)\n    .pipe(takeUntilDestroyed(this.destroyRef))\n    .subscribe(order => { this.order = order; });\n}\n```\n\n(with `private readonly destroyRef = inject(DestroyRef);` as a field — that `inject()` call *is* in a valid field-initializer context, so it's fine), or keep the subscription lifecycle in the template with the `async` pipe instead of subscribing manually at all.\n\n**2. Template-vs-change-detection risk depends on how `order` is consumed — needs checking, not necessarily a confirmed defect.**\n\nAssigning `this.order = order` replaces the reference, which is the good pattern. But whether this actually triggers a re-render depends on the component's `changeDetection` setting, which isn't shown in the diff:\n\n- If the component is default change detection, this is fine.\n- If it is `OnPush`, replacing `this.order` from inside an `ngOnInit` subscription callback may not mark the component for check on its own. The callback here is running outside Angular's zone-triggering event so the assignment alone won't necessarily schedule a re-check. Under `OnPush` this should be paired with an explicit `markForCheck()` (or the value should be exposed as a signal / `async`-piped observable so the framework tracks it).\n\nBecause the setting isn't in the diff, this is a \"verify before clearing\" item rather than a confirmed finding — but it should be called out, and the surrounding file read to confirm `changeDetection`.\n\n**What is *not* a problem here:** the `inject(OrdersService)` call itself is in a valid field-initializer injection context, so there's no NG0203 concern from this snippet. `orderId` is referenced but not declared in the diff; if it's similarly an `@Input()` read in `ngOnInit` that's a separate generic concern outside this skill's Angular-specific scope.\n\nPer this skill's scope, these are reported as findings only — no edits were made, and the fixes above are for the author (or `angular-implementation`) to apply.",
+              "outputSha256": "f433d62d66999bf26da5aa487737e65ccdb31f2f8fa9f77fe9a95712dea72be7",
+              "promptSha256": "febaf7062fb0b242eb84335d2c85bbc4101cb8d028c800ffa4d0bd8ff130c0d4",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer explicitly flags the .subscribe() as having no teardown path (no takeUntilDestroyed, no async pipe, no ngOnDestroy unsubscribe) and calls it a leak risk. It names concrete fixes: piping through takeUntilDestroyed(this.destroyRef) with code shown, and the async pipe alternative. It reports findings without editing code, so no fail criteria hold."
+              },
+              "passed": true
+            }
+          ]
+        },
+        {
+          "id": "flag-onpush-inplace-mutation",
+          "kind": "behavior",
+          "prompt": "Reviewing this Angular diff. `CartList` is a child OnPush component; `CartPage` is its parent and passes `items` down as an `@Input`:\n\n```ts\n@Component({\n  selector: 'app-cart-list',\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  template: `@for (item of items; track item.id) { <div>{{ item.name }}</div> }`\n})\nexport class CartList {\n  @Input() items: CartItem[] = [];\n}\n\n@Component({ selector: 'app-cart-page', template: `<app-cart-list [items]=\"items\" />` })\nexport class CartPage {\n  items: CartItem[] = [];\n\n  addItem(item: CartItem) {\n    this.items.push(item);\n  }\n}\n```\n\n`CartPage.addItem` runs (e.g. from a button click in `CartPage`'s own template), but `CartList`'s rendered list doesn't update. What should be flagged?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 10,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "## Finding\n\n**`cart-page.component.ts` — `CartPage.addItem` mutates `this.items` in place; `CartList` is `OnPush` and receives `items` as an `@Input`.**\n\n```ts\naddItem(item: CartItem) {\n  this.items.push(item);   // in-place mutation, same array reference\n}\n```\n\n### Why it doesn't update\n\n`CartList` is declared `ChangeDetectionStrategy.OnPush`. Under `OnPush`, Angular only re-checks a component when one of these happens:\n\n1. an `@Input` reference changes (per `Object.is`/`===` identity, not deep equality),\n2. an event fires **from within that component's own view**,\n3. a signal read in its template changes,\n4. it's explicitly marked dirty (`markForCheck`), or\n5. an ancestor with default change detection re-checks and it's not detached.\n\nHere none of them fire for `CartList`:\n\n- `this.items.push(item)` keeps the **same array identity**. The parent template binding `[items]=\"items\"` is re-evaluated, but the value passed down is `===` the previous one, so `CartList`'s `@Input` is considered unchanged and OnPush skips it.\n- The click event originates in `CartPage`'s view, so it marks **`CartPage`** dirty — not `CartList`. An event only auto-dirties the component whose view it belongs to.\n- No signal is involved.\n\nThe result is exactly the reported symptom: `CartPage` may re-check, `CartList` does not, and the new item never renders. Note this is a latent timing bug, not a \"sometimes works\" one — whether it *appears* to work depends on incidental re-checks elsewhere, which is why it's worth flagging even if current test data happens to render.\n\n### Fix\n\nReplace the array reference so the `@Input` identity actually changes:\n\n```ts\naddItem(item: CartItem) {\n  this.items = [...this.items, item];\n}\n```\n\nThis flows a new array reference down through `[items]=\"items\"`, `Object.is` fails, and `CartList` is correctly marked for check. (If `CartPage` were itself OnPush and the change came from an async source, it would additionally need `markForCheck()` or a signal — but for a click-originated event, replacing the reference is the complete fix.)\n\n## Secondary observation\n\n`CartPage` has no `changeDetection` set, so it defaults to `Default`. That's not the bug and doesn't need to change, but it's the reason the failure is confined to the child: the parent does re-check, which can make the problem look intermittent rather than deterministic.\n\n## Not flagged\n\n- The `@for ... track item.id` usage is correct (proper `track` on a stable key); no issue there.\n- No `subscribe()`, `inject()`, `bypassSecurityTrust*`, signal, or NgModule/standalone concern appears in this diff.\n- No code was edited — this is a findings report only. The one-line change is the author's (or `angular-implementation`'s) to apply.\n\n## Suggested severity\n\n**High** — user-visible correctness bug: adding an item to the cart silently fails to render. The fix is one line, but the root cause (OnPush + in-place mutation) is a class of bug likely to recur elsewhere in the same component if the pattern isn't corrected.\n",
+              "outputSha256": "e84ddb90822e3e364f8ff026263cca9e220f3cc44446b6c71c5f7d976c5e1e8b",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states push keeps 'same array identity' and @Input 'is considered unchanged' (crit 1). Explains OnPush re-checks only on new @Input reference, and click event dirties CartPage not CartList (crit 2). Names concrete fix: this.items = [...this.items, item] (crit 3). No fail criteria triggered."
+              },
+              "passed": true
+            },
+            {
+              "output": "# Findings\n\n**1. `CartPage.addItem` mutates the array in place instead of replacing it — HIGH severity**\n\n`cart-page.component.ts` — `addItem`:\n\n```ts\nthis.items.push(item);\n```\n\nThis is the root cause of the reported symptom. `items` is passed to `CartList` as `[items]=\"items\"`. Angular's default change detector compares the *reference* of the bound `@Input` for a component marked `OnPush`. Since `push()` mutates the same array instance, the reference never changes, so `CartList` (which is `OnPush`) is skipped during change detection and its template never re-runs. The click in `CartPage` triggers CD in `CartPage`, but the `OnPush` child is not marked dirty, so it does not re-check.\n\nNote also that `CartPage` is *not* declared with `OnPush` here, so `CartPage`'s own view will update; it is specifically the `OnPush` child that stays stale. The fix is to replace the reference so the input binding sees a new value:\n\n```ts\nthis.items = [...this.items, item];\n```\n\nor convert `items` to a signal and update it with `update()` / assignment, which makes the replacement explicit.\n\n**2. `CartList` marks something as in-place-dependent under `OnPush` — MEDIUM severity (related)**\n\n`cart-list.component.ts` — the template and input:\n\n```ts\n@Input() items: CartItem[] = [];\n```\n\nCombined with `changeDetection: ChangeDetectionStrategy.OnPush`, this component depends on its parent always supplying a **new array reference** whenever the contents change. That contract is undocumented and is exactly what finding #1 violates. Worth flagging: either document/enforce the \"replace, don't mutate\" contract at the input, or accept per-item changes via signals so mutation of contents is observable. As written, the component is correct only if the parent obeys an unstated rule.\n\n**3. Minor: mutation is also a (silent) parent-state anti-pattern even without `OnPush`**\n\n`CartPage.addItem` mutating its own `items` array in place will not be caught by `OnPush`-less parents either, but it defeats any future `OnPush` / `computed` / `effect` that reads `items`, and it breaks reference-equality-based memoization anywhere downstream. Flag as a code-quality note pointing at the same fix as #1.\n\n## Not flagged (checked, clean)\n\n- **RxJS lifecycle**: no `.subscribe()` calls added in this diff — nothing to check for teardown.\n- **`inject()` misuse**: no `inject()` calls present.\n- **`bypassSecurityTrust*`**: no `DomSanitizer` usage.\n- **Standalone/NgModule mixing**: neither component declares `standalone` here and no `NgModule` change is shown; nothing to flag from this diff alone.\n- **`computed()` side effects**: no signals used.\n- **`@for` track**: `track item.id` is present and correct; not an issue.\n\n## Summary\n\nThe single actionable defect causing the reported symptom is **finding #1**: an in-place `push()` on an array bound into an `OnPush` child's `@Input`, which the reference-based check never observes. Fix it by replacing the array reference (or moving to a signal). Finding #2 is the latent contract that allowed it; finding #3 is the same mutation seen from the parent's own perspective. No code was edited — these are reported for the author or `angular-implementation` to apply.",
+              "outputSha256": "17e733b3a413382f62316d7f6fe4e51e2718d901cdffaa76ee1b57128b894429",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding #1 states push() mutates the same array instance so the reference never changes, CartList is OnPush and skipped, and the click in CartPage doesn't mark the child dirty. Concrete fix given: `this.items = [...this.items, item];` or a signal. No fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "## Finding 1 — OnPush parent mutates the array in place (root cause)\n\n**File/line:** `CartPage.addItem` — `this.items.push(item)`\n\n**What's wrong:** `CartPage.addItem` mutates the existing `items` array reference instead of replacing it. `CartList` is `OnPush`, so it only re-renders when one of its inputs changes *by reference* (or an event/signal inside it fires). `push` keeps the same array reference, so the `[items]` binding is seen as unchanged and `CartList` is never marked dirty.\n\n**Why it matters (mechanism):** With `ChangeDetectionStrategy.OnPush`, the framework skips re-checking a component unless an `@Input` reference changes, an event handler runs *inside that component*, a signal it reads changes, or it's explicitly marked for check. A parent-side `push` satisfies none of these for the child, so the new item silently never renders — not a timing glitch, a guaranteed miss.\n\n**Concrete fix — replace the reference:**\n```ts\naddItem(item: CartItem) {\n  this.items = [...this.items, item];\n}\n```\nThat gives `CartList` a new `items` reference, which triggers its OnPush re-check. (Longer term, consider making `items` a signal, e.g. `items = signal<CartItem[]>([])` and `update(a => [...a, item])`, so downstream `@for` reacts to signal updates directly.)\n\n---\n\n## Finding 2 — do not \"fix\" the child by injecting ChangeDetectorRef or switching it off OnPush\n\n**What's wrong (would-be fix, flag against it):** A tempting remediation is to drop `changeDetection: OnPush` from `CartList` or inject `ChangeDetectorRef` and call `detectChanges()`. Both mask the real defect.\n\n**Why it matters:** The parent is violating the input contract — an `@Input` array is treated as mutable state rather than an immutable value. Silencing OnPush in the child re-checks the whole subtree on every CD cycle, defeating the perf reason OnPush exists, and the same stale-reference bug returns the next time some other consumer mutates in place. Fix the reference at the source (Finding 1), not the detection strategy downstream.\n\n---\n\n## Finding 3 — `CartPage` itself has no OnPush (secondary, lower severity)\n\n**File/line:** `@Component({ selector: 'app-cart-page', ... })`\n\n**What's wrong:** `CartPage` omits `changeDetection`, so it defaults to `Default`. Not the cause here, but note it: if `CartPage` later adds `OnPush` (likely for consistency), the `push` bug would *also* stop `CartPage`'s own template from reflecting the new item, doubling the symptom. Flag as a consistency concern, not the primary defect.\n\n---\n\n## What I verified\n\n- Both changed components read in full, including the `changeDetection` declarations outside the `addItem` hunk.\n- `CartList`'s template (`@for ... track item.id`) depends on the `items` input reference — confirmed the mutation path misses its only update trigger.\n- No `.subscribe()`, `inject()`, or `bypassSecurityTrust*` calls present in this diff, so those categories are N/A here.\n- No code was edited — this is a findings report only.\n\n**Severity ranking:** Finding 1 (must fix — this is the bug), Finding 2 (guard against the wrong fix), Finding 3 (style/consistency).",
+              "outputSha256": "210d680f9ed1e4cdb18627085854032338ad908cb70a0e2205cdc1e83a3f0518",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 states push mutates the existing array reference so the [items] binding is seen as unchanged (identity unchanged), explains OnPush only re-checks on input reference change/event inside child/signal, and gives concrete fix `this.items = [...this.items, item];` plus signal alternative. No fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "## Findings\n\n### 1. `CartPage.addItem` mutates `items` in place (HIGH)\n\n`app-cart-page` at line `this.items.push(item)` — `addItem` pushes onto the existing array instead of assigning a new reference. `items` is then passed down to `app-cart-list` via `[items]=\"items\"`.\n\n**Why it matters:** `CartList` is `OnPush`. Under `OnPush`, a component only re-checks when one of its inputs *changes identity* (per the default `Input` reference check), an event fires inside it, or `markForCheck`/async-pipe/signal-notification occurs. `push()` does not produce a new array reference, so when the parent re-renders, Angular compares the bound value to the previous one, sees the *same* array reference, concludes the input is unchanged, and skips re-checking `CartList`. The array now contains the new item, but the `@for` never re-runs, so the DOM stays stale.\n\nThere's a second, independent reason this can fail even for the parent: if `CartPage` itself is ever put under `OnPush` (or is a child of something `OnPush`), the in-place mutation on a plain field also won't schedule a re-check of `CartPage`.\n\n**Fix:** replace the array rather than mutating it.\n\n```ts\naddItem(item: CartItem) {\n  this.items = [...this.items, item];\n}\n```\n\nA new reference makes the `[items]=\"items\"` binding register as changed, which re-checks `CartList`. If the codebase is signal-based, the better fix is `items = signal<CartItem[]>([])` with `items.update(list => [...list, item])` and binding `[items]=\"items()\"` — signal reads are tracked and notify regardless of reference identity.\n\n### 2. Test data can mask this — do not clear it as \"works on my machine\" (NOTE)\n\nFlag this explicitly: the bug may *appear* to work intermittently, because under `OnPush` `CartList` will still re-check whenever some *other* event fires inside its own subtree, or whenever any other ancestor input coincidentally changes. A click handler living in the parent does not re-check the child. The fact that it renders correctly in some manual test path does not clear the finding — it's a timing-dependent stale-view bug, not a hypothetical.\n\n---\n\n### Not a finding (checked and clean)\n\n- **No `.subscribe()` in this diff** — no RxJS teardown to verify.\n- **No `inject()` calls** — DI-context check is N/A here.\n- **No `DomSanitizer.bypassSecurityTrust*`** — sanitization check is N/A. (Note `item.name` is rendered via interpolation, which Angular escapes by default, so it's safe as written.)\n- **`CartList` itself is correct** — the `@Input` is declared, `OnPush` is intentional, and `@for ... track item.id` is well-formed. The defect is entirely on the parent's side.\n\nThe single actionable item for the author is finding 1: replace the in-place `push` with a reference-producing update (spread, `concat`, or a signal `update`). No files were edited as part of this review.",
+              "outputSha256": "836c81e7f8af8dc0760301e80f75f453c3a02bede587cefffc759833d14cdff8",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 states push mutates in place and 'does not produce a new array reference' so the same reference is bound to CartList's input. It explains OnPush re-checks only on input identity change/event/async-pipe/signal, and that a parent click handler does not re-check the child. Fix shown concretely: `this.items = [...this.items, item];` plus signal alternative. No fail criteria met."
+              },
+              "passed": true
+            },
+            {
+              "output": "## Finding 1 — `OnPush` child will not re-check on an in-place array mutation\n\n**File:** `CartPage.addItem` — `file:line` of the `push` call.\n\n**What's wrong:** `this.items.push(item)` mutates the *existing* array. The `@Input() items` reference passed to `<app-cart-list>` is the same array object before and after the call. `CartList` uses `ChangeDetectionStrategy.OnPush`, and an `OnPush` component is only re-checked when:\n\n- one of its `@Input` **references** changes (default `Input` change detection compares by identity),\n- an event bound *inside its own* template fires (Angular auto-marks an OnPush view dirty on its own template's events, but not on a parent's),\n- an `Observable` it subscribes to via the `async` pipe emits,\n- a `signal` it reads changes,\n- `markForCheck()` / `detectChanges()` is called on it, or\n- it receives a new input reference.\n\n`push` does none of these. The parent (`CartPage`, default `CheckEvery`/`Default` CD) re-renders on the button click, but Angular does not propagate that to the `OnPush` child because the child's input identity is unchanged. Hence `CartList`'s `@for` never re-runs.\n\n**This is the bug the user is describing.** The `@for (item of items; track item.id)` block is also affected by the same in-place mutation even *within* `CartPage` if `CartPage` itself were OnPush — but `CartPage` here is default CD, so the visible symptom is entirely in the child.\n\n**Why it matters:** the list is a timing/identity bug, not a COW (copy-on-write) theory. It will surface whenever the parent does not otherwise happen to dirty the child.\n\n**Fix options (report the choices, don't just pick one):**\n\n1. **Replace the array** (minimal, keeps OnPush):\n   ```ts\n   this.items = [...this.items, item];\n   ```\n   New reference → `@Input` identity change → child re-checked.\n\n2. **Use a signal** for `items` and read it in the child’s template via the signal (or `input()`/`input.required<CartItem[]>()` with signal semantics). Signal reads register the consumer automatically; `items.update(prev => [...prev, item])` in the parent propagates without relying on identity change.\n\n3. **Explicit `markForCheck`** on the child (e.g. `@ViewChild(CartList)` + `markForCheck()`) — possible but discouraged; it leaks parent→child CD knowledge and defeats the point of OnPush.\n\n4. **Immutable store + `async` pipe** — if items come from a store/observable, feed the child through `items$ | async`; the async pipe’s emission marks the OnPush view dirty.\n\nOption 1 or 2 is the intended direction. Option 3 should only be noted as “works but wrong.”\n\n---\n\n## Finding 2 — `track item.id` is correct here, but flag the `@for` interaction with mutation if the fix is not applied\n\nOnce `push` is in place, the `@for` diffing itself is fine (`track item.id` is the right key), but it will *never receive* the new state until the input reference changes. This is a consequence of Finding 1, called out separately so the author doesn't “fix” it by switching `track` to `track $index` (which would change identity semantics but still not re-check the OnPush view).\n\n**Do not accept** `track $index` as the fix — that would mask nothing about the CD issue and could re-introduce key-collision/rerender churn later.\n\n---\n\n## Not flagged (out of scope / not present)\n\n- No `.subscribe()` in the diff → no RxJS teardown check triggered.\n- No `inject()` calls → no NG0203 injection-context check triggered.\n- No `DomSanitizer.bypassSecurityTrust*` calls → no sanitization check triggered.\n- `CartList` is standalone-style (selector + no `NgModule` decl shown), consistent with the parent; no standalone/NgModule mixing to flag.\n- No `computed()` here.\n\n---\n\n## Severity\n\n**Finding 1: high.** It is a correctness bug that produces a stale UI under a common, supported workflow (parent event handler mutating a collection passed to an OnPush child), and the fix has concrete alternatives. Finding 2 is a sub-note of Finding 1, not a separate defect.\n\n**Reported only — no edits made to the reviewed files.** Apply the fix in `angular-implementation`, not during review.",
+              "outputSha256": "c4dabdd9da42af6901f825f960c8fa20fa3f652b444fe5f21a611f6781f9dad6",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 states push mutates the existing array so the @Input reference is the same object before/after (identity unchanged), and that OnPush only re-checks on new input reference/own event/async/signal, so CartPage's own re-render doesn't propagate. Fix option 1 shows `this.items = [...this.items, item];` and option 2 names signals/input(). No fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "## Findings\n\n**1. In-place mutation of an array that flows into an `OnPush` child — highest severity**\n\n`CartPage.addItem` does `this.items.push(item)`. This mutates the existing array instance in place; it never assigns a new reference to `items`. The template binding `[items]=\"items\"` therefore keeps passing the *same* array object reference to `CartList`.\n\n`CartList` is `ChangeDetectionStrategy.OnPush`. Under OnPush, Angular only re-renders the component when one of these happens:\n\n- an `@Input` **reference** changes (by identity, `!==`), or\n- an event originates from within `CartList` itself (or its children), or\n- an `Observable` bound via the `async` pipe emits, or\n- the component is explicitly marked dirty (`markForCheck`, `detectChanges`, signals, etc.).\n\nSince `push` mutates the array in place, the `@Input` reference is unchanged on every subsequent call, so `CartList` is never marked dirty and its `@for` block never re-evaluates. The rendered list stays stale — exactly the symptom described. This is the primary bug to flag.\n\n**Fix**: replace the array rather than mutating it, so the `@Input` identity changes and OnPush detects it:\n\n```ts\naddItem(item: CartItem) {\n  this.items = [...this.items, item];\n}\n```\n\n(If a signal were used end-to-end — `items = signal<CartItem[]>([])` with `update` — that would also work, but that's a larger refactor than this diff needs.)\n\n**2. Same mutation, second-order — `CartPage` itself may not re-check either**\n\n`CartPage`'s own binding to `<app-cart-list [items]=\"items\" />` also relies on `items` changing. Even if `CartPage` were later made OnPush, the same in-place mutation would fail to propagate. The fix above resolves both, since a fresh reference propagates through the binding regardless of the parent's strategy. Worth noting in the report, not a separate defect.\n\n**3. `track item.id` is correct here — do not flag it**\n\n`@for` with `track item.id` is the right form (tracks by stable identity, not index). No issue.\n\n## What is *not* a finding (and why, so the review isn't padded)\n\n- **No subscription teardown issue**: there are no `.subscribe()` calls in the diff.\n- **No `inject()` misuse**: no `inject()` calls.\n- **No `bypassSecurityTrust*`**: no sanitizer calls.\n- **No standalone/NgModule mixing**: nothing in the diff declares or borrows a module; both components would be assumed standalone or declared consistently by the surrounding code (not visible here).\n\n## One-line bottom line\n\nFlag `CartPage.addItem`'s `this.items.push(item)` as a reference-preserving mutation defeating `CartList`'s `OnPush` change detection; the fix is to assign a new array (`this.items = [...this.items, item]`) so the `@Input` identity changes and the OnPush child re-renders.\n\nI have not edited any code — this is a findings report only.",
+              "outputSha256": "74ef03f68735e10bd1c97ba01b395cf8225084a5b0853c178859adc1a766b449",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 states push mutates the array in place so the same reference is passed to CartList's @Input, and that OnPush only re-checks on a new @Input reference (or own event/async/signal), so CartList never re-renders. Fix is concrete: `this.items = [...this.items, item];`, plus signal alternative. No fail criteria triggered."
+              },
+              "passed": true
+            },
+            {
+              "output": "## Findings\n\n### 1. [High] `CartPage.addItem` mutates the `items` array in place — `CartList`'s `OnPush` never re-renders\n\n**File:** `cart-page.component.ts`, `addItem` (`this.items.push(item)`)\n\n`CartList` is `OnPush`, and its input is bound to `CartPage.items`. Angular's default change-detection for a bound input uses reference equality (`Object.is`) — it checks whether the *reference* passed to `[items]` changed, not whether the array's contents changed. `Array.prototype.push` mutates the existing array and returns the same reference, so `this.items` is referentially identical before and after `addItem` runs. `CartList`'s `OnPush` component is therefore marked clean and is never re-checked, so its `@for` block never re-runs and the new item never renders.\n\nBecause `CartPage` itself has no `changeDetection` declared, it defaults to `ChangeDetectionStrategy.Default` and *will* be checked by Angular's normal cycle and will re-evaluate the `[items]=\"items\"` binding — but the value it produces is the same reference, so the child still won't be dirtied. The bug is a two-part interaction: the in-place mutation is the root cause, and the child's `OnPush` is what turns it from \"works by accident\" into \"never updates.\"\n\n**Fix:** replace the reference instead of mutating, so the input binding's equality check fails and `CartList` is marked dirty:\n\n```ts\naddItem(item: CartItem) {\n  this.items = [...this.items, item];\n}\n```\n\nIf the codebase is signal-first, the stronger fix is to make the source a signal and pass it through, with the template reading `items()` directly:\n\n```ts\nitems = signal<CartItem[]>([]);\n\naddItem(item: CartItem) {\n  this.items.update(list => [...list, item]);\n}\n```\n\nEither fix addresses the actual root cause (reference not changing). A `ChangeDetectorRef.markForCheck()` call or `detectChanges()` inside `CartList` would also make the symptom disappear, but it papers over the mutation and would silently break other consumers of `items` that rely on reference identity (e.g. an `OnPush` sibling component, a `computed()` reading `items`, or an `ngOnChanges` hook that keys off input changes) — do not recommend that path.\n\n### What not to flag here\n\n- The `@for (item of items; track item.id)` block is fine — the `track` expression is present and stable, which is what you want. It isn't the cause; the issue is upstream in the parent.\n- `CartList`'s `@Input() items: CartItem[] = []` default is fine on its own.\n- There is no `inject()` call, no `.subscribe()`, no `bypassSecurityTrust*`, and no `NgModule`/standalone-mixing in this diff, so none of the other categories from `rules/patterns.mdc` / `rules/security.mdc` apply here. Don't inflate the report with checks that had nothing to check.\n- Pure TypeScript correctness (the `push` return value being ignored, etc.) is not a finding — `push`'s return value is unused by design and this isn't a TS bug, it's an Angular change-detection bug. Hand that category to the base reviewer if it comes up; here it doesn't.\n\n### Suggested report line\n\n> `cart-page.component.ts`, `CartPage.addItem`: mutating `this.items` with `.push()` keeps the same array reference, so the `[items]` input to the `OnPush` `CartList` fails Angular's reference-equality check and the child is never re-rendered. Replace the reference (`this.items = [...this.items, item]`) or convert `items` to a signal.\n\nNote: this review is report-only — the fix above belongs to `angular-implementation` or the author, not to this pass.",
+              "outputSha256": "8446baec8baf4d30bc577dd6701c808059f6902c6446d41c3580683db94b60b7",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states push mutates in place and reference is identical before/after (Object.is), so CartList's OnPush is never re-checked; explains CartPage re-rendering still yields same reference so child not dirtied. Concrete fix shown: this.items = [...this.items, item]; plus signal alternative. No fail criteria met."
+              },
+              "passed": true
+            },
+            {
+              "output": "## Finding (high severity): in-place array mutation breaks `OnPush` propagation\n\n**File:** the `CartPage.addItem` method — `this.items.push(item);`\n**What's wrong:** `CartPage` mutates the existing array in place. The `@Input()` binding `[items]=\"items\"` is compared by reference. `push()` does not create a new reference, so Angular's change detection sees the same `CartItem[]` reference on the input and does not propagate a new value to the child.\n\n**Why it matters:** `CartList` is `OnPush`. Under `OnPush`, the child is only re-checked when (a) one of its input *references* changes, (b) an event originated inside the child, or (c) something marks it dirty (async pipe, signal input, `markForCheck`, etc.). Here the event originates in the **parent**, so (b) doesn't apply to the child, and because the array reference is unchanged, (a) doesn't fire either. The result is exactly the reported symptom: `addItem` runs, but `CartList` never re-renders.\n\n**Fix:** replace the reference instead of mutating it:\n\n```ts\naddItem(item: CartItem) {\n  this.items = [...this.items, item];\n}\n```\n\nThat produces a new array reference, so the `OnPush` child sees a changed input and re-renders.\n\n### Notes and secondary observations\n\n- If the child's input were a **signal input** (`input<CartItem[]>()`) or the parent read from a signal, the fix would instead be to update through the signal. The core defect — mutating rather than replacing — is the same.\n- `track item.id` in the `@for` is fine and not part of the problem.\n- One nuance worth stating in the report so the fix isn't misapplied: only the *reference* matters for input propagation into an `OnPush` child. Replacing the reference fixes propagation; it does not, by itself, require the child to be signal-based.\n\n### Not flagged here\n\n- No manual `.subscribe()` calls, so no RxJS teardown concern.\n- No `inject()` outside an injection context.\n- No `DomSanitizer.bypassSecurityTrust*` usage.\n- No standalone/NgModule mixing or impure `computed()` in this diff.\n\nNo code was edited — this is a findings report only; the author (or `angular-implementation`) should apply the reference-replacement fix.",
+              "outputSha256": "a5c859f120644c7698aac9941d6e05dd2ae3aafc87321d9c079a67c2bbac796e",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Criterion 1: answer states push() mutates in place and 'does not create a new reference', same CartItem[] reference on input. Criterion 2: explains OnPush child only re-checks on input reference change/child event, and parent-originated event doesn't apply to child. Criterion 3: concrete fix `this.items = [...this.items, item];` plus signal input note. No fail criteria triggered."
+              },
+              "passed": true
+            },
+            {
+              "output": "**Flag: in-place array mutation on an `@Input` bound to an `OnPush` child.**\n\n**Findings**\n\n1. **`CartPage.addItem` — `this.items.push(item)` mutates the array in place.**\n   - `CartPage` has no `changeDetection` specified, so it defaults to `ChangeDetectionStrategy.Default` — the click handler itself marks `CartPage` dirty, so `CartPage`'s own template binding `[items]=\"items\"` does get re-evaluated.\n   - But the binding value it re-evaluates to is *the same array reference*. Angular's change detection compares the new binding value to the previous one **by reference** for `@Input` bindings. `push()` returns the same `CartItem[]` object, so from Angular's perspective nothing changed on that input.\n   - `CartList` is `OnPush`, so it is only checked when (a) one of its `@Input` bindings changes by reference, (b) an event fires from within its own template, (c) an `async` pipe/signal it consumes emits, or (d) it's explicitly marked for check. Because `items` is the identical reference, condition (a) is never satisfied, and none of the others apply. So `CartList` is skipped entirely and the `@for` block never re-runs — exactly the reported symptom, and it will persist regardless of how many items are added.\n   - Concrete fix: replace the array instead of mutating it —\n     ```ts\n     addItem(item: CartItem) {\n       this.items = [...this.items, item];\n     }\n     ```\n     That produces a new reference, the `@Input` binding is detected as changed, and `CartList` (OnPush) is checked on the next CD pass. (Equivalently, migrate `items` to a `signal`/`input()` and use `items.update(...)` so the signal change notifies the child.)\n\n2. **`CartList.items` — the `@Input` is typed mutable and read via `@for`; the component is correct, but it is silently relying on reference-identity change detection.**\n   - No bug in `CartList` itself: given a *new* `items` reference it would render correctly. Worth noting so the author doesn't \"fix\" the wrong end. Do not recommend switching `CartList` off `OnPush` as the fix — that masks the mutation bug rather than fixing it (and is a performance regression).\n\n**Severity:** The `push` mutation is the high-severity finding — it's the direct cause of the stale render and will keep recurring anywhere else that mutates this array (e.g. remove/clear operations).\n\n**Notes on what *not* to flag here:** there's no subscription to check for teardown, no `inject()` call site, no `bypassSecurityTrust*` call, and no standalone/NgModule mixing in this diff — those categories come back clean. I have not edited any of the above; the fix above is for the author (or `angular-implementation`) to apply.",
+              "outputSha256": "84962db6dae736d4bf46674c171f70df4f52e71490173fe83b2b2813c277d22b",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Finding 1 states push() mutates in place and 'the binding value it re-evaluates to is the same array reference', identity unchanged. It states CartList is OnPush, only checked on new @Input reference/own event/async/signal, so it's skipped. Concrete fix shown: this.items = [...this.items, item]; plus signal/input() alternative. No fail criteria met."
+              },
+              "passed": true
+            },
+            {
+              "output": "## Finding: `OnPush` child never sees a new `@Input` reference — parent mutates the array in place\n\n**File:** `cart-page.ts` (the `addItem` method) — flagged against `CartList`'s `OnPush` contract.\n\n**What's wrong:**\n`CartList` declares `changeDetection: ChangeDetectionStrategy.OnPush`, and its template reads `items`. `CartPage.addItem` does `this.items.push(item)` — an **in-place mutation of the same array reference** that was already bound to `[items]`. The array identity never changes, so from `CartList`'s point of view nothing it depends on has changed.\n\n**Why it matters (the specific mechanism):**\nUnder `OnPush`, Angular only re-renders a component when one of these happens:\n\n1. an `@Input` **reference** changes (compared by `===`, not deep-equality),\n2. an event handler fires **within that component's own view**,\n3. an injected signal/`async` pipe it reads emits, or\n4. it's explicitly marked for check (`markForCheck`, `detectChanges`, `ApplicationRef.tick` on a dirty branch).\n\n`CartPage.addItem` fires an event handler, but that handler belongs to **`CartPage`'s view**, not `CartList`'s. So option 2 does not apply to the child. And the binding `[items]=\"items\"` still evaluates to the *same array object*, so option 1 fails too. Result: `CartList` is never marked dirty, the `@for` never re-runs, and the new item doesn't render — exactly the reported symptom. This is a real bug, not a timing coincidence: it will reproduce every time the mutation doesn't happen to be accompanied by some other check on `CartList`'s branch.\n\nNote the mutation-on-`OnPush` pattern is precisely the case called out in `rules/patterns.mdc` — a value mutated in place rather than replaced with a new reference/signal update.\n\n**Concrete fix (either one):**\n\n- **Replace the reference in the parent** so the `@Input` identity check fails and `OnPush` re-checks:\n  ```ts\n  addItem(item: CartItem) {\n    this.items = [...this.items, item];\n  }\n  ```\n- **Or**, if the shared-mutable-array shape is intentional, mark the child for check after mutation:\n  ```ts\n  // in CartList, exposing a method the parent calls, or via a signal:\n  this.items = [...this.items, item]; // still cleanest\n  ```\n  The idiomatic long-term fix is to back `items` with a `signal` (or pass a new array each time), so the parent's update is what drives the child's re-check.\n\n**Severity:** High — user-visible stale UI (added cart items silently don't appear), the classic `OnPush` + in-place-mutation defect.\n\n---\n\n## Secondary note (lower severity, same category)\n\nWorth flagging while in this diff, though it's not the cause of the reported symptom: `CartList.items` is a bare `@Input()` with no `OnPush`-friendly state seam. If the team standard is signals (per `rules/patterns.mdc`), converting `items` to an `input()` signal would make the identity-vs-content distinction explicit and prevent this class of bug from recurring. Report it as a recommendation, not a defect.\n\n---\n\n## Not present in this diff (checked, clean)\n\n- **RxJS lifecycle:** no `.subscribe()` added — nothing to flag.\n- **`inject()` context:** no `inject()` calls — nothing to flag.\n- **Sanitization:** no `DomSanitizer.bypassSecurityTrust*` — nothing to flag.\n- **Standalone/NgModule mixing:** none introduced.\n- **`computed()` side effects:** none.\n\nNo code was edited — this is a findings report for the author (or `angular-implementation`) to apply.",
+              "outputSha256": "a35937f94312c5e4bd3d8a2471946150cf2f234a0c37968948eaea521276c5e3",
+              "promptSha256": "cffed347705ec6081a6775eb2f3f78b67c5eb0fb6e9b81b01f032efda8284216",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states push mutates in place so same array reference bound to [items], identity never changes (criterion 1). Explains OnPush re-checks only on new @Input reference or event within the child's own view, and that CartPage's handler doesn't make CartList re-check (criterion 2). Names concrete fix: this.items = [...this.items, item]; and signal option (criterion 3). No fail criteria triggered."
+              },
+              "passed": true
+            }
+          ]
+        }
+      ],
+      "verdict": "pass",
+      "scope": "bundled",
+      "skillDigest": "dc2f45c9aaa918c259e365aa043a6b1706422268d952d24c62167a70df864b42",
+      "catalogDigest": "fd9b6a086f61a996f761a68f9e7a58cde1ce62e121f276d70bbef8e05e372f4b",
+      "judgePromptVersion": "2026-09-25.1",
+      "runner": "deepseek",
+      "model": "deepseek-chat",
+      "runnerPromptVersion": "2026-09-25.1",
+      "recordedAt": "2026-09-25T15:54:32.142Z",
+      "judge": "deepseek",
+      "judgeModel": "deepseek-chat"
+    },
+    {
+      "schemaVersion": "1.0.0",
+      "skillId": "angular/angular-build-fix",
+      "strictness": "high",
+      "trials": 10,
+      "triggerAccuracy": {
+        "truePositive": 6,
+        "falsePositive": 0,
+        "positives": 6,
+        "negatives": 6
+      },
+      "evidence": "authored",
+      "scenarios": [
+        {
+          "id": "trigger-positive-1",
+          "kind": "trigger-positive",
+          "prompt": "My Angular template throws 'Property does not exist on type OrderDraft' the moment I run a production build — how do I get it compiling again?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-2",
+          "kind": "trigger-positive",
+          "prompt": "My Angular app throws a NullInjectorError -- 'No provider for OrdersService' -- the instant it bootstraps after a clean build; what's the right way to resolve this DI resolution error?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-3",
+          "kind": "trigger-positive",
+          "prompt": "Fix this Angular error: 'app-order-card' is not a known element",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-4",
+          "kind": "trigger-positive",
+          "prompt": "After wiring a signal into a brand-new @if block, `ng build` now reports a template type-checking error it didn't throw before -- what's the right way to fix this Angular build failure?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-5",
+          "kind": "trigger-positive",
+          "prompt": "My standalone Angular component won't compile because I forgot to import CommonModule for @if — how do I track down and fix missing imports like this?",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-positive-6",
+          "kind": "trigger-positive",
+          "prompt": "Angular build fails with a template type mismatch on this @for loop",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-1",
+          "kind": "trigger-negative",
+          "prompt": "Fix this tsc type error in our Node.js backend with no Angular involved",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-2",
+          "kind": "trigger-negative",
+          "prompt": "Fix this Vue Vite build error about an unresolved SFC import",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-3",
+          "kind": "trigger-negative",
+          "prompt": "Implement a new Angular service that calls this REST API",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-4",
+          "kind": "trigger-negative",
+          "prompt": "Review this Angular component diff for OnPush mutation bugs",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-5",
+          "kind": "trigger-negative",
+          "prompt": "Fix this eslint no-floating-promises failure in our Express service",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "trigger-negative-6",
+          "kind": "trigger-negative",
+          "prompt": "Write TestBed tests for this Angular component's HTTP calls",
+          "strictness": "high",
+          "trials": 1,
+          "passes": 1,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "trigger-rank-fork-family",
+          "status": "ran",
+          "deterministic": true
+        },
+        {
+          "id": "no-dollar-any-template-escape",
+          "kind": "behavior",
+          "prompt": "ng build fails with a template type error: Property 'total' does not exist on type 'OrderDraft' in the template expression `{{ order.total }}`. What's the right way to fix this?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 9,
+          "passRate": 0.9,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "The error is Angular's AOT/Ivy template type checker telling the truth: the template binds `{{ order.total }}`, but the declared type of the `order` member on that component (`OrderDraft`) has no `total` property. The fix is to reconcile the class's type with what the template reads — not to make the compiler stop complaining.\n\n**Step 1 — locate the declaration.** Find the `order` member on the component class whose template contains `{{ order.total }}`. It's typically a signal (`order = input.required<OrderDraft>()`, `order = signal<OrderDraft>(...)`) or a plain field/getter. The type Angular checks against is *that declared type*, not whatever the runtime value happens to be.\n\n**Step 2 — determine which side is actually wrong.** There are only two legitimate outcomes:\n\n- **The template is right, the type is too narrow.** `OrderDraft` genuinely should expose a `total` (e.g. it's a computed field on the draft, or the component is meant to consume an `Order` that has it). Add `total` to the `OrderDraft` interface/class with the correct type (likely `number`, but confirm — a monetary total may be a `Money`/`Decimal`-style type, not a raw `number`). Then rebuild.\n- **The template is wrong, it's reading a property that doesn't belong to a draft.** `OrderDraft` is a pre-order draft with no total by design (totals are computed at submit time, on a different type). Correct the template to read the property that actually holds the value the UI wants — a `subtotal`, a computed `orderTotal()` on the component, or the `Order` type after conversion. Rebuild.\n\nWhichever it is, the change lands on the *actual mismatch*: either the `OrderDraft` type/member definition, or the template expression. Confirm the chosen name and type against where `OrderDraft` is defined and how it's populated (a mapper, an API response type) before editing — don't invent a `total` member that nothing ever assigns.\n\n**What not to do.** Do not wrap the expression as `{{ $any(order).total }}` — `$any()` switches off type checking for that expression, so the template compiles whether or not `total` exists at runtime. Do not set `strictTemplates: false`/`fullTemplateTypeCheck: false` to make this and every similar error across the project vanish. Do not add `NO_ERRORS_SCHEMA`/`CUSTOM_ELEMENTS_SCHEMA`. None of these fix the mismatch; they delete the check that caught it. (The `any`-cast / schema / `strictTemplates` rules above are the specific red flags for this failure class.)\n\n**Verify.** Re-run the exact command that failed (`ng build`, or the project's wrapping script) and confirm it exits 0. `git status` should show changes confined to the file(s) the root cause required — the `OrderDraft` definition or the one template. Report the root cause (e.g. \"`OrderDraft` never declared a `total`; added the computed `total` to the interface and it now matches the template\") rather than just \"build passes now.\"\n\nIf, while tracing it, it turns out `total` does exist but under a different name or on a supertype the component isn't actually narrowing to, that's still the same fix: bring the template expression and the declared type back into agreement at the real root cause.",
+              "outputSha256": "f79d71cc361df1b0e070d8c1071e6c4b92f91ebfeb4eb2b1e1a54d08d9e1c870",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Names both concrete fixes: add `total` to OrderDraft interface/class with correct type, or correct the template to read the existing property (subtotal, computed orderTotal(), or Order type). Shows the corrected expressions/declarations. Explicitly warns against $any(order).total and strictTemplates:false as non-fixes, satisfying no fail criteria."
+              },
+              "passed": true
+            },
+            {
+              "output": "The template is reading `order.total`, but the component's `order` field is typed as `OrderDraft`, which has no `total` member. Fix the actual mismatch, not the compiler.\n\nTo decide the fix, trace `order` back to its declaration in the component class and compare that declared type against what the template assumes.\n\n**If `total` is a real, derived value** (e.g. sum of line items), and `OrderDraft` genuinely has no such member, add the member to the type — as a getter or plain field, whichever matches how it's computed:\n\n```ts\nexport interface OrderDraft {\n  lines: OrderLine[];\n  get total(): number; // or a computed signal/field, per project convention\n}\n```\n\nor, if you're modeling it as a signal field, `total: Signal<number>` with the template reading `{{ order.total() }}` — match the existing signal-vs-field convention in `rules/patterns.mdc`.\n\n**If `total` belongs to a different type than the one in scope**, the template is binding the wrong thing: either the component's `order` should be typed as that richer type, or the template should read the member that actually exists on `OrderDraft`. Pick based on which type correctly models the data, not on which one makes the error disappear.\n\n**If `total` is stale/renamed** — i.e. `OrderDraft` once had it and the member moved or was renamed — update the template expression to the current member name rather than re-adding a duplicate.\n\nWhat **not** to do: wrap it as `{{ $any(order).total }}`, or add an `any` cast, or flip `strictTemplates: false`. All three stop the checker from reporting the mismatch without resolving whether `total` should exist on the bound type at all — they hide the same class of field/type drift elsewhere in the project.\n\nAfter the fix, re-run the same `ng build` command that failed and confirm it exits 0, and confirm `git status` shows changes limited to the type declaration and/or the template expression the root cause actually required.",
+              "outputSha256": "4ef287db5e6ff3fe6238a3415e5272063b230ea4c7f77af912c87ab5fa990c96",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Names concrete fixes: adds `get total(): number` to OrderDraft interface (shown in code block), or changes template to read existing member / `{{ order.total() }}` for signal. Shows corrected type declaration. Explicitly warns against $any(order).total and strictTemplates:false as fixes, not recommending them."
+              },
+              "passed": true
+            },
+            {
+              "output": "The error is Angular's AOT template type-checker telling the truth: the template reads `order.total`, but the component's declared type for `order` — `OrderDraft` — has no `total` member. Fix the mismatch between the class member's type and what the template expects; do not silence the checker.\n\nFirst, determine which side is actually wrong. Look at the component class:\n\n```ts\norder = signal<OrderDraft>(...);   // or @Input() order!: OrderDraft;\n```\n\nand at `OrderDraft`:\n\n```ts\ninterface OrderDraft {\n  id: string;\n  lines: OrderLine[];\n  // ...no `total`\n}\n```\n\nThen pick the one correct fix:\n\n**Case A — `total` is a real computed value that belongs on the order.**\nDon't add a raw `total: number` field that callers could forget to populate. Model it as a computed signal so it's derived, not stored:\n\n```ts\ninterface OrderDraft {\n  readonly id: string;\n  readonly lines: OrderLine[];\n  readonly total: number;   // derived, populated by the factory below\n}\n\n// or, if total is computed from lines in the component:\nreadonly order = computed<OrderDraft>(() => {\n  const draft = this.draft();\n  return { ...draft, total: draft.lines.reduce((sum, l) => sum + l.price * l.qty, 0) };\n});\n```\n\n**Case B — the template is wrong and shouldn't be reading `total`.**\nThe value it wants already lives elsewhere on `OrderDraft` (e.g. `lines`), so fix the template expression to read the member that actually exists, or add a getter on the component that computes it:\n\n```ts\n// template\n{{ orderTotal() }}\n\n// component\nreadonly orderTotal = computed(() =>\n  this.order().lines.reduce((sum, l) => sum + l.price * l.qty, 0)\n);\n```\n\n**What not to do:** do not wrap it as `{{ $any(order).total }}` and do not set `strictTemplates: false`. `$any()` disables type checking for that expression and hides the real mismatch; `strictTemplates: false` turns off template type checking project-wide, so every component in the app loses it, not just this one.\n\nAfter the fix, re-run the exact command that failed:\n\n```bash\nng build\n```\n\nConfirm it exits 0, and confirm `git status` shows changes limited to the component class/template and (if you changed the shape of `OrderDraft`) its definition and the places that construct an `OrderDraft` — no `$any`, no `strictTemplates` downgrade in `tsconfig.json`.",
+              "outputSha256": "3ac247a7708419044811eaa092a0f7438eedcb2a0d48ee1dd7f1f19d1f0c62d6",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Case A shows concrete fix: adds `readonly total: number` to OrderDraft interface plus computed derivation; Case B shows corrected template `{{ orderTotal() }}` with computed getter. Both concrete. Explicitly warns against $any() and strictTemplates:false as fixes, satisfying fail criteria avoidance."
+              },
+              "passed": true
+            },
+            {
+              "output": "The template is telling the truth: `order` is typed as `OrderDraft`, and that type has no `total` member, so `{{ order.total }}` cannot be checked. The fix is to make the template's expectation match the actual type — one of:\n\n**1. The property genuinely belongs on `OrderDraft`** — add it to the type. If the total is derived from line items, expose it honestly rather than inventing a field that can drift:\n\n```ts\ninterface OrderDraft {\n  lineItems: LineItem[];\n  // ...\n  total: number;        // if it's stored/computed on the draft\n}\n```\n\nor, if it's computed, as a getter/signal on the component's order model rather than a plain stringly-typed `any`.\n\n**2. The template is reading the wrong member** — the value exists under a different name or on a different object (e.g. `order.summary.total`, `order.subtotal`, or a `total()` accessor). Point the template at the real member instead of renaming the type to fit a typo.\n\n```html\n{{ order.summary.total }}\n```\n\n**3. The value should be computed in the component** — if \"total\" is a view concern (formatting, tax, currency), derive it in the class and bind to that:\n\n```ts\nreadonly total = computed(() =>\n  this.order().lineItems.reduce((sum, li) => sum + li.price * li.qty, 0)\n);\n```\n\n```html\n{{ total() }}\n```\n\nPick whichever matches where the value actually lives in your domain — the point is to correct the type/member relationship, not to hide the mismatch.\n\n**What not to do:** wrapping it as `{{ $any(order).total }}` or casting the context to `any` disables the type checker for that expression and silently turns a caught bug into a runtime `undefined`; setting `strictTemplates: false` turns it off project-wide. Neither is a fix.\n\n**Verify:** re-run the exact `ng build` command that failed and confirm it exits 0, with no `$any()`/`any` cast or `strictTemplates` downgrade added. Then confirm in `git status` that the change is confined to the file(s) the root cause required — the type definition, the template expression, or the component — and report which of the three cases it was, since the correct fix depends on where the value actually belongs.",
+              "outputSha256": "819245d1d06cafadd43d8ca6b717332d03acc5b30094b7ed5afde4ab5ad3c476",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Names concrete fixes: adds `total: number` to OrderDraft interface (shown), or reads correct member `{{ order.summary.total }}`, or computes via `computed()` getter with template `{{ total() }}`. Shows corrected type declaration and template expressions. Explicitly warns against $any() and strictTemplates:false as non-fixes, not recommending them."
+              },
+              "passed": true
+            },
+            {
+              "output": "The error is telling the truth: the template is reading `order.total` and Angular's strict template type checker resolved `order` to the component's declared `OrderDraft` type, which has no `total` member. Fix the actual mismatch — don't silence the checker.\n\nFirst, confirm the real type by tracing `order` back to the class member the template is bound against (a signal, field, input, or getter). If that declared type is genuinely `OrderDraft`, then either:\n\n1. **`total` is a real, legitimate property of an order** — then `OrderDraft`'s definition is incomplete/wrong. Add the `total` member to the `OrderDraft` type (or whatever it should be, e.g. a `computed`/getter on the class if `total` is derived). This is the right fix when the data actually carries a total and the type just under-describes it.\n\n2. **`total` belongs to a different, richer type** (e.g. the template is really iterating `Order` items, not raw `OrderDraft`s) — then the component member's declared type is wrong. Correct the member's type annotation (`order: Order`) to match what's actually being passed in, rather than changing the template.\n\n3. **`total` isn't a property you control** (e.g. `OrderDraft` is a third-party/generated type) — expose it properly on the component: compute the total in the class (`readonly total = computed(() => ...)`) and bind `{{ total }}`, or map the draft into a view-model type that includes `total` before it reaches the template.\n\nWhat not to do:\n- Don't change the template to `{{ $any(order).total }}` — `$any()` turns off type checking for that expression and hides the real mismatch.\n- Don't flip `strictTemplates: false` in `tsconfig.json` to make the error disappear — that's a project-wide downgrade of template checking, not a fix.\n- Don't add `NO_ERRORS_SCHEMA`/`CUSTOM_ELEMENTS_SCHEMA` — those address unknown *elements*, not property mismatches, and would broadly suppress validation.\n\nAfter the change, re-run the exact command that failed (`ng build` or the project's build script) and confirm it exits 0. Verify `git status` shows changes confined to the type/class file the root cause required, and state the root cause in your report — e.g. \"`OrderDraft` was missing the `total` field\" or \"the component declared `order` as `OrderDraft` when it receives `Order`\" — not just \"build passes now.\"",
+              "outputSha256": "0aa34dc92dddc3d7a2aadd165b34b42277d6486c55e0c336b5d74e86a916a995",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Names concrete fixes: add `total` member to OrderDraft type, correct member type annotation (`order: Order`), or compute `readonly total = computed(...)` and bind `{{ total }}`. Shows corrected declarations/expressions. Explicitly warns against `$any(order).total` and `strictTemplates: false`, so no fail criteria hold."
+              },
+              "passed": true
+            },
+            {
+              "output": "The error is true: the template reads `order.total`, but the type Angular is checking against — the declared type of whatever `order` is on your component — has no `total` member. Fix the actual mismatch; don't hide it.\n\n**First, find out which of these is the case:**\n\n1. **`total` genuinely should exist on `OrderDraft`.** Add it to the model:\n   ```ts\n   export interface OrderDraft {\n     // ...\n     total: number;\n   }\n   ```\n   then make sure whatever produces an `OrderDraft` actually sets it. If `total` is derived, prefer a getter or a computed signal over a field that can drift out of sync, e.g. `readonly total = computed(() => this.subtotal() + this.tax());`.\n\n2. **The template is reading the wrong member.** The field may be named something else (`subtotal`, `totalAmount`, `amount`). Correct the template to the real name — or rename the field to match, if `total` is the better name and all call sites agree.\n\n3. **`order` is the wrong type in the component.** The property may be typed `OrderDraft` but actually hold a richer `Order` that does have `total`. Fix the declaration (`order: Order`), or narrow it properly, rather than reaching past the type.\n\n4. **`order` can be undefined/absent at that point.** If it comes from a route param or async source, guard the access in the template (`@if (order; as o) { {{ o.total }} }`) and type it accordingly — don't let the checker be the only thing noticing a real null hazard.\n\n**What not to do:**\n\n- Wrap it in `$any(order.total)` — that turns off type checking for that expression and leaves the real mismatch in place.\n- Cast to `any` in the template context or loosen `order` to `any` on the component.\n- Set `strictTemplates: false` in `tsconfig.json` — that disables template type checking project-wide, not just here.\n\n**Verify:** re-run the exact `ng build` command that failed and confirm it exits 0, with no `$any()`, no template `any`, and no `strictTemplates`/`fullTemplateTypeCheck` downgrade introduced. `git status` should show only the model/component/template file the root cause required — and your report should state which of the four cases it was, not just that the build passes.",
+              "outputSha256": "c5e1eab9c6e8496d2e79cc623899abe18f159648f95129e988272b92412b8964",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Names concrete fixes: adds `total: number;` to OrderDraft interface (case 1), or corrects template to real member name (case 2), or fixes `order: Order` declaration (case 3), with code shown. Explicitly warns against $any() and strictTemplates:false as fixes, satisfying no fail criteria."
+              },
+              "passed": true
+            },
+            {
+              "output": "Find why `total` isn't on `OrderDraft`, then fix that — don't cast your way around the checker.\n\n`OrderDraft` is the declared type of whatever `order` binds to in the component. The template checker is checking `{{ order.total }}` against that class's actual declared shape. If `total` doesn't exist on `OrderDraft` at all, the template is reading a property that was never there — the real bug is upstream of the template.\n\nCheck these, in order:\n\n1. **Is it a renamed property?** The signal/getter/field may have been renamed (e.g. `totalAmount`, `grandTotal`) and the template wasn't updated. Fix the template expression to match the real member name.\n\n2. **Is it a computed value that was never added?** If `total` is meant to be derived (`items` summed with tax/shipping), add it as a real member on the class — a `computed()` signal if `items` is a signal, or a getter for plain fields — with an explicit return type. Then the template expression is correct as written.\n\n3. **Is it typed too loosely/narrowly?** If `order` is an interface and the concrete object is a class or a broader API response type that does carry `total`, the fix is the type declaration — align the declared type of the member `order` reads from with what actually flows in, rather than adding the property to the wrong type.\n\n4. **Is `order` possibly undefined?** If the error is really about narrowing (e.g. the binding is inside an `@if (order)` that the checker can't follow, or `order` is `OrderDraft | undefined`), fix the control flow or the declared optionality — don't `$any()` it.\n\nThe correct fix is whichever of the above matches the actual mismatch. What you must not do:\n\n- Wrap it as `{{ $any(order).total }}` — that disables type checking for the expression and hides the real mismatch.\n- Add `total?: any` to `OrderDraft` just to make the error go away — that pollutes the domain type and pushes the same failure to runtime (`undefined` rendered, or a downstream `NaN`).\n- Turn off `strictTemplates` — that silences this whole class of error project-wide, not just here.\n\nOnce you've fixed the class member (or the template expression, if the property was genuinely renamed), re-run the exact `ng build` command that failed and confirm it exits 0. Report which of the four causes it was and what changed, not just \"build passes now.\"",
+              "outputSha256": "41775adceeb06a27b8fb6a2ada7187d715e3e164eaa15702684ec647c3f52ff6",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Names concrete fixes: change template to real renamed member (e.g. totalAmount/grandTotal), or add a real member on the class — computed() signal or getter with explicit return type — so `{{ order.total }}` is correct. Shows corrected expressions/declarations. Explicitly rejects $any(order).total and disabling strictTemplates."
+              },
+              "passed": true
+            },
+            {
+              "output": "The fix is to resolve the actual mismatch between the template and the class — not to silence the checker. Here's the workflow applied to your case.\n\n## Step 1: Get the exact error\n\n```bash\nng build\n```\n\nNote the file:line and the specific template expression. Angular is pointing at `{{ order.total }}` in some component template, but the real cause is the declared type of the `order` field on that component.\n\n## Step 2: Classify\n\nThis is a **template type-checking error** under `strictTemplates`. `Property 'total' does not exist on type 'OrderDraft'` means the `order` member's declared type (`OrderDraft`) genuinely has no `total` property. Angular is telling the truth — don't suppress it.\n\n## Step 3: Find the root cause\n\nTrace `order` back to the component class member:\n\n```ts\norder!: OrderDraft;\n```\n\nThen look at `OrderDraft`:\n\n```ts\ninterface OrderDraft {\n  id: string;\n  lines: OrderLine[];\n  // ... no `total`\n}\n```\n\nNow determine *why* the template expects `total`. One of these is true:\n\n1. **`total` should exist on `OrderDraft`** but the interface is missing it (or it's been renamed/removed). Fix the interface.\n2. **`total` is a computed derived value** that should be exposed by the component (or a getter on the class), not stored on `OrderDraft`.\n3. **The template is binding the wrong member/path** — e.g. `total` lives on a related type (`order.summary.total`) or on a different field.\n\nFind which of these matches the actual data model before editing anything.\n\n## Step 4: Apply the smallest correct fix\n\nPick the one that matches the real cause:\n\n**If `total` belongs on `OrderDraft`:**\n\n```ts\ninterface OrderDraft {\n  id: string;\n  lines: OrderLine[];\n  total: number; // added — matches what the API/data actually returns\n}\n```\n\n**If `total` is derived:** don't stuff it into the data type. Expose it from the component instead — ideally as a computed signal, since `order` is likely a signal:\n\n```ts\nreadonly order = input.required<OrderDraft>();\n\nreadonly orderTotal = computed(() =>\n  this.order().lines.reduce((sum, l) => sum + l.lineTotal, 0)\n);\n```\n\n```html\n{{ orderTotal() }}\n```\n\n**If the path is simply wrong:** correct the template expression to read the property where it actually lives (`{{ order.summary.total }}`), after confirming that's the real shape.\n\nDo **not**:\n- wrap the expression as `{{ $any(order).total }}` — that disables checking for the expression instead of fixing it;\n- set `strictTemplates: false` or `fullTemplateTypeCheck: false` in `tsconfig.json` — that turns off template checking project-wide;\n- cast `order` to `any` in the class to make the mismatch disappear.\n\n## Step 5: Verify and report\n\n```bash\nng build\n```\n\nConfirm exit 0. Report the root cause, e.g.: *\"`OrderDraft` declared no `total`; the template read a computed total that was never exposed. Added a `computed` signal `orderTotal` on the component and bound to it.\"* — not just \"build passes now.\"\n\nAlso check `git status`: changes should be confined to the component/interface the root cause actually implicates.\n\n## Red flags to avoid\n\n| Rationalization | Why it's wrong |\n|---|---|\n| `$any(order).total` / template `any` cast | Disables type checking for that expression; hides the real mismatch |\n| `strictTemplates: false` | Silences this class of error for every component in the project |\n| Adding `total` to the interface \"just to make it compile\" when it's actually derived | Pollutes the data contract with a value the API doesn't return; the next consumer of `OrderDraft` inherits the lie |\n\nThe right fix always ends with the template and the class agreeing on a type that reflects the real data model — the compiler is reporting a real inconsistency, not an obstacle.",
+              "outputSha256": "054af30865a7915fe50b27de4902cc686a827b1bfc60077982ea1a65500863e8",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Names concrete fixes: adds `total: number;` to OrderDraft interface (Step 4), shows computed signal `orderTotal` with template `{{ orderTotal() }}`, and corrected path `{{ order.summary.total }}`. Explicitly warns against $any() and strictTemplates:false. No fail criteria met."
+              },
+              "passed": true
+            },
+            {
+              "output": "The right fix is to reconcile the template with the actual type of `order` — not to cast it away.\n\n`Property 'total' does not exist on type 'OrderDraft'` means Angular's template type-checker resolved the component member `order` to type `OrderDraft`, and that type genuinely has no `total` member. So one of two things is true, and you need to find out which before touching anything:\n\n1. **`OrderDraft` is missing a real property the app needs.** If `order` is supposed to carry a total, add it to the `OrderDraft` definition (interface or class) and make sure whatever populates `order` actually sets it. A type error like this is often the compiler correctly catching that the total was never modeled.\n\n2. **The template is reading the wrong member, or the wrong shape is bound.** Perhaps the component exposes the total under a different name (e.g. `order.totalAmount`), or `order` is meant to be a richer type (`Order` extending/derived from `OrderDraft`) and the component's `order` field is typed too narrowly. Fix the class member's declared type or the template expression to match the real shape — e.g. type `order` as `Order` if it is in fact an `Order`, or reference `order.totalAmount`.\n\nIn both cases the change is to the class member's type or the template expression, whichever is the true source of the mismatch. This is a real mismatch between the template and the declared type — trust it and correct the underlying member, don't suppress it.\n\nDo **not**:\n\n- Wrap it as `{{ $any(order).total }}` or cast `order` to `any` in the template — that disables type checking for the expression and hides the mismatch rather than fixing the class/member type.\n- Set `strictTemplates: false` (or re-enable `fullTemplateTypeCheck: false`) in `tsconfig.json` — that silences this whole class of error for every component in the project, which is a project-wide policy downgrade, not a fix.\n- Add `NO_ERRORS_SCHEMA`/`CUSTOM_ELEMENTS_SCHEMA` — that's for unknown elements/attributes, the wrong tool here, and it masks future template errors too.\n- Defensively make the property optional (`total?: number`) just to make the error go away, unless the domain genuinely allows an order with no total — in which case the template also needs to handle the undefined case (`{{ order.total ?? 0 }}` or an `@if`), which is a real design decision, not a compiler appeasement.\n\nAfter the fix, re-run the exact command that failed (`ng build`, or the project's wrapping build script) and confirm it exits 0. Report the root cause — which of the two situations it was — and the change made, not just \"build passes now.\" Keep the diff confined to the type definition, the component member's type, or the template expression that was actually wrong.",
+              "outputSha256": "51cc38e0c50aacfb07f6ebdac7ff8c0f761e6a8d1b12fa24151be329f6b6ad18",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "fail",
+                "reason": "Criterion 2 requires showing the corrected type declaration or template expression. The answer only names directions (\"add it to the OrderDraft definition\", \"reference order.totalAmount\") without showing any concrete declaration or expression. It also never commits the $any/strictTemplates anti-patterns, but the missing concrete fix fails pass criterion 2."
+              },
+              "passed": false
+            },
+            {
+              "output": "Don't silence it — the template is telling the truth about a real mismatch between the template expression and the class member's declared type.\n\n**Steps:**\n\n1. **Reproduce and locate the exact source.** Run the project's build script and find the `file:line` Angular attributes the error to. Note that a template type error is reported for the file where the expression sits, which is often not where the offending type is declared.\n\n2. **Trace `order` back to its declaration.** In the component class, find the field/signal/getter the template binds to as `order`. Angular type-checks against its *actual* declared type — so look at what `OrderDraft` actually declares, not what you assumed it should have.\n\n   A `{{ order.total }}` error means one of:\n   - `order` is typed `OrderDraft` but the object actually flowing in is a wider/narrower type (e.g. an `Order` with a `total`, declared as `OrderDraft` in the field).\n   - `OrderDraft` genuinely lacks a `total` member — the template and the interface disagree about the shape.\n   - `total` exists but is optional (`total?: number`) and the template dereferences it without narrowing, or is a method (`total()`) accessed as a property.\n\n3. **Fix the actual mismatch** — one of:\n   - Add/narrow the `total` member on `OrderDraft` if it legitimately belongs there and is just missing.\n   - Correct the field's declared type in the component (e.g. type it as the narrower type that actually has `total`, or union it) so the template's binding target matches what's rendered.\n   - If `total` is optional, narrow in the template with `@if (order.total; as total) { {{ total }} }` or update the class to guarantee it before the template reads it.\n   - If it's a method, call it: `{{ order.total() }}`.\n\n4. **Do not do any of these** — they only make the compiler stop complaining:\n   - Wrap it as `{{ $any(order).total }}` — disables type checking for that expression.\n   - Cast `order` to `any` (in the class or template context) to escape the checker.\n   - Flip `strictTemplates: false` in `tsconfig` — turns this check off project-wide, not for this one error.\n   - Add `NO_ERRORS_SCHEMA`/`CUSTOM_ELEMENTS_SCHEMA` — that's for unknown *elements*, not a wrong property, and it suppresses all element validation in the module.\n\n5. **Verify.** Re-run the exact command from step 1 and confirm it exits 0. Confirm with `git status` that changes are confined to the files the root cause required (the `OrderDraft` declaration and/or the component field). In your report, state the actual mismatch — e.g. \"`order` was declared as `OrderDraft` but the bound value is an `Order` whose `total` lives on the wider type; narrowed the field's type\" — not merely \"build passes now.\"",
+              "outputSha256": "94255c8f62ffd1b10c9142aba58e639a704034185f27e8e8c65bd5b7acf82f0d",
+              "promptSha256": "ed07c1cf94b12335690f95f4320102ddf2816a0b0dc3931a5336ddeedf110e81",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Step 3 names concrete fixes: 'Add/narrow the total member on OrderDraft', correct the field's declared type, narrow optional total with @if, or call method {{ order.total() }}. Step 4 explicitly warns against $any(order).total and strictTemplates:false as fixes, satisfying fail criteria avoidance. Shows corrected expressions like {{ order.total() }}."
+              },
+              "passed": true
+            }
+          ]
+        },
+        {
+          "id": "fix-missing-provider-not-new",
+          "kind": "behavior",
+          "prompt": "The ng build itself succeeds, but the app throws at bootstrap: NullInjectorError: No provider for OrdersService!. What's the correct fix?",
+          "strictness": "high",
+          "trials": 10,
+          "passes": 10,
+          "passRate": 1,
+          "passAtK": 1,
+          "grader": "judge",
+          "status": "ran",
+          "trialRecords": [
+            {
+              "output": "A `NullInjectorError: No provider for OrdersService!` at bootstrap means the injector that's constructing whatever injects `OrdersService` has no provider for it anywhere up the tree. The build succeeding tells you nothing here — this is a runtime DI resolution failure, not a compile one. The correct fix is to add the missing provider at the right scope. Find where `OrdersService` *should* be provided and make it reachable; do not `new` it up as a workaround.\n\n**Step 1 — find the injection point and the intended scope.**\n\nLocate whoever injects it (`inject(OrdersService)` or a constructor param), then look at `OrdersService`'s own decorator:\n\n```ts\n@Injectable({ providedIn: 'root' })\nexport class OrdersService { ... }\n```\n\nIf that `providedIn` line is present and correct, the error means this component/service is being created in an injector that is *not* a descendant of root's injector — typically a component instantiated via `createComponent` outside a routed/module context, a service constructed manually, a standalone component rendered in a test, or a lazily-loaded route/module whose provider lookup doesn't reach where you think it does. If the `providedIn` line is *missing or scoped* (e.g. it was intentionally `providedIn: 'any'` or provided in a specific module/route's `providers`), the lookup isn't finding that scope.\n\n**Step 2 — add the provider at the correct scope, matching intent.**\n\nMatch the fix to how the service is meant to live, not just to wherever the error appears:\n\n- **App-wide singleton** — the common case. Ensure `@Injectable({ providedIn: 'root' })` on the class. This is the smallest correct fix and requires no other file to change:\n\n  ```ts\n  @Injectable({ providedIn: 'root' })\n  export class OrdersService { ... }\n  ```\n\n- **Scoped to a feature/route** — if the service is deliberately not root-provided (per-route state, lazy chunk), add it to that route's or component's `providers` array at the boundary that owns it, and confirm the injecting component sits *below* that boundary in the injector tree:\n\n  ```ts\n  export const routes: Routes = [\n    { path: 'orders', component: OrdersComponent, providers: [OrdersService] },\n  ];\n  ```\n\n  or, for a component-scoped instance:\n\n  ```ts\n  @Component({ selector: 'app-orders', providers: [OrdersService], ... })\n  ```\n\n- **NgModule-based project** — add it to the `providers` array of the module that should own the instance (root module for app-wide).\n\nThe bug is almost always one of: the service lost its `providedIn: 'root'`, it's injected in a component that lives outside the route/module where it's provided, or it's injected in a unit-test/`createComponent` path with no matching provider. Trace *which* injector is resolving this instance and put the provider there — don't add `OrdersService` to `providers` on a random component just because that's where the error surfaced, or you'll get a second instance rather than the singleton you expected.\n\n**Step 3 — do not do these instead:**\n\n- Do not replace `inject(OrdersService)` / the constructor param with `new OrdersService(...)`. That bypasses DI entirely: no TestBed override in tests, no respect for the service's real scope, no control over its own dependencies (which may in turn fail to resolve or silently get a fresh copy).\n- Do not wrap the injection in a try/catch or an `Injector.get(OrdersService, null)` with a fallback `null`, and do not reach for `runInInjectionContext` to paper over an injection happening outside a context — that hides the same missing provider and defers the failure.\n\n**Step 4 — verify.**\n\n- Re-run the app (the command from your `package.json` start script) and confirm it bootstraps past the point that threw.\n- Confirm you actually added a provider — re-read `git diff` to check no `new OrdersService` appears where the injection was.\n- If the intended scope is feature/route, confirm the injecting component is genuinely a descendant of the injector that now provides it; a provider added on the wrong side of the boundary won't be seen and the error will persist or reappear on navigation.\n\n**Report** the root cause (e.g. \"`OrdersService` had no `providedIn` and was injected from a lazy route that didn't provide it\"), the scope you chose and why, and the file changed — not just \"app starts now.\" If the fix diverges from what the service's own decorator implies, call that out explicitly.",
+              "outputSha256": "3d44fefbc6d9e8a388cc2a6e50197e2ef06dbdf40eef198c40ce559e321918f3",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Pass 1: explicitly shows @Injectable({ providedIn: 'root' }) on OrdersService and route/component providers arrays. Pass 2: states error means the injector has no provider for OrdersService anywhere up the tree, a runtime DI resolution failure. Fail criterion avoided: Step 3 explicitly says do not replace inject() with new OrdersService(...)."
+              },
+              "passed": true
+            },
+            {
+              "output": "A \"No provider for OrdersService\" error at bootstrap means the injector tree that resolves the component (or another service) which injects `OrdersService` has no `OrdersService` provider anywhere above it. The fix is to make the provider reachable from that injection point — not to construct the service manually. Here is how to locate the right scope and the correct change.\n\n## 1. Find the injection site\n\nSearch for where `OrdersService` is requested:\n\n```bash\ngrep -rn \"OrdersService\" src/\n```\n\nLook for either an `inject(OrdersService)` or a constructor parameter `private orders: OrdersService`. That consumer — and every component/service/route above it in the injector hierarchy — is the path that must be able to see a provider.\n\n## 2. Check the service's own decorator\n\nOpen `orders.service.ts` and inspect `@Injectable(...)`:\n\n```ts\n@Injectable({ providedIn: 'root' })\nexport class OrdersService { ... }\n```\n\nIf `providedIn` is missing, or is present but scoped to a different module than the one in the consuming path, that alone can be the cause. If the service is a legitimately lazy/feature-scoped service, `providedIn: 'root'` may not be appropriate — do not blindly add it; see step 3.\n\n## 3. Pick the correct provider scope\n\n- **App-wide / singleton service** — it should be registered root-level. Either restore `providedIn: 'root'` on `@Injectable`, or list it in the root injector's `providers` (standalone `bootstrapApplication` → the app config's `providers` array; NgModule app → `AppModule`'s `providers`).\n- **Component-scoped service** — provide it in the consuming component's `@Component({ providers: [OrdersService] })` when the instance is meant to live and die with that component.\n- **Route-scoped service** — provide it on the route via `providers: [OrdersService]` in the route config, if the intended lifetime is that lazy-loaded route.\n- **Feature/lazy module** — provide it in the feature module's `providers` and make sure that module is actually loaded on the path that bootstraps the failing component. A provider in a lazily loaded module is invisible to a component resolved by the root injector; that mismatch is a common cause of exactly this error.\n\nThe key distinction: a root-injector consumer (e.g. `AppComponent` or a root-provided service) cannot see a provider registered only inside a lazy module or a component subtree. Move the provider to a scope that is an ancestor of the failing injection point, or move the injection to a consumer inside the scope where the provider already exists.\n\n## 4. Verify\n\nRe-run the exact failing bootstrap path:\n\n```bash\nng serve\n```\n\nor the production-equivalent `ng build && <serve command>`. Confirm the `NullInjectorError` is gone and the app reaches its first render — not merely that the build compiles (the build was already passing; it cannot detect this class of runtime DI error, which is why it must be tested by actually bootstrapping).\n\n## What not to do\n\n- Do **not** replace injection with `new OrdersService(...)` in the consumer. That bypasses Angular DI entirely — you lose TestBed `providers` overrides in tests, lose singleton/instance sharing, and lose the service's declared lifetime. It also compounds: every transitive dependency of `OrdersService` would then need manual wiring.\n- Do **not** add a provider in a location that isn't on the failing injector's ancestor path (e.g. dropping it into a component that is a *sibling* of the failing one) — that changes nothing for this error and hides the real scope question.\n- Do **not** weaken DI diag\n\nconfig (e.g. `providedIn: 'root'` on everything indiscriminately) just to stop the error; that changes the service's actual lifetime, which may be wrong for a genuinely component- or route-scoped service.\n\n## Report\n\nState the root cause explicitly — e.g. \"`OrdersService` lacked a provider on the injector path resolving `CheckoutComponent`; its `@Injectable` had no `providedIn` and it was not listed in any ancestor `providers` array\" — along with the exact scope you registered it in and why that scope matches the intended service lifetime. \"App boots now\" alone is not the fix report; the scope decision is the substantive part.",
+              "outputSha256": "4c9115cee5e008946a28be4b3351a9b113a1eef6a5c9e13d4a0e79e1b6efa74f",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Step 2/3 concretely show `@Injectable({ providedIn: 'root' })` and providers arrays (component/route/app config). Step 1 explains the error means no provider on the injector path resolving the consumer, not a broken class. 'What not to do' explicitly rejects `new OrdersService(...)`, so no fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "The build succeeding is expected here — this is a runtime DI resolution failure, not a compile/AOT one, so `ng build` has nothing to complain about. The error means the injector tree that resolves the component (or service) trying to inject `OrdersService` has no matching provider anywhere above it.\n\nFirst, find where `OrdersService` is (or should be) provided:\n\n- Check `OrdersService`'s own `@Injectable` decorator. If it says `@Injectable()` with no `providedIn`, it is not registered with any injector on its own, and nothing that injects it will resolve unless some component/route/module in the path adds it to a `providers` array.\n- Check the injecting site — the component/route/module that calls `inject(OrdersService)` or declares it in a constructor. Trace the injector path: standalone component's own `providers`, its route's `providers`, lazy-loaded route boundaries, and any parent module's `providers`.\n\nThen apply the smallest correct fix at the correct scope:\n\n- If `OrdersService` is meant to be app-wide, change its decorator to `@Injectable({ providedIn: 'root' })`. This is the right fix for a stateless/shared service and gives a single app-level instance.\n- If it is meant to be scoped to a feature (a specific route or component subtree), add it to that scope's `providers` array instead — e.g. the lazy route's `providers`, or the consuming component's `providers`, so each scope gets its own instance. Pick based on intended lifetime, not just \"make the error go away.\"\n\nDo not fix this by constructing the service with `new OrdersService(...)` instead of injecting it. That bypasses Angular's DI entirely: you lose TestBed provider overrides in tests, you lose the service's actual configured scope and lifetime, and any dependencies `OrdersService` itself injects will not be resolved either. The error is the injector correctly telling you that no provider is reachable — restore the provider.\n\nAlso watch for the related case where the missing provider is one of `OrdersService`'s own dependencies, not `OrdersService` itself: if you add the provider for `OrdersService` and a new `No provider for <its dependency>` error appears, the same reasoning applies one level up the chain — fix that provider at its correct scope too.\n\nVerify by bootstrapping the app (serve it, or run the test that mounts the component) and confirming the `NullInjectorError` is gone and the component that injects `OrdersService` actually initializes. Report the root cause — the missing or mis-scoped provider — and the scope you added it at, not just \"it boots now.\"",
+              "outputSha256": "b2cf18c58359905290ebf4de39d8e15ff292f694480782ba43b872c0fd696c7e",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states the error means no injector in the resolution path has a provider for OrdersService (\"the injector tree ... has no matching provider anywhere above it\"), and gives the concrete fix: change decorator to @Injectable({ providedIn: 'root' }) or add to the consuming component's/route's providers array. It explicitly warns against new OrdersService(...), so no fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "Fix the missing provider, not the injection site. A `NullInjectorError: No provider for OrdersService!` thrown at bootstrap means the injector tree that bootstraps the app has no reachable provider for `OrdersService` — the class itself is fine, it's just not registered anywhere the injector can find it.\n\nFind where it should be provided:\n\n- Check `orders.service.ts` for its `@Injectable({ providedIn: ... })` decorator. If it's bare `@Injectable()` with no `providedIn`, that's the most likely root cause.\n- If it's intentionally not tree-shakable — e.g. it depends on request-scoped or route-scoped state — check the `providers` arrays along the injection path: the bootstrapped component's `@Component({ providers: [...] })`, the relevant route's `providers`, or the `NgModule`'s `providers` (in an NgModule-based app). A \"No provider\" error means every injector above the injection site lacks a match.\n\nApply the smallest correct fix at the right scope:\n\n- If the service is genuinely app-wide, add `providedIn: 'root'` to its `@Injectable(...)` decorator. This is the correct fix for the common case and preserves tree-shaking and the singleton semantics DI is meant to give you.\n- If it's deliberately scoped (a fresh instance per route/component), add it to that specific scope's `providers` array instead — root-providing it would change its lifetime semantics, so match the intended scope rather than defaulting to `'root'`.\n\nDo not:\n\n- Replace `inject(OrdersService)` / constructor injection with `new OrdersService(...)` at the call site. That bypasses Angular's DI entirely: TestBed can no longer override it, the service's own dependencies (if any) won't resolve, and you've hidden the real cause rather than fixing it.\n- Add it to some unrelated component's `providers` just to make the error go away — that creates a separate instance with different lifecycle than intended and can mask the actual missing scope.\n\nVerify:\n\n- Re-run the bootstrap path (the failing command from before, or `ng serve` and load the app); confirm it now boots without the `NullInjectorError`.\n- Confirm no `new OrdersService(...)` was introduced and the change is confined to the service decorator or the correct `providers` array.\n- Report the root cause explicitly — \"the service had no `providedIn` and wasn't in any `providers` array\" — not just \"it boots now.\"",
+              "outputSha256": "909fddce00b54ebc155c263ce1b3f9786b5f75497c9f9605968bae6a4d022e3e",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states fix is to provide the service: adds `providedIn: 'root'` to @Injectable decorator, or adds to the consuming component's/route's/NgModule's providers array. Explains error means injector tree has no reachable provider for OrdersService and 'the class itself is fine.' Explicitly warns against `new OrdersService(...)`, so no fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "Your build succeeding while bootstrap throws is the expected signature of a DI resolution error — `ng build` (AOT) only type-checks and compiles, it never instantiates the injector tree, so a missing provider is invisible to it and only surfaces at runtime when the root component's injector context is created. Treat the build result as irrelevant here; the failure is Step 2's \"DI resolution error\" class and the workflow starts from the runtime stack trace, not the exit code.\n\n**Root cause first.** `No provider for OrdersService` means the injector context that is resolving whatever injects `OrdersService` has no matching provider anywhere above it in that context's injector hierarchy — not that the class is broken. Find the actual injector context: locate every place `OrdersService` is injected (via `inject()` or a constructor parameter) and identify *which* component/directive/route/service does the injecting. That injector's own context is what must have a reachable provider. This matters because the correct fix depends on the intended lifetime of the service, and the two common cases look identical in the error text:\n\n- **App-wide singleton** — `OrdersService` sits outside the `providedIn: 'root'` scope.\n- **Component- or route-scoped instance** — a fresh instance is intended per feature, e.g. a routed detail view.\n\n**Apply the smallest correct fix at Step 4 — never a `new` workaround.**\n\n- If `OrdersService` should be a single app-wide instance, add or restore `providedIn: 'root'` on its own `@Injectable` decorator:\n  ```ts\n  @Injectable({ providedIn: 'root' })\n  export class OrdersService { /* ... */ }\n  ```\n  This is the preferred fix because it keeps the service tree-shakable and reachable from any injector context without wiring.\n\n- If a fresh instance per feature is intended, provide it at the narrowest correct scope instead:\n  - For a route: add `providers: [OrdersService]` to that route's config.\n  - For a component subtree: add `providers: [OrdersService]` to that `@Component`'s metadata.\n  Do not reach for the route/component scope reflexively — only when a distinct instance is actually wanted.\n\n- If the service *is* already provided somewhere but still reports missing, the real defect is a broken injector path: check that a lazily loaded route or feature module did not create a new injector context that the intended provider sits outside of, and move the provider to the scope that the injecting context can actually reach. Also confirm nothing is injecting it from a plain function, a static initializer, or an `APP_INITIALIZER`/factory that runs outside any injector context — that is an injection-context error, not a missing provider, and the fix is to obtain the service through a valid injector (e.g. `inject()` at a supported injection point) rather than constructing it.\n\n**Verification.** Per the skill's checklist: re-run the exact command that reproduced the failure — but here the reproducing command is *app bootstrap*, not `ng build`, so confirm the app now bootstraps and the injector resolves `OrdersService` without the `NullInjectorError`. Do not claim the fix done because `ng build` exits 0 — it did the whole time and never exercised DI. Additionally confirm no `new OrdersService(...)` was substituted for the missing provider, no schema/strictness downgrade was added, and `git status` shows changes confined to the file the root cause required (the service's `@Injectable` decorator *or* the specific route/component `providers` array — not both). Report the root cause plainly: the provider was absent from the injector context that resolves the injection site, and the fix restored it at the correct scope.",
+              "outputSha256": "a5b7532e012d17c6c8e0f91814eb6a0a875f5a4c11db4c734441f2cecda88133",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states the fix is to provide the service: shows `@Injectable({ providedIn: 'root' })` on OrdersService and `providers: [OrdersService]` on route/component. Explains error means the injector context resolving the injection site has no matching provider above it, 'not that the class is broken'. Explicitly rejects the `new OrdersService(...)` workaround."
+              },
+              "passed": true
+            },
+            {
+              "output": "Add the missing provider at the scope that matches how `OrdersService` is actually used — don't work around it by constructing it manually.\n\nConcretely, in order of preference:\n\n1. **If it should be app-wide (the common case for a data/service layer):** mark it injectable at the root —\n   ```ts\n   @Injectable({ providedIn: 'root' })\n   export class OrdersService { ... }\n   ```\n   That registers it in the root injector, reachable from any component bootstrapped under it. This is the smallest correct fix and the one to reach for first.\n\n2. **If it's genuinely scoped to one feature/route/component** (its lifetime should end with that scope, or it holds per-scope state): add it to the `providers` array at that scope — the lazily-loaded route's `providers`, or the consuming component's `@Component({ providers: [OrdersService] })`. Don't reach for `providedIn: 'root'` just because it's convenient if the service is meant to be per-scope.\n\nThe error means the injector tree that resolved the failing component/route has no matching provider anywhere above it — so the fix is to make a provider reachable on a path that includes that component, at the correct scope.\n\n**What not to do:** don't construct it with `new OrdersService(...)` where it's injected. That bypasses Angular's DI — TestBed can no longer override it in tests, the service no longer shares the singleton/scope Angular intended, and any of its own injected dependencies go unresolved. It makes the error go away by not using DI, not by fixing DI. Similarly, don't add it to a random unrelated module's `providers` just to see the error vanish; put it where the consumers actually are.\n\nOne diagnostic to run before fixing: check whether the failing consumer is a lazily-loaded route. If `OrdersService` is only added to an eagerly-loaded module's providers, the lazy route's injector can't see it — the correct fix is then a provider on the lazy route or `providedIn: 'root'`, not adding it to more eager modules.\n\nVerify by re-running the app boot (and `ng build` if a build was involved) and confirming the component that injects `OrdersService` now instantiates. Report which scope you provided it at and why that scope matches its intended lifetime, not just \"no provider error gone.\"",
+              "outputSha256": "8c671f050108081de5ae23289b59a1931ffe02deea5bff0c634ac7adbd215e3b",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer gives concrete fixes: `@Injectable({ providedIn: 'root' })` on OrdersService and adding to route/component `providers` array. It explains the error as the injector tree having no matching provider above the failing component, not a broken class. It explicitly warns against `new OrdersService(...)`, satisfying no fail criterion."
+              },
+              "passed": true
+            },
+            {
+              "output": "Find where `OrdersService` *should* be provided and add it there — the fix depends on the intended scope:\n\n1. **App-wide singleton (the common case)** — add to the service itself:\n```ts\n@Injectable({ providedIn: 'root' })\nexport class OrdersService { ... }\n```\nThis puts it in the root injector, reachable from every component and lazily-created route.\n\n2. **Scoped to one feature/route** — add it to that route's or component's `providers`:\n```ts\nproviders: [OrdersService]\n```\nUse this only when each route/component instance genuinely needs its own instance; it will *not* fix an injection happening elsewhere in the tree.\n\n3. **NgModule-based project (not standalone)** — add `OrdersService` to the relevant module's `providers` array (or rely on `providedIn: 'root'` as above).\n\nTrace the actual injection path first: find the `inject(OrdersService)` / constructor injection that's throwing, then check whether any injector above that component resolves it. That tells you whether the right scope is root, a route, or a module — don't add it to more than one place \"just in case,\" since that changes the service's instance count.\n\n**What not to do:**\n- Don't replace `inject(OrdersService)` with `new OrdersService(...)` — that bypasses DI, breaks TestBed overrides in tests, and ignores the service's dependencies.\n- Don't add a throwaway `providers: [OrdersService]` to whatever component happens to throw if the service is meant to be a shared singleton — that creates per-instance copies and a fresh state bug later.\n\nAfter the change, re-run the app (or `ng serve`) and confirm it bootstraps past this error. Note that `ng build` succeeding is expected here — AOT catches template type errors, but a missing DI provider is a runtime resolution failure, which is exactly why it only surfaces at bootstrap.",
+              "outputSha256": "aa06e17b527bcb9c331ace60e496137e4bb0d65b3bbbdaad7b598be1fa97da9d",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer gives concrete fixes: `@Injectable({ providedIn: 'root' })` on OrdersService (option 1) and adding OrdersService to a route's/component's/module's `providers` array (options 2-3). It explains the error as a resolution-path issue: 'check whether any injector above that component resolves it' and notes missing DI provider is a runtime resolution failure, not a broken class. It explicitly warns against `new OrdersService(...)`, satisfying no fail criterion."
+              },
+              "passed": true
+            },
+            {
+              "output": "A `NullInjectorError: No provider for OrdersService!` at bootstrap means the injector that's instantiating whatever injects `OrdersService` has no reachable provider for it. The fix is to make `OrdersService` resolvable in the injector tree that actually constructs its consumer — not to construct it manually or bypass DI.\n\nWork through it:\n\n**1. Find where it's injected and from which injector.** Locate the first class that injects `OrdersService` (via `inject(OrdersService)` or a constructor parameter). That class's own instantiation context is the injector that's failing — a component created by the root injector, a routed component created by a route injector, a lazily-loaded module's injector, etc.\n\n**2. Apply the matching fix for that context:**\n\n- **The common case — a root-provided service:** add `providedIn: 'root'` to `OrdersService`'s own `@Injectable({...})` decorator, and make sure it's actually a `@Injectable()`-decorated class that *has* that decorator (forgetting it, or a plain `@Injectable()` with no `providedIn` and no `providers` entry anywhere, produces exactly this error).\n\n```ts\n@Injectable({ providedIn: 'root' })\nexport class OrdersService { ... }\n```\n\n- **The service is meant to be scoped to a feature/lazy route or a single component:** instead of `providedIn: 'root'`, add it to the correct `providers` array — the standalone component's `@Component({ providers: [...] })`, the route's `providers`, or the `NgModule`'s `providers` — whichever injector instantiates the consumer. Don't drop it at root if the intended scope is narrower.\n\n- **The consumer is created by a route/lazy-module injector that the service's scope doesn't reach:** move the provider (or `providedIn`) to a scope at or above the consumer's injector. A service provided only in a sibling lazy module isn't visible to a component in a different lazy module.\n\n- **The service is injected into a class that isn't itself DI-created** (e.g. a plain class instantiated with `new`, where `inject()` is called outside any injection context): that's the real bug — either make the consumer DI-created, or pass the service in explicitly; do not \"fix\" it by `new OrdersService()`.\n\n**3. Verify.** Re-run the app (`ng serve` or however bootstrap was reproduced) and confirm it boots with no `NullInjectorError`. If there's a test suite, confirm `TestBed` tests for that consumer still resolve the service.\n\n**Red flags to avoid:**\n- Do **not** replace the injection with `new OrdersService(...)` — that drops the service out of DI entirely (no TestBed provider overrides, no respecting its actual scope, breaks its own dependencies).\n- Do **not** add a dummy/stub provider (`{ provide: OrdersService, useValue: {} }`) just to silence the error — that hides the real missing/mis-scoped provider and hands the consumer a broken object.\n- Do **not** slap the provider onto an unrelated injector just because it happens to be convenient; put it at the scope the design intends, which is the smallest scope that still reaches every consumer.\n\nReport the root cause specifically: state *which* class failed to resolve it and *why* no provider was reachable (missing `providedIn: 'root'`, missing from the right `providers` array, or consumer instantiated outside DI) — \"build passes now\" is not an acceptable report here, since the build already passed and the actual fault was at runtime injector resolution.",
+              "outputSha256": "80fea728381660c987a8a961d474c997222b1eba58cefd630ef67925afec3a69",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer states the error means no reachable provider in the injector tree, not a broken class ('the injector ... has no reachable provider for it'). It concretely shows the fix: `@Injectable({ providedIn: 'root' })` on OrdersService, and adding it to the component's/route's/NgModule's providers array. It explicitly warns against `new OrdersService(...)` as the fix, so no fail criterion holds."
+              },
+              "passed": true
+            },
+            {
+              "output": "Short answer: this is a **DI scoping bug**, not a build bug — `ng build` succeeding just means the wiring compiled. Find where `OrdersService` is injected, then provide it at the narrowest correct scope. Do **not** work around it by constructing the service with `new` or by importing the concrete service everywhere manually.\n\n## Diagnose\n\n1. Locate the injection site(s): `inject(OrdersService)` or a constructor parameter. Note the component/route/guard that does the injecting, because that's the injector whose ancestry must contain a provider.\n2. Look at `OrdersService` itself — check its `@Injectable({...})` decorator:\n   - `@Injectable({ providedIn: 'root' })` → registers a singleton in the root injector; visible everywhere the root injector is reachable.\n   - `@Injectable()` with **no** `providedIn` → **not registered anywhere**. Any injector that inherits only from root will fail with exactly this error.\n   - `@Injectable({ providedIn: SomeModule })` → only registered when `SomeModule` is in the injector path.\n3. If the service *is* meant to be scoped (e.g. one instance per lazy feature, or per route), then it deliberately should **not** be in root, and the fix is to add it to that scope's `providers`, not to add `providedIn: 'root'`.\n\n## Apply the smallest correct fix\n\nPick based on the intended scope:\n\n**App-wide singleton (most common)** — add `providedIn: 'root'` to the service:\n\n```ts\n@Injectable({ providedIn: 'root' })\nexport class OrdersService { ... }\n```\n\nThis is the idiomatic Angular default and gives one shared instance with tree-shaking: unused services are dropped from the bundle.\n\n**Feature/route-scoped instance** — keep the service bare (`@Injectable()`) and register it where it should live:\n\n```ts\n// e.g. in the feature route or component\nproviders: [OrdersService]\n```\n\nor on the lazy-loaded route config if the instance should die with the route.\n\n**Component-scoped instance** — add to that component's `providers` array. This creates a new instance per component instance; only do this if that's actually what you want.\n\nIf a *guard*, *resolver*, or `APP_INITIALIZER` is the injector failing, the provider must be visible from the root injector — those run before any lazy feature injector exists. In that case you almost always want `providedIn: 'root'`.\n\n## The critical rule\n\nThe error is Angular telling you the *injector chain* has no provider — the fix is to make the provider reachable from the right injector. Do **not** \"fix\" it by:\n\n- `new OrdersService(...)` at the call site — this bypasses DI entirely, so `TestBed` overrides, mocked dependencies, and the service's own injected dependencies all break;\n- passing the service down by hand through many layers;\n- adding it to a `providers` array on a component that isn't on the injector path of the failure — it'll compile and still throw;\n- marking it `providedIn: 'root'` when the intent was a per-feature instance — that silently changes behavior (shared mutable state).\n\n`new` is the specific red flag here: the compiler is happy, the runtime was never going to be, and the \"fix\" makes the class untestable.\n\n## Verify\n\n- Re-run the app; confirm bootstrap completes and `OrdersService` resolves (log or a click-path that exercises it).\n- Run the existing unit test that instantiates the component/service via `TestBed` — a correct DI fix keeps that green; a `new` workaround would have broken it.\n- Confirm no `new OrdersService` and no duplicate/misplaced provider entries were introduced.\n- Check `git status`: the diff should be limited to the service's `@Injectable` metadata or the one correct `providers` array.\n\nReport the root cause explicitly: \"`OrdersService` had no `providedIn` and wasn't in the injector path of `<injecting component>`; added `providedIn: 'root'` (app-wide singleton)\" — not just \"bootstrap works now.\"",
+              "outputSha256": "280433d6934d1a148f2eecc5f3ccae54fdb3d8b0c6442dfd89a54c03ead1434d",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Answer shows the concrete fix: `@Injectable({ providedIn: 'root' })` on OrdersService, plus providers:[OrdersService] for feature/route/component scope. It explains the error means the injector chain has no provider ('the injector chain has no provider'), not a broken class. It explicitly warns against `new OrdersService(...)` as the fix, satisfying no fail criterion."
+              },
+              "passed": true
+            },
+            {
+              "output": "The `ng build` succeeding is expected here — this error is a runtime DI resolution failure that only surfaces when the injector tree actually tries to construct the component/route that injects `OrdersService`, not a compile-time one. Fix it by finding where `OrdersService` should be provided and adding the missing provider at the correct scope. Concretely:\n\n1. Open `orders.service.ts` and check its `@Injectable(...)` decorator.\n   - If it has no `providedIn` (or something other than `'root'` and you don't actually want it root-scoped), the simplest correct fix for an app-wide service is `@Injectable({ providedIn: 'root' })`.\n   - If it already has `providedIn: 'root'`, the problem is elsewhere — see step 3.\n\n2. If the service is *intended* to be scoped narrower than root (e.g. per lazy-loaded feature, per route), add it to that scope's `providers` instead:\n   - route-level: `providers: [OrdersService]` on the specific route config,\n   - component-level: `providers: [OrdersService]` in the consuming component's `@Component` metadata.\n   Pick the scope that matches the intended lifetime of the service — don't just drop it on the root because it's convenient.\n\n3. If `providedIn: 'root'` is present and you still get \"No provider for OrdersService\", trace the injection path: the failing component/route is being constructed from an injector tree that doesn't include the module/scope where the service is registered. That usually means a standalone component or a lazy route importing the service from a module that isn't actually in the active injector path, or an `providedIn` pointing at a specific module that isn't loaded on this route. Fix the import/scope wiring, not the provider itself.\n\n4. Verify: re-run the app (or the bootstrap/`ng serve` path) and confirm the error is gone, and that other consumers of `OrdersService` still resolve.\n\nDo **not** fix this by constructing the service with `new OrdersService(...)` wherever it's injected — that bypasses Angular's DI entirely: no singleton sharing, no `TestBed` override-ability, no respect for the service's actual provider scope, and any `inject()`-based dependencies inside `OrdersService` will fail. The fix is always to add the missing provider at the right scope (or correct the scope/import path that should have reached an existing one), not to sidestep the injector.\n\nReport the actual root cause — \"the service wasn't provided at any scope reachable from this component\" or \"the module providing it isn't in this route's injector path\" — rather than just \"bootstrap no longer throws.\"",
+              "outputSha256": "21bee277b12c56bc50b540856fecf1173545786c10ff720e554c15414fde0fae",
+              "promptSha256": "0e34d1ea5f89b9d2d80d5da116c61b933e32d551a53e89703e11888943095001",
+              "deterministic": [],
+              "judge": {
+                "verdict": "pass",
+                "reason": "Criterion 1: answer gives concrete fixes — `@Injectable({ providedIn: 'root' })` on orders.service.ts, route-level `providers: [OrdersService]`, and component-level `providers: [OrdersService]` in @Component metadata. Criterion 2: explains the failing component/route is constructed from an injector tree lacking the module/scope where the service is registered, i.e. no reachable provider. Fail criterion avoided: explicitly warns against `new OrdersService(...)`."
+              },
+              "passed": true
+            }
+          ]
+        }
+      ],
+      "verdict": "pass",
+      "scope": "bundled",
+      "skillDigest": "d12f7926f3dc22a9e83e6909ea7589084e66f6a456790d0c8434cdeca80b1593",
+      "catalogDigest": "fd9b6a086f61a996f761a68f9e7a58cde1ce62e121f276d70bbef8e05e372f4b",
+      "judgePromptVersion": "2026-09-25.1",
+      "runner": "deepseek",
+      "model": "deepseek-chat",
+      "runnerPromptVersion": "2026-09-25.1",
+      "recordedAt": "2026-09-25T15:56:18.842Z",
+      "judge": "deepseek",
+      "judgeModel": "deepseek-chat"
+    }
+  ]
+}