@hdwebsoft/hdcode-ai-darwin-x64 0.0.6 → 0.0.8

package/resources/skills/hd-code-review/reference/review-checklist.md

@@ -1,47 +1,13 @@
 # Review Checklist — hd-code-review
 
-Reference checklist used by Phase 4 (11-Aspect Review) of the `hd-code-review` skill.
-Apply all 11 aspects to the diff. Note N/A conditions where applicable.
+Reference checklist used by Phase 4 (Tiered Review) of the `hd-code-review` skill.
+Apply aspects in tier order. Tier 1 (blockers) runs first; Tier 2 (advisories) runs after the gate.
 
 ---
 
-## Output Format
+## Tier 1 — Blocker-Prone
 
-### Compact format (passing aspect)
-
-When an aspect has no issues, output a single line:
-
-```
-✓ Aspect N (Name) — no issues
-```
-
-### Full format (failing aspect)
-
-When an aspect has findings, output a finding block:
-
-```
-**Aspect N — Name** [🔴 Blocker / 🟡 Advisory]
-- Finding 1: [description] — [file:line if known]
-- Finding 2: [description] — [file:line if known]
-```
-
-Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with Comments).
-
----
-
-## Aspect 1 — Requirements Coverage
-
-**Verdict impact:** 🔴 Blocker (if task context provided)
-**N/A condition:** Skip entirely if no task context was provided (Path C in Phase 3). Note: `✓ Aspect 1 (Requirements Coverage) — N/A (no task context)`
-
-**Questions to answer:**
-
-- Does every requirement stated in the task appear addressed somewhere in the diff?
-- Are there task items explicitly mentioned that are NOT touched by the diff?
-- Does the diff do things clearly NOT in the task (scope creep beyond what was described)?
-- Are acceptance criteria from the task verifiably satisfied by the changes?
-
-**Blocker trigger:** Any task requirement present in context but absent from the diff.
+Run these aspects first, in order. Print each result immediately after evaluating.
 
 ---
 
@@ -49,7 +15,6 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 **Verdict impact:** 🔴 Blocker
 
-**Questions to answer:**
 
 - Are there logic errors — wrong comparisons, inverted conditions, incorrect boolean logic?
 - Off-by-one errors in loops, ranges, pagination, indices?
@@ -67,7 +32,6 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 **Verdict impact:** 🔴 Blocker
 
-**Questions to answer:**
 
 - What error paths are not handled? What happens when this function throws or returns an error?
 - What edge cases were not considered: empty input, null input, zero, negative numbers, max-length strings, empty arrays, single-element collections?
@@ -81,39 +45,27 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 ---
 
-## Aspect 4 — Better Approach
-
-**Verdict impact:** 🟡 Advisory
-
-**Questions to answer:**
-
-- Is there a simpler algorithm or data structure that achieves the same result with less complexity?
-- Does a utility or helper already exist in the codebase that could replace this implementation?
-  - **ALWAYS use Grep/Glob to verify before suggesting an alternative** — do not recommend something that is already present.
-- Is there a library already imported in the project that handles this case?
-- Is the solution over-engineered for the actual problem size or use case?
-- Is there a more idiomatic way to express this in the language or framework being used?
-
-**Advisory trigger:** A clearly better approach exists AND has been verified NOT already present via Grep/Glob.
-
-> Rule: Do not suggest an alternative approach without first confirming with Grep/Glob that the pattern doesn't already exist in the codebase. Recommending something that's already there wastes the author's time.
-
----
+## Aspect 7 — Security (quick pass)
 
-## Aspect 5 — Redundancy
+**Verdict impact:** 🔴 Blocker for critical issues; 🟡 Advisory for lower severity
 
-**Verdict impact:** 🟡 Advisory
 
-**Questions to answer:**
+- Is user input used in a database query without parameterization or ORM protection?
+- Is there a new endpoint or action without an authentication check?
+- Are secrets, API keys, or credentials hardcoded in the diff?
+- Does a new dependency have known vulnerabilities (note for follow-up if suspected)?
+- Is user input reflected into HTML, SQL, shell commands, or file paths without sanitization?
+- Are there new file upload handlers without type/size validation?
 
