Memory #81 CURRENT
Check existing memory before hardware/pinout claims When the user asks about a board, pinout, or any physical mapping that has plausibly been investigated before, read the relevant memory file BEFORE answering — not after they've already acted on a guess When Mark asks about hardware specifics (board pinouts, JTAG mappings, FPGA pad assignments, connector wiring), check the relevant project memory file *first*, before giving an answer from generalised model knowledge. **Why:** On 2026-04-27 Mark asked about J27 on the Colorlight 5A-75B. Claude answered from memory-of-training-data with a J27/J30/J31/J32 mapping that conflicted with the verified mapping already recorded in `project_fpga_colorlight.md` (sourced from Tom Verbeure's V7.0 reverse engineering on 2026-04-23). Mark labeled his wire colors based on the wrong mapping before Claude noticed and corrected. Net cost: avoidable confusion + a lost wiring iteration if Mark hadn't been working alongside. **How to apply:** - Trigger: any question about the physical layout of a piece of hardware Mark owns or is working with — pinouts, pad mappings, connector wiring, voltage rails, BGA ball assignments, programming headers. - Action: list the `memory/` directory or grep for the board/chip name *before* drafting a technical answer. If a relevant memory exists, lead from it; flag any uncertainty in the memory itself rather than substituting fresh guesses. - Generalises beyond FPGA: applies to any project with established physical state (Edge Node ports, Tailscale IPs, SDR connections, etc.). — [feedback_check_memory_first.md]
| Composite | CF78AA63E099E54D7 |
| Project prime | 13 |
| Domain prime | 49 |
| Type prime | 61 |
| Importance | 1.000000 (CRITICAL) |
| Decay epoch | 0 |
| Created | 2026-05-04 15:46:49 |
| Valid from | (unset) |
| Valid to | NULL — still believed true |
Outgoing Edges
No outgoing edges.