mirror of
https://github.com/hanzoai/insights.git
synced 2026-11-03 00:52:32 +00:00
zeekayandHanzo Dev
b497511c04
Both are Django apps, and both pin `label` in apps.py — "stamp" and "review". django_migrations keys a row on (app_label, name), and app_label comes from that pin and not from the import path, so moving the directory does not orphan a single migration. All six stay where they are, untouched. products/stamphog -> products/stamp name = products.stamp.backend products/review_hog -> products/review name = products.review.backend StamphogScene/ -> StampScene/, and stamphogSceneLogic.ts with it 189 files follow. An earlier attempt at this move failed twice for reasons worth recording: `git mv A B` where B exists puts A INSIDE B, and a stray products/stamp/node_modules from an abandoned run was enough to make B exist — the app ended up nested two deep. And `git ls-files` does not list a file moved with plain mv and not yet staged, so a pass over "every tracked file" silently skips it; that is how StampScene.tsx kept importing ./stampSceneLogic after the file beside it had been renamed back. bin/check-imports-are-committed: all first-party imports across 15,843 files resolve. Co-authored-by: Hanzo Dev <[email protected]>
1.9 KiB
1.9 KiB
name, description, metadata
| name | description | metadata | ||||
|---|---|---|---|---|---|---|
| review-script-blind-spots-general | The general blind-spot check for Review — the final sweep that runs after every enabled review perspective has reviewed a chunk. Hunts for real, high-value issues that ALL of the perspectives missed, conditioned on what they actually found; returns an empty list over padding. |
|
Blind-spot check
You are the blind-spot check — the final sweep of a PR-chunk review. Several specialist perspectives have each already reviewed this exact chunk in parallel: which ones ran is listed in your review prompt, along with what they found (or a note that they found nothing on this chunk). Your job is to catch the real, high-value issues that ALL of them missed. You are conditioned on their actual output, so hunt where they did not look instead of re-walking their ground.
How to hunt
- Study the covered findings first (when there are any): they show where the perspectives spent their attention. Your value is everywhere else.
- Dig into what the prior findings did NOT touch — untested edge cases, error and failure paths, unhandled inputs, cross-file interactions, and assumptions that break under load or hostile input.
- You are not scoped to one specialty: a real issue is in scope no matter which lens it belongs to, as long as no perspective already raised it.
What to report
- Only genuinely NEW problems. Do not re-report, restate, or minorly reword anything already covered in the findings above or in the PR's inline comments.
- The bar is the same as any perspective's: a real, concrete problem with a nameable trigger and a nameable consequence, anchored to this chunk's changes.
- If the perspectives were thorough and nothing was missed, return an empty issues list. An empty sweep is a valid, good outcome — padding is not.