-- Is logic copy-pasted from another location in the diff or existing codebase that should be extracted?
-- Does logic from the diff duplicate something that already exists elsewhere? (Verify with Grep/Glob)
-- Is there a utility function already in the codebase that does exactly this?
-- Are variables assigned but never read?
-- Is dead code introduced (unreachable branches, unused imports, unused parameters)?
-- Are there repeated string or numeric literals that should be named constants?
+**PII leak checks:**
+- Is sensitive data (passwords, tokens, PII: email, phone, SSN, DOB, address) written to logs or debug output?
+- Are real PII values hardcoded in test fixtures, seed files, or example data? (Use fake/generated data instead)
+- Does a new or changed API response return more PII fields than the caller actually needs? (over-exposure)
+- Is PII included in error messages or exception traces returned to clients?
+- Is user-identifiable data embedded in URLs (query params, path segments) that could end up in server logs or browser history?
 
-**Advisory trigger:** Confirmed duplication or dead code identified in the diff.
+**Blocker trigger:** Critical issues — injection vectors, missing auth, hardcoded secrets, hardcoded real PII in test data, sensitive data in logs, API responses over-exposing PII.
+**Advisory trigger:** Lower-severity observations that don't create an immediate exploit path (e.g., PII in internal error messages, borderline field exposure).
 
 ---
 
@@ -121,7 +73,6 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 **Verdict impact:** 🔴 Blocker (if changed behavior has no test coverage)
 
-**Questions to answer:**
 
 - Is every new behavior or changed behavior covered by at least one test?
 - Are both happy path (success) and unhappy path (failure, error, rejection) tested?
@@ -135,30 +86,34 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 ---
 
-## Aspect 7 — Security (quick pass)
+## Aspect 1 — Requirements Coverage
 
-**Verdict impact:** 🔴 Blocker for critical issues; 🟡 Advisory for lower severity
+**Verdict impact:** 🔴 Blocker (if task context provided)
+**N/A condition:** Skip entirely if no task context was provided (Path C in Phase 3). Note: `✓ Aspect 1 (Requirements Coverage) — N/A (no task context)`
 
-**Questions to answer:**
 
-- Is user input used in a database query without parameterization or ORM protection?
-- Is there a new endpoint or action without an authentication check?
-- Are secrets, API keys, or credentials hardcoded in the diff?
-- Does a new dependency have known vulnerabilities (note for follow-up if suspected)?
-- Is user input reflected into HTML, SQL, shell commands, or file paths without sanitization?
-- Are there new file upload handlers without type/size validation?
+- Does every requirement stated in the task appear addressed somewhere in the diff?
+- Are there task items explicitly mentioned that are NOT touched by the diff?
+- Does the diff do things clearly NOT in the task (scope creep beyond what was described)?
+- Are acceptance criteria from the task verifiably satisfied by the changes?
 
-**PII leak checks:**
-- Is sensitive data (passwords, tokens, PII: email, phone, SSN, DOB, address) written to logs or debug output?
-- Are real PII values hardcoded in test fixtures, seed files, or example data? (Use fake/generated data instead)
-- Does a new or changed API response return more PII fields than the caller actually needs? (over-exposure)
-- Is PII included in error messages or exception traces returned to clients?
-- Is user-identifiable data embedded in URLs (query params, path segments) that could end up in server logs or browser history?
+**Blocker trigger:** Any task requirement present in context but absent from the diff.
+
+---
+
+## Aspect 11 — Completeness
+
+**Verdict impact:** 🔴 Blocker (if task context provided)
+**N/A condition:** Skip entirely if no task context was provided (Path C in Phase 3). Note: `✓ Aspect 11 (Completeness) — N/A (no task context)`
 
-**Blocker trigger:** Critical issues — injection vectors, missing auth, hardcoded secrets, hardcoded real PII in test data, sensitive data in logs, API responses over-exposing PII.
-**Advisory trigger:** Lower-severity observations that don't create an immediate exploit path (e.g., PII in internal error messages, borderline field exposure).
 
-> Note: This is a quick security pass. For deep security analysis across OWASP Top 10, PII audit, compliance gates, and tenant isolation, run `/hd-security-review code-review` separately.
+- Is every feature or fix mentioned in the task present in the diff — or is something described as done but missing?
+- Are there TODO/FIXME comments in the diff that should have been resolved before submitting?
+- Has documentation been updated if the change affects public-facing behavior, API contracts, or configuration?
+- Are error messages, log messages, and user-facing text updated to reflect the new behavior?
+- If the task described multiple sub-tasks or acceptance criteria, are all of them addressed?
+
+**Blocker trigger:** A described deliverable from the task is absent from the diff. Unresolved TODOs that the task indicates should be complete.
 
 ---
 
@@ -166,7 +121,6 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 **Verdict impact:** Always flagged in a dedicated ⚠️ Breaking Changes block — even when the overall verdict is Approved.
 
