azcodr 1.5.2 → 2.0.0

package/.agents/skills/clean-code-refactor/SKILL.md

@@ -1,91 +1,91 @@
----
-name: clean-code-refactor
-description: Use when refactoring existing code to comply with Clean Code, SOLID principles, Pragmatic Programmer practices, or modern design patterns (Strategy, Adapter, Repository, Result pattern). Do not use when merely creating a new feature from scratch, fixing a minor typo, or writing initial tests.
----
-
-# Clean Code & Design Patterns Refactoring Skill
-
-> **Core Purpose:** Transform messy, coupled, or rigid code into clean, expressive, and maintainable implementations adhering to Robert C. Martin's Clean Code, The Pragmatic Programmer, and modern Gang of Four patterns without altering external behavior.
-
----
-
-## 1. When to Use This Skill
-- During the **REFACTOR** stage of the Outside-In TDD double loop (after tests are green).
-- Resolving code smells: long functions (> 30 lines), large classes, excessive parameter lists (> 3 args), primitive obsession, duplicate domain knowledge.
-- Decoupling 3rd-party dependencies using the **Adapter Pattern**.
-- Replacing complex conditional logic (`switch`/`if-else` cascades) with the **Strategy Pattern**.
-- Eliminating untyped exception throwing with the **Result / Either Pattern**.
-- Removing dead or commented-out code to restore readability.
-
----
-
-## 2. Step-by-Step Refactoring Workflow
-
-```
-1. Verify Green Tests ──► 2. Identify Code Smells ──► 3. Select Design Pattern ──► 4. Atomic Surgical Edit ──► 5. Verify 100% Green
-```
-
-### Step 1: Establish the Test Safety Net
-- Never refactor without passing tests.
-- Confirm all existing unit and acceptance tests pass: workspace test command (e.g. `npm test`, `cargo test`, `go test ./...`, `pytest`).
-- If coverage is missing or incomplete, write tests *before* touching production code.
-
-### Step 2: Identify Specific Code Smells
-Target concrete flaws:
-- **Long Method / Violating Single Responsibility**: Extract smaller private helper functions (SLAP principle).
-- **Coupling to 3rd-Party SDK**: Wrap SDK calls inside an application-owned interface (Adapter pattern).
-- **Duplicated Domain Rules**: Consolidate business logic into a single authoritative value object or service (DRY).
-- **Leaky Exceptions**: Convert error throwing across controller/service boundaries into typed `Result<T, E>` unions.
-
-### Step 3: Apply the Appropriate Pattern
-- **Adapter**: Define an interface `IEmailAdapter` or `IPaymentAdapter`. Create an implementation wrapping the open-source library.
-- **Strategy**: Define a strategy interface `ITenantPolicy`. Inject the appropriate strategy based on tenant configuration.
-- **Factory**: Centralize instantiation of complex collaborator graphs.
-- **Repository / Data Mapper**: Decouple domain entities from direct ORM queries.
-
-### Step 4: Execute Atomic Surgical Edits
-- Make one micro-refactor at a time (e.g. rename a method, extract a class).
-- Maintain existing naming conventions and idiomatic type safety.
-- Ensure zero lint or type errors: workspace linter and compiler (e.g. `npm run lint && npm run typecheck`, `cargo clippy`, `golangci-lint`, `mypy`).
-
-### Step 5: Verify Continuous Green State
-- Run tests after every single atomic change: `npm run coverage`.
-- Ensure coverage remains at **100.00%**.
-
----
-
-## 3. Gotchas & What NOT to Do
-
-- **DO NOT** change external functional behavior while refactoring. Refactoring is strictly structural.
-- **DO NOT** refactor without automated tests. A green test suite is non-negotiable.
-- **DO NOT** introduce over-engineering or speculative design patterns for simple, stable code (YAGNI).
-- **DO NOT** mock external 3rd-party types directly in tests; always mock application-owned adapter interfaces.
-- **DO NOT** leave commented-out blocks of old code behind. Clean up completely.
-
----
-
-## 4. Structured Output Template
-
-```markdown
-### Clean Code Refactoring Summary: [Module / Class Name]
-
-1. **Code Smells Identified**:
-   - [Smell 1: e.g. Long method in UserController violating Single Responsibility]
-   - [Smell 2: e.g. Direct coupling to external Stripe SDK in domain service]
-
-2. **Refactoring Steps & Patterns Applied**:
-   - Applied **Adapter Pattern**: Extracted `IPaymentAdapter` to isolate Stripe SDK.
-   - Applied **SLAP & Extract Function**: Decomposed 60-line handler into three 15-line functions.
-   - Applied **Result Pattern**: Replaced generic `throw Error` with typed `Result<Order, OrderError>`.
-
-3. **Verification Evidence**:
-   - Tests Status: PASS (100.00% statement, branch, and function coverage preserved)
-   - Linter Status: PASS (0 ESLint warnings)
-   - Typecheck / Compiler: PASS (0 errors)
-```
-
----
-
-## 5. Subdirectories & Progressive Resources
-- [references/clean_code_smells.md](./references/clean_code_smells.md): Catalog of code smells and their refactoring cures.
-- [references/design_patterns_ts.md](./references/design_patterns_ts.md): Reference implementations of Adapter, Strategy, and Result patterns (illustrated in TypeScript).
+---
+name: clean-code-refactor
+description: Use when refactoring existing code to comply with Clean Code, SOLID principles, Pragmatic Programmer practices, or modern design patterns (Strategy, Adapter, Repository, Result pattern). Do not use when merely creating a new feature from scratch, fixing a minor typo, or writing initial tests.
+---
+
+# Clean Code & Design Patterns Refactoring Skill
+
+> **Core Purpose:** Transform messy, coupled, or rigid code into clean, expressive, and maintainable implementations adhering to Robert C. Martin's Clean Code, The Pragmatic Programmer, and modern Gang of Four patterns without altering external behavior.
+
+---
+
+## 1. When to Use This Skill
+- During the **REFACTOR** stage of the Outside-In TDD double loop (after tests are green).
+- Resolving code smells: long functions (> 30 lines), large classes, excessive parameter lists (> 3 args), primitive obsession, duplicate domain knowledge.
+- Decoupling 3rd-party dependencies using the **Adapter Pattern**.
+- Replacing complex conditional logic (`switch`/`if-else` cascades) with the **Strategy Pattern**.
+- Eliminating untyped exception throwing with the **Result / Either Pattern**.
+- Removing dead or commented-out code to restore readability.
+
+---
+
+## 2. Step-by-Step Refactoring Workflow
+
+```
+1. Verify Green Tests ──► 2. Identify Code Smells ──► 3. Select Design Pattern ──► 4. Atomic Surgical Edit ──► 5. Verify 100% Green
+```
+
+### Step 1: Establish the Test Safety Net
+- Never refactor without passing tests.
+- Confirm all existing unit and acceptance tests pass: workspace test command (e.g. `npm test`, `cargo test`, `go test ./...`, `pytest`).
+- If coverage is missing or incomplete, write tests *before* touching production code.
+
+### Step 2: Identify Specific Code Smells
+Target concrete flaws:
+- **Long Method / Violating Single Responsibility**: Extract smaller private helper functions (SLAP principle).
+- **Coupling to 3rd-Party SDK**: Wrap SDK calls inside an application-owned interface (Adapter pattern).
+- **Duplicated Domain Rules**: Consolidate business logic into a single authoritative value object or service (DRY).
+- **Leaky Exceptions**: Convert error throwing across controller/service boundaries into typed `Result<T, E>` unions.
+
+### Step 3: Apply the Appropriate Pattern
+- **Adapter**: Define an interface `IEmailAdapter` or `IPaymentAdapter`. Create an implementation wrapping the open-source library.
+- **Strategy**: Define a strategy interface `ITenantPolicy`. Inject the appropriate strategy based on tenant configuration.
+- **Factory**: Centralize instantiation of complex collaborator graphs.
+- **Repository / Data Mapper**: Decouple domain entities from direct ORM queries.
+
+### Step 4: Execute Atomic Surgical Edits
+- Make one micro-refactor at a time (e.g. rename a method, extract a class).
+- Maintain existing naming conventions and idiomatic type safety.
+- Ensure zero lint or type errors: workspace linter and compiler (e.g. `npm run lint && npm run typecheck`, `cargo clippy`, `golangci-lint`, `mypy`).
+
+### Step 5: Verify Continuous Green State
+- Run tests after every single atomic change. Use the workspace's own command — do not assume one exists. Verify with the package manifest first (`node -p "JSON.stringify(require('./package.json').scripts)"`); for this template that is `npm test`, with `npm run test:coverage` for the coverage gate.
+- Ensure coverage remains at **100.00%**.
+
+---
+
+## 3. Gotchas & What NOT to Do
+
+- **DO NOT** change external functional behavior while refactoring. Refactoring is strictly structural.
+- **DO NOT** refactor without automated tests. A green test suite is non-negotiable.
+- **DO NOT** introduce over-engineering or speculative design patterns for simple, stable code (YAGNI).
+- **DO NOT** mock external 3rd-party types directly in tests; always mock application-owned adapter interfaces.
+- **DO NOT** leave commented-out blocks of old code behind. Clean up completely.
+
+---
+
+## 4. Structured Output Template
+
+```markdown
+### Clean Code Refactoring Summary: [Module / Class Name]
+
+1. **Code Smells Identified**:
+   - [Smell 1: e.g. Long method in UserController violating Single Responsibility]
+   - [Smell 2: e.g. Direct coupling to external Stripe SDK in domain service]
+
+2. **Refactoring Steps & Patterns Applied**:
+   - Applied **Adapter Pattern**: Extracted `IPaymentAdapter` to isolate Stripe SDK.
+   - Applied **SLAP & Extract Function**: Decomposed 60-line handler into three 15-line functions.
+   - Applied **Result Pattern**: Replaced generic `throw Error` with typed `Result<Order, OrderError>`.
+
+3. **Verification Evidence**:
+   - Tests Status: PASS (100.00% statement, branch, and function coverage preserved)
+   - Linter Status: PASS (0 ESLint warnings)
+   - Typecheck / Compiler: PASS (0 errors)
+```
+
+---
+
+## 5. Subdirectories & Progressive Resources
+- [references/clean_code_smells.md](./references/clean_code_smells.md): Catalog of code smells and their refactoring cures.
+- [references/design_patterns_ts.md](./references/design_patterns_ts.md): Reference implementations of Adapter, Strategy, and Result patterns (illustrated in TypeScript).

