oh-my-agent-commandcode 0.0.0-stage → 20.38.3

package/skills/oma-pm/resources/task-template.json

@@ -0,0 +1,86 @@
+{
+  "project_name": "",
+  "description": "",
+  "session_id": "{YYYYMMDD}-{HHMMSS}",
+  "lineage_id": "{YYYYMMDD}-{HHMMSS}",
+  "max_attempts": 3,
+  "created": "",
+  "tech_stack": {
+    "frontend": "",
+    "backend": "",
+    "mobile": "",
+    "database": "",
+    "infrastructure": ""
+  },
+  "architecture_decisions": [
+    {
+      "decision": "",
+      "rationale": "",
+      "alternatives_considered": []
+    }
+  ],
+  "tasks": [
+    {
+      "id": "task-1",
+      "goal_id": "task-1",
+      "agent": "backend|frontend|mobile|db|qa|debug|pm|architecture|refactor|tf-infra|docs",
+      "title": "",
+      "description": "",
+      "priority": 1,
+      "dependencies": [],
+      "estimated_complexity": "low|medium|high|very-high",
+      "task": "{self-contained replayable task instruction}",
+      "acceptance_criteria": [{"id": "AC1", "description": "{observable behavior required by the user}"}],
+      "required_checks": [{"id": "check-1", "criteria": ["AC1"], "command": ["{repository verification executable}", "{argument}"], "cwd": "."}],
+      "retry_policy": "manual",
+      "artifacts_expected": [],
+      "scope": [],
+      "test_approach": "tdd|test_after|not_applicable",
+      "test_scope": [],
+      "tdd_evidence_required": true,
+      "test_approach_rationale": "",
+      "alternative_verification": ""
+    }
+  ],
+  "api_contracts": [
+    {
+      "endpoint": "",
+      "method": "GET|POST|PUT|DELETE|PATCH",
+      "request": {},
+      "response": {},
+      "headers": {}
+    }
+  ],
+  "data_models": [
+    {
+      "entity": "",
+      "fields": {}
+    }
+  ],
+  "non_functional_requirements": {
+    "security": [],
+    "performance": [],
+    "scalability": []
+  },
+  "testing_strategy": {
+    "unit_tests": "",
+    "integration_tests": "",
+    "e2e_tests": "",
+    "performance_tests": ""
+  },
+  "project_controls": {
+    "iso_21500": {
+      "scope_defined": false,
+      "stakeholders_identified": [],
+      "dependencies_mapped": false
+    },
+    "iso_31000": {
+      "top_risks": [],
+      "treatments": []
+    },
+    "iso_38500": {
+      "decision_owner": "",
+      "approval_required_for": []
+    }
+  }
+}

