feat(ce-work,ce-security-audit): add ruflo integration and trajectory capture

README.md

@@ -8,11 +8,11 @@
 
 [![Build Status](https://github.com/EveryInc/compound-engineering-plugin/actions/workflows/ci.yml/badge.svg)](https://github.com/EveryInc/compound-engineering-plugin/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-black.svg)](LICENSE)
-[![Skills](https://img.shields.io/badge/skills-33-black.svg)](skills/guides/README.md)
+[![Skills](https://img.shields.io/badge/skills-34-black.svg)](skills/guides/README.md)
 
 </div>
 
-Compound Engineering is a plugin of 33 skills for AI coding agents. It structures the work around a loop — brainstorm, plan, build, review, then **capture what you learned** — so the knowledge from each change is written down where the next change can read it.
+Compound Engineering is a plugin of 34 skills for AI coding agents. It structures the work around a loop — brainstorm, plan, build, review, then **capture what you learned** — so the knowledge from each change is written down where the next change can read it.
 
 It runs on 14 agent hosts, including Claude Code, Cursor, and Codex.
 
@@ -170,13 +170,13 @@ Starting from a bug instead of a feature? Use [`/ce-debug`](skills/guides/ce-deb
 
 ## Skills at a glance
 
-33 skills, grouped by what they are for. The full catalog, with a page per skill and how each one chains into the others, is in **[skills/guides](skills/guides/README.md)**.
+34 skills, grouped by what they are for. The full catalog, with a page per skill and how each one chains into the others, is in **[skills/guides](skills/guides/README.md)**.
 
 | Group | Skills | What it covers |
 |-------|--------|----------------|
 | [Core loop](skills/guides/README.md#the-core-loop) | `ce-brainstorm` `ce-plan` `ce-work` `ce-simplify-code` `ce-code-review` `ce-compound` | The six steps of every iteration |
 | [Around the loop](skills/guides/README.md#around-the-loop) | `ce-strategy` `ce-product-pulse` `ce-sweep` `ce-compound-refresh` | Anchors and feeds that keep the loop grounded |
-| [On demand](skills/guides/README.md#on-demand) | `ce-ideate` `ce-pov` `ce-debug` `ce-explain` `ce-doc-review` `ce-optimize` `ce-prototype` | Reached for when a specific need arises |
+| [On demand](skills/guides/README.md#on-demand) | `ce-ideate` `ce-pov` `ce-debug` `ce-explain` `ce-doc-review` `ce-optimize` `ce-prototype` `ce-security-audit` | Reached for when a specific need arises |
 | [Git workflow](skills/guides/README.md#git-workflow) | `ce-commit` `ce-commit-push-pr` `ce-babysit-pr` `ce-resolve-pr-feedback` `ce-worktree` | Committing, shipping, and shepherding PRs |
 | [Autonomous](skills/guides/README.md#autonomous-pipeline) | `lfg` | The whole pipeline, hands-off |
 | [Testing & design](skills/guides/README.md#frontend-design) | `ce-test-browser` `ce-test-xcode` `ce-polish` `ce-dogfood` | Verifying and polishing what you built |

skills/ce-debug/references/fix.md

@@ -9,7 +9,7 @@ Read this before editing any file in Phase 3. The branch check and the pre-fix s
 1. Choose the regression test's home. Follow the active project instructions and any applicable subdirectory-scoped instructions, and always inspect existing tests before adding coverage. Use an existing failing test when it already captures the bug, update an existing test when it owns the contract but has the wrong expectation, strengthen an over-mocked test that should have caught the bug, or add a new minimal isolated test only when no existing test is the right home. It must fail on the current bug and pass once the corrected behavior lands; name it so the failure message explains the bug. The body's precondition decides whether an existing test may be updated at all: a confirmed defect, never a test whose expectation the change deliberately reverses.
 2. Verify that test fails for the right reason — the root cause, not unrelated setup.
 3. Implement the **minimal** fix: the root cause and nothing else. No drive-by refactors, formatting, or unrelated cleanup — those are separate commits.
-4. Verify the test passes, then run the broader suite for regressions.
+4. Verify the test passes. Then **revert-and-verify-failure:** revert the fix and run the test — it MUST fail (this proves the test actually catches the bug, not a false positive); restore the fix and confirm the test passes again. If the test still passes with the fix reverted, the test is a false positive — rewrite it. Then run the broader suite for regressions.
 5. Self-review the diff — read every changed line for style violations, missed edge cases, regressions in adjacent behavior, and missing coverage. The broader polish/review/PR tail belongs to Phase 4, after the debug summary.
 
 **On a failed fix:** return to Phase 2 and *explicitly invalidate the current hypothesis* before forming a new one — state what evidence ruled it out, then form a new hypothesis with its own grounding observation and prediction. Do not retry variants of the same theory ("maybe it was the other branch", "let me also catch this case"); that is the rationalization spiral, not iteration. **3 failed attempts = smart escalation** (same table as Phase 2): if fixes keep failing, the root cause identification was likely wrong.

skills/ce-security-audit/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: ce-security-audit
+description: "Run an on-demand security audit using OWASP Top 10 and STRIDE threat modeling. Use when you want a quick security check without a full /ce-review, before deploying security-sensitive changes, or when touching auth, payments, user data, or API endpoints."
+argument-hint: "[directory path, 'pr', 'diff', or 'full' for full codebase scan]"
+---
+
+# Security Audit
+
+Run a focused security audit on the specified scope. This skill dispatches two security review personas — a **security reviewer** and a **security sentinel** — as generic subagents in parallel and combines their findings into a single report. Each persona is a local prompt asset in this skill's own `references/agents/` directory; seed a generic subagent with the prompt file (do not use a typed `Agent`/`subagent_type` name or platform-level agent registration).
+
+Unlike `/ce-review` (which runs many reviewers across all concerns), this skill runs **only** the security personas — faster and more focused.
+
+## Input
+
+<input_scope> #$ARGUMENTS </input_scope>
+
+## Determine Scope
+
+Based on the input:
+
+| Input | Scope | How to gather files |
+|-------|-------|-------------------|
+| Directory path (e.g., `src/auth/`) | All files in that directory | `Glob` for source files in the path |
+| `pr` or `diff` | Changed files in current branch vs main | `git diff --name-only origin/main...HEAD` |
+| `full` | Entire codebase | All source files (exclude node_modules, dist, vendor) |
+| Empty/no input | Default to `diff` (current branch changes) | Same as `pr` |
+
+## Execution
+
+1. **Gather the file list** based on scope above
+2. **Read the changed/target files** to build the review context
+3. **Dispatch two agents in parallel:**
+
+   **Agent 1: security reviewer** (seed with `references/agents/security-reviewer.md`)
+   - Attacker-mindset review
+   - Focus: injection vectors, auth bypass, secrets in code, SSRF, path traversal
+
+   **Agent 2: security sentinel** (seed with `references/agents/security-sentinel.md`)
+   - Checklist-driven audit
+   - Focus: OWASP Top 10 compliance + STRIDE threat modeling (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege)
+
+   Provide each agent with:
+   - The file contents or diff
+   - The scope description (what area of the codebase this covers)
+   - Any relevant context from CLAUDE.md about the project's auth, payment, or data handling patterns
+
+4. **Wait for both agents to complete**
+5. **Automated vulnerability scan (optional):**
+   If ruflo-security-audit MCP tools are available (check for `mcp__claude-flow__security_scan` in available tools):
+   - Run `mcp__claude-flow__security_scan` with `--depth full` on the scoped files
+   - This adds CVE detection, shell injection scanning, and secrets-at-rest checks that the prompt-based agents above cannot perform
+   - Merge ruflo findings with CE agent findings. Deduplicate: same file:line from both sources -> keep the more detailed finding
+   - If ruflo is not installed, skip this step — CE agents provide sufficient coverage for threat modeling and OWASP
+6. **Combine findings** into a single report
+
+## Output Format
+
+Present a combined security report:
+
+### Summary
+- Total findings by severity (Critical / High / Medium / Low)
+- Overall risk assessment (one sentence)
+
+### Findings
+For each finding (sorted by severity, then by category):
+
+| # | Severity | Category | File:Line | Description | Remediation |
+|---|----------|----------|-----------|-------------|-------------|
+| 1 | Critical | OWASP A01 | `src/auth/login.js:45` | Missing authorization check on admin endpoint | Add role verification middleware |
+| 2 | High | STRIDE: Spoofing | `src/webhooks/handler.js:12` | Webhook signature not verified | Validate HMAC signature before processing |
+
+### Clean Areas
+Note areas that were reviewed and found clean — this provides confidence, not just a list of problems.
+
+## Error Handling
+
+- If one agent fails to dispatch, report findings from the other and note the failure
+- If no files match the scope, report "No files found for the specified scope" and suggest alternatives
+- If the scope is very large (>100 files), warn about token cost and ask whether to proceed or narrow the scope
+
+## When to Use This Skill
+
+- Before deploying changes that touch auth, payments, user data, or API endpoints
+- When adding new endpoints or modifying access control
+- After a security incident to audit related code
+- As a quick check during development — faster than a full `/ce-review`
+- When onboarding to unfamiliar code that handles sensitive operations
+
+## What This Skill Does NOT Do
+
+- Does not replace static analysis tools (Snyk, SonarQube, npm audit) — though ruflo-security-audit adds partial CVE coverage when available
+- Does not run penetration tests or active exploitation
+- Does not modify code — report only

skills/ce-security-audit/references/agents/security-reviewer.md

@@ -0,0 +1,45 @@
+# Security Reviewer
+
+You are an application security expert who thinks like an attacker looking for the one exploitable path through the code. You don't audit against a compliance checklist -- you read the diff and ask "how would I break this?" then trace whether the code stops you.
+
+## What you're hunting for
+
+- **Injection vectors** -- user-controlled input reaching SQL queries without parameterization, HTML output without escaping (XSS), shell commands without argument sanitization, or template engines with raw evaluation. Trace the data from its entry point to the dangerous sink.
+- **Auth and authz bypasses** -- missing authentication on new endpoints, broken ownership checks where user A can access user B's resources, privilege escalation from regular user to admin, CSRF on state-changing operations.
+- **Secrets in code or logs** -- hardcoded API keys, tokens, or passwords in source files; sensitive data (credentials, PII, session tokens) written to logs or error messages; secrets passed in URL parameters.
+- **Insecure deserialization** -- untrusted input passed to deserialization functions (pickle, Marshal, unserialize, JSON.parse of executable content) that can lead to remote code execution or object injection.
+- **SSRF and path traversal** -- user-controlled URLs passed to server-side HTTP clients without allowlist validation; user-controlled file paths reaching filesystem operations without canonicalization and boundary checks.
+
+## Confidence calibration
+
+Security findings have a **lower effective threshold** than other personas because the cost of missing a real vulnerability is high. Security findings at anchor 50 should typically be filed at P0 severity so they survive the gate via the P0 exception (P0 + anchor 50 always reports).
+
+Use the anchored confidence rubric in the subagent template. Persona-specific guidance:
+
+**Anchor 100** — the vulnerability is verifiable from the code: a literal SQL injection (`f"SELECT ... {user_input}"`), a missing CSRF token where the framework convention requires one, an unauthenticated endpoint with `current_user` referenced in the body. No interpretation needed.
+
+**Anchor 75** — you can trace the full attack path: untrusted input enters here, passes through these functions without sanitization, and reaches this dangerous sink. The exploit is constructible from the code alone.
+
+**Anchor 50** — the dangerous pattern is present but you can't fully confirm exploitability — e.g., the input *looks* user-controlled but might be validated in middleware you can't see, or the ORM *might* parameterize automatically. File at P0 if the potential impact is critical so the P0 exception keeps it visible.
+
+**Anchor 25 or below — suppress** — the attack requires conditions you have no evidence for.
+
+## What you don't flag
+
+- **Defense-in-depth suggestions on already-protected code** -- if input is already parameterized, don't suggest adding a second layer of escaping "just in case." Flag real gaps, not missing belt-and-suspenders.
+- **Theoretical attacks requiring physical access** -- side-channel timing attacks, hardware-level exploits, attacks requiring local filesystem access on the server.
+- **HTTP vs HTTPS in dev/test configs** -- insecure transport in development or test configuration files is not a production vulnerability.
+- **Generic hardening advice** -- "consider adding rate limiting," "consider adding CSP headers" without a specific exploitable finding in the diff. These are architecture recommendations, not code review findings.
+
+## Output format
+
+Return your findings as JSON matching the findings schema. No prose outside the JSON.
+
+```json
+{
+  "reviewer": "security",
+  "findings": [],
+  "residual_risks": [],
+  "testing_gaps": []
+}
+```