package/.agents/skills/clean-code-refactor/references/clean_code_smells.md

@@ -1,27 +1,27 @@
-# Code Smells & Refactoring Cures Reference
-
-Catalog of common code smells and their remedies in modern TypeScript codebases.
-
----
-
-## 1. Bloated Functions (> 25–30 Lines)
-- **Smell**: A single function performs input parsing, business calculation, database persistence, and response formatting.
-- **Cure**: Apply *Extract Function* and *Single Level of Abstraction (SLAP)*. Group lower-level details into descriptive helper functions.
-
----
-
-## 2. Deep Conditional Nesting (Arrow Anti-Pattern)
-- **Smell**: 3+ levels of nested `if / else` blocks checking permissions, status, and input validity.
-- **Cure**: Apply *Guard Clauses* (Return Early) or the *Strategy Pattern* for polymorphic behavior.
-
----
-
-## 3. Direct 3rd-Party Coupling
-- **Smell**: Domain controllers directly importing external SDKs (e.g. `import Stripe from 'stripe'`).
-- **Cure**: Apply the *Adapter Pattern*. Define an interface `IPaymentGateway` owned by the domain. Create an infrastructure adapter implementing the interface.
-
----
-
-## 4. Primitive Obsession & Long Parameter Lists (> 3 Parameters)
-- **Smell**: Methods taking 6 primitive strings and numbers (`createUser(first, last, email, role, phone, tenantId)`).
-- **Cure**: Bundle related fields into a strongly typed DTO or Zod schema (`CreateUserInput`).
+# Code Smells & Refactoring Cures Reference
+
+Catalog of common code smells and their remedies in modern TypeScript codebases.
+
+---
+
+## 1. Bloated Functions (> 25–30 Lines)
+- **Smell**: A single function performs input parsing, business calculation, database persistence, and response formatting.
+- **Cure**: Apply *Extract Function* and *Single Level of Abstraction (SLAP)*. Group lower-level details into descriptive helper functions.
+
+---
+
+## 2. Deep Conditional Nesting (Arrow Anti-Pattern)
+- **Smell**: 3+ levels of nested `if / else` blocks checking permissions, status, and input validity.
+- **Cure**: Apply *Guard Clauses* (Return Early) or the *Strategy Pattern* for polymorphic behavior.
+
+---
+
+## 3. Direct 3rd-Party Coupling
+- **Smell**: Domain controllers directly importing external SDKs (e.g. `import Stripe from 'stripe'`).
+- **Cure**: Apply the *Adapter Pattern*. Define an interface `IPaymentGateway` owned by the domain. Create an infrastructure adapter implementing the interface.
+
+---
+
+## 4. Primitive Obsession & Long Parameter Lists (> 3 Parameters)
+- **Smell**: Methods taking 6 primitive strings and numbers (`createUser(first, last, email, role, phone, tenantId)`).
+- **Cure**: Bundle related fields into a strongly typed DTO or Zod schema (`CreateUserInput`).