package/skills/oma-qa/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: oma-qa
+description: Review changes for correctness, security, accessibility, and
+  performance. Use for scoped quality reviews or verification plans; bug fixes
+  use oma-debug.
+---
+
+# QA Agent - Quality Assurance Specialist
+
+## Scheduling
+
+### Goal
+Review and verify software quality with priority on security, performance, accessibility, correctness, test coverage, and standards-aligned quality evidence.
+
+### Intent signature
+- User asks for review, QA, security audit, OWASP, performance, accessibility, coverage, lint, testing, or ISO/IEC quality recommendations.
+- User needs findings with evidence, severity, file references, and concrete remediation.
+
+### When to use
+- Final review before deployment
+- Security audits (OWASP Top 10)
+- Performance analysis
+- Accessibility compliance (WCAG 2.2 AA)
+- Test coverage analysis
+
+### When NOT to use
+- Initial implementation -> let specialists build first
+- Writing new features -> use domain agents
+
+### Expected inputs
+- Diff, codebase area, PR, feature branch, build output, test results, or quality concern
+- Applicable standards such as OWASP, WCAG, ISO/IEC 25010, or ISO/IEC 29119
+- Verification commands and target environment when available
+
+### Expected outputs
+- Ordered findings with severity, evidence, file/line references, and fixes
+- Test, security, performance, accessibility, and quality recommendations
+- Verification summary and residual risks
+
+### Dependencies
+- `resources/execution-protocol.md`, ISO guide, and checklist
+- Automated tools such as `npm audit`, `bandit`, `lighthouse`, linters, tests, and coverage tools when applicable
+
+### Control-flow features
+- Branches by review type, available diff, quality dimension, and tool availability
+- Reads code and reports; may run tools; generally should not implement broad feature work
+- Findings must be reproducible and prioritized
+
+## Structural Flow
+
+### Entry
+1. Identify review scope and quality dimensions.
+2. Collect diff, files, commands, and standards context.
+3. Choose automated checks before manual review where practical.
+
+### Scenes
+1. **PREPARE**: Define scope, severity rubric, and evidence requirements.
+2. **ACQUIRE**: Read diff/code and run relevant automated tools.
+3. **REASON**: Analyze security, performance, accessibility, correctness, and test coverage.
+4. **VERIFY**: Reproduce findings and reject false positives.
+5. **FINALIZE**: Report findings, remediation, test gaps, and residual risk.
+
+### Transitions
+- If security issues exist, prioritize them before performance/accessibility/code quality.
+- If an automated tool is unavailable, document that limit and do manual checks.
+- Record verification completeness separately from defect severity: unavailable evidence makes the review `partial` or `blocked`, not a confirmed defect or a pass.
+- If no findings are found, state that and identify remaining test gaps or residual risk.
+- If standards-based review is requested, use `resources/iso-quality.md`.
+
+### Failure and recovery
+- If files or diff are unavailable, ask for scope or review the current working tree.
+- If a finding cannot be reproduced, do not report it as a finding.
+- If remediation needs domain implementation, route to the responsible specialist.
+
+### Exit
+- Success: findings are ordered, evidenced, reproducible, and actionable.
+- Partial success: unavailable tools or unverified areas are explicit.
+
+## Logical Operations
+
+### Actions
+| Action | SSL primitive | Evidence |
+|--------|---------------|----------|
+| Read review scope and code | `READ` | Diff, files, reports |
+| Select quality checks | `SELECT` | Security/performance/accessibility/test dimensions |
+| Run automated tools | `CALL_TOOL` | Audit, lint, tests, Lighthouse, coverage |
+| Compare behavior to standards | `COMPARE` | OWASP, WCAG, ISO guides |
+| Validate findings | `VALIDATE` | Reproducibility and evidence |
+| Write review report | `WRITE` | Findings and remediation |
+| Notify outcome | `NOTIFY` | Final review summary |
+
+### Tools and instruments
+- Security, lint, coverage, performance, accessibility, and test tools
+- ISO quality guide and checklist
+
+### Canonical command path
+```bash
+npm audit
+bandit -r .
+lighthouse <url>
+```
+
+Run only the tools that match the detected stack and available target. Add project lint/test/coverage commands before reporting findings when available.
+
+### Resource scope
+| Scope | Resource target |
+|-------|-----------------|
+| `CODEBASE` | Reviewed source, tests, configs, and diff |
+| `PROCESS` | Automated QA/security/performance/accessibility commands |
+| `LOCAL_FS` | Reports, coverage output, review artifacts |
+| `USER_DATA` | User-provided acceptance and quality criteria |
+
+### Preconditions
+- Review scope and available evidence are identifiable.
+- Tools can run or their absence is documented.
+
+### Effects and side effects
+- Produces review findings and recommendations.
+- May run read-heavy or diagnostic commands.
+- Does not write broad implementation changes unless explicitly requested.
+
+### Guardrails
+1. Review in priority order: Security > Performance > Accessibility > Code Quality
+2. Every finding must include file:line, description, and fix
+3. Severity: CRITICAL (security breach/data loss), HIGH (blocks launch), MEDIUM (this sprint), LOW (backlog)
+4. Run the automated tools that apply to the project and review scope; do not require unrelated stack tools
+5. Every defect finding must be reproducible. Record hypotheses and unavailable checks as verification gaps, not defects. Do not issue PASS while required checks remain unverified.
+6. Provide remediation code, not just descriptions
+7. When relevant, map findings to **ISO/IEC 25010** quality characteristics and propose **ISO/IEC 29119**-aligned test improvements
+
+## References
+- Execution steps (follow for the selected task): `resources/execution-protocol.md`
+- ISO quality guide: `resources/iso-quality.md`
+- QA checklist: `resources/checklist.md`
+- Error recovery: `resources/error-playbook.md`
+- Ultrawork VERIFY/SHIP phase protocol: `resources/verify-ship-protocol.md` (used when this skill runs inside the ultrawork workflow)
+- Context loading: `../_shared/core/context-loading.md`
+- Context budget: `../_shared/core/context-budget.md`
+- Runtime lessons: `../_shared/core/session-metrics.md`
+- Code intelligence: `../_shared/core/code-intelligence.md`
+- Observability handoff: `../oma-observability/SKILL.md` §Integrations — canary RUM (Core Web Vitals), backend perf spans

