Claude is writing memories

claude/integration-memory/MEMORY.md

@@ -55,4 +55,6 @@
 ## Feedback
 
 - [UE Wingman testing mindset](feedback_wingman_testing.md) — flag tool friction during game work sessions
-- [Use mv for file renames](feedback_rename_with_mv.md) — mv + targeted edits, don't rewrite from memory
+- [Use mv for file renames](feedback_rename_with_mv.md) — mv + targeted edits, don't rewrite from memory
+- [LLDB formatter style — let lldb do the math](feedback_lldb_formatter_style.md) — typed SBValues, no raw pointer/byte math in Python
+- [LLDB formatter style — no defensive IsValid checks](feedback_lldb_formatter_no_defensive_checks.md) — let invalid SBValues fail loudly; silent returns conceal bugs

claude/integration-memory/feedback_lldb_formatter_no_defensive_checks.md

@@ -0,0 +1,15 @@
+---
+name: LLDB data formatter style — no defensive IsValid checks
+description: In tools/UEDataFormatter.py and similar lldb formatter code, do not add paranoid IsValid/null checks at every step. Silently-swallowed errors conceal bugs; let invalid SBValues fail loudly.
+type: feedback
+originSessionId: 783fd7be-2cf8-4075-a708-2909c6cf000b
+---
+In `tools/UEDataFormatter.py` (and any other lldb data formatter code in this project): do **not** add defensive `IsValid()` or null-guard checks at every step of an SBValue chain. If something goes wrong upstream, the subsequent call should fail loudly rather than be silently papered over.
+
+**Why:** Concealing bugs by silently returning `None`/`''`/`0` is itself a bug. When a provider silently bails, there's no signal that anything was wrong — the value just mysteriously shows no summary. A loud failure (exception, traceback in the lldb log) makes the problem visible and diagnosable.
+
+**How to apply:** When writing or editing a summary/synth provider:
+- Skip `if not x.IsValid(): return` paranoia on intermediate SBValue chain steps.
+- Only guard at genuine external boundaries — e.g., `process.ReadMemory` / `ReadPointerFromMemory` calls that can legitimately fail at runtime, where the `SBError` pattern is load-bearing.
+- Null-pointer checks on values the user-facing semantics actually care about (e.g., "is this pointer null?" as part of the summary output) are fine — those are business logic, not defensive boilerplate.
+- Trust that typed SBValue operations either succeed or raise/produce something obviously broken.

claude/integration-memory/feedback_lldb_formatter_style.md

@@ -0,0 +1,15 @@
+---
+name: LLDB data formatter style — let lldb do the math
+description: In tools/UEDataFormatter.py and similar lldb formatter code, use typed SBValues so lldb handles alignment/pointer-size/endianness, rather than doing raw byte math in Python.
+type: feedback
+originSessionId: 783fd7be-2cf8-4075-a708-2909c6cf000b
+---
+In `tools/UEDataFormatter.py` (and any other lldb data formatter code in this project): use typed SBValues to let lldb compute offsets, alignments, pointer sizes, and endianness. Do not do raw pointer arithmetic, byte-offset math, or architecture-assumption math in Python.
+
+**Why:** Manual math assumes things about the target (pointer size, struct layout, endianness) that lldb already knows from debug info. Letting lldb do it via typed SBValue APIs — `GetChildMemberWithName`, `Dereference`, `CreateValueFromAddress(addr, type)`, `GetArrayType`, `GetTemplateArgumentType`, etc. — is portable, robust, and avoids subtle bugs when the target architecture changes.
+
+**How to apply:** When writing or editing a summary/synth provider:
+- Prefer `GetChildMemberWithName('X')` over computing a field's offset and doing `ReadMemory`.
+- Prefer `CreateValueFromAddress(addr, sometype)` over raw reads followed by manual decoding.
+- Use `GetArrayType(N)` / `GetTemplateArgumentType(i)` to derive element types rather than hardcoding sizes.
+- Only drop to raw `process.ReadMemory` / pointer math when no typed path exists (e.g., walking the GNameBlocks table in `UEFNameSummaryProvider`, where the underlying storage is an untyped block array).