package/.agents/skills/clean-code-refactor/references/design_patterns_ts.md

@@ -1,65 +1,65 @@
-# Modern Design Patterns in TypeScript Reference
-
-Production implementations of essential design patterns in full-stack TypeScript.
-
----
-
-## 1. Adapter Pattern (Dependency Isolation)
-
-```typescript
-// 1. Domain Interface (Owned by the application)
-export interface IEmailAdapter {
-  send(to: string, subject: string, html: string): Promise<Result<void, Error>>;
-}
-
-// 2. Open-Source Infrastructure Implementation (e.g. Mailpit/Nodemailer)
-export class NodemailerEmailAdapter implements IEmailAdapter {
-  constructor(private readonly transporter: nodemailer.Transporter) {}
-
-  async send(to: string, subject: string, html: string): Promise<Result<void, Error>> {
-    try {
-      await this.transporter.sendMail({ to, subject, html });
-      return { success: true, value: undefined };
-    } catch (error) {
-      return { success: false, error: error as Error };
-    }
-  }
-}
-```
-
----
-
-## 2. Strategy Pattern (Runtime Policy Swapping)
-
-```typescript
-// 1. Strategy Contract
-export interface ITenantPricingStrategy {
-  calculateMonthlyRate(activeSeats: number): number;
-}
-
-// 2. Concrete Strategies
-export class StandardPricingStrategy implements ITenantPricingStrategy {
-  calculateMonthlyRate(activeSeats: number): number {
-    return activeSeats * 15;
-  }
-}
-
-export class EnterprisePricingStrategy implements ITenantPricingStrategy {
-  calculateMonthlyRate(activeSeats: number): number {
-    return activeSeats * 10 + 500; // Flat base fee
-  }
-}
-```
-
----
-
-## 3. Result / Either Pattern (Type-Safe Errors)
-
-```typescript
-export type Result<T, E = Error> =
-  | { success: true; value: T }
-  | { success: false; error: E };
-
-export const Ok = <T>(value: T): Result<T, never> => ({ success: true, value });
-export const Err = <E>(error: E): Result<never, E> => ({ success: false, error });
-```
+# Modern Design Patterns in TypeScript Reference
+
+Production implementations of essential design patterns in full-stack TypeScript.
+
+---
+
+## 1. Adapter Pattern (Dependency Isolation)
+
+```typescript
+// 1. Domain Interface (Owned by the application)
+export interface IEmailAdapter {
+  send(to: string, subject: string, html: string): Promise<Result<void, Error>>;
+}
+
+// 2. Open-Source Infrastructure Implementation (e.g. Mailpit/Nodemailer)
+export class NodemailerEmailAdapter implements IEmailAdapter {
+  constructor(private readonly transporter: nodemailer.Transporter) {}
+
+  async send(to: string, subject: string, html: string): Promise<Result<void, Error>> {
+    try {
+      await this.transporter.sendMail({ to, subject, html });
+      return { success: true, value: undefined };
+    } catch (error) {
+      return { success: false, error: error as Error };
+    }
+  }
+}
+```
+
+---
+
+## 2. Strategy Pattern (Runtime Policy Swapping)
+
+```typescript
+// 1. Strategy Contract
+export interface ITenantPricingStrategy {
+  calculateMonthlyRate(activeSeats: number): number;
+}
+
+// 2. Concrete Strategies
+export class StandardPricingStrategy implements ITenantPricingStrategy {
+  calculateMonthlyRate(activeSeats: number): number {
+    return activeSeats * 15;
+  }
+}
+
+export class EnterprisePricingStrategy implements ITenantPricingStrategy {
+  calculateMonthlyRate(activeSeats: number): number {
+    return activeSeats * 10 + 500; // Flat base fee
+  }
+}
+```
+
+---
+
+## 3. Result / Either Pattern (Type-Safe Errors)
+
+```typescript
+export type Result<T, E = Error> =
+  | { success: true; value: T }
+  | { success: false; error: E };
+
+export const Ok = <T>(value: T): Result<T, never> => ({ success: true, value });
+export const Err = <E>(error: E): Result<never, E> => ({ success: false, error });
+```

