mcp-subagents-opencode 1.0.0

package/build/templates/overlays/researcher-library.mdx

@@ -0,0 +1,59 @@
+## LIBRARY EVALUATION REFERENCE
+
+These frameworks help structure library evaluation. Use what's relevant — a simple "which library" question may only need a comparison matrix, while an adoption decision needs the full analysis. Let the research question guide depth.
+
+---
+
+### COMPARISON MATRIX (Template)
+
+When comparing libraries, this structure helps organize findings:
+
+| Criterion | Library A | Library B |
+|-----------|-----------|-----------|
+| Core features | Does it do what we need? | |
+| Performance / bundle size | Benchmarks, minified+gzip | |
+| TypeScript support | Native types? Quality? | |
+| License | Compatible with our project? | |
+| Maintenance | Last release, active issues | |
+| Migration cost | From current → this library | |
+| Community | Downloads, SO questions, Discord | |
+
+---
+
+### GITHUB HEALTH SIGNALS
+
+Quick health check for any library:
+
+| Signal | Healthy | Red Flag |
+|--------|---------|----------|
+| Last commit | <3 months | >12 months |
+| Contributors | >5 active | Single maintainer |
+| Releases | Regular | None in >1 year |
+| Open issues | Triaged, responsive | >500 untriaged |
+
+---
+
+### LICENSE COMPATIBILITY (Reference)
+
+| Our License | Safe | Risky |
+|-------------|------|-------|
+| MIT/Apache | MIT, Apache, BSD, ISC | GPL (copyleft) |
+| GPL | MIT, Apache, GPL, LGPL | Proprietary |
+| Proprietary | MIT, Apache, BSD, ISC | GPL, AGPL |
+
+---
+
+### MIGRATION COST FACTORS
+
+When evaluating a library that replaces an existing one:
+- API surface similarity (drop-in vs complete rewrite)
+- Files affected (scope)
+- Type compatibility
+- Test impact
+- Runtime behavior differences
+
+---
+
+### COMMUNITY HEALTH SIGNALS
+
+Beyond GitHub: npm/PyPI download trends, Stack Overflow activity, Discord/Slack community responsiveness, blog ecosystem, conference talks.

package/build/templates/overlays/researcher-performance.mdx

@@ -0,0 +1,68 @@
+## PERFORMANCE RESEARCH REFERENCE
+
+These frameworks help structure performance research. Use what's relevant — a specific "why is X slow" question needs profiling guidance, while a "should we use X or Y" question needs benchmark methodology. Let the question guide your approach.
+
+---
+
+### BENCHMARK METHODOLOGY
+
+When evaluating or comparing performance:
+- **Warm-up:** Discard first N iterations (JIT, cache warming)
+- **Sample size:** 100+ for micro, 10+ for integration
+- **Percentiles:** Report p50, p95, p99 — not averages (averages hide tail latency)
+- **Environment:** Note hardware, OS, runtime, load — results aren't portable without context
+- **Comparison:** Same environment, same workload, same methodology, warm-up excluded
+
+---
+
+### PROFILING BY LAYER
+
+When investigating performance issues, identify the bottleneck layer first:
+
+| Layer | Tools | Key Metrics |
+|-------|-------|-------------|
+| Frontend | Lighthouse, DevTools | FCP, LCP, CLS, TTI, bundle size |
+| Network | DevTools Network, curl -w | TTFB, transfer size, connections |
+| Backend | Profiler, APM | Response time, CPU, memory |
+| Database | EXPLAIN ANALYZE, slow query log | Query time, index usage, locks |
+| Infrastructure | top, iostat, docker stats | CPU%, memory%, disk I/O |
+
+**Rule of thumb:** Identify WHICH layer is the bottleneck before recommending optimizations.
+
+---
+
+### CORE WEB VITALS (Reference)
+
+| Metric | Good | Poor | Measures |
+|--------|------|------|----------|
+| LCP | <2.5s | >4.0s | Largest content rendered |
+| INP | <200ms | >500ms | Interaction responsiveness |
+| CLS | <0.1 | >0.25 | Visual stability |
+
+Lab tools: Lighthouse, WebPageTest. Field tools: CrUX, RUM.
+
+---
+
+### OPTIMIZATION HIERARCHY
+
+When recommending optimizations, higher levels yield bigger gains:
+
+```
+1. ALGORITHM (Big-O)     — up to 1000x (right data structure? unnecessary work?)
+2. ARCHITECTURE           — up to 100x  (caching, async, connection pooling)
+3. IMPLEMENTATION         — up to 10x   (batching, streaming, pagination)
+4. MICRO-OPTIMIZATION     — up to 2x    (object pooling, SIMD, JIT hints)
+```
+
+A better algorithm always beats a micro-optimized bad algorithm.
+
+---
+
+### DATABASE PERFORMANCE PATTERNS (Reference)
+
+| Problem | Diagnosis | Solution |
+|---------|-----------|----------|
+| Slow queries | EXPLAIN ANALYZE | Add indexes, rewrite, denormalize |
+| N+1 queries | Count queries/request | Eager loading, batch, DataLoader |
+| Lock contention | pg_stat_activity | Optimize transactions, reduce scope |
+| Connection exhaustion | Pool metrics | Pool sizing, timeouts |

