@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/angular-template-sanitizer-security-review/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: angular-template-sanitizer-security-review
+description: Statically review Angular templates and components for injection via DomSanitizer bypass calls (bypassSecurityTrustHtml, bypassSecurityTrustUrl, bypassSecurityTrustResourceUrl), unsanitized [innerHTML] bindings, and dynamically bound iframe security attributes such as [attr.sandbox], grounded in Angular's own sanitizer and NG0910 documentation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# Angular Template Sanitizer Security Review
+
+## Purpose
+
+Review Angular templates, components, and their data-flow for the documented injection classes Angular's own sanitizer architecture is built to catch, and that are only unsafe when application code deliberately or accidentally routes around it: `DomSanitizer` bypass calls (`bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, `bypassSecurityTrustResourceUrl`) fed by user-reachable input, unsanitized `[innerHTML]` bindings, and dynamically bound iframe security attributes such as `[attr.sandbox]` that Angular's own NG0910 check exists to reject. This skill exists so the review stays anchored to these documented, concrete sinks instead of drifting into a general "Angular code review" — it does not re-litigate change detection, signals architecture, or component design in every response.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review whether a `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, or `bypassSecurityTrustResourceUrl` call is safe,
+- assess whether an `[innerHTML]` binding is safe,
+- review an `<iframe>` embed for a dynamically bound security attribute (`[attr.sandbox]`, `[sandbox]`, `[attr.allow]`, `[attr.credentialless]`) or an NG0910 error,
+- perform a pre-launch security review of Angular templates that render user- or third-party-supplied content.
+
+Do not use this skill for:
+
+- Angular architecture review with no security angle (signals usage, change-detection strategy, component decomposition quality) — use `angular-architecture-signals-review` instead,
+- SSR/hydration-specific defects (`TransferState` leakage, hydration mismatches) — use `angular-ssr-hydration-review` instead,
+- a bug that requires live traffic reproduction (a captured XSS payload in a running app, a browser-based exploit proof) to confirm exploitation — static analysis proves the structural risk, not that it has already been exploited in production.
+
+## Context7 Documentation Protocol
+
+- Resolve the Angular library ID with `resolve-library-id` (matched result: `/angular/angular`) before citing any sanitizer-mechanism or NG0910 claim.
+- `/angular/angular` is Angular's own source-and-docs repository (high reputation, corroborated against `packages/platform-browser/src/security/dom_sanitization_service.ts`, `packages/core/src/sanitization/html_sanitizer.ts`, `packages/core/src/render3/instructions/shared.ts`, and `adev/src/content/reference/errors/NG0910.md`). Use `query-docs` against it to confirm low-level sanitizer mechanics directly from source: that `bypassSecurityTrustHtml` (and its URL/resource-URL siblings) mark a value trusted so `sanitize()` skips the HTML/URL sanitizer and returns the value unchanged, that property bindings like `[innerHTML]` accept a compiler-added sanitizer function that only risky properties receive, and that text interpolation instead calls `renderer.setValue()` on a text node — a path that never parses HTML and needs no sanitizer.
+- Before flagging a `[attr.sandbox]`/`[sandbox]`/`[attr.allow]`/`[attr.credentialless]` binding, confirm Angular's own NG0910 check: these attributes are documented as required to be static (fixed at element-creation time) because they configure the iframe's security model before `src`/`srcdoc` load — a dynamic binding either throws NG0910 in dev or, if that check is suppressed, lets a runtime value weaken the sandbox.
+- Read the component's imports first to confirm `DomSanitizer` (from `@angular/platform-browser`) is actually in use before assuming a bypass call exists — do not assume a project uses the bypass APIs without confirming the import and call site.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label the claim `documentation-based, unverified against current release`.
+
+## Lean operating rules
+
+- Injection findings default to HIGH severity. This is a security-scoped skill: do not downgrade an untraced `bypassSecurityTrustHtml`/`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` call or an unsanitized `[innerHTML]` binding to MEDIUM just because it has not been observed exploited yet — the risk is in the structure, not in whether someone has already hit it.
+- Trace every finding to a concrete file:line and a concrete data-flow path. A finding that says "this bypass call might be unsafe" or "this innerHTML might be risky" without showing the specific origin (route param, query string, request body, or a third-party API response that itself echoes user input) and the specific sink is not a valid finding — it is a guess.
+- Do not approve any `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, or `bypassSecurityTrustResourceUrl` call whose input includes user-reachable data unless the trace shows the value was validated or sanitized on that exact path before the bypass call — the bypass APIs are intentional escape hatches from Angular's compiler-driven sanitization, not accidental gaps, so their mere presence is not evidence of prior review.
+- Do not approve an `[innerHTML]` binding fed by user-reachable input unless a named sanitizer call (e.g., `DomSanitizer.sanitize(SecurityContext.HTML, ...)`, or a project-specific equivalent) is visibly present on that exact data-flow path. A sanitizer import existing elsewhere in the codebase does not clear this bar — trace the specific path under review.
+- Flag any `[attr.sandbox]`, `[sandbox]`, `[attr.allow]`, or `[attr.credentialless]` binding on an `<iframe>` as a finding regardless of whether NG0910 is currently thrown in the reviewed environment — a suppressed or bypassed dev-mode check does not make the underlying dynamic-security-attribute pattern safe in production.
+- Check dynamic `[href]`/`[src]` bindings fed through `bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` for scheme validation (an allowlist rejecting `javascript:` and other non-`http(s)` schemes) on the traced path before the bypass call — the bypass call itself performs no validation.
+- Never execute, build, or run application code, and never send live requests, as part of this review; this is a static-review skill (Read/Grep/Glob only).
+- Load only the reference needed for the concern in scope.
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the step-by-step review procedure, the sanitizer-bypass/innerHTML/iframe decision tree, and the required output shape.
+- [DomSanitizer bypass calls and innerHTML](references/sanitizer-bypass-and-innerhtml.md) — load only when the review scope includes a `bypassSecurityTrustHtml`/`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` call or an `[innerHTML]` binding. Includes the OWASP XSS grounding reference; load that citation only when a finding is actually present.
+- [Dynamic iframe security attributes](references/iframe-security-attributes.md) — load only when the review scope includes an `<iframe>` element with a bound `sandbox`, `allow`, or `credentialless` attribute, or a reported NG0910 error.
+
+## Response minimum
+
+Return, at minimum:
+
+- the component(s), template binding(s), and/or `DomSanitizer` call site(s) in scope,
+- ranked findings with file:line evidence, defect category (`xss`, `url-injection`, or `iframe-sandbox-escape`), the concrete data-flow trace (origin-to-sink path naming every hop), and a fix sketch matching Angular's documented pattern,
+- for every bypass call or `[innerHTML]` finding, an explicit statement of whether validation or sanitization is present on the traced path — never approve on the assumption one exists elsewhere,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming actual exploitation requires a live payload test in a running browser session, not static review").