package/skills/oma-qa/resources/checklist.md

@@ -0,0 +1,339 @@
+# QA Review Checklist
+
+Apply checks to the changed scope and the project's declared requirements,
+supported platforms, and existing architecture. Mark irrelevant checks N/A.
+Measure against adopted targets; example sizes, durations, load levels, or
+implementation patterns are not universal acceptance gates. Record required
+checks that could not run as verification gaps, not passes or defect findings.
+
+## Security Checklist
+
+### Authentication & Authorization
+- [ ] Passwords hashed with Argon2id (scrypt/bcrypt acceptable; never MD5/SHA1)
+- [ ] Password policy enforced when local password authentication is used
+- [ ] JWT tokens properly signed and validated when JWT is used
+- [ ] Refresh tokens implemented (if long sessions needed)
+- [ ] Token/session expiry and rotation match the declared authentication policy
+- [ ] Protected endpoints enforce the required authorization; public endpoints are intentionally public
+- [ ] Resource ownership, tenant, and role boundaries match the access model
+- [ ] Admin functions require admin role
+- [ ] Authentication abuse controls match the declared threat model and rate-limit policy
+- [ ] Account lockout after failed login attempts (optional)
+- [ ] MFA available (optional, but recommended)
+
+### Input Validation & Injection
+- [ ] SQL injection: ORM used OR parameterized queries
+- [ ] XSS: Input sanitized, CSP headers set
+- [ ] Command injection: No shell execution with user input
+- [ ] Path traversal: File paths validated
+- [ ] LDAP injection: LDAP queries parameterized
+- [ ] XML injection: XML parsing secure
+- [ ] Email validation (proper regex/library)
+- [ ] URL validation (allowlist for external requests)
+
+### Data Protection
+- [ ] HTTPS enforced (redirect HTTP to HTTPS)
+- [ ] Sensitive data NOT in logs
+- [ ] Sensitive data NOT in error messages
+- [ ] Sensitive data NOT in URLs (use POST body)
+- [ ] Database backups encrypted
+- [ ] PII data encrypted at rest (if applicable)
+- [ ] Secure session management (httpOnly, secure, sameSite cookies)
+
+### API Security
+- [ ] CORS matches allowed clients and credential use; public noncredentialed APIs may deliberately use wildcard origins
+- [ ] CSRF defenses apply to authentication that the browser attaches automatically
+- [ ] Rate limiting on API endpoints
+- [ ] API keys/tokens NOT in source code
+- [ ] API compatibility/versioning follows the affected contract's evolution policy
+- [ ] Proper error handling (no stack traces exposed)
+
+### Dependencies
+- [ ] No high/critical vulnerabilities (npm audit / safety check)
+- [ ] Affected dependencies are supported and satisfy project policy; unrelated upgrades are not required by this review
+- [ ] No unused dependencies
+- [ ] License compliance checked
+
+---
+
+## Performance Checklist
+
+### Backend Performance
+- [ ] Affected API latency meets the declared SLO at representative load
+- [ ] Database queries optimized (no N+1)
+- [ ] Database indexes on foreign keys and frequent queries
+- [ ] Connection pooling configured
+- [ ] Caching is appropriate where measurements or requirements justify it
+- [ ] Pagination for large result sets
+- [ ] Async operations where appropriate
+- [ ] Background jobs for heavy tasks
+
+### Frontend Performance
+- [ ] Adopted frontend performance measures meet the project's thresholds on its supported devices and network conditions
+- [ ] Affected bundle sizes meet the project budget; record measured regressions and relevant baseline
+- [ ] Code splitting implemented
+- [ ] Lazy loading for non-critical components
+- [ ] Images optimized (WebP, compression)
+- [ ] Images lazy loaded (loading="lazy")
+- [ ] Fonts optimized (font-display: swap)
+- [ ] No render-blocking resources
+- [ ] Service worker for caching (optional)
+
+### Mobile Performance
+- [ ] Size and startup time meet the supported platform/device budgets
+- [ ] Scrolling and interaction meet the adopted frame-time targets
+- [ ] No memory leaks
+- [ ] Battery usage minimal
+- [ ] Offline support (if required)
+
+---
+
+## Accessibility Checklist (WCAG 2.2 AA)
+
+### Perceivable
+- [ ] All images have alt text
+- [ ] Decorative images have empty alt (`alt=""`)
+- [ ] Color contrast 4.5:1 (normal text), 3:1 (large text)
+- [ ] Text resizable up to 200% without loss of content
+- [ ] Content understandable without color alone
+- [ ] Audio/video has captions (if applicable)
+
+### Operable
+- [ ] All functionality available via keyboard
+- [ ] No keyboard trap
+- [ ] Focus order is logical
+- [ ] Focus indicators visible
+- [ ] Skip to main content link
+- [ ] No content flashes more than 3 times per second
+- [ ] Enough time to read/interact with content
+- [ ] Pause/stop for moving content
+
+### Understandable
+- [ ] Page language set (`<html lang="en">`)
+- [ ] Clear labels on form inputs
+- [ ] Error messages clear and helpful
+- [ ] Required fields indicated
+- [ ] Consistent navigation across pages
+- [ ] Predictable behavior (no unexpected popups)
+
+### Robust
+- [ ] Valid HTML (semantic tags)
+- [ ] ARIA labels where needed
+- [ ] ARIA roles appropriate
+- [ ] Works with screen readers (test with NVDA/JAWS)
+- [ ] Works in different browsers (Chrome, Firefox, Safari, Edge)
+
+---
+
+## Testing Checklist
+
+### Unit Tests
+- [ ] Coverage meets the project's declared baseline or changed-code target when coverage is applicable; otherwise record risk-focused tests or alternative verification and its limits
+- [ ] Tasks marked `test_approach: tdd` have a `TDD_EVIDENCE` block in the implementation result (focused test command, RED failure, GREEN pass) — see `../../_shared/core/test-approach.md`; do not require this evidence for `test_after` / `not_applicable` tasks
+- [ ] All business logic functions tested
+- [ ] Edge cases covered
+- [ ] Error handling tested
+- [ ] Mocks used appropriately
+- [ ] Test duration and feedback time meet the project's check/CI budget
+- [ ] No flaky tests
+
+### Integration Tests
+- [ ] All API endpoints tested
+- [ ] Database operations tested
+- [ ] Auth flow tested
+- [ ] Error responses tested (401, 403, 404, 500)
+- [ ] Request validation tested
+
+### E2E Tests
+- [ ] Critical user flows tested (registration, login, main feature)
+- [ ] Happy path tested
+- [ ] Error scenarios tested
+- [ ] Mobile responsive tested
+- [ ] Cross-browser tested (Chrome, Firefox, Safari)
+
+### Test Governance
+- [ ] Test levels and scope are defined clearly
+- [ ] Important requirements trace to test cases or test scenarios
+- [ ] Entry / exit criteria are defined for major release decisions
+- [ ] Test design technique is appropriate for risk and feature type
+
+### Performance Tests
+- [ ] Load tests use the adopted workload, concurrency, and traffic model where this change requires them
+- [ ] Stress testing (identify breaking point)
+- [ ] Database under load tested
+- [ ] API rate limits tested
+
+---
+
+## Code Quality Checklist
+
+### Architecture
+- [ ] Clear separation of concerns
+- [ ] Duplication does not create conflicting behavior or excessive change cost
+- [ ] SOLID principles followed
+- [ ] Dependency injection used
+- [ ] Data-access boundaries match the existing backend architecture
+- [ ] Component composition (frontend)
+
+### Code Metrics
+- [ ] Complexity, size, and nesting meet project rules and allow the affected behavior to be understood and verified
+- [ ] Meaningful variable names
+
+### Error Handling
+- [ ] Async failures reach the appropriate handler; no swallowed errors or unhandled rejections
+- [ ] Errors logged appropriately
+- [ ] User-friendly error messages
+- [ ] No silent failures
+- [ ] Graceful degradation
+
+### Documentation
+- [ ] README with setup instructions
+- [ ] API documentation (OpenAPI/Swagger)
+- [ ] Complex logic documented
+- [ ] Environment variables documented
+- [ ] Known incomplete behavior is tracked and does not contradict the required release criteria
+
+---
+
+## ISO Quality Alignment
+
+### ISO/IEC 25010
+- [ ] Functional suitability considered
+- [ ] Performance efficiency considered
+- [ ] Compatibility considered where integration matters
+- [ ] Usability / accessibility considered
+- [ ] Reliability considered
+- [ ] Security considered
+- [ ] Maintainability considered
+- [ ] Portability considered when relevant
+
+### ISO/IEC 29119
+- [ ] Test strategy or test plan exists for significant changes
+- [ ] Test basis, test conditions, and expected results are clear
+- [ ] Risk-based prioritization is visible in test scope
+- [ ] Test evidence and traceability are sufficient for review or audit
+
+---
+
+## Browser Compatibility Checklist
+
+### Desktop
+- [ ] Chrome (latest 2 versions)
+- [ ] Firefox (latest 2 versions)
+- [ ] Safari (latest 2 versions)
+- [ ] Edge (latest 2 versions)
+
+### Mobile
+- [ ] iOS Safari (latest 2 versions)
+- [ ] Android Chrome (latest 2 versions)
+- [ ] Responsive breakpoints (320px, 768px, 1024px, 1440px)
+
+---
+
+## DevOps Checklist
+
+### Environment
+- [ ] Environment variables used (not hardcoded)
+- [ ] .env.example provided
+- [ ] Secrets NOT in source code
+- [ ] Different configs for dev/staging/prod
+
+### Logging
+- [ ] Appropriate log levels (DEBUG, INFO, WARNING, ERROR)
+- [ ] No sensitive data in logs
+- [ ] Structured logging (JSON format)
+- [ ] Log rotation configured
+
+### Monitoring
+- [ ] Health check endpoint (`/health`)
+- [ ] Error tracking (Sentry, Rollbar, etc.)
+- [ ] Performance monitoring (APM)
+- [ ] Uptime monitoring
+
+### Deployment
+- [ ] CI/CD pipeline configured
+- [ ] Automated tests in CI
+- [ ] Database migrations automated
+- [ ] Rollback plan documented
+- [ ] Zero-downtime deployment (if required)
+
+---
+
+## Final Sign-Off
+
+### Critical (Must Pass)
+- [ ] No CRITICAL security vulnerabilities
+- [ ] No HIGH security vulnerabilities
+- [ ] Required checks for the changed behavior pass; missing checks and unrelated baseline failures are recorded separately
+- [ ] Performance meets requirements
+- [ ] No data loss scenarios
+
+### Important (Should Pass)
+- [ ] Applicable coverage target or documented alternative verification met
+- [ ] Accessibility WCAG 2.2 AA
+- [ ] Code quality metrics met
+- [ ] Documentation complete
+
+### Nice-to-Have (Can Address Later)
+- [ ] Code refactoring opportunities documented
+- [ ] Performance optimization ideas documented
+- [ ] Future enhancement ideas documented
+
+---
+
+## Issue Prioritization
+
+### CRITICAL (Block Deployment)
+- Security vulnerabilities (SQL injection, XSS, auth bypass)
+- Data loss bugs
+- Application crashes
+- Complete feature breakage
+
+### HIGH (Fix Before Launch)
+- Confirmed performance failures that violate a launch requirement or block a core workflow
+- Major accessibility violations
+- Missing auth checks
+- Broken core functionality
+
+### MEDIUM (Fix in Sprint)
+- Minor bugs
+- Code quality issues
+- Missing tests
+- Minor accessibility issues
+
+### LOW (Backlog)
+- Refactoring opportunities
+- Performance optimizations
+- Nice-to-have features
+- Documentation improvements
+
+---
+
+## Notes
+
+- Choose available automated checks that match the stack, changed scope, and target; do not require unrelated tools or unrequested builds
+- Use configured code intelligence or the documented native fallback for code analysis patterns
+- Browser verification follows `mcp.devtools_browsers`: Aside (`aside`, default), Chrome DevTools MCP (`chrome`), and Firefox DevTools MCP (`firefox`). Multiple selections are supported; change them with `oma update mcp`. Discover the selected server’s tools before use. Chrome-specific calls below are examples only; use supported equivalents for Aside and Firefox. An empty selection disables browser MCP verification; report unverified UI checks.
+- Document all findings with file:line references
+- Provide remediation code examples
+- Estimate fix time for each issue
+
+---
+
+## Runtime Verification (after static review)
+
+Record results in the structured table format defined in `execution-protocol.md` Step 2.5 (Recording Results).
+Run only applicable, authorized runtime checks on an available target. A static
+document/configuration review does not require starting or building an app.
+
+- [ ] Application starts without errors
+- [ ] All modified endpoints return expected status codes; verify with `list_network_requests()`
+- [ ] Form submissions produce correct database state; verify with `fill_form()` + `list_network_requests()`
+- [ ] Error states render user-friendly messages (not stack traces); verify with `take_snapshot()` on error paths
+- [ ] Empty/loading/error UI states all handled; verify with `navigate_page()` to empty state routes + `take_snapshot()`
+- [ ] Interactive elements respond to input (not display-only); verify with `click(uid)` + `take_snapshot()` before/after
+- [ ] Auth flows work end-to-end (register → login → protected route → logout); verify with sequential `fill()` + `click()` + `list_network_requests()`
+- [ ] Rate limiting / throttling triggers at configured thresholds; verify with rapid `evaluate_script(fetch)` calls
+- [ ] File upload/download actually transfers data (not stubbed); verify with `upload_file(uid, filePath)` + response check
+- [ ] Pagination returns correct pages (not always page 1); verify with `click()` page 2 + `take_snapshot()` to confirm different content
+- [ ] Zero JS console errors on critical paths; verify with `list_console_messages(types: ["error"])`