package/build/templates/overlays/researcher-security.mdx

@@ -0,0 +1,86 @@
+## SECURITY RESEARCH REFERENCE
+
+These frameworks and references are available to guide your research. Use what's relevant to the specific question — you don't need to apply every framework to every task. Let the research question drive your approach.
+
+---
+
+### OWASP TOP 10 (Reference)
+
+Use when evaluating security posture of a component:
+
+| # | Category | Key Question |
+|---|----------|-------------|
+| A01 | Broken Access Control | Can users act outside their intended permissions? |
+| A02 | Cryptographic Failures | Is sensitive data properly encrypted in transit and at rest? |
+| A03 | Injection | Can untrusted data be interpreted as commands? |
+| A04 | Insecure Design | Are there missing security controls in the architecture? |
+| A05 | Security Misconfiguration | Are defaults secure? Unnecessary features disabled? |
+| A06 | Vulnerable Components | Are dependencies up-to-date? Known CVEs? |
+| A07 | Auth Failures | Can authentication be bypassed? |
+| A08 | Data Integrity Failures | Can software updates or CI/CD pipelines be compromised? |
+| A09 | Logging & Monitoring | Would an attack be detected? |
+| A10 | SSRF | Can the server make requests to internal resources? |
+
+---
+
+### CVE LOOKUP PATTERNS
+
+When researching known vulnerabilities:
+- NVD: `site:nvd.nist.gov [library] [version]`
+- GitHub Advisories: `site:github.com/advisories [library]`
+- Snyk: `site:snyk.io/vuln [library]`
+- Library's own SECURITY.md
+
+For each CVE: note ID, CVSS score, affected versions, whether our version is affected, available fix/patch.
+
+---
+
+### STRIDE THREAT MODEL (Reference)
+
+Useful when analyzing a system for threats:
+
+| Threat | Question |
+|--------|----------|
+| **S**poofing | Can someone impersonate another identity? |
+| **T**ampering | Can data be modified in transit/at rest? |
+| **R**epudiation | Can actions be denied without audit trail? |
+| **I**nformation Disclosure | Can unauthorized data be accessed? |
+| **D**enial of Service | Can the system be made unavailable? |
+| **E**levation of Privilege | Can an attacker gain higher access? |
+
+---
+
+### COMPLIANCE STANDARDS (Reference)
+
+Reference only when the research question involves compliance:
+
+| Standard | Scope | Key Concern |
+|----------|-------|-------------|
+| SOC 2 | SaaS/Cloud | Access control, encryption, monitoring |
+| GDPR | EU user data | Consent, data minimization, deletion rights |
+| HIPAA | Health data | PHI encryption, access logs |
+| PCI DSS | Payment data | Card data encryption, segmentation |
+
+---
+
+### SOURCE AUTHORITY RANKING
+
+For security topics, prefer higher-authority sources:
+
+```
+NIST, RFCs, FIPS > OWASP, CWE, SANS, CVE/NVD > Auth0/Cloudflare/AWS blogs > Reddit, Stack Overflow
+```
+
+---
+
+### SEVERITY CLASSIFICATION
+
+When reporting findings, classify severity to help prioritize:
+
+| Severity | Definition |
+|----------|-----------|
+| CRITICAL | Active exploitation possible, data breach risk |
+| HIGH | Exploitable with minimal skill, significant impact |
+| MEDIUM | Requires specific conditions or moderate skill |
+| LOW | Theoretical risk, minimal impact |
+| INFO | Best practice deviation, no direct risk |

package/build/templates/overlays/tester-graphql.mdx

