docs: block display name enrichment pending source evidence

docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md

@@ -1873,15 +1873,15 @@ Implemented and verified in this loop:
 - If evidence is not enough, keep JID-only behavior explicit and choose the next business-read hardening node.
 - Do not add write/send/file-download behavior.
 
-- [ ] **Step 1: Inspect current evidence**
+- [x] **Step 1: Inspect current evidence**
 
 Use committed source-discovery docs first; only inspect ignored local summaries/counts if needed. Do not commit raw evidence.
 
-- [ ] **Step 2: Update matrix/status and next loop**
+- [x] **Step 2: Update matrix/status and next loop**
 
 Record whether display-name enrichment can proceed and rewrite C24 accordingly.
 
-- [ ] **Step 3: Verify and commit docs**
+- [x] **Step 3: Verify and commit docs**
 
 Run:
 
@@ -1895,6 +1895,58 @@ Expected: all exit 0. Commit exact C23 paths only and rewrite the next loop from
 
 ---
 
+## Loop C23 Result
+
+Evidence precheck result:
+
+- `MsgLib.db` remains the strongest likely source for contact/group display names and richer metadata, but the ignored schema summary reports the inspected copies as `file is not a database`; no readable SQLite table/column mapping is validated yet.
+- PacketReader/Smark message logs prove JIDs, `chat`/`groupchat` routing, message bodies, subjects, timestamps, and receipts, but not display names, departments, titles, group titles, owners, or member counts.
+- `LoginInfo` proves sensitive local account context only; it does not prove a roster or group display-name mapping for arbitrary contacts/groups.
+- `SaveToDB` summary proves message-arrival shapes but not a display-name mapping.
+- Decision: keep contact/group tools JID-derived and mark display-name/member enrichment blocked until DB wrapper/decryption, roster stanza, bridge/API, or safe live UIA mapping evidence is validated.
+
+---
+
+## Loop C24: `MsgLib.db` readability/wrapper path precheck
+
+**Goal:** Determine why extracted `MsgLib.db` candidates are not directly readable as SQLite and identify the safest next path for contact/group display-name and richer message metadata extraction.
+
+**Planned files:**
+- Modify: `docs/source-discovery/capability-source-matrix.md`
+- Modify: `docs/current-status-card.md`
+- Modify: `docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md`
+- Optionally create a focused source-discovery note under `docs/source-discovery/`.
+- Optionally create ignored metadata under `runs/`; do not commit raw DB bytes, decrypted content, or personal values.
+
+**Planned behavior:**
+- Inspect only safe metadata first: file headers, sizes, hashes, known nearby DLL names, committed notes, and existing metadata summaries.
+- Determine whether the DB issue looks like encryption, compression, copy truncation, custom wrapper, or a wrong file candidate.
+- If a safe local wrapper/decryption path is identifiable, write C25 as a minimal read-only schema extraction loop.
+- If not identifiable, record the blocker and shift to another business-read hardening node.
+- Do not add write/send/file-download behavior.
+
+- [ ] **Step 1: Inspect safe DB metadata**
+
+Use file headers, existing summaries, and committed notes only. Avoid committing raw bytes.
+
+- [ ] **Step 2: Record likely wrapper/read path**
+
+Write a source-discovery note with the decision and next implementation slice.
+
+- [ ] **Step 3: Verify and commit docs**
+
+Run:
+
+```powershell
+git diff --check
+go test ./...
+powershell -NoProfile -ExecutionPolicy Bypass -File scripts/verify-go-mcp.ps1
+```
+
+Expected: all exit 0. Commit exact C24 paths only and rewrite the next loop from actual results.
+
+---
+
 ## Self-Review
 
 - Spec coverage: the plan follows the user's cyclic requirement: plan first, implement one loop at a time, update the next loop after each result, and ask only on blockers.