@nano-step/skill-manager 5.6.0 → 5.6.2

package/skills/pr-code-reviewer/references/subagent-prompts.md

@@ -0,0 +1,323 @@
+# Subagent Prompt Templates
+
+Launch ALL 4 subagents simultaneously with `run_in_background: true`.
+
+**IMPORTANT**: Include the PR Summary in each subagent's context so they understand the overall change.
+
+**IMPORTANT**: If project memory results were gathered in Phase 1, include them as a `## NANO-BRAIN MEMORY` section in each subagent's prompt.
+
+**IMPORTANT**: Include `$REVIEW_DIR` (the temp clone path from Phase 0) in each subagent's prompt. All file reads, grep searches, and LSP operations MUST target this path — NOT the original workspace repo. This ensures subagents see the actual PR branch code.
+
+**IMPORTANT**: If Phase 2 produced cross-repo tracing results or a Premise Check (for DELETION changes), include them as `## CROSS-REPO TRACING` and `## PREMISE CHECK` sections in each subagent's prompt.
+
+```
+## REVIEW DIRECTORY
+All file reads and searches MUST use this path (temp clone of PR branch):
+  ${REVIEW_DIR}
+Do NOT read from the original workspace repo — it may be on a different branch.
+```
+
+## Filtering Rules (Include in ALL subagent prompts)
+
+Every subagent MUST apply these rules before returning findings:
+
+```
+## FILTERING RULES (MANDATORY)
+- ONLY report findings that would make a senior engineer stop and think
+- SKIP anything a linter/formatter would catch (let tools handle those)
+- SKIP style nits that don't affect readability or correctness
+- SKIP obvious comments like "add JSDoc to this function" unless it's a public API
+- For each finding, ask: "Would I block a PR for this?" If no → downgrade or drop
+- Severity guide:
+  - critical: Blocks merge. Security hole, data loss, crash, logic bug
+  - warning: Should fix before merge. Edge case, missing validation, race condition
+  - improvement: Code works but can be better. Cleaner, faster, more idiomatic
+  - suggestion: Nice-to-have. Won't block, won't even flag strongly
+
+## EVIDENCE REQUIREMENT (MANDATORY for critical/warning)
+- Every finding with severity `critical` or `warning` MUST include an `evidence` field
+- Evidence MUST cite specific file paths and line numbers you actually read
+- Findings with severity `critical` or `warning` that lack evidence will be AUTO-DOWNGRADED to `suggestion` by the orchestrator
+- `improvement` and `suggestion` findings do NOT require evidence (field can be empty)
+
+## VERIFICATION PROTOCOL (MANDATORY for critical/warning)
+
+Before reporting any finding with severity `critical` or `warning`, complete these 4 steps:
+
+### Step 1: IDENTIFY
+What looks wrong? State the specific concern.
+
+### Step 2: TRACE
+Read the surrounding context beyond the changed file. For each concern type:
+- **Error handling**: Trace the throw/error path UP to the HTTP boundary (controller/route handler). Check for try-catch at EVERY layer between the throw and the controller.
+- **Null safety**: Trace the data DOWN to its source (SQL query, API contract, constructor). Check if the source guarantees non-null (e.g., DB primary key, NOT NULL column, JOIN constraint).
+- **Framework patterns**: Check if the specific usage context makes the pattern safe (e.g., Pinia singleton backing a composable, client-only component, intentionally non-reactive value).
+- **Logic errors**: Construct a CONCRETE triggering scenario with specific input values that would cause the bug.
+
+### Step 3: VERIFY
+Can you PROVE this is a real problem? You need ONE of:
+- A concrete execution path that reaches the bug (with specific inputs)
+- A missing handler at the HTTP boundary (cite the controller file:line where the catch SHOULD be but ISN'T)
+- A data source that can actually produce the problematic value (cite the query/API that returns nullable data)
+
+If you cannot construct concrete proof after tracing → DROP the finding silently.
+
+### Step 4: DECIDE
+- **Verified** → Report with `evidence` field containing your proof (file:line references)
+- **Unverifiable** (too many layers, external system) → Report as `suggestion` with `evidence: "unverified: {reason}"`
+- **Disproven** (e.g., try-catch exists at boundary, data source is non-null) → DROP silently. Do NOT report.
+
+## EVIDENCE EXAMPLES
+
+GOOD evidence (concrete, traceable):
+- "Throw at `openSearchService.js:870` propagates through `insightService.js:939` (no catch) → `metaService.js:158` (no catch) → controller `meta.js:28` has NO try-catch. Error reaches HTTP boundary unhandled."
+- "`.id` comes from `fetchItemMetaImages` SQL query at `metaRepo.js:332` using LEFT JOIN — `imiu.item_id` can be NULL when no image row exists."
+- "AbortController is non-reactive by design — backed by Pinia singleton store at `useTradeSimilarItemsStore.js:3`, composable creates one closure per component lifecycle."
+
+BAD evidence (will be auto-downgraded by orchestrator):
+- "This could throw an error" (no trace to boundary)
+- "This might be null" (no trace to data source)
+- "This violates best practices" (no concrete impact)
+- "Missing error handling" (didn't check if caller handles it)
+```
+
+## Subagent 1: EXPLORE — Code Quality & Patterns
+
+```javascript
+delegate_task({
+  subagent_type: "explore",
+  load_skills: [],
+  run_in_background: true,
+  prompt: `
+    ## REVIEW DIRECTORY
+    All file reads and searches MUST use this path (temp clone of PR branch):
+      ${REVIEW_DIR}
+    Do NOT read from the original workspace repo — it may be on a different branch.
+    
+    ## PR SUMMARY
+    ${prSummary}
+    
+    ## CHANGED FILES
+    ${changedFilesWithDiff}
+    
+    ## TRACED DEPENDENCIES
+    ${tracedDependencies}
+    
+    ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
+    ${projectMemory || "No nano-brain memory available for this workspace"}
+    
+    ## LINEAR TICKET CONTEXT (from linked Linear ticket)
+    ${linearTicketContext || "No Linear ticket linked to this PR"}
+    
+    ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
+    ${crossRepoTracing || "No cross-repo tracing performed"}
+    
+    ## PREMISE CHECK (for DELETION changes — why the code existed)
+    ${premiseCheck || "Not a DELETION change — no premise check needed"}
+    
+    ${FILTERING_RULES}
+    
+    ## TASK
+    Analyze code quality, patterns, and improvement opportunities
+    
+    ## CHECK
+    1. Error handling patterns — missing catches, swallowed errors, generic catches
+    2. Type safety — any casts, missing null checks, unsafe assertions
+    3. Code duplication — repeated logic that should be extracted
+    4. Complexity — deep nesting, long functions, god objects
+    5. **Code improvements** — cleaner alternatives, better abstractions, simpler logic
+    6. **Dead code from deletions** — if code was removed, check if related code (exports, i18n keys, config) is now orphaned
+    
+    DO NOT report: naming nits, formatting, import order, missing comments on obvious code
+    
+    ## RETURN FORMAT
+    JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
+    severity: "critical" | "warning" | "improvement" | "suggestion"
+    evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
+    confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
+    trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
+  `
+});
+```
+
+## Subagent 2: ORACLE — Security & Logic
+
+```javascript
+delegate_task({
+  subagent_type: "oracle",
+  load_skills: [],
+  run_in_background: true,
+  prompt: `
+    ## REVIEW DIRECTORY
+    All file reads and searches MUST use this path (temp clone of PR branch):
+      ${REVIEW_DIR}
+    Do NOT read from the original workspace repo — it may be on a different branch.
+    
+    ## PR SUMMARY
+    ${prSummary}
+    
+    ## CHANGED FILES
+    ${changedFilesWithDiff}
+    
+    ## TRACED DEPENDENCIES
+    ${tracedDependencies}
+    
+    ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
+    ${projectMemory || "No nano-brain memory available for this workspace"}
+    
+    ## LINEAR TICKET CONTEXT (from linked Linear ticket)
+    ${linearTicketContext || "No Linear ticket linked to this PR"}
+    
+    ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
+    ${crossRepoTracing || "No cross-repo tracing performed"}
+    
+    ## PREMISE CHECK (for DELETION changes — why the code existed)
+    ${premiseCheck || "Not a DELETION change — no premise check needed"}
+    
+    ${FILTERING_RULES}
+    
+    ## TASK
+    Deep security, logic analysis, and logic improvement opportunities
+    
+    ## CHECK
+    1. OWASP Top 10 vulnerabilities
+    2. Logic correctness (especially for LOGIC-type changes)
+    3. Edge cases and boundary conditions
+    4. Race conditions and state management
+    5. Input validation gaps
+    6. Authentication/authorization holes
+    7. **Logic improvements** — simpler conditionals, better error paths, clearer state machines
+    8. **Ticket alignment** — do the code changes match the acceptance criteria from the Linear ticket?
+    9. **Cross-repo data consistency** — if the code consumes API data, do frontend assumptions match backend behavior? Are there hardcoded values that should come from backend config?
+    10. **Deletion premise validation** — if code was deleted: Was the code there for a valid reason? Is removal the right fix, or should the logic be corrected instead? Does the deletion hide a problem rather than solve it?
+    
+    CRITICAL: For any if-else or conditional changes, trace ALL code paths affected.
+    CRITICAL: For DELETION changes, you MUST evaluate whether removal is correct or whether the code should be FIXED instead. Challenge the PR's premise — don't assume deletion is the right approach.
+    CRITICAL: For any data consumed from an API, verify the frontend's interpretation matches the backend's actual behavior. Flag hardcoded values that correspond to backend config.
+    
+    DO NOT report: theoretical vulnerabilities with no realistic attack vector in this context
+    
+    ## RETURN FORMAT
+    JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
+    severity: "critical" | "warning" | "improvement" | "suggestion"
+    evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
+    confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
+    trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
+  `
+});
+```
+
+## Subagent 3: LIBRARIAN — Documentation & Best Practices
+
+```javascript
+delegate_task({
+  subagent_type: "librarian",
+  load_skills: [],
+  run_in_background: true,
+  prompt: `
+    ## REVIEW DIRECTORY
+    All file reads and searches MUST use this path (temp clone of PR branch):
+      ${REVIEW_DIR}
+    Do NOT read from the original workspace repo — it may be on a different branch.
+    
+    ## PR SUMMARY
+    ${prSummary}
+    
+    ## CHANGED FILES
+    ${changedFilesWithDiff}
+    
+    ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
+    ${projectMemory || "No nano-brain memory available for this workspace"}
+    
+    ## LINEAR TICKET CONTEXT (from linked Linear ticket)
+    ${linearTicketContext || "No Linear ticket linked to this PR"}
+    
+    ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
+    ${crossRepoTracing || "No cross-repo tracing performed"}
+    
+    ## PREMISE CHECK (for DELETION changes — why the code existed)
+    ${premiseCheck || "Not a DELETION change — no premise check needed"}
+    
+    ${FILTERING_RULES}
+    
+    ## TASK
+    Best practices review and idiomatic improvement opportunities
+    
+    ## CHECK
+    1. Framework anti-patterns (Next.js, React, Express, etc.)
+    2. Library misuse — using APIs incorrectly or suboptimally
+    3. **Idiomatic improvements** — more idiomatic usage of language/framework features
+    4. Missing docs ONLY on public APIs or complex algorithms
+    5. **Orphaned resources** — if code was deleted, check for orphaned i18n keys, unused imports, dead CSS classes, abandoned config entries
+    
+    DO NOT report: missing JSDoc on internal functions, obvious code, or private helpers
+    
+    ## RETURN FORMAT
+    JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
+    severity: "critical" | "warning" | "improvement" | "suggestion"
+    evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
+    confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
+    trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
+  `
+});
+```
+
+## Subagent 4: GENERAL — Tests & Integration
+
+```javascript
+delegate_task({
+  subagent_type: "general",
+  load_skills: [],
+  run_in_background: true,
+  prompt: `
+    ## REVIEW DIRECTORY
+    All file reads and searches MUST use this path (temp clone of PR branch):
+      ${REVIEW_DIR}
+    Do NOT read from the original workspace repo — it may be on a different branch.
+    
+    ## PR SUMMARY
+    ${prSummary}
+    
+    ## CHANGED FILES
+    ${changedFilesWithDiff}
+    
+    ## TRACED TEST FILES
+    ${tracedTestFiles}
+    
+    ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
+    ${projectMemory || "No nano-brain memory available for this workspace"}
+    
+    ## LINEAR TICKET CONTEXT (from linked Linear ticket)
+    ${linearTicketContext || "No Linear ticket linked to this PR"}
+    
+    ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
+    ${crossRepoTracing || "No cross-repo tracing performed"}
+    
+    ## PREMISE CHECK (for DELETION changes — why the code existed)
+    ${premiseCheck || "Not a DELETION change — no premise check needed"}
+    
+    ${FILTERING_RULES}
+    
+    ## TASK
+    Test coverage, integration analysis, and performance improvement opportunities
+    
+    ## CHECK
+    1. Untested critical code paths (logic branches, error handlers)
+    2. Edge cases not covered by tests
+    3. Broken contracts — do changes break existing integrations?
+    4. **Performance improvements** — unnecessary allocations, N+1 queries, missing caching
+    5. Historical regressions — have similar changes caused issues before?
+    6. **Acceptance criteria coverage** — are all acceptance criteria from the ticket addressed by code + tests?
+    7. **Cross-repo contract integrity** — if frontend code was changed/deleted, does it break assumptions the backend relies on? Does the backend expect the frontend to display certain data?
+    
+    DO NOT report: missing tests for trivial getters/setters, style-only changes, or config files
+    
+    ## RETURN FORMAT
+    JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
+    severity: "critical" | "warning" | "improvement" | "suggestion"
+    evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
+    confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
+    trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
+  `
+});
+```