package/skills/frontend/angular-template-sanitizer-security-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "angular-template-sanitizer-security-review",
+  "name": "Angular Template Sanitizer Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Angular templates and components for injection via DomSanitizer bypass calls (bypassSecurityTrustHtml, bypassSecurityTrustUrl, bypassSecurityTrustResourceUrl), unsanitized [innerHTML] bindings, and dynamically bound iframe security attributes such as [attr.sandbox], grounding claims via Context7 and Angular's own sanitizer and NG0910 documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://angular.dev/best-practices/security",
+    "https://angular.dev/errors/NG0910",
+    "https://owasp.org/www-project-top-ten/",
+    "https://owasp.org/www-community/attacks/xss/"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: DomSanitizer bypass calls and unsanitized [innerHTML] bindings are XSS vectors, and dynamically bound iframe security attributes are a sandbox-escape vector Angular's own NG0910 check exists to reject. Every finding defaults to HIGH severity unless proven otherwise with concrete validation/sanitizer evidence on the traced path. Static-review-only skill: it reads and greps components and templates but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/angular-template-sanitizer-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/angular-template-sanitizer-security-review/references/iframe-security-attributes.md

@@ -0,0 +1,63 @@
+# Dynamic Iframe Security Attributes
+
+Use this reference only when the review scope includes an `<iframe>` element with a bound `sandbox`, `allow`, `credentialless`, `csp`, `referrerPolicy`, or `fetchPriority` attribute, or a reported NG0910 error.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "Angular throws NG0910 if I bind these attributes dynamically, so if my app runs without that error, my iframe binding must be fine."
+
+Wrong in two ways. First, the check can be suppressed or not exercised in the exact code path under review (a conditional branch not hit during development, or an older Angular version without the check). Second, even when the error is correctly thrown and "fixed" by refactoring around it, the underlying intent — a *dynamic*, potentially user-influenced sandbox/allow value — is still the actual security concern, independent of whether the specific Angular version enforces it at compile/runtime.
+
+## Officially grounded rules
+
+Angular's own documentation (`documentation-based`, `adev/src/content/reference/errors/NG0910.md`, confirmed via Context7 `/angular/angular`) states directly:
+
+- **Angular throws NG0910 when it detects a binding on specific security-related `<iframe>` attributes**: `sandbox`, `allow`, `allowFullscreen`, `referrerPolicy`, `csp`, `fetchPriority`, or `credentialless`. These attributes configure the iframe's security model and must be applied before the `src`/`srcdoc` attributes load content, so Angular requires them to be static — their values fixed at element-creation time and never bound as a property (`[sandbox]="..."`) or attribute (`[attr.sandbox]="..."`) binding, including via a directive's host bindings.
+- **The recommended fix is a static attribute**, e.g. `sandbox="allow-scripts"`, or Angular's `@if`/`@switch` control-flow blocks to conditionally render entire `<iframe>` elements with different static attribute values, rather than binding the attribute's value dynamically on one persistent element.
+
+## Non-negotiable design rules
+
+### 1. Flag the pattern regardless of whether NG0910 currently fires
+
+A dynamically bound security-sensitive iframe attribute is the finding — not the NG0910 error message itself. If the error is suppressed (an older Angular version, a downgraded compiler check, or code that technically avoids triggering the exact check Angular implements) but the underlying dynamic-binding pattern is present, it is still a finding: the sandbox's actual value can still be influenced by whatever expression it is bound to.
+
+### 2. Check reachability of the bound expression
+
+A `[attr.sandbox]` bound to a hardcoded, non-configurable constant expression evaluated once at compile time is a lower-severity finding (still worth fixing for forward-compatibility with future Angular checks) than one bound to a value that traces back to user-reachable input (a query parameter, a per-tenant config value editable by end users, or similar) — the latter is a HIGH finding because an attacker-influenced value can directly weaken the iframe sandbox.
+
+### 3. Use static attributes or conditional rendering, not dynamic binding
+
+The correct fix is either a static attribute value or Angular's `@if`/`@switch` blocks rendering distinct `<iframe>` elements per case — not attempting to bind the attribute dynamically through a workaround (e.g., manual DOM manipulation via `ElementRef` to set the attribute outside Angular's binding system), which reintroduces the same risk outside Angular's own safety check.
+
+## Minimal safe implementation pattern
+
+```html
+<!-- Static attribute, fixed at element-creation time. -->
+<iframe sandbox="allow-scripts" [src]="trustedEmbedUrl"></iframe>
+```
+
+```html
+<!-- Conditional rendering of distinct static configurations. -->
+@if (isTrustedPartner) {
+  <iframe sandbox="allow-scripts allow-same-origin" [src]="trustedEmbedUrl"></iframe>
+} @else {
+  <iframe sandbox="allow-scripts" [src]="trustedEmbedUrl"></iframe>
+}
+```
+
+Anti-pattern (dynamic binding — do not approve):
+
+```html
+<!-- userSandbox may originate from a per-tenant config value; even if
+     NG0910 is not currently thrown in this environment, the sandbox's
+     effective value can be influenced by that input at runtime. -->
+<iframe [attr.sandbox]="userSandbox" [src]="trustedEmbedUrl"></iframe>
+```
+
+## Verification targets
+
+- Grep `<iframe>` elements for `[sandbox]`, `[attr.sandbox]`, `[allow]`, `[attr.allow]`, `[credentialless]`, `[attr.credentialless]`, `[csp]`, `[attr.csp]`, `[referrerPolicy]`, `[attr.referrerPolicy]`, `[fetchPriority]`, and `[attr.fetchPriority]`.
+- For each match, trace the bound expression backward to determine whether it is a fixed compile-time constant or reachable from user-influenced input (query params, tenant config editable by end users, form state).
+- Grep for `ElementRef`-based manual attribute manipulation on iframe elements, which can reintroduce the same dynamic-binding risk outside Angular's compiler-enforced static-attribute check.