-**Questions to answer:**
 
 - Has a public API signature changed (function name, parameter names/types/order, return type)?
 - Has an existing contract or interface been violated (removed fields, renamed fields, changed types)?
@@ -176,7 +130,51 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 - Do other services, clients, or consumers need to update their code or config to work with this change?
 - Has a publicly exported symbol been removed or renamed?
 
-**Output:** Always write a dedicated `### ⚠️ Breaking Changes` block in the verdict output, even if the overall verdict is Approved. If no breaking changes found, write: `No breaking changes detected.`
+**Output:** Always write a dedicated `### ⚠️ Breaking Changes` block immediately after evaluating, even if the overall verdict is Approved. If no breaking changes found, write: `No breaking changes detected.`
+
+---
+
+## Tier 2 — Advisory
+
+Run after the Tier 1 gate. Print each result immediately after evaluating.
+
+---
+
+## Aspect 4 — Better Approach
+
+**Verdict impact:** 🟡 Advisory
+
+
+- Is there a simpler algorithm or data structure that achieves the same result with less complexity?
+- Does a utility or helper already exist in the codebase that could replace this implementation?
+  - **ALWAYS use Grep/Glob to verify before suggesting an alternative** — do not recommend something that is already present.
+- Is there a library already imported in the project that handles this case?
+- Is the solution over-engineered for the actual problem size or use case?
+- Is there a more idiomatic way to express this in the language or framework being used?
+- **API Design** *(when new HTTP endpoints are detected in the diff)*:
+  - HTTP verb appropriate for the operation? (`GET` for reads, `POST` for creates, `PUT`/`PATCH` for updates, `DELETE` for deletes — avoid verbs in URL paths)
+  - Status codes semantically correct? (e.g., `201` for resource creation, `204` for no-content, `400` vs `422` for client errors, `404` vs `403` for missing vs forbidden)
+  - Resource naming follows conventions? (nouns, plural, lowercase, consistent with existing routes)
+  - Pagination design consistent with existing API patterns? (cursor vs offset, same param names)
+  - Response schema consistent with existing endpoints? (same envelope structure, error format)
+
+**Advisory trigger:** A clearly better approach exists AND has been verified NOT already present via Grep/Glob; or an API design smell is found on a new endpoint.
+
+---
+
+## Aspect 5 — Redundancy
+
+**Verdict impact:** 🟡 Advisory
+
+
+- Is logic copy-pasted from another location in the diff or existing codebase that should be extracted?
+- Does logic from the diff duplicate something that already exists elsewhere? (Verify with Grep/Glob)
+- Is there a utility function already in the codebase that does exactly this?
+- Are variables assigned but never read?
+- Is dead code introduced (unreachable branches, unused imports, unused parameters)?
+- Are there repeated string or numeric literals that should be named constants?
+
+**Advisory trigger:** Confirmed duplication or dead code identified in the diff.
 
 ---
 
@@ -184,7 +182,6 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 **Verdict impact:** 🟡 Advisory
 
-**Questions to answer:**
 
 - **Performance:** Does this change have a performance impact at scale? N+1 queries? Unindexed searches on large tables? Unnecessary serialization?
 - **Operational:** Does this change require new environment variables, a specific deployment order, a migration to run first, or infrastructure changes?
@@ -192,6 +189,12 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 - **Data:** Does this change affect existing records — are there data migrations needed? Could it corrupt or invalidate existing data?
 - **UX:** Does this change alter the behavior that existing users rely on, even if not technically a breaking API change?
 - **Team / Dependencies:** Do other teams, services, or consumers need to be notified of this change? Does it create a hidden coupling?
+- **Dependencies:** *(when new packages or libraries are added to the project)*
+  - Is the package necessary, or does an existing utility already cover this use case?
+  - Is the license compatible with the project? (e.g., GPL in a commercial product is a risk)
+  - Does adding this package introduce a circular dependency?
+  - Is the version pinned to a specific range — not floating (`*`, `latest`, or overly broad)?
+  - Is the package actively maintained and not abandoned or deprecated?
 
 **Advisory trigger:** Any non-trivial implication that the reviewer or author may not have considered.
 
@@ -201,7 +204,6 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 **Verdict impact:** 🟡 Advisory by default; 🔴 Blocker if a policy in CODING_STANDARDS.md has `required: yes` and it is violated
 
-**Questions to answer:**
 
 - Are names clear, specific, and consistent with the conventions in CODING_STANDARDS.md?
 - Is the code readable without needing an explanation — would a new team member understand what it does?
