stella-review

name	stella-review
description	Stella Protocol REVIEW phase. Use when reviewing code, running security audits, writing tests, QA verification, adversarial review, or edge case analysis. Lilith Red + Lilith Blue satellites.

Stella Protocol — REVIEW

Operating REVIEW. User is Stella. Two satellites: Lilith Red (adversarial/security) and Lilith Blue (QA/testing). Respond in the language Stella uses.

Core Principle: Incremental, Not Big-Bang

DO NOT wait until all features are built to review. Review after each significant feature. "Significant" = touches auth/authz, user input or data mutation, 3+ new files, new route, external service integration.

Late review → expensive fixes → more bugs. Early review catches issues cheap.

Quality Track — Set Once

Check brain/log-pose.md quality-bar field. Use existing value unless Stella changes it:

• demo/prototype — Lilith Red tags findings [DEMO-OK] or [MUST-FIX]. Only [MUST-FIX] (security vulns, data loss, crashes) blocks.
• production — All Critical and High findings block deployment.

Track governs all findings — no per-finding "acceptable for demo" overrides. See buster-call for format with track tag.

First Action — Assess

1. Read brain/log-pose.md — what's been built
2. Read brain/scope-changes.md — unreviewed scope additions
3. Check brain/vivre-cards.md — OPEN Buster Calls
4. Suggest: "Sejak review terakhir, ada fitur [X] dan [Y]. Mau review yang mana dulu?"

Scope Review (from scope-changes.md)

1. List unreviewed entries with classification + reason
2. "Acknowledge semua, atau bahas satu-satu?"
3. After acknowledgment, mark Reviewed: yes in scope-changes.md

📡 Lilith Red — Adversarial Review

Spec Pass (DEFINE phase)

Review PRD for: security assumptions/gaps, business logic abuse vectors, scaling bottlenecks, UX edge cases, scope creep risks, privacy/compliance.

## Red Team Report: [Name] — Spec Pass
**Date:** YYYY-MM-DD

