swe-workflow-skills 0.1.0

package/skills/rollback-strategy/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: rollback-strategy
+description: "Design safe rollback plans before deploying — identify irreversible changes, classify rollback complexity, create tested undo procedures. Triggers: rollback plan, rollback strategy, how do I undo this, can we revert, what if the deploy fails, safe to deploy, feature flag rollout, blue-green, database migration rollback, irreversible change."
+model: haiku
+allowed-tools: Read, Grep, Glob, Write, Edit
+---
+
+# Rollback Strategy
+
+Design the undo plan before deploying — not during a production incident. A deployment without a rollback plan is a bet that nothing will go wrong.
+
+## ⛔ The Iron Law
+
+**If you can't undo it, don't ship it yet.**
+
+Every change is classified by rollback complexity before deploy, and every non-Simple change has a written rollback procedure that has been *tested* — not just imagined. Decide rollback before the incident, never during it: the minutes you'd spend designing an undo mid-incident are the minutes users are down.
+
+## Step 1: Analyze the Deployment
+
+List every change being deployed:
+
+- **Code changes**: Which services, which endpoints, what behavior changes?
+- **Schema changes**: New tables, columns, indexes, constraints, dropped columns?
+- **Data migrations**: Backfills, transformations, deletes?
+- **Configuration changes**: New env vars, feature flag states, infrastructure config?
+- **Dependency updates**: Library upgrades, external service version changes?
+
+For each change, ask: **If this change caused a production incident 30 minutes after deploy, what would rollback look like?**
+
+## Step 2: Classify by Rollback Complexity
+
+Assign each change a rollback complexity:
+
+| Complexity | Definition | Examples |
+|-----------|-----------|---------|
+| **Simple** | Revert the code deploy, no other steps | Logic change, UI change, new feature behind a flag |
+| **Coordinated** | Code revert + one other step | New env var (remove it), new index (drop it), additive column (leave it, no harm) |
+| **Complex** | Requires data migration reversal or multi-step coordination | Column rename (requires data migration), data backfill (must un-backfill) |
+| **Irreversible** | Cannot be fully undone | Destructive data operations, sent emails/notifications, external API calls with side effects |
+
+**If any change is Irreversible**: explicitly document what partial rollback looks like and get sign-off before deploying.
+
+See [references/rollback-patterns.md](references/rollback-patterns.md) for detailed patterns per component type.
+
+## Step 3: Design the Rollback Procedure
+
+For each non-Simple change, write the explicit rollback steps:
+
+**Database schema rollback:**
+- Additive columns (new nullable column): safe to leave after rollback — old code ignores them
+- Non-additive changes (rename, type change, NOT NULL constraint): require a reverse migration
+- Dropped columns: need to be re-added and re-populated (use `git bisect` to find the data state)
+
+**Feature flag rollback:**
+- Define the "off" state before deploying
+- Test the "off" state in staging before deploying to production
+- Know which percentage to roll back to if doing a canary rollout
+
+**Data migration rollback:**
+- Write the reverse migration before deploying the forward migration
+- Test both on a copy of production data
+- If the migration is too large to reverse quickly, plan for an emergency read-only mode instead
+
+**Configuration rollback:**
+- Document the previous value of every env var being changed
+- For secrets rotation: keep the old secret valid for 24 hours after switching
+
+## Step 4: Document and Test the Plan
+
+Write the rollback plan in the deployment PR or deployment runbook:
+
+```
+Rollback Plan:
+1. [Step]: [Command or action]
+2. [Step]: [Command or action]
+3. Verify: [How to confirm rollback succeeded]
+Estimated rollback time: [X minutes]
+Rollback owner: [Who executes this during an incident]
+```
+
+**Test it before you need it:**
+- Run the rollback steps in staging before production deploy
+- Confirm the rollback takes the expected time (important during incidents)
+- Verify application health after rollback completes
+
+Use [templates/rollback-plan.md](templates/rollback-plan.md) for the full plan format.
+
+## Principles Applied
+
+- **KISS**: Prefer feature flags over complex rollback procedures. The simplest rollback is turning a flag off.
+- **YAGNI**: Don't deploy a change you can't roll back without a documented, tested plan. If you can't undo it, don't ship it yet.
+- **Defense in depth**: Multiple rollback options (flag → revert → data migration reversal) provide fallbacks when the first option isn't enough.
+- **Fail fast**: Define rollback triggers before deploying (see `deployment-checklist`). Waiting until an incident to decide when to rollback wastes critical time.
+
+## Rationalizations to reject
+
+| Excuse | Reality |
+|--------|---------|
+| "We'll figure out rollback if it breaks" | Designing rollback mid-incident wastes the minutes that matter most. |
+| "The migration is reversible, trust me" | Reversible in theory ≠ tested. Run the reverse on production-sized data first. |
+| "It's behind a flag, that's enough" | Only if the off-state was defined and tested before deploy. |
+| "Rollback is unlikely, skip the plan" | A rollback plan is insurance — you write it before you need it, not after. |
+| "Additive column, no rollback needed" | Confirm old code ignores it and document the no-op explicitly. |
+
+## Red flags — stop and correct course
+
+- An Irreversible change with no documented partial-rollback and no sign-off.
+- A reverse migration that has never actually been executed.
+- A feature flag whose off-state was never tested in staging.
+- The estimated rollback time is unknown.
+
+## Cross-Skill References
+
+- `deployment-checklist` — run before every deploy; rollback plan is a required gate
+- `incident-response` — execute the rollback plan when an incident occurs
+- `configuration-strategy` — design feature flags as part of config strategy (reduces rollback complexity)

