@vigolium/piolium 0.0.1

package/skills/audit/references/chamber-protocol.md

@@ -0,0 +1,384 @@
+# Review Chamber Protocol
+
+Defines the debate format, agent interaction rules, round limits, and convergence criteria for the
+Phase 10 Review Chamber multi-agent debate system.
+
+## Overview
+
+A Review Chamber is a 4-agent debate team that processes a threat scenario cluster (grouped
+DFD/CFD slices sharing trust boundaries). Four roles — Attack Ideator, Code Tracer, Devil's
+Advocate, and Chamber Synthesizer — operate through structured rounds of hypothesis generation,
+evidence gathering, adversarial challenge, and verdict synthesis.
+
+Findings emerge from structured argumentation, not solitary analysis. This eliminates the
+confirmation bias inherent in a single agent both imagining and validating an attack.
+
+## Chamber Formation
+
+### Cluster Formation
+
+After Phase 4 (SAST + inline enrichment) and Phase 9 (spec gap) complete, the orchestrator forms threat
+clusters from the KB:
+
+1. Read `## High-Risk DFD Slices` and `## High-Risk CFD Slices` from `archon/attack-surface/knowledge-base-report.md`
+2. Group slices by shared trust boundary or component affinity (slices accessing the same data store,
+   enforcement point, or transport layer belong together)
+3. Each cluster becomes one chamber
+4. Typical audit produces 3-8 chambers depending on architecture complexity
+5. Priority ordering: clusters touching authentication/authorization first, then data ingestion,
+   then external API surface, then internal components
+
+### Chamber Directory Structure
+
+```
+archon/chamber-workspace/
+  chamber-01-auth-flows/
+    debate.md              # append-only debate transcript
+    evidence/              # tracer evidence attachments (on-demand QL queries, screenshots)
+    variant-candidates/    # scout-discovered variant candidates
+  chamber-02-data-ingestion/
+    debate.md
+    evidence/
+    variant-candidates/
+```
+
+### NNN Range Assignment
+
+To prevent finding ID collisions across parallel chambers, the orchestrator assigns non-overlapping
+ranges before spawning:
+
+```
+Chamber 1: p7-001 through p7-019
+Chamber 2: p7-020 through p7-039
+Chamber 3: p7-040 through p7-059
+Chamber 4: p7-060 through p7-079
+...
+```
+
+The Synthesizer receives its assigned range in the spawn prompt.
+
+### Concurrency Limit
+
+Up to 3 chambers run simultaneously. If more than 3 clusters exist, the orchestrator spawns the
+first 3 in priority order, then spawns subsequent chambers as earlier ones complete.
+
+## Agent Roles and Constraints
+
+### Attack Ideator
+
+- Generates attack hypotheses by cycling through 8 creative modes
+  (see `creative-attack-modes.md`)
+- Does NOT trace code paths, does NOT issue verdicts
+- Reads: KB (threat model, domain attack research, attack surface), CodeQL structural analysis
+  section, enrichment notes, spec gap analysis
+- Writes: hypothesis batches to debate transcript
+- Produces 3-7 numbered hypotheses (H-01 through H-07) per batch
+
+### Code Tracer
+
+- Takes each hypothesis and traces through actual code with evidence
+- Uses Method 2.6 from `deep-analysis.md`: call-graph-slices.json, entry-points.json, sinks.json,
+  flow-paths-all-severities.md, on-demand QL queries against live DB
+- Does NOT generate hypotheses, does NOT issue final verdicts
+- Reads: source code, CodeQL artifacts, KB structural analysis
+- Writes: per-hypothesis evidence blocks to debate transcript
+- Produces: reachability verdict (REACHABLE / UNREACHABLE / PARTIAL) with file:line chains
+
+### Devil's Advocate
+
+- Challenges EVERY finding the Tracer marks reachable
+- Searches 5 protection layers: language, framework, middleware, application, documentation
+- Must argue against even obvious vulnerabilities — inability to construct credible defense is
+  itself strong evidence of a genuine vulnerability
+- Does NOT generate hypotheses
+- Reads: source code, framework documentation, project SECURITY.md, deployment configs
+- Writes: defense briefs to debate transcript
+- Must explicitly check all 8 Claude-Specific FP patterns from `triage-and-prereqs.md`
+
+### Chamber Synthesizer
+
+- Orchestrates the debate flow by writing phase markers to the transcript
+- Reads all arguments from other roles and makes judgment calls
+- Requests additional investigation rounds when evidence is insufficient
+- Assigns calibrated severity per `triage-and-prereqs.md` Severity Calibration
+- Only role that writes finding drafts to `archon/findings-draft/`
+- Manages the attack pattern registry (append confirmed patterns)
+- Does NOT generate hypotheses, does NOT trace code
+
+## Debate Protocol
+
+### Round Flow
+
+```
+Synthesizer writes "## Round 1 -- Ideation" marker to debate.md
+  │
+  ▼
+Ideator reads marker, generates 3-7 hypotheses, appends to debate.md
+  │
+  ▼
+Synthesizer writes "## Round 2 -- Tracing" marker
+  │
+  ▼
+Tracer reads hypotheses, traces each through code, appends evidence to debate.md
+  │
+  ▼
+Synthesizer writes "## Round 3 -- Challenge" marker
+  │
+  ▼
+Devil's Advocate reads Tracer evidence, writes defense brief per hypothesis, appends to debate.md
+  │
+  ▼
+Synthesizer writes "## Round 4 -- Synthesis" marker
+  │
+  ▼
+Synthesizer reads all arguments, issues verdicts OR writes "INVESTIGATE:" directives
+  │
+  ▼
+[Optional] Rounds 5-6: Focused re-investigation (max 2 additional rounds per hypothesis)
+  │
+  ▼
+Synthesizer writes finding drafts for VALID findings, closes chamber
+```
+
+### Agent Communication
+
+Within archon-audit-claude: agents communicate via the shared `debate.md` file AND `SendMessage`.
+The Synthesizer uses `SendMessage` to notify each agent when its turn begins. Agents read
+the transcript to understand prior arguments.
+
+Within archon-audit-codex: agents poll `debate.md` for new sections (file-based coordination).
+
+### Turn-Taking Rules
+
+1. Only ONE agent writes to `debate.md` at a time (serialized by debate rounds)
+2. Each agent appends to the end of the file — never edits prior sections
+3. Each section is tagged with the role name: `### [IDEATOR]`, `### [TRACER]`, `### [ADVOCATE]`,
+   `### [SYNTHESIZER]`
+4. Timestamps are included for debugging and performance analysis
+
+### Round Limits
+
+- **Maximum 7 hypotheses per ideation batch**: if the Ideator generates more, the Synthesizer
+  prioritizes by expected impact and defers the rest
+- **Maximum 3 rounds per hypothesis**: 1 initial trace+challenge round + 2 follow-up rounds.
+  If unresolved after 3 rounds, the Synthesizer issues a judgment call or marks INCONCLUSIVE
+- **Maximum 6 total rounds per chamber** (1 ideation + 1 tracing + 1 challenge + 1 synthesis +
+  2 follow-up). The Synthesizer may not request more than 2 follow-up rounds.
+
+## Convergence Criteria
+
+Debate ends for a hypothesis when any condition is met:
+
+| Condition | Verdict | Action |
+|-----------|---------|--------|
+| Tracer: UNREACHABLE, Advocate confirms no alternate path | DROP | No draft written |
+| Tracer: REACHABLE, Advocate cannot find blocking protection (2 attempts) | VALID | Write finding draft |
+| Tracer: REACHABLE, Advocate finds blocking protection | FALSE POSITIVE | No draft written |
+| 3 rounds without resolution | Synthesizer judgment | Verdict or INCONCLUSIVE |
+| Duplicate of already-adjudicated finding | DUPLICATE | No draft written |
+| Severity determined to be Low | DROP (low severity) | No draft written |
+
+A chamber closes when all hypotheses have reached a terminal verdict.
+
+## Pre-Finding Quality Gate
+
+Before the Synthesizer writes any finding draft, apply this 5-point check:
+
+1. **Attacker control verified?** Tracer confirmed input reaches the path (not inferred)?
+2. **Framework protection checked?** Advocate searched all 5 layers?
+3. **Same-origin confusion?** Is the attack cross-trust-boundary, not same-session?
+4. **Config vs. vulnerability?** Exploitation requires only normal attacker position (not admin)?
+5. **Test/example code?** Vulnerable code ships to production?
+
+If any check fails, the finding is dropped. If ambiguous, the Synthesizer adds
+`Pre-FP-Flag: check-N-ambiguous` to the finding draft for Phase 11 priority.
+
+## Cross-Chamber Intelligence
+
+### Attack Pattern Registry
+
+File: `archon/attack-pattern-registry.json`
+
+When the Synthesizer confirms a finding, it checks the registry:
+- Pattern exists → append to `confirmed_instances`
+- New pattern → create entry with `detection_signature` and `untested_candidates`
+
+Other chambers read the registry before starting new ideation rounds. The Ideator
+incorporates confirmed patterns to look for the same class of vulnerability in its cluster's scope.
+
+Schema:
+
+```json
+{
+  "patterns": [{
+    "id": "AP-001",
+    "title": "Unsafe ObjectInputStream deserialization",
+    "bug_class": "deserialization",
+    "root_cause": "ObjectInputStream.readObject() without ObjectInputFilter",
+    "detection_signature": {
+      "codeql": "<QL query fragment>",
+      "grep": "<regex pattern>",
+      "semgrep": "<semgrep pattern>"
+    },
+    "confirmed_instances": [
+      {"finding_ref": "p7-003-admin-deser.md", "file": "src/admin/AdminService.java:142"}
+    ],
+    "untested_candidates": [
+      {"file": "src/backup/BackupRestoreService.java:201", "reason": "Uses ObjectInputStream"}
+    ],
+    "severity": "CRITICAL"
+  }]
+}
+```
+
+### Variant Scout Integration
+
+The Variant Scout (optional 5th agent) monitors the debate transcript for confirmed patterns
+and immediately searches for structural variants in sibling components. Findings are written to
+`archon/chamber-workspace/<chamber-id>/variant-candidates/` for the Synthesizer to decide
+whether to open a new debate round or defer to Phase 12.
+
+## Debate Transcript Format
+
+File: `archon/chamber-workspace/<chamber-id>/debate.md`
+
+```markdown
+# Review Chamber: <chamber-id>
+
+Cluster: <description of threat scenario cluster>
+DFD Slices: <comma-separated slice identifiers from KB>
+NNN Range: <assigned range, e.g., 001-019>
+Started: <ISO timestamp>
+Status: ACTIVE | CLOSED
+
+---
+
+## Round 1 -- Ideation
+
+### [IDEATOR] Hypothesis Batch -- <ISO timestamp>
+
+**H-01: <hypothesis title>**
+- Attack class: <e.g., TOCTOU, second-order injection, trust boundary confusion>
+- Chain: <multi-step chain description if applicable>
+- Preconditions: <attacker starting position>
+- Target asset: <what the attacker gains>
+- Entry point: <suspected entry, may be approximate>
+- Sink: <suspected sensitive operation>
+- Creativity signal: <why a solo agent would miss this>
+
+**H-02: <hypothesis title>**
+...
+
+---
+
+## Round 2 -- Tracing
+
+### [TRACER] Evidence for H-01 -- <ISO timestamp>
+
+**Reachability: REACHABLE | UNREACHABLE | PARTIAL**
+
+Code path:
+1. `<file:line>` -- <description>
+2. `<file:line>` -- <description>
+3. `<file:line>` -- <description>
+
+Sanitizers on path:
+- `<file:line>` -- <description of control and bypassability>
+
+CodeQL slice: call-graph-slices.json entry #<N>, reachable: <true|false>
+On-demand query: <path to .ql file if run>
+
+**Assessment**: <summary of reachability evidence>
+
+---
+
+## Round 3 -- Challenge
+
+### [ADVOCATE] Defense Brief for H-01 -- <ISO timestamp>
+
+**Protection search results:**
+
+| Layer | Protection Found | Blocks Attack? |
+|-------|-----------------|----------------|
+| Language | <finding> | <Yes/No> |
+| Framework | <finding> | <Yes/No> |
+| Middleware | <finding> | <Yes/No> |
+| Application | <finding> | <Yes/No> |
+| Documentation | <finding> | <Yes/No> |
+
+**Claude FP Pattern Check**: <which of the 8 patterns were checked, any matches>
+
+**Defense argument**: <strongest case for false positive>
+
+**Verdict recommendation**: Cannot disprove | Disproved by <layer> protection
+
+---
+
+## Round 4 -- Synthesis
+
+### [SYNTHESIZER] Verdict for H-01 -- <ISO timestamp>
+
+**Prosecution summary**: <key evidence from Tracer>
+
+**Defense summary**: <key argument from Advocate>
+
+**Pre-FP Gate**: all checks passed | failed on check-<N>
+
+**Verdict: VALID | FALSE POSITIVE | DROP | INCONCLUSIVE**
+**Severity: MEDIUM | HIGH | CRITICAL**
+**Rationale**: <one-sentence justification citing evidence from both sides>
+
+**Finding draft written to**: archon/findings-draft/p7-<NNN>-<slug>.md
+**Registry updated**: AP-<NNN> <title> (or "no new pattern")
+
+---
+
+## [Optional] Round 5 -- Focused Re-investigation
+
+### [SYNTHESIZER] Investigation Request -- <ISO timestamp>
+
+**Directed to**: TRACER | ADVOCATE
+**Regarding**: H-<NN>
+**Question**: <specific question>
+
+### [TRACER|ADVOCATE] Response for H-<NN> -- <ISO timestamp>
+...
+
+---
+
+## Chamber Summary
+
+| Hypothesis | Verdict | Severity | Finding Draft |
+|-----------|---------|----------|---------------|
+| H-01 | VALID | HIGH | p7-001-<slug>.md |
+| H-02 | FALSE POSITIVE | -- | -- |
+| H-03 | DROP (unreachable) | -- | -- |
+| ... | | | |
+
+Findings written: <count>
+Patterns added to registry: <count>
+Variant candidates: <count>
+
+Chamber closed: <ISO timestamp>
+```
+
+## Relationship to Phase 11
+
+The Devil's Advocate within the chamber subsumes most of Phase 11 Stage 2's adversarial function.
+Phase 11 is reduced to **P11-LITE**:
+
+- **Stage 1 (unchanged)**: apply `fp-check` skill to all VALID findings. Catches systematic
+  FP patterns the Advocate might share with other chamber agents.
+- **Stage 2 (CRITICAL/HIGH only)**: spawn one fresh cold-verification agent per CRITICAL/HIGH
+  finding with ONLY the finding draft path (no debate transcript). Focus on real-environment
+  reproduction per `real-env-validation.md`. Medium findings skip Stage 2 entirely — already
+  challenged by the Devil's Advocate during debate.
+
+## Error Recovery
+
+- **Agent crashes mid-round**: Synthesizer detects via missing response. Notifies orchestrator.
+  Orchestrator spawns replacement agent with the current debate transcript as context.
+- **Chamber stalls**: if no new content appears in debate.md for an extended period, the
+  orchestrator messages the Synthesizer to check status or force convergence.
+- **Session recovery**: orchestrator reads `debate.md` Status field. ACTIVE chambers with
+  incomplete rounds are resumed from the last completed round marker.