package/.agents/skills/compliance-audit/SKILL.md

@@ -1,120 +1,120 @@
----
-name: compliance-audit
-description: Use when conducting a security, compliance, or vulnerability audit against SOC 2 Type II, ISO/IEC 27001, or OWASP Top 10 controls using open-source scanners (Trivy, Semgrep, Gitleaks, Steampipe, Syft, Grype). Do not use for writing application business logic or routine test authoring.
----
-
-# Compliance & Security Audit Skill (100% Open-Source)
-
-> **Core Purpose:** Execute systematic compliance and vulnerability evaluations against SOC 2 Type II Trust Services Criteria, ISO/IEC 27001 ISMS standards, and the OWASP Top 10 using exclusively open-source security toolchains.
-
----
-
-## 1. When to Use This Skill
-- Preparing for or validating SOC 2 Type II readiness (access controls, tamper-evident audit logging, encryption).
-- Verifying ISO/IEC 27001 Annex A technical security controls.
-- Running comprehensive static analysis and vulnerability scans before a production release.
-- Generating software bill of materials (SBOM) and container vulnerability reports.
-- Reviewing sensitive data handling and GDPR/privacy erasure compliance.
-
----
-
-## 2. Step-by-Step Audit Workflow
-
-```
-1. Secrets & Credentials ──► 2. SAST Analysis ──► 3. Dependency CVEs ──► 4. Architecture & Access ──► 5. Audit Report
-```
-
-### Step 1: Secret & Credential Scan (Open-Source)
-Run open-source secret scanners to verify zero committed keys, tokens, or credentials:
-```bash
-# Using open-source Gitleaks
-gitleaks detect --source . -v
-# Using open-source Secretlint
-npx secretlint "**/*"
-```
-*Pass Criteria:* 0 detected secrets or private keys in git history and working tree.
-
-### Step 2: Static Application Security Testing (SAST)
-Run open-source `semgrep` with security rulesets to detect injection flaws, insecure deserialization, and dangerous sinks:
-```bash
-semgrep --config p/security-audit --config p/owasp-top-ten .
-```
-*Pass Criteria:* 0 High or Critical vulnerabilities.
-
-### Step 3: Dependency & Container Vulnerability Scan
-Run open-source `trivy` and `grype` to audit lockfiles and containers for known CVEs:
-```bash
-# Filesystem CVE scan via Trivy
-trivy fs --severity HIGH,CRITICAL --scanners vuln,misconfig .
-# Generate CycloneDX SBOM via Syft
-syft dir:. -o cyclonedx-json=bom.json
-# Scan SBOM via Grype
-grype sbom:bom.json
-```
-*Pass Criteria:* 0 unpatched Critical or High CVEs in production dependencies.
-
-### Step 4: SOC 2 & ISO 27001 Control Verification
-Audit architectural implementation against compliance baselines:
-- **Audit Logging (CC7.2 / A.12)**: Are all state mutations logged with `{ timestamp, actorId, tenantId, action, entityType, entityId, ipAddress, userAgent, changes: { before, after } }`? Are audit logs write-only and tamper-evident?
-- **Access Control & RBAC (CC6.1 / A.9)**: Are built-in roles protected against mutation (`403 Forbidden`)? Is tenant isolation enforced on every query (`tenantId` predicate)?
-- **Cryptography (CC6.6 / A.10)**: Is TLS 1.3 enforced? Are passwords hashed using Argon2id or bcrypt? Is AES-256-GCM used for sensitive data at rest?
-- **Data Erasure & GDPR**: Does the tenant deletion endpoint cascade purge or pseudonymize user PII across all entities?
-
----
-
-## 3. Gotchas & What NOT to Do
-
-- **DO NOT** use proprietary cloud security scanners when open-source equivalents exist (`trivy`, `semgrep`, `gitleaks`, `syft`, `grype`).
-- **DO NOT** ignore medium/low secrets warnings if they indicate staging credentials or API endpoints.
-- **DO NOT** pass an audit if audit logs lack the `actorId` or `tenantId`. Traceability is a mandatory SOC 2 requirement.
-- **DO NOT** accept raw SQL concatenation anywhere in the codebase. All queries must be parameterized.
-- **DO NOT** recommend disabling security checks or silencing scanner rules without a documented ADR exception in `memory.md`.
-
----
-
-## 4. Structured Audit Output Template
-
-```markdown
-# Security & Compliance Audit Report
-
-- **Date:** [YYYY-MM-DD]
-- **Auditor:** AI Assistant (Compliance Audit Skill)
-- **Frameworks Evaluated:** SOC 2 Type II, ISO/IEC 27001, OWASP Top 10
-
----
-
-## 1. Executive Summary
-- **Overall Status:** [PASS / CONDITIONAL PASS / FAIL]
-- **Critical Issues:** [Count]
-- **High Issues:** [Count]
-
----
-
-## 2. Open-Source Tool Execution Evidence
-| Tool | Target | Status | Findings |
-|---|---|---|---|
-| `gitleaks` | Git Tree | PASS | 0 secrets found |
-| `semgrep` | Source Code | PASS | 0 critical SAST flaws |
-| `trivy` | Dependencies | PASS | 0 high/critical CVEs |
-
----
-
-## 3. Compliance Control Evaluation Matrix
-| Framework | Control ID | Control Description | Status | Evidence / Notes |
-|---|---|---|---|---|
-| **SOC 2** | CC6.1 | Least-privilege RBAC & tenant isolation | PASS | Scoped database queries / RLS |
-| **SOC 2** | CC7.2 | Tamper-evident mutation audit logging | PASS | Audit table with actor tracing |
-| **ISO 27001** | A.10.1 | Cryptographic controls (AES-256, TLS 1.3) | PASS | TLS 1.3 configured, Argon2id auth |
-| **OWASP** | A01 | Broken Access Control checks | PASS | Server-side guards on all routes |
-
----
-
-## 4. Required Remediation Actions
-1. [Action item #1 with assigned file and timeline]
-```
-
----
-
-## 5. Subdirectories & Progressive Resources
-- [references/soc2_iso_controls.md](./references/soc2_iso_controls.md): Detailed mapping of SOC 2 Trust Services Criteria and ISO 27001 Annex A controls.
-- [references/owasp_top10_controls.md](./references/owasp_top10_controls.md): OWASP Top 10 verification checklist and remediation patterns.
+---
+name: compliance-audit
+description: Use when conducting a security, compliance, or vulnerability audit against SOC 2 Type II, ISO/IEC 27001, or OWASP Top 10 controls using open-source scanners (Trivy, Semgrep, Gitleaks, Steampipe, Syft, Grype). Do not use for writing application business logic or routine test authoring.
+---
+
+# Compliance & Security Audit Skill (100% Open-Source)
+
+> **Core Purpose:** Execute systematic compliance and vulnerability evaluations against SOC 2 Type II Trust Services Criteria, ISO/IEC 27001 ISMS standards, and the OWASP Top 10 using exclusively open-source security toolchains.
+
+---
+
+## 1. When to Use This Skill
+- Preparing for or validating SOC 2 Type II readiness (access controls, tamper-evident audit logging, encryption).
+- Verifying ISO/IEC 27001 Annex A technical security controls.
+- Running comprehensive static analysis and vulnerability scans before a production release.
+- Generating software bill of materials (SBOM) and container vulnerability reports.
+- Reviewing sensitive data handling and GDPR/privacy erasure compliance.
+
+---
+
+## 2. Step-by-Step Audit Workflow
+
+```
+1. Secrets & Credentials ──► 2. SAST Analysis ──► 3. Dependency CVEs ──► 4. Architecture & Access ──► 5. Audit Report
+```
+
+### Step 1: Secret & Credential Scan (Open-Source)
+Run open-source secret scanners to verify zero committed keys, tokens, or credentials:
+```bash
+# Using open-source Gitleaks
+gitleaks detect --source . -v
+# Using open-source Secretlint
+npx secretlint "**/*"
+```
+*Pass Criteria:* 0 detected secrets or private keys in git history and working tree.
+
+### Step 2: Static Application Security Testing (SAST)
+Run open-source `semgrep` with security rulesets to detect injection flaws, insecure deserialization, and dangerous sinks:
+```bash
+semgrep --config p/security-audit --config p/owasp-top-ten .
+```
+*Pass Criteria:* 0 High or Critical vulnerabilities.
+
+### Step 3: Dependency & Container Vulnerability Scan
+Run open-source `trivy` and `grype` to audit lockfiles and containers for known CVEs:
+```bash
+# Filesystem CVE scan via Trivy
+trivy fs --severity HIGH,CRITICAL --scanners vuln,misconfig .
+# Generate CycloneDX SBOM via Syft
+syft dir:. -o cyclonedx-json=bom.json
+# Scan SBOM via Grype
+grype sbom:bom.json
+```
+*Pass Criteria:* 0 unpatched Critical or High CVEs in production dependencies.
+
+### Step 4: SOC 2 & ISO 27001 Control Verification
+Audit architectural implementation against compliance baselines:
+- **Audit Logging (CC7.2 / A.12)**: Are all state mutations logged with `{ timestamp, actorId, tenantId, action, entityType, entityId, ipAddress, userAgent, changes: { before, after } }`? Are audit logs write-only and tamper-evident?
+- **Access Control & RBAC (CC6.1 / A.9)**: Are built-in roles protected against mutation (`403 Forbidden`)? Is tenant isolation enforced on every query (`tenantId` predicate)?
+- **Cryptography (CC6.6 / A.10)**: Is TLS 1.3 enforced? Are passwords hashed using Argon2id or bcrypt? Is AES-256-GCM used for sensitive data at rest?
+- **Data Erasure & GDPR**: Does the tenant deletion endpoint cascade purge or pseudonymize user PII across all entities?
+
+---
+
+## 3. Gotchas & What NOT to Do
+
+- **DO NOT** use proprietary cloud security scanners when open-source equivalents exist (`trivy`, `semgrep`, `gitleaks`, `syft`, `grype`).
+- **DO NOT** ignore medium/low secrets warnings if they indicate staging credentials or API endpoints.
+- **DO NOT** pass an audit if audit logs lack the `actorId` or `tenantId`. Traceability is a mandatory SOC 2 requirement.
+- **DO NOT** accept raw SQL concatenation anywhere in the codebase. All queries must be parameterized.
+- **DO NOT** recommend disabling security checks or silencing scanner rules without a documented ADR exception in `memory.md`.
+
+---
+
+## 4. Structured Audit Output Template
+
+```markdown
+# Security & Compliance Audit Report
+
+- **Date:** [YYYY-MM-DD]
+- **Auditor:** AI Assistant (Compliance Audit Skill)
+- **Frameworks Evaluated:** SOC 2 Type II, ISO/IEC 27001, OWASP Top 10
+
+---
+
+## 1. Executive Summary
+- **Overall Status:** [PASS / CONDITIONAL PASS / FAIL]
+- **Critical Issues:** [Count]
+- **High Issues:** [Count]
+
+---
+
+## 2. Open-Source Tool Execution Evidence
+| Tool | Target | Status | Findings |
+|---|---|---|---|
+| `gitleaks` | Git Tree | PASS | 0 secrets found |
+| `semgrep` | Source Code | PASS | 0 critical SAST flaws |
+| `trivy` | Dependencies | PASS | 0 high/critical CVEs |
+
+---
+
+## 3. Compliance Control Evaluation Matrix
+| Framework | Control ID | Control Description | Status | Evidence / Notes |
+|---|---|---|---|---|
+| **SOC 2** | CC6.1 | Least-privilege RBAC & tenant isolation | PASS | Scoped database queries / RLS |
+| **SOC 2** | CC7.2 | Tamper-evident mutation audit logging | PASS | Audit table with actor tracing |
+| **ISO 27001** | A.10.1 | Cryptographic controls (AES-256, TLS 1.3) | PASS | TLS 1.3 configured, Argon2id auth |
+| **OWASP** | A01 | Broken Access Control checks | PASS | Server-side guards on all routes |
+
+---
+
+## 4. Required Remediation Actions
+1. [Action item #1 with assigned file and timeline]
+```
+
+---
+
+## 5. Subdirectories & Progressive Resources
+- [references/soc2_iso_controls.md](./references/soc2_iso_controls.md): Detailed mapping of SOC 2 Trust Services Criteria and ISO 27001 Annex A controls.
+- [references/owasp_top10_controls.md](./references/owasp_top10_controls.md): OWASP Top 10 verification checklist and remediation patterns.