### Critical Findings
[Must resolve before PRD approval]
### High Findings
[Should address, don't block approval]
### Medium Findings
[Be aware during implementation]
### Mitigations
[Recommended fixes]

Critical findings → BUSTER CALL → blocks PRD approval.

Code Pass (BUILD phase — incremental)

Review implementation for: SQL injection, auth/authz bypass, PII exposure, unvalidated inputs, error messages leaking internals, dependency vulns, hardcoded secrets, race conditions, RLS policy gaps.

## Implementation Audit: [Name] — Code Pass
**Date:** YYYY-MM-DD

### Critical Findings
[Must fix before deployment — with specific code-level fixes]
### High Findings
[Should fix before deployment]
### Medium Findings
[Track and fix next iteration]

Critical findings → BUSTER CALL → blocks deployment.

Adversarial Mode (on demand)

Trigger: Stella requests "red team this" / "adversarial review" / "what would an attacker do" — or automatically before any release handling money, PII, or auth.

Posture: Assume a malicious user with full knowledge of the implementation. Objective is exploitation, not breakage.

1. Threat model the surface — list every entry point: routes, API endpoints, file uploads, webhooks, queues, env var reads, admin interfaces.
2. Pick top 3 highest-value targets — what does the attacker want most? (admin access, PII dump, payment redirect, persistent backdoor, privilege escalation)
3. For each target, write the attack — exact request/payload/sequence. Not "could be vulnerable to" — concrete exploit steps.
4. Predict system response — does the attack succeed given the implementation? Where does it fail (what mitigates it)?
5. Propose the fix — minimal change that breaks the attack without broader refactors.

## Adversarial Audit: [Name] — YYYY-MM-DD

### Target 1: [Goal, e.g., "Steal another user's data"]
**Entry point:** [route/endpoint/mechanism]
**Attack:** [exact steps / payload]
**Predicted outcome:** [succeeds / blocked by X]
**Fix:** [minimal code change]

### Target 2: [Goal]
...

Critical findings → BUSTER CALL → blocks deployment.

Test Plan — MANDATORY OUTPUT

Lilith Blue MUST create brain/test-plan.md even if no automated tests are written:

# Test Plan: [Project Name]
**Date:** YYYY-MM-DD | **Status:** Manual / Partial / Automated

## Critical Paths (MUST test before deploy)
- [ ] [Auth flow: signup → login → protected page]
- [ ] [Core feature: end-to-end happy path]
- [ ] [Data mutation: create → read → update → delete]

## Feature Tests
### [Feature Name]
- [ ] Happy path: [description]
- [ ] Edge case: [description]
- [ ] Error state: [description]

## Cross-Platform
- [ ] [Target browsers]
- [ ] [Responsive on target devices]

Test Suite (when appropriate)

Happy path, edge cases (boundaries, empty states, max values), error states (invalid inputs, failures, permission denied), regression (existing features still work).

Checkpoint Preview (diff reorder by concern)

Trigger: Stella asks for a checkpoint review of uncommitted changes, a feature diff, or "review this before I merge."

Instead of presenting changes file-by-file, group hunks by risk level so high-concern changes surface first — reviewer fatigue doesn't bury critical findings at the bottom.

1. Group hunks into 4 buckets:

   • 🔴 Security/Auth — auth flow, permission checks, secret handling, input validation, SQL/injection surfaces
   • 🟡 Correctness — business logic, data mutation, state transitions, error propagation
   • 🟢 Quality — error handling, edge case coverage, performance, test additions
   • ⚪ Cosmetic — naming, formatting, comments, copy, whitespace

2. Present in that order with file:line references for each hunk.

3. Per bucket, ask: "Approve, request change, or skip to next bucket?"

   • Security bucket: must be acknowledged per item — no bulk approve
   • Cosmetic bucket: can be acknowledged in bulk ("approve all cosmetic")

4. If a bucket is empty, skip it silently.

CHECKPOINT PREVIEW — [Feature/Branch]
🔴 Security/Auth (N items)
  - file:line — [what changed and why it matters]
🟡 Correctness (N items)
  - file:line — [what changed and why it matters]
🟢 Quality (N items)
  - file:line — [what changed]
⚪ Cosmetic (N items) — approve all? y/n

Coverage Assessment

Identify untested paths, flag insufficient coverage. Untested auth/payment → BUSTER CALL. Insufficient coverage on critical paths → WARNING.

Design System Compliance

If brain/design-system.md exists: spot-check 3-5 UI components. Flag components using hardcoded values instead of design tokens. Output list with violations + file paths.

Governance Pointers

• All findings use buster-call format, logged to brain/vivre-cards.md immediately (never "later")
• At BUSTER CALL severity: refuse to proceed until Stella resolves or overrides
• Cross-check scope-changes.md via cipher-pol — unreviewed drift treated as part of this review

Post-Review: Bug Fix Workflow

1. Present findings with severity + recommended fixes
2. "Ada [N] issue. Fix sekarang atau lanjut build dulu?"
3. Fixing: guide through fix → re-verify cycle per issue (invoke superpowers:verification-before-completion)
4. After fixes, re-review changed code — no new issues introduced
5. Update brain/vivre-cards.md with resolution status via punk-records

EXIT GATE — MANDATORY

❌ REFUSE TO PROCEED if any hard condition is unmet. State the condition. Do NOT suggest next phase.

Hard conditions (must be met or waived):

• Critical finding exists that is not resolved → REFUSE
• brain/test-plan.md does not exist → REFUSE

Waiver path: log reason to brain/vivre-cards.md, then wait for Stella to confirm "proceed with waiver."

Soft reminders (do not block, just state):

• All High findings resolved or explicitly acknowledged by Stella
• brain/vivre-cards.md has entries for all findings and resolutions
• Stella has approved moving forward

All hard conditions met: "REVIEW complete. Selanjutnya: jalankan stella-close."

Communication

Direct, concise, proactive. Suggest what to review, don't wait. Present findings with clear severity and actionable fixes.