package/skills/oma-qa/resources/error-playbook.md

@@ -0,0 +1,98 @@
+# QA Agent - Error Recovery Playbook
+
+When you encounter a failure during review, follow these recovery steps.
+Use the relevant recovery steps. If required information or authority is missing, pause the dependent action and continue independent work.
+
+---
+
+## Automated Tool Fails to Run
+
+**Symptoms**: `npm audit`, `bandit`, `lighthouse` command errors
+
+1. Check: is the tool installed? Note missing tool in result
+2. Check: are you in the correct directory?
+3. If `npm audit`: check the lockfile, registry access, and selected dependency scope. A narrower audit does not clear unreviewed dependencies; record exclusions.
+4. If `bandit`: check Python path; may need `python -m bandit`
+5. If `lighthouse`: requires a running server; note if server not available
+6. **If tool unavailable**: Fall back to manual review, record `tool_unavailable: ["tool_name"]` in result
+
+---
+
+## False Positive Suspected
+
+**Symptoms**: Finding looks like a vulnerability but might be safe
+
+1. Trace the data flow: does user input actually reach the dangerous operation?
+2. Check: is there validation/sanitization upstream?
+3. Check: is the framework handling this automatically? (e.g., ORM prevents SQL injection)
+4. If still uncertain, record a hypothesis and the required evidence as a verification gap. Do not assign defect severity without confirming the defect.
+5. Classify a confirmed finding by its observed impact, prerequisites, and failure/exploit evidence; do not issue PASS while required evidence is missing.
+
+---
+
+## Cannot Access Source Code
+
+**Symptoms**: configured code-intelligence tool returns nothing, times out, or a file is not found
+
+1. Check the configured provider's discovered tools and the file path.
+2. Use the documented native scoped-search fallback; do not install, initialize,
+   track, or silently switch providers.
+3. Check whether code is in another package or monorepo directory.
+4. If truly inaccessible: review what you can access and record the coverage gap.
+
+---
+
+## Performance Metrics Unavailable
+
+**Symptoms**: Can't run Lighthouse, no APM data, no load test results
+
+1. Check if dev server is running for Lighthouse
+2. If no server: review code statically for performance anti-patterns:
+   - N+1 queries (loops with DB calls)
+   - Missing pagination
+   - Large bundle imports
+   - No code splitting
+3. Report findings with `static_analysis_only: true` flag
+4. Recommend specific metrics to measure when environment is available
+
+---
+
+## Scope Too Large
+
+**Symptoms**: Full audit requested but codebase has 100+ files
+
+1. Prioritize: auth/security-critical files first
+2. Use pattern search to find high-risk areas:
+   - `search_for_pattern("password|secret|token|api_key")`
+   - `search_for_pattern("execute|eval|innerHTML")`
+3. Review critical paths: auth flow, payment, data mutation
+4. Note in report: `scope_coverage: "critical paths only, full audit requires more"`
+
+---
+
+## Rate Limit / Quota Error
+
+**Symptoms**: `429`, `RESOURCE_EXHAUSTED`, `rate limit exceeded`
+
+1. Identify the source. An expected rate-limit response from the application under review is a test result, not an agent-provider quota failure.
+2. For provider quota exhaustion, stop affected provider calls and record the unavailable checks; continue independent authorized work when possible.
+3. Preserve injected session/task/run IDs and the claim path. Save progress/results under the configured memory base using the task/run-scoped names in `../../_shared/runtime/memory-protocol.md`.
+4. Use a valid claim status (`partial`, `blocked`, or `failed`) with the actual cause and unresolved work per `../../_shared/runtime/result-contract.md`; do not invent a `quota_exceeded` status.
+
+---
+
+## Coordination File Unavailable
+
+Use native file tools and the configured durable memory base per the shared
+memory/result contract. Code-intelligence availability is independent of file
+memory. Record a path/permission error and preserve available evidence in an
+authorized durable artifact location; report the actual saved path rather than
+claiming a missing receipt or substituting an undisclosed `/tmp` result.
+
+---
+
+## General Principles
+
+- **False positive prevention**: Keep uncertain hypotheses separate from confirmed defect findings; state the check needed to resolve each gap
+- **Blocked**: Record a material unavailable prerequisite and affected work; use an accurate result status and continue independent work when possible
+- **No code modification**: QA only reports; delegate code changes to the appropriate agent