package/skills/rollback-strategy/evals/evals.json

@@ -0,0 +1,55 @@
+{
+  "skill_name": "rollback-strategy",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I'm about to deploy a feature that adds a new 'subscription_tier' column to the users table and backfills it based on existing billing data. How do I make sure I can roll back safely?",
+      "expected_output": "Structured rollback analysis covering the schema change (additive column = simple) and the backfill (data migration = complex), with a phased deploy recommendation and explicit reverse migration guidance",
+      "assertions": [
+        "Identifies the additive column as safe/simple for rollback",
+        "Identifies the backfill as the complex part requiring a reverse transformation",
+        "Recommends writing and testing the reverse backfill before deploying",
+        "Suggests testing migration timing on production-sized data",
+        "Recommends making a database backup before the backfill runs",
+        "Produces or outlines a written rollback plan"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "We need to rename the 'email' column to 'email_address' in our users table. What's the safest way to do this and be able to roll back?",
+      "expected_output": "Recommends the expand-contract pattern (4-step phased approach) rather than a single rename, explaining why a direct rename is a breaking change that cannot be safely rolled back",
+      "assertions": [
+        "Warns that a direct column rename is a breaking change for any running application code",
+        "Recommends the expand-contract pattern: add new column → backfill → migrate reads/writes → drop old column",
+        "Explains that each step is independently rollback-safe",
+        "Notes that the old column should not be dropped until all references to it are confirmed removed"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Help me roll back the deploy I just did — users are getting 500 errors.",
+      "expected_output": "Recognizes this is an active incident execution context, not a planning context — redirects to incident-response skill for immediate action while potentially providing the rollback steps if a rollback plan exists",
+      "assertions": [
+        "Recognizes this is an active incident, not a pre-deploy planning session",
+        "Prioritizes speed and clear action over comprehensive planning",
+        "Mentions incident-response skill for the overall incident workflow",
+        "Asks for or uses the rollback plan if one was previously created",
+        "Does not spend time on rollback planning when immediate action is needed"
+      ]
+    }
+  ],
+  "pressure_tests": [
+    {
+      "id": 1,
+      "prompt": "We're behind schedule. The migration renames a column but it's probably reversible. Skip the rollback plan — we'll deal with it if it breaks.",
+      "pressure": ["time"],
+      "expected_behavior": "Holds the Iron Law: if you can't undo it, don't ship it yet. Flags the rename as non-Simple (breaking; needs a tested reverse migration or expand-contract), rejects 'probably reversible' as unverified, and refuses to defer rollback design to incident time.",
+      "assertions": [
+        "Flags the column rename as non-Simple / breaking",
+        "Rejects 'probably reversible' as unverified",
+        "Refuses to skip the rollback plan despite the schedule pressure",
+        "Explains that designing rollback mid-incident wastes the critical minutes"
+      ]
+    }
+  ]
+}

package/skills/rollback-strategy/references/rollback-patterns.md

