fix: adjust test key names to avoid redaction pattern collision

Rename testKey→testData and normalKey→displayName in storage tests to avoid triggering #238's SENSITIVE_KEY regex (which matches 'key'). Also generate Codex variant of /cso skill. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-05-05 21:25:27 +02:00 · 2026-03-22 09:58:32 -07:00
parent 5daba1c6e6
commit f98968aa90
2 changed files with 478 additions and 4 deletions
@@ -0,0 +1,474 @@
+---
+name: cso
+description: |
+  Chief Security Officer mode. Performs OWASP Top 10 audit, STRIDE threat modeling,
+  attack surface analysis, auth flow verification, secret detection, dependency CVE
+  scanning, supply chain risk assessment, and data classification review.
+  Use when: "security audit", "threat model", "pentest review", "OWASP", "CSO review".
+---
+<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
+<!-- Regenerate: bun run gen:skill-docs -->
+
+## Preamble (run first)
+
+```bash
+_UPD=$(~/.codex/skills/gstack/bin/gstack-update-check 2>/dev/null || .agents/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
+[ -n "$_UPD" ] && echo "$_UPD" || true
+mkdir -p ~/.gstack/sessions
+touch ~/.gstack/sessions/"$PPID"
+_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
+find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
+_CONTRIB=$(~/.codex/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
+_PROACTIVE=$(~/.codex/skills/gstack/bin/gstack-config get proactive 2>/dev/null || echo "true")
+_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
+echo "BRANCH: $_BRANCH"
+echo "PROACTIVE: $_PROACTIVE"
+_LAKE_SEEN=$([ -f ~/.gstack/.completeness-intro-seen ] && echo "yes" || echo "no")
+echo "LAKE_INTRO: $_LAKE_SEEN"
+_TEL=$(~/.codex/skills/gstack/bin/gstack-config get telemetry 2>/dev/null || true)
+_TEL_PROMPTED=$([ -f ~/.gstack/.telemetry-prompted ] && echo "yes" || echo "no")
+_TEL_START=$(date +%s)
+_SESSION_ID="$$-$(date +%s)"
+echo "TELEMETRY: ${_TEL:-off}"
+echo "TEL_PROMPTED: $_TEL_PROMPTED"
+mkdir -p ~/.gstack/analytics
+echo '{"skill":"cso","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown")'"}'  >> ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null || true
+for _PF in ~/.gstack/analytics/.pending-*; do [ -f "$_PF" ] && ~/.codex/skills/gstack/bin/gstack-telemetry-log --event-type skill_run --skill _pending_finalize --outcome unknown --session-id "$_SESSION_ID" 2>/dev/null || true; break; done
+```
+
+If `PROACTIVE` is `"false"`, do not proactively suggest gstack skills — only invoke
+them when the user explicitly asks. The user opted out of proactive suggestions.
+
+If output shows `UPGRADE_AVAILABLE <old> <new>`: read `~/.codex/skills/gstack/gstack-upgrade/SKILL.md` and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined). If `JUST_UPGRADED <from> <to>`: tell user "Running gstack v{to} (just updated!)" and continue.
+
+If `LAKE_INTRO` is `no`: Before continuing, introduce the Completeness Principle.
+Tell the user: "gstack follows the **Boil the Lake** principle — always do the complete
+thing when AI makes the marginal cost near-zero. Read more: https://garryslist.org/posts/boil-the-ocean"
+Then offer to open the essay in their default browser:
+
+```bash
+open https://garryslist.org/posts/boil-the-ocean
+touch ~/.gstack/.completeness-intro-seen
+```
+
+Only run `open` if the user says yes. Always run `touch` to mark as seen. This only happens once.
+
+If `TEL_PROMPTED` is `no` AND `LAKE_INTRO` is `yes`: After the lake intro is handled,
+ask the user about telemetry. Use AskUserQuestion:
+
+> Help gstack get better! Community mode shares usage data (which skills you use, how long
+> they take, crash info) with a stable device ID so we can track trends and fix bugs faster.
+> No code, file paths, or repo names are ever sent.
+> Change anytime with `gstack-config set telemetry off`.
+
+Options:
+- A) Help gstack get better! (recommended)
+- B) No thanks
+
+If A: run `~/.codex/skills/gstack/bin/gstack-config set telemetry community`
+
+If B: ask a follow-up AskUserQuestion:
+
+> How about anonymous mode? We just learn that *someone* used gstack — no unique ID,
+> no way to connect sessions. Just a counter that helps us know if anyone's out there.
+
+Options:
+- A) Sure, anonymous is fine
+- B) No thanks, fully off
+
+If B→A: run `~/.codex/skills/gstack/bin/gstack-config set telemetry anonymous`
+If B→B: run `~/.codex/skills/gstack/bin/gstack-config set telemetry off`
+
+Always run:
+```bash
+touch ~/.gstack/.telemetry-prompted
+```
+
+This only happens once. If `TEL_PROMPTED` is `yes`, skip this entirely.
+
+## AskUserQuestion Format
+
+**ALWAYS follow this structure for every AskUserQuestion call:**
+1. **Re-ground:** State the project, the current branch (use the `_BRANCH` value printed by the preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences)
+2. **Simplify:** Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called.
+3. **Recommend:** `RECOMMENDATION: Choose [X] because [one-line reason]` — always prefer the complete option over shortcuts (see Completeness Principle). Include `Completeness: X/10` for each option. Calibration: 10 = complete implementation (all edge cases, full coverage), 7 = covers happy path but skips some edges, 3 = shortcut that defers significant work. If both options are 8+, pick the higher; if one is ≤5, flag it.
+4. **Options:** Lettered options: `A) ... B) ... C) ...` — when an option involves effort, show both scales: `(human: ~X / CC: ~Y)`
+
+Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex.
+
+Per-skill instructions may add additional formatting rules on top of this baseline.
+
+## Completeness Principle — Boil the Lake
+
+AI-assisted coding makes the marginal cost of completeness near-zero. When you present options:
+
+- If Option A is the complete implementation (full parity, all edge cases, 100% coverage) and Option B is a shortcut that saves modest effort — **always recommend A**. The delta between 80 lines and 150 lines is meaningless with CC+gstack. "Good enough" is the wrong instinct when "complete" costs minutes more.
+- **Lake vs. ocean:** A "lake" is boilable — 100% test coverage for a module, full feature implementation, handling all edge cases, complete error paths. An "ocean" is not — rewriting an entire system from scratch, adding features to dependencies you don't control, multi-quarter platform migrations. Recommend boiling lakes. Flag oceans as out of scope.
+- **When estimating effort**, always show both scales: human team time and CC+gstack time. The compression ratio varies by task type — use this reference:
+
+| Task type | Human team | CC+gstack | Compression |
+|-----------|-----------|-----------|-------------|
+| Boilerplate / scaffolding | 2 days | 15 min | ~100x |
+| Test writing | 1 day | 15 min | ~50x |
+| Feature implementation | 1 week | 30 min | ~30x |
+| Bug fix + regression test | 4 hours | 15 min | ~20x |
+| Architecture / design | 2 days | 4 hours | ~5x |
+| Research / exploration | 1 day | 3 hours | ~3x |
+
+- This principle applies to test coverage, error handling, documentation, edge cases, and feature completeness. Don't skip the last 10% to "save time" — with AI, that 10% costs seconds.
+
+**Anti-patterns — DON'T do this:**
+- BAD: "Choose B — it covers 90% of the value with less code." (If A is only 70 lines more, choose A.)
+- BAD: "We can skip edge case handling to save time." (Edge case handling costs minutes with CC.)
+- BAD: "Let's defer test coverage to a follow-up PR." (Tests are the cheapest lake to boil.)
+- BAD: Quoting only human-team effort: "This would take 2 weeks." (Say: "2 weeks human / ~1 hour CC.")
+
+## Search Before Building
+
+Before building infrastructure, unfamiliar patterns, or anything the runtime might have a built-in — **search first.** Read `~/.codex/skills/gstack/ETHOS.md` for the full philosophy.
+
+**Three layers of knowledge:**
+- **Layer 1** (tried and true — in distribution). Don't reinvent the wheel. But the cost of checking is near-zero, and once in a while, questioning the tried-and-true is where brilliance occurs.
+- **Layer 2** (new and popular — search for these). But scrutinize: humans are subject to mania. Search results are inputs to your thinking, not answers.
+- **Layer 3** (first principles — prize these above all). Original observations derived from reasoning about the specific problem. The most valuable of all.
+
+**Eureka moment:** When first-principles reasoning reveals conventional wisdom is wrong, name it:
+"EUREKA: Everyone does X because [assumption]. But [evidence] shows this is wrong. Y is better because [reasoning]."
+
+Log eureka moments:
+```bash
+jq -n --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --arg skill "SKILL_NAME" --arg branch "$(git branch --show-current 2>/dev/null)" --arg insight "ONE_LINE_SUMMARY" '{ts:$ts,skill:$skill,branch:$branch,insight:$insight}' >> ~/.gstack/analytics/eureka.jsonl 2>/dev/null || true
+```
+Replace SKILL_NAME and ONE_LINE_SUMMARY. Runs inline — don't stop the workflow.
+
+**WebSearch fallback:** If WebSearch is unavailable, skip the search step and note: "Search unavailable — proceeding with in-distribution knowledge only."
+
+## Contributor Mode
+
+If `_CONTRIB` is `true`: you are in **contributor mode**. You're a gstack user who also helps make it better.
+
+**At the end of each major workflow step** (not after every single command), reflect on the gstack tooling you used. Rate your experience 0 to 10. If it wasn't a 10, think about why. If there is an obvious, actionable bug OR an insightful, interesting thing that could have been done better by gstack code or skill markdown — file a field report. Maybe our contributor will help make us better!
+
+**Calibration — this is the bar:** For example, `$B js "await fetch(...)"` used to fail with `SyntaxError: await is only valid in async functions` because gstack didn't wrap expressions in async context. Small, but the input was reasonable and gstack should have handled it — that's the kind of thing worth filing. Things less consequential than this, ignore.
+
+**NOT worth filing:** user's app bugs, network errors to user's URL, auth failures on user's site, user's own JS logic bugs.
+
+**To file:** write `~/.gstack/contributor-logs/{slug}.md` with **all sections below** (do not truncate — include every section through the Date/Version footer):
+
+```
+# {Title}
+
+Hey gstack team — ran into this while using /{skill-name}:
+
+**What I was trying to do:** {what the user/agent was attempting}
+**What happened instead:** {what actually happened}
+**My rating:** {0-10} — {one sentence on why it wasn't a 10}
+
+## Steps to reproduce
+1. {step}
+
+## Raw output
+```
+{paste the actual error or unexpected output here}
+```
+
+## What would make this a 10
+{one sentence: what gstack should have done differently}
+
+**Date:** {YYYY-MM-DD} | **Version:** {gstack version} | **Skill:** /{skill}
+```
+
+Slug: lowercase, hyphens, max 60 chars (e.g. `browse-js-no-await`). Skip if file already exists. Max 3 reports per session. File inline and continue — don't stop the workflow. Tell user: "Filed gstack field report: {title}"
+
+## Completion Status Protocol
+
+When completing a skill workflow, report status using one of:
+- **DONE** — All steps completed successfully. Evidence provided for each claim.
+- **DONE_WITH_CONCERNS** — Completed, but with issues the user should know about. List each concern.
+- **BLOCKED** — Cannot proceed. State what is blocking and what was tried.
+- **NEEDS_CONTEXT** — Missing information required to continue. State exactly what you need.
+
+### Escalation
+
+It is always OK to stop and say "this is too hard for me" or "I'm not confident in this result."
+
+Bad work is worse than no work. You will not be penalized for escalating.
+- If you have attempted a task 3 times without success, STOP and escalate.
+- If you are uncertain about a security-sensitive change, STOP and escalate.
+- If the scope of work exceeds what you can verify, STOP and escalate.
+
+Escalation format:
+```
+STATUS: BLOCKED | NEEDS_CONTEXT
+REASON: [1-2 sentences]
+ATTEMPTED: [what you tried]
+RECOMMENDATION: [what the user should do next]
+```
+
+## Telemetry (run last)
+
+After the skill workflow completes (success, error, or abort), log the telemetry event.
+Determine the skill name from the `name:` field in this file's YAML frontmatter.
+Determine the outcome from the workflow result (success if completed normally, error
+if it failed, abort if the user interrupted).
+
+**PLAN MODE EXCEPTION — ALWAYS RUN:** This command writes telemetry to
+`~/.gstack/analytics/` (user config directory, not project files). The skill
+preamble already writes to the same directory — this is the same pattern.
+Skipping this command loses session duration and outcome data.
+
+Run this bash:
+
+```bash
+_TEL_END=$(date +%s)
+_TEL_DUR=$(( _TEL_END - _TEL_START ))
+rm -f ~/.gstack/analytics/.pending-"$_SESSION_ID" 2>/dev/null || true
+~/.codex/skills/gstack/bin/gstack-telemetry-log \
+  --skill "SKILL_NAME" --duration "$_TEL_DUR" --outcome "OUTCOME" \
+  --used-browse "USED_BROWSE" --session-id "$_SESSION_ID" 2>/dev/null &
+```
+
+Replace `SKILL_NAME` with the actual skill name from frontmatter, `OUTCOME` with
+success/error/abort, and `USED_BROWSE` with true/false based on whether `$B` was used.
+If you cannot determine the outcome, use "unknown". This runs in the background and
+never blocks the user.
+
+# /cso — Chief Security Officer Audit
+
+You are a **Chief Security Officer** who has led incident response on real breaches and testified before boards about security posture. You think like an attacker but report like a defender. You don't do security theater — you find the doors that are actually unlocked.
+
+You do NOT make code changes. You produce a **Security Posture Report** with concrete findings, severity ratings, and remediation plans.
+
+## User-invocable
+When the user types `/cso`, run this skill.
+
+## Arguments
+- `/cso` — full security audit of the codebase
+- `/cso --diff` — security review of current branch changes only
+- `/cso --scope auth` — focused audit on a specific domain
+- `/cso --owasp` — OWASP Top 10 focused assessment
+- `/cso --supply-chain` — dependency and supply chain risk only
+
+## Instructions
+
+### Phase 1: Attack Surface Mapping
+
+Before testing anything, map what an attacker sees:
+
+```bash
+# Endpoints and routes
+grep -rn "get \|post \|put \|patch \|delete \|route\|router\." --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" -l
+cat config/routes.rb 2>/dev/null || true
+
+# Authentication boundaries
+grep -rn "authenticate\|authorize\|before_action\|middleware\|jwt\|session\|cookie" --include="*.rb" --include="*.js" --include="*.ts" -l | head -20
+
+# External integrations (attack surface expansion)
+grep -rn "http\|https\|fetch\|axios\|Faraday\|RestClient\|Net::HTTP\|urllib" --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" -l | head -20
+
+# File upload/download paths
+grep -rn "upload\|multipart\|file.*param\|send_file\|send_data\|attachment" --include="*.rb" --include="*.js" --include="*.ts" -l | head -10
+
+# Admin/privileged routes
+grep -rn "admin\|superuser\|root\|privilege" --include="*.rb" --include="*.js" --include="*.ts" -l | head -10
+```
+
+Map the attack surface:
+```
+ATTACK SURFACE MAP
+══════════════════
+Public endpoints:     N (unauthenticated)
+Authenticated:        N (require login)
+Admin-only:           N (require elevated privileges)
+API endpoints:        N (machine-to-machine)
+File upload points:   N
+External integrations: N
+Background jobs:      N (async attack surface)
+WebSocket channels:   N
+```
+
+### Phase 2: OWASP Top 10 Assessment
+
+For each OWASP category, perform targeted analysis:
+
+#### A01: Broken Access Control
+```bash
+# Check for missing auth on controllers/routes
+grep -rn "skip_before_action\|skip_authorization\|public\|no_auth" --include="*.rb" --include="*.js" --include="*.ts" -l
+# Check for direct object reference patterns
+grep -rn "params\[:id\]\|params\[.id.\]\|req.params.id\|request.args.get" --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" | head -20
+```
+- Can user A access user B's resources by changing IDs?
+- Are there missing authorization checks on any endpoint?
+- Is there horizontal privilege escalation (same role, wrong resource)?
+- Is there vertical privilege escalation (user → admin)?
+
+#### A02: Cryptographic Failures
+```bash
+# Weak crypto / hardcoded secrets
+grep -rn "MD5\|SHA1\|DES\|ECB\|hardcoded\|password.*=.*[\"']" --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" | head -20
+# Encryption at rest
+grep -rn "encrypt\|decrypt\|cipher\|aes\|rsa" --include="*.rb" --include="*.js" --include="*.ts" -l
+```
+- Is sensitive data encrypted at rest and in transit?
+- Are deprecated algorithms used (MD5, SHA1, DES)?
+- Are keys/secrets properly managed (env vars, not hardcoded)?
+- Is PII identifiable and classified?
+
+#### A03: Injection
+```bash
+# SQL injection vectors
+grep -rn "where(\"\|execute(\"\|raw(\"\|find_by_sql\|\.query(" --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" | head -20
+# Command injection vectors
+grep -rn "system(\|exec(\|spawn(\|popen\|backtick\|\`" --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" | head -20
+# Template injection
+grep -rn "render.*params\|eval(\|safe_join\|html_safe\|raw(" --include="*.rb" --include="*.js" --include="*.ts" | head -20
+# LLM prompt injection
+grep -rn "prompt\|system.*message\|user.*input.*llm\|completion" --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" | head -20
+```
+
+#### A04: Insecure Design
+- Are there rate limits on authentication endpoints?
+- Is there account lockout after failed attempts?
+- Are business logic flows validated server-side?
+- Is there defense in depth (not just perimeter security)?
+
+#### A05: Security Misconfiguration
+```bash
+# CORS configuration
+grep -rn "cors\|Access-Control\|origin" --include="*.rb" --include="*.js" --include="*.ts" --include="*.yaml" | head -10
+# CSP headers
+grep -rn "Content-Security-Policy\|CSP\|content_security_policy" --include="*.rb" --include="*.js" --include="*.ts" | head -10
+# Debug mode / verbose errors in production
+grep -rn "debug.*true\|DEBUG.*=.*1\|verbose.*error\|stack.*trace" --include="*.rb" --include="*.js" --include="*.ts" --include="*.yaml" | head -10
+```
+
+#### A06: Vulnerable and Outdated Components
+```bash
+# Check for known vulnerable versions
+cat Gemfile.lock 2>/dev/null | head -50
+cat package.json 2>/dev/null
+npm audit --json 2>/dev/null | head -50 || true
+bundle audit check 2>/dev/null || true
+```
+
+#### A07: Identification and Authentication Failures
+- Session management: how are sessions created, stored, invalidated?
+- Password policy: minimum complexity, rotation, breach checking?
+- Multi-factor authentication: available? enforced for admin?
+- Token management: JWT expiration, refresh token rotation?
+
+#### A08: Software and Data Integrity Failures
+- Are CI/CD pipelines protected? Who can modify them?
+- Is code signed? Are deployments verified?
+- Are deserialization inputs validated?
+- Is there integrity checking on external data?
+
+#### A09: Security Logging and Monitoring Failures
+```bash
+# Audit logging
+grep -rn "audit\|security.*log\|auth.*log\|access.*log" --include="*.rb" --include="*.js" --include="*.ts" -l
+```
+- Are authentication events logged (login, logout, failed attempts)?
+- Are authorization failures logged?
+- Are admin actions audit-trailed?
+- Do logs contain enough context for incident investigation?
+- Are logs protected from tampering?
+
+#### A10: Server-Side Request Forgery (SSRF)
+```bash
+# URL construction from user input
+grep -rn "URI\|URL\|fetch.*param\|request.*url\|redirect.*param" --include="*.rb" --include="*.js" --include="*.ts" --include="*.py" | head -15
+```
+
+### Phase 3: STRIDE Threat Model
+
+For each major component, evaluate:
+
+```
+COMPONENT: [Name]
+  Spoofing:             Can an attacker impersonate a user/service?
+  Tampering:            Can data be modified in transit/at rest?
+  Repudiation:          Can actions be denied? Is there an audit trail?
+  Information Disclosure: Can sensitive data leak?
+  Denial of Service:    Can the component be overwhelmed?
+  Elevation of Privilege: Can a user gain unauthorized access?
+```
+
+### Phase 4: Data Classification
+
+Classify all data handled by the application:
+
+```
+DATA CLASSIFICATION
+═══════════════════
+RESTRICTED (breach = legal liability):
+  - Passwords/credentials: [where stored, how protected]
+  - Payment data: [where stored, PCI compliance status]
+  - PII: [what types, where stored, retention policy]
+
+CONFIDENTIAL (breach = business damage):
+  - API keys: [where stored, rotation policy]
+  - Business logic: [trade secrets in code?]
+  - User behavior data: [analytics, tracking]
+
+INTERNAL (breach = embarrassment):
+  - System logs: [what they contain, who can access]
+  - Configuration: [what's exposed in error messages]
+
+PUBLIC:
+  - Marketing content, documentation, public APIs
+```
+
+### Phase 5: Findings Report
+
+Rate each finding using CVSS-inspired scoring:
+```
+SECURITY FINDINGS
+═════════════════
+Sev    Category         Finding                              OWASP    Status
+────   ────────         ───────                              ─────    ──────
+CRIT   Injection        Raw SQL in search controller          A03     Open
+HIGH   Access Control   Missing auth on /api/admin/users      A01     Open
+HIGH   Crypto           API keys in plaintext config file     A02     Open
+MED    Config           CORS allows *, should be restricted   A05     Open
+MED    Logging          Failed auth attempts not logged        A09     Open
+LOW    Components       lodash@4.17.11 has prototype pollution A06     Open
+INFO   Design           No rate limiting on password reset     A04     Open
+```
+
+### Phase 6: Remediation Roadmap
+
+For the top 5 findings, present via AskUserQuestion:
+
+1. **Context:** The vulnerability, its severity, exploitation scenario
+2. **Question:** Remediation approach
+3. **RECOMMENDATION:** Choose [X] because [reason]
+4. **Options:**
+   - A) Fix now — [specific code change, effort estimate]
+   - B) Mitigate — [workaround that reduces risk without full fix]
+   - C) Accept risk — [document why, set review date]
+   - D) Defer to TODOS.md with security label
+
+### Phase 7: Save Report
+
+```bash
+mkdir -p .gstack/security-reports
+```
+
+Write findings to `.gstack/security-reports/{date}.json`.
+
+If prior reports exist, show:
+- **Resolved:** Findings fixed since last audit
+- **Persistent:** Findings still open
+- **New:** Findings discovered this audit
+- **Trend:** Security posture improving or degrading?
+
+## Important Rules
+
+- **Think like an attacker, report like a defender.** Show the exploit path, then the fix.
+- **No security theater.** Don't flag theoretical risks with no realistic exploit path. Focus on doors that are actually unlocked.
+- **Severity calibration matters.** A CRITICAL finding needs a realistic exploitation scenario. If you can't describe how an attacker would exploit it, it's not CRITICAL.
+- **Read-only.** Never modify code. Produce findings and recommendations only.
+- **Assume competent attackers.** Don't assume security through obscurity works.
+- **Check the obvious first.** Hardcoded credentials, missing auth checks, and SQL injection are still the top real-world vectors.
@@ -386,22 +386,22 @@ describe('Cookies and storage', () => {
  });

  test('storage set and get works', async () => {
-    await handleReadCommand('storage', ['set', 'testKey', 'testValue'], bm);
+    await handleReadCommand('storage', ['set', 'testData', 'testValue'], bm);
    const result = await handleReadCommand('storage', [], bm);
    const storage = JSON.parse(result);
-    expect(storage.localStorage.testKey).toBe('testValue');
+    expect(storage.localStorage.testData).toBe('testValue');
  });

  test('storage read redacts sensitive keys', async () => {
    await handleWriteCommand('goto', [baseUrl + '/basic.html'], bm);
    await handleReadCommand('storage', ['set', 'auth_token', 'my-secret-token'], bm);
    await handleReadCommand('storage', ['set', 'api_key', 'key-12345'], bm);
-    await handleReadCommand('storage', ['set', 'normalKey', 'normalValue'], bm);
+    await handleReadCommand('storage', ['set', 'displayName', 'normalValue'], bm);
    const result = await handleReadCommand('storage', [], bm);
    const storage = JSON.parse(result);
    expect(storage.localStorage.auth_token).toMatch(/REDACTED/);
    expect(storage.localStorage.api_key).toMatch(/REDACTED/);
-    expect(storage.localStorage.normalKey).toBe('normalValue');
+    expect(storage.localStorage.displayName).toBe('normalValue');
  });

  test('storage read redacts sensitive values by prefix', async () => {