package/skills/pr-code-reviewer/skill.json

@@ -0,0 +1,15 @@
+{
+    "name": "pr-code-reviewer",
+    "version": "3.1.0",
+    "description": "Comprehensive code review with 4 parallel subagents, smart tracing, iterative refinement, workspace-aware configuration, and GitHub Copilot-style PR summaries.",
+    "compatibility": "OpenCode with nano-brain",
+    "agent": null,
+    "commands": [],
+    "tags": [
+        "code-review",
+        "pr",
+        "security",
+        "quality",
+        "subagents"
+    ]
+}

package/skills/rri-t-testing/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: rri-t-testing
+description: RRI-T v2 - Rapid Risk-Informed Testing with BMAD-enhanced risk scoring, traceability, quality gates, and nano-brain memory persistence
+---
+
+# RRI-T v2.0 Testing Skill
+
+Rapid Risk-Informed Testing methodology for AI agents. Guides systematic QA testing through 6 phases with risk scoring, traceability, quality gates, and cross-session memory persistence.
+
+## When to Use
+
+- Testing a new feature before release
+- Validating a bug fix with regression coverage
+- Assessing release readiness with quality gates
+- Building test cases from requirements with traceability
+- Resuming interrupted testing sessions via nano-brain
+
+## Input Parameters
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `feature` | Yes | Feature name or PR reference |
+| `tier` | No | Testing depth: `full` (default), `standard`, `minimal` |
+| `acceptance_criteria` | No | List of acceptance criteria or link to spec |
+| `environment` | No | Target environment (dev/staging/prod) |
+
+## Workflow Phases
+
+### Phase 0: ASSESS
+
+Run testability gate, score risk, classify category, select tier, make go/no-go decision.
+
+**Steps:**
+1. Load `assets/rri-t-testability-gate.md` template
+2. Validate prerequisites (environment, test data, deployment, acceptance criteria)
+3. Assess testability (locators, API docs, auth flows, error states, baselines)
+4. Score risk: Probability (1-3) x Impact (1-3) = Score (1-9)
+5. Classify category: TECH / SEC / PERF / DATA / BUS / OPS
+6. Select tier based on score
+7. Decision: PROCEED / CONCERNS / BLOCK
+
+**Output:** `00-assess.md`, `risk-matrix.md`
+
+**MEMORY SAVE:** `rri-t/{feature}/assess` - Save risk register, tier, decision
+
+---
+
+### Phase 1: PREPARE
+
+Define test scope, assign personas, select dimensions based on tier.
+
+**Steps:**
+1. Define test scope based on tier selection
+2. Assign personas (5 for Full, 3 for Standard, 1 for Minimal)
+3. Select dimensions (7 for Full, 4 for Standard, 2 for Minimal)
+4. Set coverage targets per tier
+5. Create output directory structure
+
+**Output:** `01-prepare.md`
+
+**MEMORY SAVE:** `rri-t/{feature}/prepare` - Save scope, persona assignments, dimension targets
+
+---
+
+### Phase 2: DISCOVER
+
+Run persona interviews, map to dimensions, consolidate findings.
+
+**Steps:**
+1. Load `assets/rri-t-persona-interview.md` template
+2. Run persona interviews using risk-tagged questions
+3. Map questions to dimensions (D1-D7)
+4. Consolidate findings into risk register update
+5. Generate raw test ideas
+
+**Output:** `02-discover.md`
+
+**MEMORY SAVE:** `rri-t/{feature}/discover` - Save interview findings, test ideas, updated risks
+
+---
+
+### Phase 3: STRUCTURE
+
+Create test cases, select stress axes, build traceability matrix.
+
+**Steps:**
+1. Load `assets/rri-t-test-case.md` template
+2. Create test cases with Q-A-R-P-T format + risk category + traceability
+3. Load `assets/rri-t-stress-matrix.md` and select relevant stress axes
+4. Build traceability matrix using `assets/rri-t-traceability-matrix.md`
+5. Identify coverage gaps
+
+**Output:** `03-structure.md`, `traceability.md`
+
+**MEMORY SAVE:** `rri-t/{feature}/structure` - Save test cases, traceability, gaps
+
+---
+
+### Phase 4: EXECUTE
+
+Execute test cases via Playwright MCP, capture evidence, record results.
+
+**Steps:**
+1. Execute test cases using Playwright MCP browser automation
+2. Capture evidence (screenshots, console logs, network requests)
+3. Record results: PASS / FAIL / PAINFUL / MISSING
+4. Calculate quality score using `assets/rri-t-quality-scorecard.md`
+5. Log bugs found
+
+**Output:** `04-execute.md`, `quality-scorecard.md`
+
+**MEMORY SAVE:** `rri-t/{feature}/execute` - Save results, bugs, quality score
+
+---
+
+### Phase 5: ANALYZE
+
+Fill coverage dashboard, apply gate rules, generate final report.
+
+**Steps:**
+1. Load `assets/rri-t-coverage-dashboard.md` template
+2. Fill coverage dashboard with results
+3. Complete traceability matrix with test results
+4. Apply gate decision rules (PASS/CONCERNS/FAIL/WAIVED)
+5. Generate final report
+6. Extract reusable patterns for knowledge base
+
+**Output:** `05-analyze.md`, `coverage-dashboard.md`
+
+**MEMORY SAVE:** `rri-t/{feature}/analyze` - Save gate decision, report, lessons learned, reusable patterns
+
+---
+
+## Output Directory Structure
+
+```
+rri-t-{feature}/
+  00-assess.md              # Phase 0: Testability gate + risk assessment
+  01-prepare.md             # Phase 1: Scope, personas, dimensions
+  02-discover.md            # Phase 2: Interview findings, test ideas
+  03-structure.md           # Phase 3: Test cases, stress selections
+  04-execute.md             # Phase 4: Execution log, evidence
+  05-analyze.md             # Phase 5: Final analysis, recommendations
+  risk-matrix.md            # Risk register with PxI scoring
+  traceability.md           # Requirement-to-test mapping
+  quality-scorecard.md      # 0-100 quality scoring
+  coverage-dashboard.md     # Coverage metrics, gate decision
+  evidence/                 # Screenshots, logs
+```
+
+## Templates
+
+| Template | Purpose |
+|----------|---------|
+| `rri-t-testability-gate.md` | Phase 0 readiness checklist |
+| `rri-t-risk-matrix.md` | PxI risk scoring template |
+| `rri-t-traceability-matrix.md` | Requirement-to-test mapping |
+| `rri-t-quality-scorecard.md` | 0-100 quality scoring |
+| `rri-t-memory-protocol.md` | nano-brain save/resume protocol |
+| `rri-t-test-case.md` | Q-A-R-P-T test case format |
+| `rri-t-persona-interview.md` | 5-persona interview template |
+| `rri-t-coverage-dashboard.md` | Coverage metrics dashboard |
+| `rri-t-stress-matrix.md` | 8-axis stress testing scenarios |
+
+## 7 Dimensions
+
+| ID | Dimension | Target Coverage |
+|----|-----------|-----------------|
+| D1 | UI/UX | >= 85% |
+| D2 | API | >= 85% |
+| D3 | Performance | >= 70% |
+| D4 | Security | >= 85% |
+| D5 | Data Integrity | >= 85% |
+| D6 | Infrastructure | >= 70% |
+| D7 | Edge Cases | >= 85% |
+
+## 5 Personas
+
+| Persona | Focus |
+|---------|-------|
+| End User | Daily usage, speed, clarity, data safety |
+| Business Analyst | Business rules, permissions, data consistency |
+| QA Destroyer | Edge cases, race conditions, malformed inputs |
+| DevOps Tester | Load, recovery, observability, scalability |
+| Security Auditor | Auth, access control, data exposure, audit trails |
+
+## Tier Selection
+
+| Tier | Risk Score | Personas | Dimensions | Stress Axes | Est. Time |
+|------|------------|----------|------------|-------------|-----------|
+| Full | 6-9 | 5 | 7 | 8 | 2-4 hours |
+| Standard | 3-5 | 3 | 4 | 4 | 1-2 hours |
+| Minimal | 1-2 | 1 | 2 | 2 | 30-60 min |
+
+## Release Gates
+
+| State | Criteria |
+|-------|----------|
+| PASS | P0 coverage = 100% AND P1 >= 90% AND overall >= 80% |
+| CONCERNS | P0 = 100% AND P1 = 80-89% AND mitigations documented |
+| FAIL | P0 < 100% OR P1 < 80% OR unresolved security issues |
+| WAIVED | FAIL + business approval + owner + expiry + remediation plan |
+
+## Risk Categories
+
+| Code | Category | Description |
+|------|----------|-------------|
+| TECH | Technical | Architecture/integration fragility |
+| SEC | Security | Security vulnerabilities |
+| PERF | Performance | Performance/scalability issues |
+| DATA | Data | Data integrity/corruption |
+| BUS | Business | Business logic errors |
+| OPS | Operational | Deployment/operational issues |
+
+## Guardrails
+
+- Always run Phase 0 ASSESS before testing
+- Score risk before testing (PxI formula)
+- Use Q-A-R-P-T format for all test cases
+- Map every test case to a requirement (traceability)
+- Capture evidence for all FAIL and PAINFUL results
+- Save to nano-brain after every phase
+- Never skip security dimension for SEC-category risks
+- Document all waivers with owner, expiry, remediation