@@ -0,0 +1,125 @@
+# Rollback Patterns by Component
+
+## Database Schema Changes
+
+### Safe to deploy without a rollback plan
+- **New nullable column**: Old code ignores it. If you roll back the code, the column sits unused — no harm.
+- **New table**: Old code doesn't know about it. Drop it if truly unnecessary after rollback.
+- **New index**: Can be dropped. Concurrent index creation avoids locking.
+
+### Requires a rollback migration
+- **NOT NULL constraint added to existing column**: Old code may insert nulls; rollback requires removing the constraint.
+- **Column type change**: Data may be lost in conversion. Write a reverse migration and test it.
+- **Column rename**: Requires the reverse rename. The safest approach: add new column → backfill → switch reads/writes → remove old column (4 deploys, fully reversible at each step).
+
+### Requires careful coordination or is irreversible
+- **Column dropped**: Must add back and re-populate from backups or recalculate. Avoid dropping columns in the same deploy as removing references to them — deploy the code change first, verify the column is unused, then drop in a separate deploy.
+- **Data deleted**: If rows are deleted, rollback means restoring from backup. Always make a point-in-time backup before destructive migrations.
+- **Data backfilled or transformed**: Write the reverse transformation before deploying. Test on a copy of production data.
+
+### Schema migration rollback pattern
+```sql
+-- Forward migration: add_status_to_orders
+ALTER TABLE orders ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'pending';
+
+-- Reverse migration (write before deploying forward):
+ALTER TABLE orders DROP COLUMN status;
+```
+
+For long-running migrations on large tables, test timing on production data size before deploying.
+
+---
+
+## Feature Flags
+
+Feature flags are the simplest rollback mechanism. They decouple deployment from release.
+
+### Rollback with feature flags
+1. Disable the flag (turn off the feature)
+2. Verify the application is in the expected "off" state
+3. No code revert needed — old behavior is restored immediately
+
+### Canary rollout and rollback
+```
+0%  → 5%  → 25%  → 100%
+     ↑
+     Monitor here: error rate, latency, conversion metrics
+     If metrics degrade: roll back to 0% before proceeding
+```
+
+### What to test before deploying a flagged feature
+- The "flag off" state works correctly (not just "flag on")
+- Flag state changes propagate in under 1 minute
+- The feature works correctly when the flag is enabled mid-session for a user
+
+---
+
+## API Changes
+
+### Backwards-compatible (rollback-safe)
+- Adding new optional fields to response
+- Adding new endpoints
+- Adding new optional request parameters with documented defaults
+- Deprecating fields (keep returning them, add deprecation notice)
+
+### Breaking changes (require versioning or coordination)
+- Removing fields from response
+- Changing field types or semantics
+- Removing endpoints
+- Making optional fields required
+
+### Breaking change rollback strategy: API versioning
+Deploy v2 alongside v1. Route clients to v2 incrementally. If v2 has issues, route back to v1. Remove v1 once v2 is stable and all clients have migrated.
+
+### Breaking change rollback strategy: Expand-contract
+1. **Expand**: Add new behavior alongside old (both old and new work)
+2. **Migrate**: Move clients to new behavior
+3. **Contract**: Remove old behavior once all clients have migrated
+
+Rollback is possible at every step of expand-contract. Skip to step 3 without step 2 and rollback becomes risky.
+
+---
+
+## Cache Invalidation
+
+If a rollback changes what valid cached data looks like:
+
+- **Application-level cache**: Clear the cache as part of rollback
+- **CDN cache**: Purge or set a short TTL before deploying so stale content expires quickly
+- **Client-side cache**: Use cache-busting keys (content hash in asset filenames) so old clients don't cache new assets across deploys
+
+---
+
+## Event-Driven / Message Queue Changes
+
+### Message schema changes
+- **Additive fields**: Consumers ignore unknown fields in most message formats (protobuf, JSON with lenient parsers)
+- **Removing fields**: Deploy consumers that handle missing fields before deploying producers that omit them
+- **Consumer-first pattern**: For breaking changes, always deploy the consumer change first, then the producer change
+
+### Message replay
+If a bad deploy produced bad messages in a queue, rollback may require:
+- Stopping consumers
+- Dead-lettering or discarding the bad messages
+- Rolling back code
+- Replaying from a known-good point in the event log
+
+---
+
+## Infrastructure Changes
+
+### Rollback for infrastructure-as-code
+Always use version control for IaC. Rollback = apply the previous version of the Terraform/CloudFormation/Pulumi code.
+
+**Before destructive infrastructure changes:**
+- `terraform plan` and review what will be destroyed
+- For stateful resources (databases, queues), add lifecycle rules: `prevent_destroy = true`
+- Take a snapshot of stateful resources before making changes
+
+### Blue-green deployment rollback
+Maintain the previous environment ("blue") until the new environment ("green") is verified stable. Rollback = switch traffic back to blue.
+
+**Prerequisites:**
+- Load balancer or DNS supports instant traffic switching
+- "Blue" environment remains live and healthy during deployment (don't recycle it immediately)
+- Both environments can connect to the same database (or database is compatible with both)

package/skills/rollback-strategy/templates/rollback-plan.md

@@ -0,0 +1,69 @@
+# Rollback Plan
+
+**Deployment**: [PR/ticket/description]
+**Date**: [DATE]
+**Author**: [Name]
+**Rollback owner**: [Who executes this if needed]
+
+---
+
+## Changes Being Deployed
+
+| Component | Change | Rollback complexity |
+|-----------|--------|---------------------|
+| [Service/component] | [Description] | Simple / Coordinated / Complex / Irreversible |
+
+---
+
+## Rollback Triggers
+
+Roll back immediately if any of the following occur within [30/60] minutes of deployment:
+
+- Error rate exceeds [X%]
+- [Specific metric] drops below [threshold]
+- [Specific alert fires]
+- [Other trigger]
+
+---
+
+## Rollback Procedure
+
+**Estimated rollback time**: [X minutes]
+
+### Step 1: [First action]
+```
+[Command or instructions]
+```
+
+### Step 2: [Second action]
+```
+[Command or instructions]
+```
+
+### Step 3: Verify rollback succeeded
+- [ ] [Check 1]: [How to verify]
+- [ ] [Check 2]: [How to verify]
+- [ ] Error rate returned to baseline
+- [ ] Application health checks passing
+
+---
+
+## Irreversible Changes
+
+*If any changes above are marked Irreversible, document them here and what partial rollback looks like:*
+
+[Description of what cannot be undone and how to mitigate]
+
+---
+
+## Rollback Test Results
+
+- [ ] Rollback procedure tested in staging on [DATE]
+- [ ] Rollback completed in [X minutes] during test
+- [ ] Application was healthy after test rollback
+
+---
+
+## Notes
+
+[Any additional context, warnings, or dependencies for the rollback executor]

package/skills/security-audit/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: security-audit
+description: "Comprehensive security analysis — OWASP Top 10, auth/authz flows, injection vulnerabilities, data exposure, secrets detection, dependency CVEs, hardening recommendations. Triggers: security audit, vulnerability, is this secure, security review, pentest prep, OWASP, harden this, check for vulnerabilities, injection, XSS, CSRF, auth security."
+model: opus
+allowed-tools: Read, Grep, Glob, Write, Edit, WebFetch, WebSearch
+---
+
+# Security Audit
+
+Perform a structured security assessment of an application. This skill goes far deeper than the security checklist in code-reviewing — it's a dedicated, systematic analysis covering the OWASP Top 10 and beyond.
+
+## Scope Boundary
+
+This skill analyzes code, configuration, and architecture for security vulnerabilities through static analysis and design review. It does not replace penetration testing, but it prepares code for one by catching the issues a pentester would find.
+
+## ⛔ The Iron Law
+
+**"No obvious problems" is not a pass.**
+
+Absence of evidence is not evidence of security. Every clearance is backed by evidence — the specific control you read and where it's enforced — and every finding cites the exact code path plus a concrete exploit scenario. If you can't write the exploit, you haven't assessed the risk; if you can, it isn't theoretical.
+
+## Workflow
+
+### Step 1: Define the Attack Surface
+
+Before reviewing code line by line, map what's exposed:
+
+- **Entry points**: HTTP endpoints, WebSocket connections, GraphQL resolvers, CLI inputs, file uploads, webhooks, cron jobs
+- **Authentication boundaries**: What's public vs authenticated vs admin-only?
+- **Data flows**: Where does sensitive data enter, travel, and get stored?
+- **External integrations**: Third-party APIs, OAuth providers, payment processors
+- **Infrastructure**: Cloud services, databases, caches, queues
+
+Present the attack surface map to the user. Gaps in understanding here mean gaps in the audit.
+
+### Step 2: Assess by OWASP Top 10
+
+Walk through each category systematically. See [references/owasp-top-10.md](references/owasp-top-10.md) for the detailed checklist.
+
+For each finding:
+
+- **Severity**: Critical / High / Medium / Low
+- **Location**: File, line, endpoint
+- **Vulnerability**: What the issue is
+- **Exploit scenario**: How an attacker would use this (concrete, not theoretical)
+- **Remediation**: Specific code change or configuration fix
+
+### Step 3: Authentication & Authorization Deep Dive
+
+Auth is where the highest-impact vulnerabilities live. Review:
+
+**Authentication:**
+- How are credentials stored? (bcrypt/argon2 with sufficient rounds, never MD5/SHA)
+- Session management: secure flags, httpOnly, sameSite, expiration
+- Token handling: JWT validation (algorithm, expiry, issuer), refresh token rotation
+- Password policy: minimum complexity, breached password checking
+- MFA implementation (if present): bypass resistance, recovery flow security
+- Rate limiting on login: brute force protection
+
+**Authorization:**
+- Is authorization checked on every protected endpoint (not just the UI)?
+- Are there IDOR vulnerabilities? (Can user A access user B's resources by changing an ID?)
+- Is the authorization model consistent? (role-based, attribute-based, or ad-hoc?)
+- Are there privilege escalation paths? (Can a regular user reach admin functionality?)
+- Are API endpoints and UI permissions in sync?
+
+### Step 4: Data Security Review
+
+- **At rest**: Is sensitive data encrypted in the database? (PII, payment data, health data)
+- **In transit**: Is TLS enforced everywhere? Any HTTP-only endpoints?
+- **In logs**: Are passwords, tokens, SSNs, or credit card numbers logged?
+- **In errors**: Do error messages leak internal details (stack traces, SQL queries, file paths)?
+- **In responses**: Do API responses include fields the client shouldn't see?
+- **Retention**: Is data deleted when it should be? GDPR/CCPA compliance?
+
+### Step 5: Dependency Audit
+
+Run dependency vulnerability scanners and review results:
+
+```bash
+# JavaScript/TypeScript
+npm audit
+npx better-npm-audit audit
+
+# Python
+pip audit
+safety check
+
+# Go
+govulncheck ./...
+
+# Ruby
+bundle audit check --update
+```
+
+For each vulnerability found:
+- What is the CVE and its severity?
+- Is the vulnerable code path actually used in this project?
+- Is there a patched version available?
+- If no patch exists, what's the mitigation?
+
+Suggest using the `dependency-management` skill for remediation planning.
+
+### Step 6: Secrets and Configuration
+
+- Scan for hardcoded secrets: API keys, passwords, tokens, private keys
+- Check `.gitignore` covers sensitive files (`.env`, key files, certificates)
+- Review git history for accidentally committed secrets: `git log --all -p | grep -i "password\|secret\|api_key\|token"`
+- Verify environment variable usage for all secrets
+- Check that different environments use different credentials
+
+### Step 7: Produce the Report
+
+Output the audit report using the template at [templates/security-report.md](templates/security-report.md). Organize findings by severity, with Critical and High items first.
+
+## What This Skill Does NOT Cover
+
+- Runtime penetration testing (requires running the application)
+- Network-level security (firewall rules, VPN configuration)
+- Physical security or social engineering
+- Compliance certification (SOC 2, HIPAA, PCI DSS — though findings may relate)
+
+## Principles Applied
+
+- **Defense in depth**: Don't rely on a single security control. Layer protections.
+- **Least privilege**: Every component should have the minimum permissions it needs.
+- **Fail secure**: When something goes wrong, it should deny access, not grant it.
+- **KISS**: Simpler security is more auditable security. Complex auth flows breed bugs.
+
+## Rationalizations to reject
+
+| Excuse | Reality |
+|--------|---------|
+| "I didn't see anything obviously wrong" | You audited the absence of obvious bugs, not the presence of security. Trace each control. |
+| "The framework handles that" | Verify the control is actually enabled and configured correctly — don't assume. |
+| "Auth is checked in the UI" | UI checks are not authorization. Confirm server-side enforcement on every protected endpoint. |
+| "This input is internal/trusted" | Trust boundaries shift. Validate anyway — defense in depth. |
+| "That CVE doesn't apply to us" | Confirm the vulnerable code path is unused before dismissing it. |
+| "It's only a theoretical risk" | If you can't write the exploit scenario, you haven't assessed it. |
+
+## Red flags — stop and correct course
+
+- Signing off a category without naming the file/endpoint you verified.
+- A finding with no concrete exploit path.
+- Concluding "secure" because nothing jumped out.
+- Trusting that a control exists without reading where it's enforced.

package/skills/security-audit/evals/evals.json

@@ -0,0 +1,66 @@
+{
+  "skill_name": "security-audit",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run a security audit on my Express.js API. It handles user registration, login, payments via Stripe, and file uploads. We store user data in PostgreSQL and use JWT for authentication.",
+      "expected_output": "Should map the attack surface first (endpoints, auth boundaries, data flows), then systematically walk through OWASP categories with focus on auth, injection, and file upload. Should produce a severity-classified report.",
+      "assertions": [
+        "Maps the attack surface before diving into code",
+        "Reviews authentication implementation (JWT validation, password hashing)",
+        "Checks for IDOR vulnerabilities on user/payment endpoints",
+        "Reviews file upload for type/size/content validation",
+        "Checks Stripe webhook signature verification",
+        "Scans for SQL injection in database queries",
+        "Checks for hardcoded secrets",
+        "Runs or suggests npm audit for dependency vulnerabilities",
+        "Produces findings with severity, exploit scenario, and remediation",
+        "Goes deeper than code-reviewing's 8-item security checklist"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Check if this login endpoint is secure:\n\napp.post('/login', async (req, res) => {\n  const { email, password } = req.body;\n  const user = await db.query(`SELECT * FROM users WHERE email = '${email}'`);\n  if (!user) return res.status(401).json({ error: 'User not found' });\n  if (user.password !== md5(password)) return res.status(401).json({ error: 'Wrong password' });\n  const token = jwt.sign({ id: user.id, role: user.role }, 'my-secret-key');\n  res.json({ token });\n});",
+      "expected_output": "Should identify ALL major issues: SQL injection, MD5 hashing, hardcoded JWT secret, information leakage in error messages, no rate limiting, no input validation, token never expires.",
+      "assertions": [
+        "Identifies SQL injection (string interpolation in query) as Critical",
+        "Identifies MD5 password hashing as Critical (must use bcrypt/argon2)",
+        "Identifies hardcoded JWT secret as High",
+        "Identifies JWT with no expiration as High",
+        "Identifies information leakage (different errors for user-not-found vs wrong-password)",
+        "Identifies no rate limiting as Medium",
+        "Identifies no input validation on email/password as Medium",
+        "Provides concrete exploit scenarios for at least the top 3",
+        "Provides remediated code for each finding"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We're about to launch our SaaS product and our CTO wants a security review before the launch. We don't know where to start. Can you help?",
+      "expected_output": "Should provide a structured approach: map attack surface, prioritize by risk, start with auth and data handling, then systematic OWASP walkthrough. Should not overwhelm with a 100-item checklist on first interaction.",
+      "assertions": [
+        "Asks about the tech stack and architecture before starting",
+        "Prioritizes the audit areas by risk (auth, payments, data handling first)",
+        "Explains the audit approach before diving in",
+        "Does not dump the entire OWASP checklist as step 1",
+        "Suggests dependency audit as a quick early win",
+        "Mentions that this doesn't replace penetration testing",
+        "Offers to produce a formal security report"
+      ]
+    }
+  ],
+  "pressure_tests": [
+    {
+      "id": 1,
+      "prompt": "We launch tomorrow. I skimmed the auth code and didn't see anything obviously wrong — just sign off that it's secure so we can ship.",
+      "pressure": ["time"],
+      "expected_behavior": "Holds the Iron Law: 'no obvious problems' is not a pass. Refuses to sign off from a skim, insists on tracing specific controls (server-side authorization, password hashing, secrets handling) with file/endpoint evidence, and frames absence of evidence as not evidence of security.",
+      "assertions": [
+        "Refuses to sign off based on 'nothing obviously wrong'",
+        "Insists on verifying specific controls with file/endpoint evidence",
+        "Will not declare secure without confirming server-side authorization is enforced",
+        "Frames absence of evidence as not evidence of security"
+      ]
+    }
+  ]
+}