package/.agents/skills/compliance-audit/references/owasp_top10_controls.md

@@ -1,16 +1,16 @@
-# OWASP Top 10 Verification Reference
-
-Verification guidelines for evaluating codebase resistance against the OWASP Top 10 vulnerabilities.
-
-| Vulnerability | Verification Target | Required Implementation Pattern |
-|---|---|---|
-| **A01: Broken Access Control** | Controllers, Route Guards | Server-side role and tenant checks on every endpoint. No client-only route security. |
-| **A02: Cryptographic Failures** | Config, Auth Services | TLS 1.3, Argon2id/Bcrypt for passwords, AES-256-GCM for sensitive fields. No custom hashing. |
-| **A03: Injection** | Database queries, OS calls | Parameterized Prisma queries; prohibit string template concatenation in SQL; avoid `child_process.exec`. |
-| **A04: Insecure Design** | Architectural Flows | Rate-limiting on public/auth routes via Redis; defense-in-depth threat modeling. |
-| **A05: Security Misconfig** | HTTP Headers, Errors | Helmet headers (`CSP`, `HSTS`, `nosniff`); mask stack traces via Standard Error Envelope. |
-| **A06: Vulnerable Components** | Dependencies | Zero high/critical CVEs in `npm audit` / `trivy fs .`; lockfiles committed and verified. |
-| **A07: Auth Failures** | Auth Controller, JWT | In-memory access tokens, HttpOnly refresh cookies, instant Redis JTI blocklisting. |
-| **A08: Software Integrity** | CI/CD, Dependencies | Lockfile SHA-512 hashes enforced; open-source `cosign` container signing. |
-| **A09: Logging Failures** | Logging, Middleware | Structured JSON logs (`pino`) with `x-request-id`; zero credentials or PII in logs. |
-| **A10: SSRF** | Outbound HTTP Clients | Block outbound requests to internal/private IPs (`127.0.0.1`, `10.0.0.0/8`, `169.254.169.254`). |
+# OWASP Top 10 Verification Reference
+
+Verification guidelines for evaluating codebase resistance against the OWASP Top 10 vulnerabilities.
+
+| Vulnerability | Verification Target | Required Implementation Pattern |
+|---|---|---|
+| **A01: Broken Access Control** | Controllers, Route Guards | Server-side role and tenant checks on every endpoint. No client-only route security. |
+| **A02: Cryptographic Failures** | Config, Auth Services | TLS 1.3, Argon2id/Bcrypt for passwords, AES-256-GCM for sensitive fields. No custom hashing. |
+| **A03: Injection** | Database queries, OS calls | Parameterized Prisma queries; prohibit string template concatenation in SQL; avoid `child_process.exec`. |
+| **A04: Insecure Design** | Architectural Flows | Rate-limiting on public/auth routes via Redis; defense-in-depth threat modeling. |
+| **A05: Security Misconfig** | HTTP Headers, Errors | Helmet headers (`CSP`, `HSTS`, `nosniff`); mask stack traces via Standard Error Envelope. |
+| **A06: Vulnerable Components** | Dependencies | Zero high/critical CVEs in `npm audit` / `trivy fs .`; lockfiles committed and verified. |
+| **A07: Auth Failures** | Auth Controller, JWT | In-memory access tokens, HttpOnly refresh cookies, instant Redis JTI blocklisting. |
+| **A08: Software Integrity** | CI/CD, Dependencies | Lockfile SHA-512 hashes enforced; open-source `cosign` container signing. |
+| **A09: Logging Failures** | Logging, Middleware | Structured JSON logs (`pino`) with `x-request-id`; zero credentials or PII in logs. |
+| **A10: SSRF** | Outbound HTTP Clients | Block outbound requests to internal/private IPs (`127.0.0.1`, `10.0.0.0/8`, `169.254.169.254`). |