package/skills/frontend/angular-template-sanitizer-security-review/references/sanitizer-bypass-and-innerhtml.md

@@ -0,0 +1,93 @@
+# DomSanitizer Bypass Calls and [innerHTML] Bindings
+
+Use this reference only when the review scope includes a `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, or `bypassSecurityTrustResourceUrl` call, or an `[innerHTML]` binding. The OWASP XSS citation below is loaded only when a finding is actually present — do not cite it preemptively in a review that has no finding.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "I called `bypassSecurityTrustHtml`, so I must have already decided this content is safe — the method name itself is my proof of review."
+
+Wrong. The bypass method's name documents *intent* to skip sanitization, not that the argument was actually checked. The recurring real-world failure is a bypass call added to silence Angular's sanitizer error during development, with the "we'll add validation later" step never landing, or a bypass call whose argument source changes in a later refactor (a static string swapped for a computed value fed by an API response) without anyone re-reviewing the call site.
+
+## Officially grounded rules
+
+Angular's own source (`repo evidence` via Context7 `/angular/angular`, `packages/platform-browser/src/security/dom_sanitization_service.ts`) confirms the mechanism directly:
+
+- **`bypassSecurityTrustHtml()` disables Angular's XSS sanitization for the value it wraps.** It marks a string as trusted `SafeHtml`, which causes `sanitize()` to skip the HTML sanitizer entirely and return the value as-is. `bypassSecurityTrustUrl()` and `bypassSecurityTrustResourceUrl()` do the equivalent for URL and resource-URL contexts.
+- **Property bindings like `[innerHTML]` accept a compiler-added sanitizer function.** `setDomProperty()` (in `packages/core/src/render3/instructions/shared.ts`) only calls a sanitizer when one is present — "it is assumed that the sanitizer is only added when the compiler determines that the property is risky." Without a sanitizer function reaching that call (which happens whenever a `Safe*` value from a bypass call is passed, since `sanitize()` unwraps it unchanged), the raw value is set directly via `renderer.setProperty()`.
+- **Text interpolation is a structurally different, safer path.** `updateTextNode()` calls `renderer.setValue()` on a text node — a text node never parses HTML, so interpolated content cannot execute as markup or script regardless of its contents. This is why interpolation needs no sanitizer at all, and why it is the default recommendation whenever raw HTML rendering is not actually required.
+- **`_sanitizeHtml()` (`packages/core/src/sanitization/html_sanitizer.ts`) is the actual sanitizer** invoked when no bypass has occurred: it parses the HTML into an inert DOM tree, strips disallowed elements/attributes against an allowlist, and repeats parsing to catch mutation-XSS (mXSS) auto-correction attacks. This is the protection a bypass call routes around entirely.
+
+## Non-negotiable design rules
+
+### 1. Trace the full origin-to-sink path before judging a bypass call or [innerHTML] binding
+
+Do not evaluate `sanitizer.bypassSecurityTrustHtml(someVar)` or `[innerHTML]="someVar"` in isolation. Follow `someVar` backward: is it a literal string in the component? An `@Input()`? A value derived from a service call? An API response that itself echoes content any user (not necessarily the current one) previously submitted? The finding depends on where that trace terminates, not on the call/binding syntax alone.
+
+### 2. The bypass call's existence is not evidence the argument was validated
+
+A `bypassSecurityTrustHtml`/`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` call is an intentional escape hatch by design — its presence proves a developer wanted to skip sanitization, not that they checked the value first. Only a validation or sanitization step visibly present *before* the bypass call on that exact path clears the finding.
+
+### 3. A sanitizer call elsewhere in the codebase does not clear a specific [innerHTML] finding
+
+If the trace reveals user-reachable input reaching an `[innerHTML]` binding, the only thing that clears the finding is a named sanitizer call (e.g., `DomSanitizer.sanitize(SecurityContext.HTML, ...)`, or a project-specific equivalent such as DOMPurify) visibly present on that exact path. "This codebase has a sanitize utility used elsewhere" is not evidence the specific path under review calls it.
+
+### 4. Third-party API responses are not automatically trusted
+
+An API response is not "safe by default" just because it did not come directly from the current request's form input. If the API itself stores and echoes content that any user previously submitted (a comment system, a CMS with contributor accounts, a product-review feed), that response is user-reachable input for this review's purposes.
+
+### 5. URL-context bypasses need scheme validation, not HTML sanitization
+
+`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` are a distinct injection surface from `bypassSecurityTrustHtml` — do not conflate the fixes. The correct control before a URL-context bypass is scheme validation (an allowlist accepting only `http:`/`https:`/`mailto:` as appropriate, rejecting `javascript:` and other schemes), not HTML sanitization.
+
+## Minimal safe implementation patterns
+
+```ts
+import { Component, Input } from '@angular/core';
+
+@Component({
+  selector: 'app-comment',
+  // Text interpolation never sets innerHTML and needs no sanitizer.
+  template: `<div>{{ userComment }}</div>`,
+})
+export class CommentComponent {
+  @Input() userComment = '';
+}
+```
+
+```html
+<!-- A named sanitizer call sits directly on the path between the
+     untrusted field and the binding. -->
+<div [innerHTML]="sanitizer.sanitize(userBio)"></div>
+```
+
+Anti-pattern (untraced bypass call — do not approve):
+
+```ts
+// userComment comes from a profile API that echoes user-submitted text.
+// No validation anywhere between the API response and this bypass call.
+this.trustedComment = this.sanitizer.bypassSecurityTrustHtml(this.userComment);
+```
+
+## Adversarial checklist
+
+Before clearing a bypass call or `[innerHTML]` binding, answer these:
+
+- What is the literal origin of the bound value — a template literal, an `@Input()`, a service call result, or an API response?
+- Does any point along that trace involve content any user (current or otherwise) previously submitted?
+- Is there a named sanitizer or validation call visible on the exact path traced, or only "we sanitize somewhere in this codebase"?
+- Could a later code change (a refactor that swaps the data source, or a new field added to an existing API response) reach this same call or binding without re-triggering a security review?
+
+If any answer is unclear or reveals a gap, the finding is HIGH — do not soften it to "worth double-checking."
+
+## OWASP grounding (load only when a finding is present)
+
+Cross-Site Scripting (XSS) is the general vulnerability class that an unvalidated bypass call or unsanitized `[innerHTML]` binding produces: an attacker-controlled or attacker-influenced string is rendered as live HTML/script in another user's browser session. The OWASP XSS reference and OWASP Top Ten (both listed in this skill's `official_docs`) provide the vendor-neutral grounding for why this defect class is treated as HIGH severity by default — it typically enables session/token theft, credential harvesting via injected forms, or full account takeover in the victim's authenticated context. Cite these only in the specific finding write-up for a confirmed or suspected defect, not as boilerplate in every review.
+
+## Verification targets
+
+- Grep component and template source for `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, `bypassSecurityTrustResourceUrl`, `bypassSecurityTrustScript`, and `bypassSecurityTrustStyle`.
+- Grep templates for `[innerHTML]` and enumerate every match.
+- For each match, grep backward through the component's `@Input()`s, service injections, and any imported store/composable for the value's origin.
+- Grep for a `DomSanitizer.sanitize(` call (or an equivalent project-specific sanitizer utility) and confirm its call site is on the traced path, not merely present in the file or module.