package/skills/audit/references/creative-attack-modes.md

@@ -0,0 +1,221 @@
+# Creative Attack Generation Modes
+
+Eight structured thinking modes for the Attack Ideator agent. Cycle through all 8 modes for each
+threat cluster, generating at least one hypothesis per applicable mode. Hypotheses that span
+multiple modes (e.g., chaining + race condition) are the most valuable and should be prioritized.
+
+## Mode 1: Vulnerability Chaining
+
+Chain individually-low-severity issues into high-severity exploit paths. No single issue may
+qualify as a finding alone, but the combination crosses a trust boundary.
+
+**Thinking prompts:**
+- "If IDOR gives read access to user metadata, and metadata contains session tokens, then
+  IDOR + token reuse = account takeover"
+- "If SSRF is limited to internal DNS resolution, and internal DNS resolves to metadata endpoints,
+  then SSRF + cloud metadata = credential theft"
+- "This CVE was patched, but the patch only covers the HTTP path. The WebSocket path uses the same
+  parser without the fix"
+- "Phase 1 advisory + Phase 9 spec gap: can a known CVE's patch be bypassed through a protocol
+  compliance gap?"
+- "Low-severity information disclosure + low-severity injection = high-severity authenticated RCE"
+
+**Cross-reference inputs:**
+- Phase 1 advisory intelligence (known CVEs, patch commits)
+- Phase 9 spec gap analysis (protocol compliance gaps)
+- Phase 4 SAST enrichment notes (individually-dropped low-severity findings)
+- Phase 3 domain attack research (known attack chains per domain)
+
+## Mode 2: Business Logic Abuse
+
+Think about what the application is *designed* to do and how that design can be abused.
+Business logic bugs are invisible to SAST tools.
+
+**Thinking prompts:**
+- "Can I refund more than I paid? Process a negative quantity?"
+- "Can I invite myself to a higher-privilege role?"
+- "Can I skip step 2 and go directly from step 1 to step 3?"
+- "Can I exhaust another tenant's quota by manipulating the accounting?"
+- "Can I register the same resource twice and exploit the race between checks?"
+- "Can I abuse a legitimate feature (export, share, webhook) as an exfiltration channel?"
+- "Can I manipulate the order of operations to bypass a check that assumes sequential execution?"
+- "Can I abuse an undo/rollback mechanism to restore a revoked privilege?"
+
+**Focus areas:**
+- Multi-step workflows (payment, registration, approval, provisioning)
+- Quota and rate systems (credits, API limits, storage)
+- Invitation and delegation systems
+- State machines with transitions (draft -> published -> archived)
+
+## Mode 3: Race Conditions and TOCTOU
+
+Identify state-dependent operations and ask "what if the state changes between check and use?"
+Race conditions are notoriously difficult to find through static analysis.
+
+**Thinking prompts:**
+- "The balance check and deduction are not atomic — double-spend?"
+- "Role is checked, then 100ms later the privileged action executes. Can I change my role between?"
+- "Symlink substitution between stat() and open()?"
+- "Database isolation level is READ COMMITTED — phantom reads in this multi-query operation?"
+- "The session is validated, then the request body is parsed. Can I invalidate the session mid-parse?"
+- "Two concurrent requests to the same endpoint — does the second see the first's uncommitted state?"
+- "The file is written, then permissions are set. Is there a window where the file is world-readable?"
+
+**Detection strategy:**
+- Look for check-then-act patterns without locking or atomic transactions
+- Identify shared mutable state accessed by concurrent handlers
+- Find operations that span multiple I/O calls (DB, file, network)
+- Check for non-atomic read-modify-write sequences
+
+## Mode 4: Second-Order and Stored Attacks
+
+Look for inputs that are stored before being used in a dangerous context. The storage creates
+temporal and spatial separation that hides the attack from simple source-to-sink analysis.
+
+**Thinking prompts:**
+- "User input stored in profile field, later rendered unescaped in admin dashboard (stored XSS)"
+- "Username stored in table A, later concatenated into query when joining table B (second-order SQLi)"
+- "Webhook URL stored in config, later fetched by background job (stored SSRF)"
+- "Template variable stored in database, later rendered by email templating engine (stored SSTI)"
+- "Filename stored during upload, later used in a shell command during processing (stored command injection)"
+- "JSON payload stored in event queue, later deserialized by a consumer with different trust level"
+
+**Detection strategy:**
+- Identify all write paths (user input -> database/file/cache/queue)
+- For each stored value, trace all read paths and their consumption contexts
+- Check if the read context applies different (weaker) sanitization than the write context
+- Pay special attention to cross-service data flows where the consuming service trusts stored data
+
+## Mode 5: Trust Boundary Confusion
+
+Identify where identity, authorization, or trust assumptions change across component boundaries.
+
+**Thinking prompts:**
+- "Microservice A trusts microservice B's claims without re-verification"
+- "Frontend validation assumed to be present by backend"
+- "Internal API endpoints exposed through a public reverse proxy with no re-auth"
+- "Plugin/extension code running with host-level privileges"
+- "The auth middleware checks tokens, but this endpoint is registered before the middleware in the
+  route chain"
+- "The API gateway validates JWT, but the downstream service accepts any request from the gateway IP"
+- "Admin panel is 'internal only' but shares the same origin as the public app (CORS, cookies)"
+- "The CLI tool runs with user privileges but shells out to a helper that runs as root"
+
+**Detection strategy:**
+- Map all trust boundaries from the Phase 3 threat model
+- For each boundary, check: does crossing it require re-authentication? Re-authorization?
+- Identify implicit trust assumptions (IP-based trust, shared-origin trust, process-level trust)
+- Check middleware ordering: are security checks applied before or after route registration?
+- Look for "internal" APIs accessible from external networks
+
+## Mode 6: Parser and Protocol Differentials
+
+Look for places where two components interpret the same input differently. Parser differentials
+are high-severity because they bypass controls that appear correct in isolation.
+
+**Thinking prompts:**
+- "HTTP request smuggling between proxy and backend (CL vs TE)"
+- "JSON parser differential (duplicate keys — which value wins?)"
+- "URL parser differential (authority parsing, percent-encoding, backslash handling)"
+- "Content-Type mismatch between what the validator checks and what the processor consumes"
+- "XML namespace-aware vs namespace-unaware parser (SAML signature wrapping)"
+- "Multipart boundary parsing difference between framework and application code"
+- "Header folding: proxy treats continuation line as part of previous header, backend treats it as new"
+- "Path normalization: security check uses one library, router uses another"
+
+**Cross-reference inputs:**
+- Phase 9 spec gap analysis (RFC compliance gaps in parsers)
+- Phase 3 domain attack research Mode C (protocol-specific attack patterns)
+- `deep-analysis.md` Section 6 (parsing/normalization/sanitization discrepancies)
+
+**Detection strategy:**
+- Identify every parser in the system (URL, JSON, XML, multipart, headers, cookies, query strings)
+- For each parser, check: is the same parser used by both the security check and the consumer?
+- Look for double-encoding, normalization order issues, and spec-non-compliant behavior
+- Check for polyglot inputs that are valid in multiple formats
+
+## Mode 7: State Machine Attacks
+
+Analyze multi-step protocols and state machines for out-of-order, replay, or missing-transition
+attacks.
+
+**Thinking prompts:**
+- "Can I replay step 3 of the OAuth flow to get a second access token?"
+- "Can I send the password reset link to a different email by modifying the request between steps?"
+- "What happens if I send an API request during the 'pending deletion' grace period?"
+- "The session invalidation is async — there is a window where the old session still works"
+- "Can I reuse a one-time code (TOTP, email verification, invite link) by racing the invalidation?"
+- "Can I transition from 'suspended' back to 'active' by calling an endpoint that assumes 'pending'?"
+- "Can I bypass the email verification step by directly calling the post-verification endpoint?"
+- "The payment flow assumes state A -> B -> C, but can I go A -> C directly?"
+
+**Detection strategy:**
+- Map all state machines (user lifecycle, order lifecycle, auth flow, payment flow)
+- For each transition, verify: is the previous state checked? Is the check atomic?
+- Look for state stored in client-side tokens (JWT, cookies) that can be replayed
+- Check for async state updates where the old state remains valid during propagation
+- Identify one-time tokens and verify they are actually invalidated after use
+
+## Mode 8: Supply Chain and Dependency Interaction
+
+Use Phase 1 dependency intelligence to generate hypotheses about how dependencies interact
+with application code.
+
+**Thinking prompts:**
+- "This dependency has a known deserialization gadget. Does the application ever deserialize
+  user-controlled data with this library?"
+- "This transitive dependency is 3 years out of date. What security fixes happened since then?"
+- "The application monkey-patches this library's validation function. Does the patch weaken security?"
+- "The library provides a safe API and an unsafe API. Which one does the application use?"
+- "The library's default configuration is insecure. Does the application override the defaults?"
+- "Two dependencies implement the same protocol differently. Does the application use both on the
+  same data path?"
+- "The dependency was designed for server-side use. The application uses it in a browser context."
+- "The library's error handling returns sensitive information. Does the application expose these errors?"
+
+**Cross-reference inputs:**
+- Phase 1 advisory intelligence (CVEs, GHSAs, patch commits)
+- Phase 3 domain attack research Mode A (library-as-target) and Mode B (library-as-consumer)
+- `supply-chain-risk-auditor` skill output
+- `sharp-edges` and `insecure-defaults` skill outputs
+
+**Detection strategy:**
+- For each security-relevant dependency, trace how the application uses it
+- Check if the application uses the dependency's safe or unsafe API surface
+- Verify default configurations are overridden appropriately
+- Look for version pinning issues and dependency confusion opportunities
+
+## Applying Multiple Modes
+
+The most creative and impactful hypotheses combine multiple modes. When generating a hypothesis
+batch, explicitly attempt at least 2 cross-mode combinations:
+
+**Examples:**
+- Mode 1 (chaining) + Mode 3 (TOCTOU): "Chain a race condition in the payment check with an IDOR
+  to achieve unauthorized fund transfer"
+- Mode 4 (stored) + Mode 5 (trust boundary): "Store a payload via the low-trust user API that gets
+  executed by the high-trust admin renderer"
+- Mode 6 (parser differential) + Mode 7 (state machine): "Use a URL parser differential to bypass
+  the OAuth redirect_uri check, then replay the authorization code"
+- Mode 2 (business logic) + Mode 8 (supply chain): "The caching library serves stale responses.
+  Abuse this to serve a revoked user's data to a new user inheriting the same cache key"
+
+## Ideator Output Format
+
+Each hypothesis must include ALL of these fields:
+
+```markdown
+**H-<NN>: <hypothesis title>**
+- Attack class: <primary mode used>
+- Cross-modes: <secondary modes if applicable, or "none">
+- Chain: <multi-step chain description, or "single-step">
+- Preconditions: <attacker starting position and required capabilities>
+- Target asset: <what the attacker gains>
+- Entry point: <suspected entry point in the code>
+- Sink: <suspected sensitive operation>
+- Creativity signal: <why a solo agent would miss this — what makes it non-obvious>
+```
+
+The "creativity signal" field is mandatory. If the hypothesis is obvious (e.g., "SQL injection in
+a query that concatenates user input"), it does not need the Ideator — the SAST tools already
+found it. The Ideator's value is in hypotheses that require human-like lateral thinking.