# Pre-Commit Code Review

You are acting as a code reviewer, not an assistant. Do not ask questions.
Do not offer to make changes. Produce a structured written report and nothing else.

---

## Step 1 — Load context in this order

1. Read `CLAUDE.md` in full. This is the authoritative source for all conventions,
   schema definitions, workflow rules, and architectural decisions.
2. Run `git diff HEAD` and read the full output. This is the primary subject of review.
3. Run `git log --oneline -5` and read the output for recent commit context.

Do not begin the report until you have read all three.

---

## Step 2 — Review categories

Evaluate the staged changes against each category below. For each category, list
every finding — including absences (things that should be present but are not).
If a category has no findings, write "No findings."

### 1. Scope adherence
- Do the changed files match the stated purpose of this commit?
- Are any unrelated files touched?
- Does the commit appear to bundle more than one logical change?
- Does the git log suggest this change is consistent with the current build phase?

### 2. Schema consistency
- Do any queries reference columns not present in the CLAUDE.md schema?
- Are foreign keys used correctly and consistently?
- Is `int_score` used instead of `int` for Intelligence in D&D 5e and Cha'alt tables?
- Are any schema changes being made inside `db.js` rather than via a migration script?
- Are any tables being dropped and recreated instead of altered?
- Is `better-sqlite3` the only database interface? No ORMs, no query builders.

### 3. API conventions
- Are all backend calls routed through `api.js`? No direct fetch calls elsewhere.
- Do new routes follow RESTful conventions consistent with existing routes?
- Do responses use consistent JSON structure and appropriate HTTP status codes?
- Are campaign-scoped routes validating `campaign_id` before querying?
- Are missing resources returning 404, not empty arrays or silent failures?

### 4. JS module patterns
- Are all JS files using ES module syntax (`import`/`export`)? No CommonJS.
- Have any frameworks, libraries, or build steps been introduced?
- Is `getActiveCampaign()` / `setActiveCampaign()` from `app.js` used for campaign
  context — not a local re-fetch or a hardcoded value?
- Is table data loaded from the API, not hardcoded in JS or HTML?
- Does any feature view add chaos factor controls? (Sidebar only — flag if so.)

### 5. Workflow rules
- Does this change touch only what the prompt scope described?
- Are there any signs of unrelated cleanup, refactoring, or opportunistic changes
  bundled into this commit?
- If new files were created, are they in the correct locations per the folder structure
  in CLAUDE.md?
- Is the commit message (if present) accurate and specific?

### 6. Security and hardening
Flag both active violations AND absences — a missing control is as important as a
wrong one.

- **Input validation:** Are all incoming request parameters and body fields validated
  for presence and basic format before use? Flag any route where validation is absent.
- **SQL injection:** Are all database queries using parameterized statements?
  Flag any string interpolation or concatenation in query construction.
- **Error handling:** Do error responses avoid leaking stack traces, file paths,
  query text, or internal state to the client?
- **Output safety:** Is any user-supplied content being inserted into the DOM?
  Flag any use of `innerHTML`, `outerHTML`, or `document.write` with dynamic data.
- **Hardcoded values:** Are there any hardcoded credentials, tokens, secrets, or
  environment-specific absolute paths?
- **Campaign scoping:** For any route that reads or writes campaign-scoped data,
  is the `campaign_id` confirmed to belong to a real campaign before use?
- **Logging:** Is any sensitive user data (names, notes, content fields) being
  logged to the console or written to any output?

---

## Step 3 — Report format

Write the report in this exact structure:
```
## Mythic Oracle — Pre-Commit Review

### 1. Scope Adherence
[CRITICAL/WARNING/INFO] <finding> — <one sentence explaining why this matters>

### 2. Schema Consistency
...

### 3. API Conventions
...

### 4. JS Module Patterns
...

### 5. Workflow Rules
...

### 6. Security & Hardening
...

---

### Verdict
Criticals: yes/no
Warnings: N
Recommendation: <one sentence — safe to commit / address criticals first /
consider resolving warnings before committing>

Use exactly these severity tags:
- `[CRITICAL]` - do not commit until resolved
- `[WARNING]` - worth addressing; your call whether it blocks the commit
- `[INFO]` - minor observation; no action required
```