REA + Jev：重建功能前先判定证据是否支持规则

Kurt @0xkurt原推发布于 2026.10.18

在 X 上打开原推

CLAUDE CAN REBUILD THE WRONG FEATURE PERFECTLY. THAT’S THE TRAP. You ask it to recreate a feature. It writes the code, writes the tests, passes the tests and says done. But if it misunderstood the behavior at the start, the whole loop can agree on the same mistake. The useful idea behind REA + Jev: separate finding out what the app does from deciding what is supported and writing the replacement. Here’s the workflow I’d wire up: → REA investigates the feature and records each behavior with its evidence. → Jev judges the relationship between each proposed rule and that evidence: accept, investigate further, or review. → Code enforces the required evidence links. An unsupported rule stays UNVERIFIED. → After you approve SPEC.md, a fresh builder gets that contract, without the original files. → Acceptance checks run against the rebuild AND three intentionally broken versions. That last step matters. If a test suite passes the version with a broken filter, it hasn’t earned your trust just because the correct version is green. REA’s setup command: npx rea-agents setup That sets up REA’s agent integration. The Jev gate, isolated handoff and acceptance policy still need to be wired around it. The attached example makes the failure visible: search must match title OR description, ignore case and preserve the selected status. The local rebuild passes all 6 checks. All 3 deliberately broken variants are caught. The model routing is illustrated; the checks really run in Python. Prompt to adapt: “Investigate [FEATURE] in [APP]. Write a SPEC.md with an evidence ID for every required behavior. Keep unsupported rules UNVERIFIED. Use Jev for narrow evidence judgments; enforce required links in code. Show me the spec before building. Once I approve it, give a fresh builder only the approved spec. Run acceptance checks against the rebuild and three broken variants. Stop for missing evidence, an unclear mandatory decision, or the attempt limit.” Jev can still judge incorrectly, and six toy checks don’t establish production reliability. The point is to make the claim, evidence and stopping rule inspectable instead of treating a confident “done” as proof. Save the workflow. The article below breaks down the evidence reports, diagnostic choices and bounded repair loop behind it.

这条是引用着另一条写的：x.com/archiveexplorer/status/2103590048230695408