package/skills/frontend/angular-template-sanitizer-security-review/references/workflow-and-output.md

@@ -0,0 +1,45 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure and the required output shape. Load the other two references only for the specific defect class the component or template under review actually raises.
+
+## Prerequisites
+
+- Read the component's imports to confirm whether `DomSanitizer` (from `@angular/platform-browser`) is in use. Do not assume a bypass call exists without confirming the import and the call site.
+- Identify the Angular major version in use (`package.json` — `@angular/core`) — sanitizer internals and the NG0910 check are current-Angular behavior; note explicitly if reviewing a much older major where behavior may differ, and label the claim accordingly.
+
+## Workflow
+
+1. **Locate every `DomSanitizer` bypass call.** Grep for `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, `bypassSecurityTrustResourceUrl`, `bypassSecurityTrustScript`, and `bypassSecurityTrustStyle`. For each, trace the argument backward through props/`@Input()`s, computed getters, service calls, and API responses to its origin.
+2. **Locate every `[innerHTML]` binding.** For each, trace its bound expression the same way. Determine whether the origin includes user-reachable input (route params, query strings, request bodies, or a third-party API response that itself echoes user input) and whether a named sanitizer call (`DomSanitizer.sanitize(SecurityContext.HTML, ...)` or an equivalent) sits on that exact path.
+3. **Locate every dynamically bound iframe security attribute.** Grep for `[attr.sandbox]`, `[sandbox]`, `[attr.allow]`, `[allow]`, `[attr.credentialless]`, `[credentialless]`, `[attr.csp]`, `[attr.referrerPolicy]`, and `[attr.fetchPriority]` on `<iframe>` elements (including via a directive's host bindings). See `references/iframe-security-attributes.md` for the decision tree.
+4. **Locate every dynamic `[href]`/`[src]` binding fed by `bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl`.** Check for scheme validation (an allowlist rejecting `javascript:` and other non-`http(s)` schemes) on the path before the bypass call.
+5. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- A bypass call's traced argument includes user-reachable input and no validation/sanitization occurs on that exact path before the call → **HIGH** finding, XSS or URL-injection depending on the bypass method. Do not accept "we validate elsewhere" — the trace must show the check on the specific path reviewed.
+- A bypass call's traced argument is fully origin-controlled with no user-reachable input anywhere in the trace (e.g., a static, developer-authored HTML fragment with no user-submission path) → not a finding, but state this explicitly in the output rather than silently omitting the call site.
+- An `[innerHTML]` binding's traced source includes user-reachable input and no sanitizer call is present on that exact path → **HIGH** finding, XSS.
+- An `[innerHTML]` binding's traced source is fully origin-controlled → not a finding, stated explicitly.
+- Any security-sensitive iframe attribute (`sandbox`, `allow`, `allowFullscreen`, `referrerPolicy`, `csp`, `fetchPriority`, `credentialless`) is bound dynamically (property or `attr.` binding) rather than set as a static attribute → **MEDIUM-to-HIGH** finding depending on whether the bound value can be influenced by user-reachable input, regardless of whether NG0910 is currently thrown in the environment reviewed.
+- A dynamic `[href]`/`[src]` fed through a bypass call has no scheme allowlist on the path before the bypass → **MEDIUM-to-HIGH** finding depending on reachability (public unauthenticated surface vs. requiring an authenticated session to trigger).
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the component(s), template binding(s), and/or `DomSanitizer` call site(s) reviewed.
+2. **Ranked findings** — each with file:line, defect category (`xss`, `url-injection`, or `iframe-sandbox-escape`), the concrete data-flow trace naming every hop from origin to sink, and a fix sketch matching Angular's documented pattern.
+3. **Validation/sanitizer status per finding** — an explicit statement of whether validation or sanitization is present on the traced path; never infer one exists.
+4. **Evidence level per finding** — `repo evidence`, `documentation-based`, or `inference`. Label structural risk findings as structural risk explicitly — do not imply confirmed exploitation without live evidence.
+5. **Verdict** — approve / approve-with-notes / block.
+6. **Open questions or out-of-scope items** — e.g., "confirming actual exploitation requires a live payload test in a running browser session, not static review," or "hydration-mismatch risk in this same file is out of scope — recommend `angular-ssr-hydration-review` if relevant."
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a bypass call because "we validate elsewhere in the app" without a validation/sanitizer call visible on the specific traced path — that is not evidence, it is an assumption,
+- treat a bound `[attr.sandbox]`/`[sandbox]` as acceptable because "NG0910 didn't fire in our environment" — a suppressed or unhit dev-mode check does not make the dynamic-binding pattern safe in production,
+- downgrade an untraced `[innerHTML]` finding to informational because "it's probably fine" — this skill's default is HIGH for exactly this class of unproven claim,
+- skip the review because "DomSanitizer bypass calls are always intentional, so they must already be safe" — the bypass APIs are intentional escape hatches from sanitization, not proof the argument was validated before the call.

package/skills/frontend/api-integration-contract-review/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: api-integration-contract-review
+description: Reviews frontend-to-backend API contracts — BFF route handlers and direct backend calls — for data-minimization, server-side object-level authorization enforcement, error-shape leakage, CORS misconfiguration, and backward-compatible versioning before they ship.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: architecture
+---
+
+# API Integration Contract Review
+
+## Purpose
+
+Review any new or changed API contract consumed by the frontend — a direct backend call or a BFF (backend-for-frontend) route handler — for data-minimization (no field returned to a client that the caller is not authorized to see), object-level authorization enforced independently on the server, error-shape safety (no upstream internals leaking to the client), CORS correctness, and backward-compatible versioning for existing consumers. This skill exists so those four concerns get a disciplined, security-severity review every time a contract is introduced or changed, instead of being waved through as "just wiring."
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a new API endpoint or BFF route handler before it ships,
+- review a change to an existing response shape, status-code contract, or error format,
+- audit whether the frontend fetches more fields than it renders,
+- investigate a reported data-exposure or authorization-bypass (BOLA) concern,
+- review CORS configuration for an endpoint that accepts credentialed requests.
+
+Do not use this skill for:
+
+- the frontend's caching/store logic once data has already arrived — route to `state-management-decision-review`,
+- BFF-vs-direct-call topology or new-BFF-service ownership decisions at the platform level — route to `frontend-platform-architecture-review`; use this skill for the contract itself once the boundary decision is made,
+- SSR/hydration mechanics — route to the relevant SSR skill,
+- general Next.js data-fetching patterns unrelated to authorization/data-shape — route to `nextjs-app-router-data-fetching-review`.
+
+## Context7 Documentation Protocol
+
+- Before assessing a Next.js Route Handler's caching configuration, query Next.js docs for the current caching-directive semantics (`dynamic`, `revalidate`, `fetchCache`, `runtime`) against the repo's confirmed major version — read `package.json` first. As of Next.js 15+, `GET` Route Handlers are no longer cached by default; caching requires an explicit `export const dynamic = 'force-static'`. A route relying on pre-15 default-caching behavior to protect against overexposure (or that assumes it is uncached when it is actually configured `force-static`) is a version-sensitive misconfiguration risk, not a stylistic detail — verify the version before trusting either claim.
+- Matched library ID for this skill's default grounding: Next.js is `/vercel/next.js`. Resolve fresh via `resolve-library-id` for any other backend/BFF framework named in the review (Express, Fastify, NestJS, etc.) rather than assuming Next.js conventions transfer.
+- Before approving a query-key or cache-key design that scopes data by session/role, query TanStack Query docs for query-key structuring guidance — object-based key segments are order-independent and `undefined` properties are dropped during serialization, so a key intended to separate two roles/users can silently collide if one property is `undefined` for one caller and omitted for another. Matched library ID: `/tanstack/query`.
+- Documentation proves what the framework *supports* (e.g., that `force-static` exists and changes default caching). It does not prove this specific route handler is configured correctly, or that authorization is actually enforced server-side. Pair every Context7-grounded capability claim with a repo-evidence check (the actual route handler code, the actual authorization middleware) before treating a finding as resolved.
+- Never approve a version-sensitive caching or contract claim without Context7 verification. If Context7 is unavailable, label the claim `documentation-based — unverified this session` and require confirmation before final sign-off.
+
+## Lean operating rules
+
+- Treat every unjustified field in a response as a data-minimization defect, not a style note. "We return the whole object because it's simpler" is not a justification.
+- Treat client-supplied identifiers (a URL param, a body field, a bearer-token claim the client can influence) as untrusted for authorization decisions. Object-level authorization must be re-derived server-side from the authenticated session, independent of what the client claims to be requesting.
+- Escalate every finding of client-side-only authorization enforcement or excessive data exposure to security severity, not a style/lint-level note — these map directly to OWASP API Security Top 10 categories (Broken Object Level Authorization, Excessive Data Exposure).
+- Treat raw upstream error forwarding (stack traces, internal hostnames, DB driver errors, vendor error payloads) as a blocking finding. Error responses reaching the client must be shaped and sanitized, not passed through for "easier debugging."
+- Treat wildcard CORS (`Access-Control-Allow-Origin: *`) combined with `Access-Control-Allow-Credentials: true` as an automatic blocking finding — this combination is invalid per the CORS spec in browsers that enforce it correctly, and where it is not rejected outright it defeats the purpose of credentialed requests.
+- For a breaking contract change (removed field, renamed field, changed status-code meaning, changed error shape), require an identified list of existing consumers and a stated deprecation window before approval. Do not accept "nothing should be calling this yet" without evidence.
+- Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only) — verdicts are based on route-handler code, authorization middleware, and documented contract evidence, not live requests you generate yourself.
+- Label every claim `repo evidence`, `Context7-verified`, `documentation-based — unverified this session`, or `inference`. Documentation proves framework capability; it does not prove this endpoint's authorization is correctly wired.
+
+## References
+
+Load these only when needed:
+
+- [Contract review workflow and verdict contract](references/workflow-and-output.md) — use for the step-by-step review procedure, the block / block-with-conditions / approve decision tree, and the required output shape.
+- [Authorization and data-minimization patterns](references/authorization-and-data-minimization.md) — use when the contract involves per-object access control, role-scoped fields, or a BOLA/excessive-data-exposure concern; grounds server-side enforcement patterns and field-justification review.
+- [Error shape, CORS, and versioning](references/error-shape-cors-versioning.md) — use when reviewing error-handling code, CORS configuration, or a breaking/backward-compatible contract change with existing consumers.
+
+## Response minimum
+
+Return, at minimum:
+
+- the endpoint/route handler and consumer(s) in scope,
+- a per-field data-minimization justification (or the unjustified fields flagged),
+- the object-level authorization enforcement mechanism and whether it is independently server-verified,
+- error-shape and CORS findings, each labeled by severity,
+- verdict (approve / approve-with-conditions / block) with the specific unresolved conditions if any,
+- versioning/deprecation plan status for any breaking change,
+- every version-sensitive framework claim labeled `Context7-verified` or `documentation-based — unverified this session`.

package/skills/frontend/api-integration-contract-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "api-integration-contract-review",
+  "name": "API Integration Contract Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews frontend-to-backend API contracts for data-minimization, authorization enforcement, versioning safety, and error-shape leakage before they ship, using OWASP API Security Top 10 grounding, server-side object-level authorization checks, and CORS/versioning gates loaded progressively and validated via Context7 against the repo's confirmed framework versions.",
+  "source_type": "original",
+  "official_docs": [
+    "https://nextjs.org/docs/app/building-your-application/routing/route-handlers",
+    "https://owasp.org/www-project-api-security/",
+    "https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS",
+    "https://tanstack.com/query/latest/docs/framework/react/guides/query-keys"
+  ],
+  "security_notes": "Static-review-only skill: it reads and greps route handler code, authorization middleware, and contract documentation but never executes, builds, or runs application code, and never issues live requests. Every finding of client-side-only authorization or excessive data exposure is treated as a security-severity finding, not a style note. Wildcard CORS combined with credentialed requests is an automatic blocking finding. Raw upstream error forwarding to the client is a blocking finding.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/api-integration-contract-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/api-integration-contract-review/references/authorization-and-data-minimization.md

@@ -0,0 +1,73 @@
+# Authorization and Data-Minimization Patterns
+
+Use this reference only when the contract under review involves per-object access control, role-scoped fields, or a suspected Broken Object Level Authorization (BOLA) / Excessive Data Exposure concern (OWASP API Security Top 10, API1:2023 and API3:2023).
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "The client only asks for the objects it owns, so we don't need to check ownership server-side."
+
+That is backwards. A client-supplied identifier — a URL path parameter, a query string, a request body field, or even a claim embedded in a bearer token that the caller can request to include — describes what the caller is *asking for*, not what the caller is *entitled to*. If the server returns whatever object matches the requested ID without independently checking it against the authenticated session, any caller can enumerate IDs and read (or in a mutating endpoint, write) other users' data. This is OWASP's #1 API risk category for a reason: it is the single most common real-world API vulnerability, and it is invisible in a UI walkthrough because the legitimate user's own ID always "just works."
+
+A second bad assumption:
+
+> "We'll just return the full object; the frontend only renders the fields it needs."
+
+Returning the full object regardless of caller scope is Excessive Data Exposure. It shifts the trust boundary from the server (correct) to the client (wrong) — a browser DevTools Network tab, a proxy, or a modified client can see every field the server sent, whether or not the UI renders it. Internal fields (cost basis, internal flags, other users' identifiers embedded in nested objects, soft-deleted records) leak this way constantly.
+
+## Non-negotiable design rules
+
+### 1. Authorization is re-derived, not trusted
+
+The server must independently determine "does the authenticated session have access to this object?" using the session's own identity (user ID, tenant ID, role claims from a verified token) — never by trusting that the requested ID implies ownership. Concretely: `SELECT * FROM orders WHERE id = :id AND account_id = :sessionAccountId`, not `SELECT * FROM orders WHERE id = :id` followed by returning the result unconditionally.
+
+If the authorization check is a client-side redirect, a hidden form field, or a UI-only role gate with no matching server-side re-check, the finding is BOLA regardless of how the client behaves in the happy path.
+
+### 2. Every field has a stated scope justification
+
+Walk the response shape field by field. For each field, the reviewer (or the code's authorization logic) must be able to state: "this field is visible to caller scope X because Y." A field with no stated justification — "we just always send it" — is a data-minimization defect. This applies recursively to nested objects and arrays: a `user` object embedded inside an `order` response can leak another user's email or phone number even if the top-level `order` fields are all justified.
+
+### 3. Scope-derived shape, not scope-derived filtering-after-the-fact
+
+Prefer response shapes that are constructed per-scope (a query/serializer that only selects authorized fields for the caller's role) over constructing the full object and filtering fields out afterward in application code. Post-hoc filtering is fragile — a new field added to the full object later is exposed by default unless every filter call site is updated. Scope-derived construction fails closed; post-hoc filtering fails open.
+
+### 4. List/collection endpoints get the same scrutiny as single-object endpoints
+
+BOLA and data-minimization findings are not limited to `/resource/:id` endpoints. A `/resources?filter=...` list endpoint that does not scope the underlying query to the caller's authorized set — relying instead on the client to only ever request filters it "should" use — has the same defect, at higher blast radius (one request enumerates many objects instead of one).
+
+### 5. Role/tier changes must invalidate cached authorization decisions
+
+If authorization or field-visibility decisions are cached (a memoized permission check, a cached JWT-derived scope, a client-side cache key that doesn't include role), a role downgrade or tenant/session change must not leave stale broader access in effect. When reviewing a query-key or cache-key design for this kind of endpoint, confirm the key includes whatever identity/role dimension the response depends on — see the Context7-grounded query-key note in `SKILL.md`.
+
+## Minimal safe review flow
+
+1. Get the actual response shape (from code, not from a client-facing types file that may drift from what the server actually returns).
+2. For each field, ask: which caller scope needs this, and where is that justified?
+3. Find the authorization check in the route handler or its middleware. Confirm it reads the session's own identity, not a client-supplied value, to decide access.
+4. Confirm the check runs before data is fetched/returned, not after (an after-the-fact check that still leaks partial data in an error path is still a finding).
+5. For list/collection endpoints, confirm the underlying query itself is scoped, not just the individual-object path.
+6. If a permission/role decision is cached, confirm the cache key includes the role/session dimension.
+
+## Adversarial checklist
+
+Before approving, answer these:
+
+- If I change only the ID in the request (keeping the same session/token), do I get another caller's data? If untested and unverifiable from code alone, say so explicitly rather than assuming "probably fine."
+- Is there any field in the response that exists only because "the ORM/serializer returns it by default"?
+- Does a nested/embedded object carry fields belonging to a *different* principal than the top-level resource's owner?
+- Is the authorization check duplicated per route, or centralized in a way that a new route can accidentally skip?
+- Does a list endpoint's filter/query parameter influence which authorization scope is applied, instead of the scope being derived purely from the session?
+
+If any answer is "unknown," the review's output must surface that as an open question, not an implicit pass.
+
+## When to push back
+
+Push back if the user says:
+
+- "the frontend already filters it, so the API response doesn't matter"
+- "nobody would guess another user's ID" (security by obscurity is not a mitigation)
+- "we'll add the server-side check later, ship the endpoint now"
+- "it's an internal-only field, the response just happens to include it"
+
+Those are not acceptable trade-offs for a shipped contract. They are the two most common root causes (API1/API3) in the OWASP API Security Top 10.

package/skills/frontend/api-integration-contract-review/references/error-shape-cors-versioning.md

@@ -0,0 +1,65 @@
+# Error Shape, CORS, and Versioning
+
+Use this reference only when reviewing error-handling code, CORS configuration, or a breaking/backward-compatible contract change with existing consumers.
+
+## What people get wrong
+
+> "Forwarding the upstream error makes debugging easier for us and for API consumers."
+
+That reasoning optimizes for the wrong audience. A stack trace, an internal hostname, a database driver error message, or a raw vendor error payload (e.g., an unmodified error body from a third-party payment processor) is useful to the team operating the service — via server-side logs and traces — and actively harmful when returned to the client. It discloses internal topology, library versions, and sometimes query fragments or schema details to anyone who can call the endpoint, authenticated or not. Debuggability belongs in observability tooling, not in the HTTP response body.
+
+> "CORS is just a browser annoyance; a wildcard origin gets people unblocked faster."
+
+CORS is an authorization control at the browser layer, and it is meaningfully different from server-side authorization: a wildcard `Access-Control-Allow-Origin: *` says "any origin's script may read this response in the caller's browser." Combined with `Access-Control-Allow-Credentials: true` (cookies, HTTP auth, or client TLS certs sent automatically), this combination is invalid per the Fetch/CORS spec — browsers that implement the spec correctly reject wildcard-origin-plus-credentials at the browser level — and where a misconfigured server pairs a *reflected* origin (echoing back whatever `Origin` header the request sent, which is not a literal `*` but has the same effect) with credentials enabled, it functionally defeats the same-origin protections credentialed requests depend on.
+
+## Officially grounded shape (MDN CORS)
+
+- `Access-Control-Allow-Origin` must be a specific origin (or `null`) when the response is to be used with credentialed requests; the literal value `*` cannot be combined with `Access-Control-Allow-Credentials: true` per spec.
+- A server that wants to support credentialed requests from multiple known origins must validate the incoming `Origin` header against an explicit allowlist and echo back only that validated value — not blindly reflect any `Origin` header received.
+- Preflight (`OPTIONS`) responses must correctly declare `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers` for the actual methods/headers the real request will use; an overly broad preflight response (allowing methods/headers never actually used) is a smaller but related over-permissioning smell worth flagging alongside a wildcard-origin finding.
+
+## Non-negotiable design rules
+
+### 1. Error responses are shaped at the boundary, not passed through
+
+Every upstream/backend error must be caught and mapped to a client-facing shape (a stable error code, a safe human-readable message, no internal detail) before it reaches the client. This mapping should happen at a consistent boundary (a shared error handler / middleware), not ad hoc per route, so a new route can't accidentally skip it.
+
+### 2. CORS is an explicit allowlist wherever credentials are involved
+
+If the endpoint accepts cookies, HTTP auth, or client certificates (`Access-Control-Allow-Credentials: true`, or the client sets `credentials: 'include'`), the allowed-origin policy must be an explicit, reviewed allowlist — validated against the `Origin` header, not a wildcard and not an unvalidated reflection of whatever origin asked.
+
+### 3. Breaking changes require an identified consumer list and a stated migration path
+
+A contract change is breaking if it removes a field, renames a field, narrows a previously-accepted input shape, changes the meaning of an existing status code, or changes the error response shape in a way an existing consumer's error-handling logic depends on. Before approving a breaking change:
+
+- Identify existing consumers (search the codebase; ask the requester about out-of-repo/cross-team consumers if the contract is public).
+- Require a stated plan: an additive-only change (preferred — add a new field/route instead of changing the old one), a versioned route (`/v2/...`), or a dual-write/deprecation window with a communicated sunset date.
+- "Nothing should be calling this yet" is only acceptable when the reviewer has evidence (a search result, a service registry entry, an explicit statement from the requester with context) — not assumed by default.
+
+### 4. Additive changes still get a data-minimization pass
+
+A new field added to an existing response is not automatically safe just because it's additive — it still needs the same field-justification check as a net-new endpoint (see `authorization-and-data-minimization.md`).
+
+## Minimal safe review flow
+
+1. Find every place the route handler / BFF catches an error from an upstream call, a database, or an SDK.
+2. Confirm each catch site maps to a sanitized client-facing error shape — check for accidental pass-through (`res.status(500).json(err)` or equivalent is a common accidental-leak pattern).
+3. Find the CORS configuration for the route. Confirm it's an explicit allowlist if credentials are enabled; flag a wildcard-plus-credentials combination as blocking.
+4. For a contract change, diff the old and new response/request shape field by field and status-code by status-code.
+5. Search for existing consumers of any field/status-code/error-shape being removed or changed in a breaking way.
+6. If consumers exist and the change is breaking, require the stated migration plan before approval.
+
+## Safe command/code verification targets
+
+- Grep the route handler and its shared error-handling middleware for direct pass-through of caught error objects into the response body.
+- Grep the CORS configuration (framework middleware config, reverse-proxy config, or manual header-setting code) for a literal `*` origin alongside `credentials: true` / `Access-Control-Allow-Credentials: true`.
+- Search the codebase for callers of the changed endpoint/field/status-code (import references, fetch/query-key usage, generated API client usage) to build the consumer list.
+
+## When to push back
+
+Push back if the user says:
+
+- "just forward the error, it's faster to debug that way" — redirect them to server-side logging/tracing instead.
+- "CORS is blocking my testing, just set it to `*`" for anything that also sets credentials — a scoped allowlist (including `localhost` explicitly for local dev) is the correct fix, not a wildcard shipped to production.
+- "nothing should be calling the old shape" without having checked — require the search first.
+- "we'll tell people about the breaking change after we ship it" — the deprecation window has to exist before the breaking change ships, not after.

package/skills/frontend/api-integration-contract-review/references/workflow-and-output.md

@@ -0,0 +1,38 @@
+# Contract Review Workflow and Verdict Contract
+
+Use this reference for the step-by-step review procedure and the required output shape for every API integration contract review. Load the other two references only when the specific concern (authorization/data-minimization, or error-shape/CORS/versioning) is actually in scope for the endpoint under review.
+
+## Workflow
+
+1. **Identify the contract surface.** Is this a direct frontend-to-backend call, or a BFF route handler aggregating/proxying one or more upstream calls? Note every upstream system the response depends on.
+2. **List every field in the response.** For each field, state which caller role(s)/scope(s) need it and why. Any field without a stated justification is a data-minimization finding.
+3. **Trace the authorization path.** Find where the object/resource being requested is checked against the authenticated session. Confirm this check happens server-side, using the session's own identity — not merely by trusting a client-supplied ID as proof of ownership.
+4. **Inspect error handling.** Find where upstream/backend errors are caught and confirm they are mapped to a sanitized client-facing shape before being returned, not forwarded as-is.
+5. **Check CORS configuration.** Confirm the allowed-origin policy is an explicit allowlist (not a wildcard) whenever `Access-Control-Allow-Credentials: true` is set, and confirm the policy matches the actual trust boundary (not a blanket allowance for convenience during development left in place).
+6. **For contract changes, identify existing consumers.** Search the codebase (and ask the user for out-of-repo consumers if the contract is public/cross-team) for callers of the changed field/status-code/error-shape. If any exist and the change is breaking, require a stated deprecation window (dual-write, versioned route, or additive-only change) before approval.
+7. **Verify version-sensitive framework claims via Context7** (see `SKILL.md`'s Context7 Documentation Protocol) before relying on any claim about caching defaults, route-handler behavior, or query-key serialization.
+8. **Issue a verdict** using the decision tree below.
+
+## Decision tree
+
+- Any response field lacks a stated authorization justification → **block** (excessive data exposure).
+- Object-level authorization is not independently re-derived server-side from the authenticated session → **block** (BOLA risk; escalate as a security finding, not a style note).
+- Error responses forward upstream detail (stack traces, internal hostnames, DB/vendor error bodies) → **block**.
+- CORS is wildcard origin combined with credentialed requests → **block**.
+- A breaking contract change has identified existing consumers with no deprecation plan → **block-with-conditions**, naming the required plan.
+- All of the above are resolved, and any version-sensitive framework claim is Context7-verified or flagged unverified with the flag surfaced to the requester → **approve**, or **approve-with-conditions** if only non-blocking conditions (e.g., an unverified Context7 claim pending confirmation) remain.
+
+## Output contract
+
+Every response from this skill must include:
+
+1. The endpoint/route handler and its consumer(s), stated explicitly.
+2. A per-field data-minimization table or list: field → justified for which caller scope, or flagged unjustified.
+3. The authorization enforcement mechanism found in the code, and whether it is independently server-verified (yes/no, with the file/line evidence).
+4. Error-shape and CORS findings, each labeled by severity (blocking / non-blocking).
+5. The versioning/deprecation status for any breaking change, including the consumer list found.
+6. The verdict: approve / approve-with-conditions / block, with every unresolved condition listed explicitly (not implied).
+7. Every version-sensitive framework claim labeled `Context7-verified` or `documentation-based — unverified this session`.
+8. Open questions the review could not resolve from available evidence (e.g., "cannot confirm out-of-repo consumers without a service registry").
+
+A response missing any of these eight elements is an incomplete review, not a shorter one.