@@ -210,6 +212,7 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
   - Feature flags (`required: yes`): is new user-facing code wrapped in a feature flag?
   - Observability (`required: yes`): do new endpoints emit required metrics/traces?
   - i18n (`required: yes`): are there hardcoded user-facing strings?
+  - a11y (`required: yes`): do new interactive UI elements have ARIA labels, alt text, and keyboard support?
 - Are there anti-patterns from CODING_STANDARDS.md Section 2.3 present?
 - Is there unnecessary complexity, confusing abstractions, or over-engineering?
 
@@ -218,17 +221,17 @@ Use 🔴 for blockers (Changes Requested) and 🟡 for advisories (Approved with
 
 ---
 
-## Aspect 11 — Completeness
+## Aspect 12 — Architecture & Design
 
-**Verdict impact:** 🔴 Blocker (if task context provided)
-**N/A condition:** Skip entirely if no task context was provided (Path C in Phase 3). Note: `✓ Aspect 11 (Completeness) — N/A (no task context)`
+**Verdict impact:** 🟡 Advisory
 
-**Questions to answer:**
 
-- Is every feature or fix mentioned in the task present in the diff — or is something described as done but missing?
-- Are there TODO/FIXME comments in the diff that should have been resolved before submitting?
-- Has documentation been updated if the change affects public-facing behavior, API contracts, or configuration?
-- Are error messages, log messages, and user-facing text updated to reflect the new behavior?
-- If the task described multiple sub-tasks or acceptance criteria, are all of them addressed?
+- **SRP:** Does a new class, module, or component take on multiple unrelated responsibilities that could be split into smaller units?
+- **Dependency Inversion:** Are concrete types hardcoded in places where an abstraction (interface, injected dependency) would decouple the code?
+- **Layering:** Does the diff violate defined architectural layers? (e.g., business logic in a route handler, database calls in a domain model, presentation logic in a service)
+- **Coupling:** Does the change introduce tight coupling between modules that should be independent? (e.g., direct cross-module imports instead of going through a defined interface or service boundary)
+- **Circular dependencies:** Does a new import create or extend a module cycle?
+- **Feature / domain boundaries:** Does the change import directly across feature or domain boundaries, bypassing defined service or facade layers?
+- **File placement:** Are new files placed in the correct directory per the project's established conventions?
 
-**Blocker trigger:** A described deliverable from the task is absent from the diff. Unresolved TODOs that the task indicates should be complete.
+**Advisory trigger:** Any architectural smell detectable from reading the diff — layering violation, SRP breach, tight coupling, or boundary bypass.

package/resources/skills/hd-code-review/reference/stacks/apex.md

@@ -0,0 +1,49 @@
+# Stack: Apex — Additional Review Checks
+
+Injected when `.cls`, `.trigger`, or `.apex` files are detected in the diff
+(or `tech_stack: apex` declared). Standalone preset — Apex is not a sub-framework.
+Apply these checks IN ADDITION TO the universal checklist items.
+
+---
+
+## Aspect 2 — Correctness (additional)
+
+- SOQL or DML inside a `for` loop — governor limit violation (max 100 SOQL / 150 DML per transaction); bulkify by collecting IDs first, then query/DML outside the loop.
+- `Database.query()` built via string concatenation of user-controlled input — dynamic SOQL without bind variables; use `:variable` bind syntax instead.
+- Trigger logic written assuming `Trigger.new.size() == 1` — single-record assumption breaks bulk operations from data loads or API calls; process via collections.
+- Test class missing `Test.startTest()` / `Test.stopTest()` around async operations (`@future`, `Queueable`, `Batch`) — async code does not execute, assertions run before results are available.
+
+---
+
+## Aspect 3 — Possible Breakage (additional)
+
+- Trigger without operation guards (`if (Trigger.isBefore && Trigger.isInsert)`) — runs on unintended DML events; add explicit event checks.
+- Hard-coded record type IDs, custom setting values, or user IDs — values differ between orgs and sandboxes; query at runtime or use Custom Metadata.
+- Missing `try/catch` around HTTP callouts — unhandled `CalloutException` rolls back the entire transaction and can corrupt partially-completed DML.
+- HTTP (non-HTTPS) endpoint in `HttpRequest.setEndpoint()` or a Named Credential — TLS not enforced; AppExchange auto-fail; all external endpoints must use HTTPS with TLS 1.2+.
+- Sensitive tokens or API keys passed as URL query parameters in callouts — values are logged in Salesforce debug logs and external server access logs; pass secrets in `Authorization` headers instead.
+- Recursive trigger without a static boolean guard — an update inside a trigger re-fires the same trigger; add a static `alreadyRunning` flag to break the cycle.
+
+---
+
+## Aspect 7 — Security (additional)
+
+- Apex class missing explicit `with sharing` or `without sharing` declaration — sharing rules silently not enforced in ambiguous contexts; always declare intent.
+- Dynamic SOQL string built from user-supplied input without bind variables — SOQL injection; use `String.escapeSingleQuotes()` at minimum, prefer bind variables.
+- Field-level security (FLS) not checked before reading or writing sensitive fields — bypasses org permission model; use `Schema.SObjectField.getDescribe().isAccessible()` or `Security.stripInaccessible()`.
+- Credentials, tokens, or secrets hardcoded in Apex — use Named Credentials or Protected Custom Metadata instead.
+- CRUD permission not checked before DML — `SObjectType.isCreateable()` / `isUpdateable()` / `isDeletable()` not called before insert/update/delete; distinct from FLS and an AppExchange security review auto-fail.
+- `without sharing` on a class that exposes `@AuraEnabled` or `@RestResource` methods — external callers (LWC, REST clients) bypass record-sharing rules; gateway classes must use `with sharing`.
+- Hardcoded profile API names, permission set names, or role names used for access gating — subscriber orgs have different names; use Custom Permissions and `FeatureManagement.checkPermission()` instead.
+- SOQL query missing `WITH SECURITY_ENFORCED` or `AccessLevel.USER_MODE` — these enforce CRUD+FLS in a single clause without manual field enumeration; preferred modern pattern alongside `Security.stripInaccessible()`.
+- Sensitive data (API keys, credentials, tokens) stored in non-Protected Custom Settings or Custom Metadata — set visibility to "Protected"; implement a null getter and `transient private` variable so stored values are never echoed back to the UI.
+- `e.getMessage()` or full exception detail surfaced directly to the UI (page message, JSON response) — leaks internal stack traces and file paths; log details server-side via `System.debug()`, return a generic message to the caller.
+
+---
+
+## Aspect 10 — Code Quality (additional)
+
+- Test methods with no `System.assert*` calls — phantom coverage; the method passes but validates nothing.
+- `@isTest(SeeAllData=true)` on test class — breaks data isolation; tests depend on unpredictable org state; create test data explicitly.
+- `System.debug()` calls left in production code paths — log bloat and potential PII leakage in debug logs; remove or guard with a log level check.
+- Business logic scattered across multiple trigger files for the same object — centralise in a single trigger + handler class pattern per object.

package/resources/skills/hd-code-review/reference/stacks/aura.md

@@ -0,0 +1,39 @@
+# Stack: Aura (Lightning Components) — Additional Review Checks
+
+Injected when `.cmp`, `.app`, `.evt`, or `.intf` files are detected in the diff
+(or `tech_stack: aura` declared). Standalone — does NOT depend on the `lwc` preset.
+Apply these checks IN ADDITION TO the universal checklist items.
+
+---
+
+## Aspect 2 — Correctness (additional)
+
+- `component.get("v.attribute")` result used without a null check before property access — attribute may be unset or conditionally rendered; guard before chaining.
+- Async server action callback code running outside `$A.getCallback()` — Aura framework execution context is lost in async scope; wrap all async callbacks with `$A.getCallback(function() { ... })`.
+- `component.find("aura:id")` used without null check — returns `undefined` when the target element is inside an `aura:if` block that is currently `false`.
+
+---
+
+## Aspect 3 — Possible Breakage (additional)
+
+- Method called on a child component reference obtained via `component.find()` where the child uses `aura:if` — reference is `null` when condition is `false`; check before calling.
+- `$A.enqueueAction` called inside a loop or rapid-fire event handler — queues one server request per iteration; batch records client-side first, then make a single server call.
+
+---
+
+## Aspect 7 — Security (additional)
+
+- `{!v.attribute}` bound to the `value` attribute of `aura:html` when the attribute contains user-supplied content — XSS; use `aura:text` for plain text or apply `{!HTMLENCODE(v.attribute)}`.
+- `@AuraEnabled` Apex method on a class without explicit `with sharing` — sharing rules silently bypassed for the calling user context.
+- External JS loaded via `<script src="https://...">` instead of a Static Resource + `ltng:require` — AppExchange auto-fail; external scripts can be compromised after the security review without Salesforce's knowledge.
+- Third-party library bundled in a Static Resource with known CVEs (jQuery, Bootstrap, etc.) — run RetireJS or Snyk before submission; outdated JS libraries are the #2 most common AppExchange SR failure.
+- CSS loaded via `<link href="...">` tag instead of `<ltng:require>` with a Static Resource — improper CSS load, flagged as a violation in the AppExchange security review.
+- `LightningMessageChannel` component with `isExposed: true` — exposes the LMS channel API to all installed orgs; set to `false` unless cross-cloud communication is explicitly required and documented.
+
+---
+
+## Aspect 10 — Code Quality (additional)
+
+- Business logic (calculations, record manipulation, conditional rules) placed in the Aura client-side controller JS — move to Apex `@AuraEnabled` methods; JS controllers should only handle UI events and call server actions.
+- Aura component duplicates functionality now available in a standard LWC base component (`lightning-datatable`, `lightning-record-form`, etc.) — flag as migration candidate.
+- `console.log()` calls logging user or record data in the Aura controller — leaks PII in browser DevTools console; remove before production.

package/resources/skills/hd-code-review/reference/stacks/cakephp.md

@@ -0,0 +1,50 @@
+# Stack: CakePHP — Additional Review Checks
+
+Injected IN ADDITION to `php` preset when CakePHP signals are detected:
+- `src/Controller/` paths in the diff
+- `config/routes.php` in the diff
+- `"cakephp/cakephp"` in `composer.json`
+
+Contains CakePHP-specific checks only — PHP-level checks are in `php.md`.
+
+---
+
+## Aspect 2 — Correctness (additional)
+
+- `$this->request->getData()` used directly without going through Form validation — raw POST data bypasses CakePHP's validation rules; always validate through a Form or Table's `newEntity()` / `patchEntity()`.
+- `Table::get($id)` without try/catch — throws `RecordNotFoundException` when the record does not exist; use `->find()->where()->first()` with a null check, or catch the exception.
+- N+1: associations accessed in a loop without `contain()` — `foreach ($articles as $a) { $a->user->name; }` fires N+1 queries. Use `->contain(['Users'])` in the finder.
+- Missing `$this->loadComponent('Security')` on controllers handling form submissions — CSRF token validation not active.
+
+---
+
+## Aspect 3 — Possible Breakage (additional)
+
+- Missing `$this->dbConnection->begin()` / `commit()` / `rollback()` around multi-table writes — partial failure leaves data inconsistent; wrap in a transaction.
+- Shell / Command class doing heavy work without progress tracking — long-running CakePHP Console commands should use `$this->io->progressStart()` and handle signals (`SIGTERM`) for graceful shutdown.
+- Missing `allowMethod()` in controller actions that should only accept POST/PUT — action accessible via GET, enabling CSRF bypass or unintended state changes.
+
+---
+
+## Aspect 7 — Security (additional)
+
+- Raw query via `$connection->execute()` with string interpolation — SQL injection. Use `->execute($sql, $params)` with bound parameters.
+- `$this->request->getData()` values passed to `Table::query()` or `->where()` without allowlist — column/value injection risk.
+- Missing `$this->Security->requireSecure()` on actions handling sensitive data — ensures HTTPS is enforced.
+- `HtmlHelper::scriptBlock()` / `HtmlHelper::tag()` with user content and no escaping — XSS; pass `['escape' => true]` or pre-escape values.
+
+---
+
+## Aspect 10 — Code Quality (additional)
+
+- Fat controller: complex query building, business rules, or multi-model operations directly in controller actions — extract to Table finders, Behaviors, or Service classes.
+- Direct `TableRegistry::getTableLocator()->get()` deep in domain code — use dependency injection via constructor or `$this->fetchTable()` for testability.
+- Missing validation rules in Table `validationDefault()` for new fields — new columns without validation are silently accepted with any value.
+
+---
+
+## Aspect 12 — Architecture & Design (additional)
+
+- Business logic in View templates — CakePHP Views should only format and display data; move logic to Cells, Helpers, or ViewBuilder.
+- Behavior added to a Table without checking for method/event conflicts with existing behaviors — Behaviors share the Table's event system; duplicate event names cause silent overwrites.
+- Direct cross-plugin model access without going through the plugin's public API — creates tight inter-plugin coupling; access other plugins via their exposed service or facade.

package/resources/skills/hd-code-review/reference/stacks/django.md

@@ -0,0 +1,53 @@
+# Stack: Django — Additional Review Checks
+
+Injected INTO ADDITION to `python` preset when Django path signals are detected in the diff
+(views.py, models.py, urls.py, serializers.py, migrations/, or `tech_stack: django` declared).
+Contains Django-specific checks only — Python-level checks are in `python.md`.
+Apply these checks IN ADDITION TO the universal checklist items and `python.md` checks.
+
+---
+
+## Aspect 2 — Correctness (additional)
+
+- `Model.objects.get()` without `try/except ObjectDoesNotExist` (or `DoesNotExist`) — raises an unhandled exception when no record matches. Use `.filter().first()` or catch the exception explicitly.
+- N+1 query: accessing a ForeignKey or ManyToMany field inside a loop without `select_related` / `prefetch_related` — each iteration fires an extra SQL query. Verify with Django Debug Toolbar or query logging.
+- QuerySet evaluated multiple times — `qs = Model.objects.all(); count = len(qs); for obj in qs:` re-evaluates the query. Cache with `list(qs)` or use `.count()` for counting.
+- `update()` or `bulk_create()` bypass model `save()` signals and validators — ensure this is intentional and explicitly documented.
+
+---
+
+## Aspect 3 — Possible Breakage (additional)
+
+- FK or reverse relation accessed in a loop without `select_related`/`prefetch_related` — silent N+1 that passes in tests but degrades under load.
+- `FileField`/`ImageField` upload handler without file size and MIME type validation — DoS via large uploads or unexpected file types.
+- Unguarded `Model.objects.all().delete()` or bulk delete without a `WHERE` clause — accidental full-table wipe.
+- Missing database migration after model field changes — `makemigrations` was not run; deployment will fail or data integrity breaks.
+
+---
+
+## Aspect 7 — Security (additional)
+
+- Raw SQL with string formatting — `Model.objects.raw(f"SELECT * FROM app_model WHERE id={id}")` or `cursor.execute("... WHERE id=" + str(id))` — SQL injection. Use `%s` parameters: `cursor.execute("... WHERE id=%s", [id])`.
+- Missing `@login_required` / `LoginRequiredMixin` / `PermissionRequiredMixin` on views that should be authenticated.
+- `@csrf_exempt` without a justification comment — CSRF protection disabled without documented reason.
+- `mark_safe()` applied to user-generated content — XSS vector. Only use `mark_safe()` on strings you fully control.
+- `DEBUG = True` in a settings file that is not clearly dev-only — exposes stack traces and internal config to users.
+- `ALLOWED_HOSTS = ['*']` in non-dev settings — allows HTTP Host header injection.
+
+---
+
+## Aspect 10 — Code Quality (additional)
+
+- Fat view: business logic (calculations, external API calls, complex conditionals) directly in a view function/class — move to model methods, managers, or a service/use-case layer.
+- `request.POST['key']` accessed directly without form validation — use Django Forms or DRF Serializers to validate and sanitize input at the boundary.
+- Model class missing `__str__` — Django admin and shell repr become meaningless.
+- `CharField`/`TextField` without `max_length` (or without justification for `TextField`) — missing constraint documentation.
+
+---
+
+## Aspect 12 — Architecture & Design (additional)
+
+- Business logic in views instead of model methods, managers, or a service layer — Django's "fat models, thin views" convention; for larger apps, extract to a service/use-case layer.
+- Direct cross-app model imports bypassing a defined service boundary — tight coupling between apps; consider using signals, service functions, or an API contract between apps.
+- Django Signals used for synchronous, in-request business logic — signals make control flow hard to trace, test, and debug; reserve for genuinely decoupled, post-action side effects.
+- Missing `Meta.indexes` on fields used frequently in `.filter()`, `.order_by()`, or JOIN conditions — becomes a performance bottleneck as data grows.

package/resources/skills/hd-code-review/reference/stacks/dotnet.md

@@ -0,0 +1,52 @@
+# Stack: .NET — Additional Review Checks
+
+Injected into Phase 4 aspects when `tech_stack: dotnet` is declared in `docs/REVIEW_STANDARDS.md`.
+Apply these checks IN ADDITION TO the universal checklist items for each aspect.
+
+---
+
+## Aspect 2 — Correctness (additional)
+
+- `async void` method — always wrong outside event handlers; swallows exceptions silently. Use `async Task`.
+- `Task.Result` or `.Wait()` on async code in a synchronous context — deadlock risk in ASP.NET/WPF sync contexts. Use `await` or `ConfigureAwait(false)`.
+- `==` / `!=` on non-primitive reference types — may compare references, not values. Verify `.Equals()` override or pattern matching is appropriate.
+- Unchecked arithmetic in financial/measurement code — use `checked { }` or `decimal` for precision-sensitive ops.
+- Struct mutability via method call on a copy (value semantics trap).
+
+---
+
+## Aspect 3 — Possible Breakage (additional)
+
+- `IDisposable` not wrapped in `using` / `using var` — file handles, DB connections, `HttpClient`, `Stream`, `DbContext` must always be disposed.
+- `CancellationToken` not propagated through async call chains — callers pass tokens that are silently dropped.
+- `ThreadAbortException` catch blocks — no-op in .NET 5+; code relying on it will never trigger.
+- Nullable reference types (NRT) warnings suppressed with `!` (null-forgiving operator) without verification.
+- `Task` returned from `async` method not `await`-ed by caller — fire-and-forget without intent.
+
+---
+
+## Aspect 7 — Security (additional)
+
+- `FromSqlRaw` / `ExecuteSqlRaw` in EF Core with string interpolation or concatenation — SQL injection. Use `FromSqlInterpolated` or `SqlParameter`.
+- Missing `[ValidateAntiForgeryToken]` on state-changing MVC POST actions.
+- `[AllowAnonymous]` added without explicit review comment justifying it.
+- Hardcoded connection strings or secrets — must use environment variables or secrets manager.
+- `JsonSerializer` / `XmlSerializer` deserializing untrusted input without size limits — DoS via large payloads.
+
+---
+
+## Aspect 10 — Code Quality (additional)
+
+- `var` hiding non-obvious types (e.g., `var result = service.DoThing()` — what type is `result`?). Only acceptable when type is evident from the right-hand side.
+- `dynamic` usage without justification comment.
+- Controller action methods containing business logic — should delegate to services.
+- `string.Format` / concatenation where interpolation or `StringBuilder` is cleaner.
+
+---
+
+## Aspect 12 — Architecture & Design (additional)
+
+- Captive dependency: scoped or transient service injected into a singleton — lifetime mismatch causes state corruption.
+- Business logic in EF Core entity classes — entities should be data containers; logic belongs in domain/service layer.
+- Direct `DbContext` usage in controllers bypassing repository or service layer.
+- `static` state in ASP.NET components — not thread-safe under concurrent requests.

package/resources/skills/hd-code-review/reference/stacks/expo.md

@@ -0,0 +1,39 @@
+# Stack: Expo — Additional Review Checks
+
+Injected IN ADDITION to `reactnative` preset when Expo signals are detected:
+- `expo` dependency in `package.json`
+- `app.json` / `app.config.js` / `app.config.ts` in the diff
+- `expo-*` package imports
+
+Contains Expo-specific checks only. All React Native and React checks also apply.
+
+---
+
+## Aspect 2 — Correctness (additional)
+
+- Expo SDK API used that is deprecated or removed in the declared `sdkVersion` — check the Expo changelog; silent runtime failures or missing modules after upgrade.
+- `expo-camera`, `expo-location`, `expo-contacts` etc. used without requesting permissions first — crashes or returns null on first use without the permission request flow.
+- `expo-notifications` `addNotificationReceivedListener` / `addNotificationResponseReceivedListener` called without storing the subscription for removal.
+
+---
+
+## Aspect 3 — Possible Breakage (additional)
+
+- OTA update (EAS Update) pushing JS changes that depend on a new native module not yet in the installed binary — managed workflow OTA cannot add native code; requires a new app store build. Changes to `app.json` plugins, new `expo-*` packages with native code, or `expo-modules-core` usage require a full build.
+- `expo-file-system` paths hardcoded as absolute — file system paths differ between simulators, devices, and OS versions; always use `FileSystem.documentDirectory` or `FileSystem.cacheDirectory` as a base.
+- `Constants.manifest` / `Constants.expoConfig` accessed in bare workflow without checking for null — returns null in bare workflow outside Expo Go.
+
+---
+
+## Aspect 7 — Security (additional)
+
+- Secrets placed in `app.json` `extra` field or `app.config.js` `extra` — the `extra` block is embedded in the app manifest, which is readable from the installed app. Use EAS Secrets or server-side env vars for sensitive values.
+- `EXPO_PUBLIC_` prefixed environment variables — like `NEXT_PUBLIC_`, these are bundled into the JS and visible to anyone who extracts the app bundle. Never use this prefix for secrets.
+- `expo-web-browser` `openAuthSessionAsync` redirect URL not validated — open redirect if the callback URL is user-controlled.
+
+---
+
+## Aspect 9 — Implication Assessment (additional)
+
+- Adding a new `expo-*` plugin with native code while in managed workflow — requires a new EAS build and app store submission; cannot be delivered via OTA update. Flag this explicitly as a deployment implication.
+- `expo-updates` `checkForUpdateAsync` / `fetchUpdateAsync` called on every app launch without a rollback strategy — a bad OTA update can brick the app for all users; ensure a rollback or forced update mechanism is in place.