docs: confirm file receive metadata evidence

docs/current-status-card.md

@@ -1,6 +1,6 @@
 # Current Status Card
 
-Date: 2026-07-09
+Date: 2026-07-10
 Branch: `main`
 Loop base: `e993ce1 docs: trim safety constraints from mcp roadmap`
 Remote base before local roadmap commits: `b2d839e Merge branch 'codex/n15-report-hardening'`
@@ -29,7 +29,7 @@ Remote base before local roadmap commits: `b2d839e Merge branch 'codex/n15-repor
 
 ## What cannot be claimed externally
 
-- The project has not yet implemented business MCP tools for message sending, file receiving, or file sending; `isphere_receive_messages`, `isphere_search_contacts`, and `isphere_search_groups` have operator-local encrypted log-file support but not a production ingestion path.
+- The project has not yet implemented business MCP tools for message sending, file receiving/download, or file sending; `isphere_receive_messages`, `isphere_search_contacts`, and `isphere_search_groups` have operator-local encrypted log-file support but not a production ingestion path.
 - The project has not completed production iSphere integration.
 - The project has not proven a stable real message source for the full business workflow beyond decrypted PacketReader log evidence and synthetic/redacted tests.
 - The project has not implemented real message sending or real file upload.
@@ -41,7 +41,7 @@ Remote base before local roadmap commits: `b2d839e Merge branch 'codex/n15-repor
 - The repository has a Go MCP + C# WinHelper foundation for controlled Windows-side read-only observation.
 - The helper protocol boundary is explicit and keeps Windows/UIA work separate from the Go MCP service layer.
 - The current code can support future MCP business tools by routing low-level Windows/UIA fallback work through a bounded helper layer.
-- The project has repeatable verification scripts for the helper/MCP foundation and the current five-tool surface.
+- The project has repeatable verification scripts for the helper/MCP foundation and the current seven-tool surface.
 - The project now has a corrected business contract and plan for core MCP communication tools, plus registered receive/contact/group read tools that can use `ISPHERE_PACKET_LOG_FILE` for operator-local encrypted PacketReader log lines.
 
 ## N13/N14/N15 positioning
@@ -50,7 +50,7 @@ N13/N14/N15 are pre-business validation results. They can help identify UI eleme
 
 ## Current loop
 
-Current loop: `Stage C / Loop C12 - file receive source evidence precheck`.
+Current loop: `Stage C / Loop C13 - log-backed file metadata extraction`.
 
 Plan file: `docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md`.
 
@@ -74,10 +74,11 @@ Current loop output so far:
 9. C9: group source evidence precheck confirmed groupchat/conference/MUC hits in ignored decrypted logs.
 10. C10: log-backed group candidate extraction from groupchat/conference JIDs.
 11. C11: `isphere_search_groups` MCP registration and seven-tool verification.
+12. C12: file evidence precheck confirmed enough PacketReader/Smark evidence for file metadata listing, but not enough for real cache/download mapping.
 
 ## Next business mainline
 
-1. Run Stage C Loop C12: verify current evidence for `isphere_receive_files` before implementation.
-2. Implement file metadata extraction only after file-transfer/cache evidence is recorded.
+1. Run Stage C Loop C13: implement log-backed file metadata extraction from normalized messages.
+2. Register `isphere_receive_files` list mode after C13 source behavior passes; leave actual download/cache mapping as a later connector node.
 3. Add `isphere_send_message` and `isphere_send_file` after source discovery and connector selection.
 4. Keep UIA selector/report work as fallback support, not as the primary roadmap.