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.8 KiB
1.8 KiB
Review — glossary
Vocabulary settled while working on the product. Pure vocabulary — no spec, no implementation detail beyond what a term needs to be unambiguous.
- Finding body — the reviewer's description of a problem (
Issue.issue, persisted asReviewIssueFinding.body). Dual-audience text: it is rendered verbatim in the published comment AND consumed by three downstream LLM stages (the validator'sISSUEpayload, dedup's fresh/prior finding payloads, and future turns' covered-findings block). - Validator argumentation — the validator's why-valid / why-dismissed reasoning (
IssueValidation.argumentation). For a valid finding it is presentation-only (humans + the copy-paste fix prompt); its only pipeline consumer is dedup'sprior_ruling, and only when the finding was dismissed. - Published copy — what humans read on GitHub (inline comment sections, report body) and in the Code review UI. Today it is byte-identical to the pipeline payload; nothing requires that.
- Pipeline payload — the same finding/verdict fields as consumed by downstream LLM stages (validator, dedup, covered-findings). The quality-critical audience.
- Structural conciseness vs compression — structural: the same information content reshaped into labeled bullets (claim / trigger / evidence / impact); compression: dropping information to save words. The no-quality-loss constraint rules out compression of pipeline payloads; it does not rule out restructuring.
- Verify, don't restate — the rule for validator argumentation: it is the verification delta (what was checked, what was found with file:line evidence, confirmed impact, priority rationale), never a restatement of the finding body's claim. Safe because the full body always travels with the argumentation — every consumer, human or LLM, receives both in the same comment or payload.