@@ -0,0 +1,191 @@
+## GRAPHQL API TESTING GUIDELINES
+
+You are testing a **GraphQL API**. GraphQL has unique testing patterns — errors come in the response body (not HTTP status), a single endpoint handles all operations, and schema introspection enables systematic testing.
+
+---
+
+### TOOLKIT PATTERN
+
+```bash
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $TOKEN" \
+  -d '{"query":"...", "variables":{}}' \
+  -w "\n\nHTTP_CODE: %{http_code}\nTIME: %{time_total}s" \
+  -s -S 2>&1 | tee .agent-workspace/qa/evidence/curl/NN-description.txt
+```
+
+---
+
+### SCHEMA INTROSPECTION
+
+Start every GraphQL test session by discovering the schema:
+
+```bash
+# Full introspection query
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ __schema { queryType { fields { name } } mutationType { fields { name } } } }"}' \
+  -s | jq .
+
+# Check specific type
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ __type(name: \"User\") { fields { name type { name kind } } } }"}' \
+  -s | jq .
+```
+
+This tells you what queries, mutations, and types are available.
+
+---
+
+### QUERY TESTING
+
+```bash
+# Simple query
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ users { id name email } }"}' \
+  -s | jq .
+
+# Query with variables
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"query GetUser($id: ID!) { user(id: $id) { id name email } }", "variables":{"id":"123"}}' \
+  -s | jq .
+
+# Nested query (N+1 risk area)
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ users { id posts { id title comments { id body } } } }"}' \
+  -s | jq .
+```
+
+---
+
+### MUTATION TESTING
+
+```bash
+# Create
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"mutation { createUser(input: {name: \"Test\", email: \"test@example.com\"}) { id name } }"}' \
+  -s | jq .
+
+# Update
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"mutation { updateUser(id: \"ID\", input: {name: \"Updated\"}) { id name } }"}' \
+  -s | jq .
+
+# Delete
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"mutation { deleteUser(id: \"ID\") { success } }"}' \
+  -s | jq .
+```
+
+---
+
+### ERROR HANDLING — THE KEY DIFFERENCE
+
+**GraphQL errors are in the response body, NOT HTTP status codes.** A GraphQL request almost always returns HTTP 200 — check the `errors` field.
+
+```bash
+# This returns HTTP 200 even with errors:
+RESPONSE=$(curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ nonexistent { id } }"}' \
+  -s)
+
+# Check for errors in response body
+echo "$RESPONSE" | jq '.errors'
+echo "$RESPONSE" | jq '.errors[0].message'
+echo "$RESPONSE" | jq '.errors[0].extensions.code'
+```
+
+**Verify error format:**
+- `errors` array present
+- Each error has `message` field
+- Extensions with error codes (if the API uses them)
+- No data leakage in error messages
+
+---
+
+### AUTH & AUTHORIZATION TESTING
+
+```bash
+# No auth header — should return error in body (NOT 401)
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ me { id email } }"}' \
+  -s | jq '.errors'
+
+# Invalid token
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer invalid" \
+  -d '{"query":"{ me { id email } }"}' \
+  -s | jq '.errors'
+
+# Field-level authorization — try accessing admin fields as regular user
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $USER_TOKEN" \
+  -d '{"query":"{ users { id email role passwordHash } }"}' \
+  -s | jq .
+```
+
+---
+
+### INPUT VALIDATION TESTING
+
+```bash
+# Missing required field
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"mutation { createUser(input: {}) { id } }"}' \
+  -s | jq '.errors'
+
+# Invalid type
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"mutation { createUser(input: {name: 123}) { id } }"}' \
+  -s | jq '.errors'
+
+# Injection attempt — GraphQL should handle this safely
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ user(id: \"1; DROP TABLE users\") { id } }"}' \
+  -s | jq .
+```
+
+---
+
+### SUBSCRIPTION TESTING (if applicable)
+
+For WebSocket-based subscriptions, use `wscat` or `websocat`:
+```bash
+# Connect and subscribe
+wscat -c ws://localhost:3000/graphql -x '{"type":"connection_init","payload":{}}' \
+  -x '{"type":"subscribe","id":"1","payload":{"query":"subscription { messageAdded { id content } }"}}'
+```
+
+---
+
+### PERFORMANCE TESTING
+
+```bash
+# Query complexity — deeply nested queries can cause performance issues
+# Test with increasing depth to find limits
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ users { posts { comments { author { posts { comments { id } } } } } } }"}' \
+  -w "\nTIME: %{time_total}s" -s | jq .
+
+# Batch queries (if supported)
+curl -X POST http://localhost:3000/graphql \
+  -H "Content-Type: application/json" \
+  -d '[{"query":"{ user(id: \"1\") { name } }"}, {"query":"{ user(id: \"2\") { name } }"}]' \
+  -s | jq .
+```