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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hdwebsoft/hdcode-ai-darwin-x64",
-  "version": "0.0.7",
+  "version": "0.0.8",
   "os": [
     "darwin"
   ],

package/resources/agents/finder.md

@@ -1,7 +1,7 @@
 ---
 description: Fast, parallel code search agent. Use when you need to find files and code based on functionality or concepts, chain multiple searches, or locate all occurrences of patterns across the codebase.
 mode: subagent
-model: hdwebsoft/claude-haiku-4-5
+model: hdwebsoft/claude-haiku-4-5-20251001
 temperature: 1
 color: "#F59E0B"
 tools:

package/resources/agents/mermaid.md

@@ -1,7 +1,7 @@
 ---
 description: Renders Mermaid diagrams for visualizing architecture, workflows, data flows, and code relationships. Use proactively when diagrams convey information better than prose.
 mode: subagent
-model: hdwebsoft/claude-haiku-4-5
+model: hdwebsoft/claude-haiku-4-5-20251001
 temperature: 0.3
 color: "#06B6D4"
 tools:

package/resources/skills/hd-code-review/CODING_STANDARDS.md

@@ -1,45 +1,11 @@
 # Coding Standards
 
-This document defines the baseline coding standards template used by `hd-code-review` as its first layer. It establishes generic conventions and project policy templates. Projects can override and extend it by providing `docs/CODING_STANDARDS.md` in their own repo — the same two-layer inheritance pattern used by `hd-security-review/SECURITY_STANDARDS.md`.
-
----
-
-## Table of Contents
-
-1. [Loading Convention](#1-loading-convention)
-2. [Code Style](#2-code-style)
-3. [Project Policies](#3-project-policies)
-4. [Project Override Convention](#4-project-override-convention)
-
----
-
-## 1. Loading Convention
-
-`hd-code-review` loads coding standards using a two-layer inheritance pattern:
-
-```
-Layer 1 (always):   skills/hd-code-review/CODING_STANDARDS.md   ← this file (generic baseline)
-Layer 2 (override): <project-root>/docs/CODING_STANDARDS.md     ← project-specific (wins on conflict)
-```
-
-**Resolution rules:**
-
-- Layer 1 is always loaded first — it provides the generic baseline.
-- If the project has `docs/CODING_STANDARDS.md`, load it as Layer 2.
-- Where both layers define the same section or field, the **project (Layer 2) values win**.
-- Sections present only in Layer 1 and absent from Layer 2 remain active (fallback).
-- Project Layer 2 is **additive and overriding** — it does not replace Layer 1 wholesale; it patches it.
-
-**Behavioral contract for the skill:**
-
-The skill must explicitly implement this load order. It is not enforced by tooling — it is a behavioral contract. When a project layer exists, the skill should note which standards are active and which policies have `required: yes` set.
+Baseline used by `hd-code-review` (Layer 1). Projects override via `docs/CODING_STANDARDS.md` (Layer 2 wins on conflict).
 
 ---
 
 ## 2. Code Style
 
-Generic baseline conventions. These serve as defaults when no project override is provided. Projects should replace each placeholder with their actual conventions in `docs/CODING_STANDARDS.md`.
-
 ### 2.1 Naming Conventions
 
 | Element | Convention | Example |
@@ -53,7 +19,6 @@ Generic baseline conventions. These serve as defaults when no project override i
 | Database columns | snake_case | `created_at`, `user_id` |
 | Environment variables | UPPER_SNAKE_CASE | `DATABASE_URL`, `JWT_SECRET` |
 
-> Replace these placeholders with project-specific naming conventions in `docs/CODING_STANDARDS.md`.
 
 ### 2.2 Patterns to Follow
 
@@ -64,7 +29,6 @@ Generic baseline conventions. These serve as defaults when no project override i
 - Immutability by default: prefer immutable data structures where the language supports it
 - Dependency injection over global state
 
-> Projects should extend this list with patterns specific to their stack and architecture.
 
 ### 2.3 Patterns to Avoid
 
@@ -76,7 +40,6 @@ Generic baseline conventions. These serve as defaults when no project override i
 - `any` type in TypeScript without justification
 - Swallowed errors (empty catch blocks)
 
-> Projects should add language-specific and framework-specific anti-patterns to `docs/CODING_STANDARDS.md`.
 
 ### 2.4 Project-Specific Patterns
 
@@ -93,9 +56,7 @@ _Empty at base level — defined by the project in `docs/CODING_STANDARDS.md`._
 
 ## 3. Project Policies
 
-Structured templates for common project-level policies. Each policy records the provider, whether it is required, and the usage pattern expected in code.
-
-**At base level, all policies are `required: no`.** Projects promote policies to `required: yes` in their `docs/CODING_STANDARDS.md` override. When a policy is `required: yes`, violations are treated as **blockers** by `hd-code-review` (not merely advisory).
+All `required: no` at base level. Projects set `required: yes` to make violations blockers.
 
 ---
 
@@ -105,14 +66,10 @@ Structured templates for common project-level policies. Each policy records the
 feature_flags:
   provider: <LaunchDarkly | Unleash | custom | none>
   required: no
-  pattern: |
-    # Describe how feature flags must be used in code.
-    # Example: all new features behind a flag for incremental rollout.
-    # Example pattern:
-    #   if (featureFlag.isEnabled('new-checkout-flow', userId)) { ... }
+  pattern: ~
 ```
 
-> When `required: yes`, every new user-facing feature must be wrapped in a feature flag. Missing flags on new features are a blocker finding.
+> When `required: yes`: new user-facing features without a flag = blocker.
 
 ---
 
@@ -122,15 +79,10 @@ feature_flags:
 observability:
   provider: <OpenTelemetry | Datadog | Prometheus | custom | none>
   required: no
-  requirement: |
-    # Describe observability requirements for new code.
-    # Example: all new endpoints must emit:
-    #   - a request counter metric
-    #   - a latency histogram
-    #   - a distributed trace span
+  requirement: ~
 ```
 
-> When `required: yes`, new endpoints or background workers without metrics and tracing are a blocker finding.
+> When `required: yes`: new endpoints/workers without metrics+tracing = blocker.
 
 ---
 
@@ -139,72 +91,20 @@ observability:
 ```yaml
 i18n:
   required: no
-  requirement: |
-    # No hardcoded user-facing strings in source code.
-    # All user-visible text must go through the i18n translation system.
-    # Example: use t('key') or i18n.t('namespace.key'), never "Hello World" in JSX.
+  requirement: ~
 ```
 
-> When `required: yes`, hardcoded user-facing strings are a blocker finding.
+> When `required: yes`: hardcoded user-facing strings = blocker.
 
 ---
 
-## 4. Project Override Convention
-
-Projects extend this file by creating `docs/CODING_STANDARDS.md` at their repo root. `hd-code-review` loads this file as Layer 2 on top of this base.
-
-**Scaffolding:** `hd-docs-init` scaffolds `docs/CODING_STANDARDS.md` when bootstrapping a new project's documentation. It creates the file with the project's detected stack and placeholder values.
-
-**Maintenance:** `hd-docs-sync` updates `docs/CODING_STANDARDS.md` based on git history and `history/` session logs when code analysis reveals new conventions have been established in the project.
+### 3.4 Accessibility (a11y)
 
-### Example project override file structure
-
-```markdown
-# docs/CODING_STANDARDS.md
-# Project: <project-name>
-# Last updated: YYYY-MM-DD
-
-## 2. Code Style
-
-### 2.1 Naming Conventions
-# (override naming table here — or omit to inherit base defaults)
-
-### 2.4 Project-Specific Patterns
-- All database access must go through repository classes in `src/repositories/`
-- HTTP handlers must use the shared `withErrorHandling()` wrapper
-- All async functions must be explicitly typed with return types (no implicit Promise<any>)
-
-## 3. Project Policies
-
-### 3.1 Feature Flags
-feature_flags:
-  provider: LaunchDarkly
-  required: yes
-  pattern: |
-    Use `ldClient.variation('flag-key', user, false)` for boolean flags.
-    Define flag keys as constants in `src/flags.ts`.
-
-### 3.2 Observability
-observability:
-  provider: OpenTelemetry
-  required: yes
-  requirement: |
-    All new HTTP endpoints must call `metrics.incrementCounter('http.requests', { route })`.
-    All new background jobs must create a root trace span via `tracer.startActiveSpan(...)`.
-
-### 3.3 Internationalization (i18n)
-i18n:
-  required: yes
-  requirement: |
-    No hardcoded user-visible strings. Use `t('namespace.key')` from react-i18next.
-    Add keys to `public/locales/en/translation.json` before using them.
+```yaml
+a11y:
+  required: no
+  requirement: ~
 ```
 
-**Override resolution summary:**
+> When `required: yes`: new UI elements missing ARIA labels/alt text/keyboard support = blocker.
 
-| Scenario | Result |
-|----------|--------|
-| Project defines Section 2.4 | Project section used; base Section 2.4 placeholder replaced |
-| Project sets `required: yes` on a policy | Policy becomes a blocker in hd-code-review |
-| Project omits a section entirely | Base layer section remains active |
-| Project adds a new section not in base | Applied additively; base is unchanged |

package/resources/skills/hd-code-review/REVIEW_STANDARDS.md

@@ -0,0 +1,76 @@
+# Review Standards
+
+Baseline used by `hd-code-review` (Layer 1). Projects override via `docs/REVIEW_STANDARDS.md` (Layer 2 wins on conflict).
+
+---
+
+## 1. Tech Stack
+
+```yaml
+tech_stack: ~
+# Default (~): auto-detected from diff file extensions in Phase 4.
+#   .cs / .csproj / .sln           → dotnet
+#   .ts / .js / package.json       → nodejs
+#   mixed extensions in one diff   → all matching presets loaded
+#
+# Override (set explicitly) when auto-detection would be wrong:
+#   tech_stack: dotnet             ← force single stack
+#   tech_stack: [dotnet, nodejs]   ← force multiple stacks
+#
+# Available presets: dotnet | nodejs | react | reactnative | expo | vuejs | python | django | go | flutter | php | laravel | cakephp | wordpress | scala | apex | lwc | aura | visualforce
+# (Add more by creating reference/stacks/<name>.md following the existing preset format)
+```
+
+> Stack presets live in `reference/stacks/`. Auto-detection means zero config is needed for most projects.
+> Set `tech_stack` explicitly only to override the detected value.
+
+---
+
+## 2. Aspect Escalations
+
+```yaml
+aspect_escalations: []
+# Promote Tier 2 advisory aspects to Tier 1 blocker for this project.
+# Example:
+# - aspect: 12      # Architecture & Design
+#   level: blocker
+# - aspect: 5       # Redundancy
+#   level: blocker
+```
+
+---
+
+## 3. Remote URL
+
+```yaml
+remote_url: ~
+# Optional. Override the auto-detected git remote URL for generating platform links in findings.
+# Use when the auto-detected remote is wrong, the remote is self-hosted, or git remote is unavailable.
+#
+# Set to the repo's blob base URL — the skill will append /<branch>/<file>#L<line> automatically.
+# Examples:
+#   remote_url: "https://github.com/myorg/myrepo"
+#   remote_url: "https://gitlab.mycompany.com/myorg/myrepo"
+#   remote_url: "https://bitbucket.org/myorg/myrepo"
+#
+# Leave as ~ to use auto-detection from `git remote get-url origin`.
+```
+
+---
+
+## 4. Custom Aspects
+
+```yaml
+custom_aspects: []
+# Add project-specific review dimensions beyond the 12 universal aspects.
+# Example:
+# - name: "API Documentation"
+#   tier: 2                    # 1 = run in Tier 1 (blocker-prone), 2 = Tier 2 (advisory)
+#   check: "New public endpoints must have JSDoc annotations and appear in OpenAPI spec"
+#   trigger: advisory          # advisory | blocker
+#
+# - name: "Repository Pattern"
+#   tier: 1
+#   check: "Database access must go through the repository layer — no direct DbContext in controllers"
+#   trigger: blocker
+```