docs: add file download mapping precheck

This commit is contained in:
zhaoyilun
2026-07-10 09:44:08 +08:00
parent 6ca6c08b62
commit ea38346ce3
4 changed files with 163 additions and 3 deletions

View File

@@ -29,7 +29,7 @@
| Search groups | Registered MCP tool; deterministic exact-match ranking and case-insensitive de-duplication across groupchat/conference candidates and optional copied-DB MsgLib display enrichment. | Optional member count, owner refs, and nested/group hierarchy remain future enrichment, not a core search blocker. | complete for core search; optional enrichment later |
| Receive messages | PacketReader source works; copied `MsgLib.db` explicit receive works with `source_preference="msglib_readonly"`; R1 precheck says default should remain PacketReader until a future reconciliation helper is implemented. | Future reconciliation helper, source confidence scoring, pagination policy. | future receive helper after R2/R3 |
| Send messages | Contract exists; no validated write connector. | Need connector discovery, preview-only path, idempotency and audit before production send. | R5 then R6 |
| Receive files | List mode exists from message-derived file metadata. | Need message-to-cache/download mapping and output-dir download behavior. | R3 then R4 |
| Receive files | List mode exists from message-derived file metadata; R3 precheck confirms cache/download mapping is still unvalidated. | Need sanitized cache mapping diagnostic before output-dir download behavior. | R3b then R4 if validated |
| Send files | Contract exists; no validated upload/send connector. | Depends on send-message connector plus upload/file-transfer evidence. | R7 then R8 |
## Node Sequence
@@ -229,6 +229,36 @@ powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-go-mcp.ps1
3. additional evidence request.
- No file content or local file path values are committed.
**R3 Result:**
- Created `docs/source-discovery/2026-07-10-file-download-mapping-precheck.md`.
- PacketReader remains sufficient for file metadata list mode, but has 0 cache path and 0 download keyword hits in the C12 safe count evidence.
- MsgLib `TD_ReceiveFileRecord` provides safe attachment metadata (`ReceiveMsgGuid`, filename, size, source id), but current sidecar intentionally returns empty `download_ref` and `file_paths_returned=false`.
- Ignored cache evidence shows 11 importal hash-shape files under 32-character hash directories, but no validated message/file-record-to-cache-file mapping.
- Decision: do not start R4 yet; insert R3b file cache mapping diagnostic as the next node.
---
### R3b: File cache mapping diagnostic
**Purpose:** Prove or reject a safe mapping from MsgLib received-file metadata to local cache files before implementing download mode.
**Files:**
- Create or modify: `scripts/verify-file-cache-mapping.ps1` or an equivalent local-only diagnostic.
- Modify docs: this roadmap, `docs/current-status-card.md`, and `docs/source-discovery/capability-source-matrix.md`.
**Diagnostic policy:**
- Read copied DB/cache metadata only; do not read attachment contents.
- Do not print local paths, raw rows, real message bodies, or unredacted file names.
- Output counts, extension groups, hash-directory shape, match strategy counts, and safety booleans only.
**Acceptance gate:**
- Diagnostic output includes `raw_paths_printed=false`, `file_contents_read=false`, and `file_paths_returned=false`.
- Diagnostic chooses one route: R4 cache-file resolver, UI/client download connector, or additional evidence request.
**Stop condition:**
- If no unique/repeatable cache mapping exists, do not implement R4 download mode.
---
### R4: Receive-file download implementation