test: add file download resolver v2 diagnostic
This commit is contained in:
zhaoyilun
@@ -59,7 +59,7 @@ N13/N14/N15 are pre-business validation results. They can help identify UI eleme
|
||||
|
||||
## Current loop
|
||||
|
||||
Current loop: `R7 send-file preview tool complete`; next R8 send-file idempotency and audit hardening.
|
||||
Current loop: `R10 receive-file download resolver v2 diagnostic complete`; next R11 receive-file download preview contract.
|
||||
|
||||
Active continuous execution plan: `docs/superpowers/plans/2026-07-10-r6f-r14-continuous-execution-plan.md`.
|
||||
|
||||
@@ -240,8 +240,8 @@ Continuous execution plan R6f-R14 is approved and execution has started:
|
||||
- Plan file: `docs/superpowers/plans/2026-07-10-r6f-r14-continuous-execution-plan.md`.
|
||||
- Scope: 15 ordered rounds covering send-message connector/gate hardening, send-file preview/idempotency/package, receive-file download preview, receive-message reconciliation, end-to-end business smoke, and release-candidate report.
|
||||
- Execution rule after approval: one round at a time, status-card update, verification, commit, push, then continue automatically until an evidence-only blocker requires user action.
|
||||
- Last completed round: R9 send-file upload evidence package.
|
||||
- Next active round: R10 receive-file download resolver v2 diagnostic.
|
||||
- Last completed round: R10 receive-file download resolver v2 diagnostic.
|
||||
- Next active round: R11 receive-file download preview contract.
|
||||
|
||||
R6g send audit and idempotency replay diagnostics is complete:
|
||||
|
||||
@@ -326,3 +326,12 @@ R9 send-file upload evidence package is complete:
|
||||
- Local verification generated and validated `runs\send-file-sandbox-gate-package.zip`; no production file upload connector was enabled.
|
||||
- Verification passed: git diff --check, scripts\verify-send-file-sandbox-gate-package.ps1, go test ./..., go build ./cmd/isphere-mcp, and scripts\verify-go-mcp.ps1.
|
||||
- Next node: R10 receive-file download resolver v2 diagnostic.
|
||||
|
||||
R10 receive-file download resolver v2 diagnostic is complete:
|
||||
|
||||
- Added fixture-backed scoring to `scripts\verify-file-cache-mapping.ps1` with `-FixtureRecordsPath`, `-CacheRoot`, and `-SanitizedOutputPath`.
|
||||
- `scripts\test-verify-file-cache-mapping.ps1` now covers the legacy archive-list summary and the v2 scoring fixture.
|
||||
- Fixture result: `records_checked=3`, `cache_candidates_checked=4`, `accepted_matches=2`, `ambiguous_matches=0`, `score_100_matches=1`, `score_80_matches=1`, and `score_40_only_matches=1`.
|
||||
- Diagnostic output keeps `raw_paths_printed=false`, `file_contents_read=false`, and `file_paths_returned=false`.
|
||||
- Decision: resolver logic is proven, but real production file download remains blocked until a real cache mapping package produces accepted non-ambiguous matches.
|
||||
- Next node: R11 receive-file download preview contract.
|
||||
|
||||
49
docs/source-discovery/2026-07-10-file-download-mapping-v2.md
Normal file
49
docs/source-discovery/2026-07-10-file-download-mapping-v2.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# File download mapping v2 diagnostic - 2026-07-10
|
||||
|
||||
## Purpose
|
||||
|
||||
R10 checks whether received-file metadata can be mapped to an operator-local cache/download file strongly enough for a future `isphere_receive_files` download path.
|
||||
|
||||
## What changed
|
||||
|
||||
`scripts/verify-file-cache-mapping.ps1` now has a fixture-backed scoring mode:
|
||||
|
||||
- `-FixtureRecordsPath`: JSON records with `file_name`, `size_bytes`, `source_id`, and `created_at`.
|
||||
- `-CacheRoot`: operator-local cache root or fixture cache root.
|
||||
- `-SanitizedOutputPath`: writes a compact JSON summary without raw paths or file contents.
|
||||
|
||||
Scoring rules:
|
||||
|
||||
| Rule | Score | Accepted |
|
||||
| --- | ---: | --- |
|
||||
| exact filename + exact size + close timestamp | 100 | yes, if unique |
|
||||
| exact size + source id appears in cache name/ref | 80 | yes, if unique |
|
||||
| filename only | 40 | no |
|
||||
|
||||
## Fixture result
|
||||
|
||||
`powershell -NoProfile -ExecutionPolicy Bypass -File scripts\test-verify-file-cache-mapping.ps1` produced:
|
||||
|
||||
```json
|
||||
{"ok":true,"archive_candidate_count":2,"records_checked":3,"cache_candidates_checked":4,"accepted_matches":2,"ambiguous_matches":0,"score_100_matches":1,"score_80_matches":1,"score_40_only_matches":1,"raw_paths_printed":false,"file_contents_read":false}
|
||||
```
|
||||
|
||||
Interpretation:
|
||||
|
||||
- The resolver algorithm can produce accepted matches when file metadata is strong.
|
||||
- One weak filename-only case is intentionally not accepted.
|
||||
- The diagnostic output stays committed-safe: no raw operator paths and no file contents.
|
||||
|
||||
## Production decision
|
||||
|
||||
This round proves the resolver logic, not a real iSphere cache mapping on this machine. The local machine still cannot log in to iSphere, and no real returned receive-file package in this repository state proves a stable cache/download mapping.
|
||||
|
||||
Therefore:
|
||||
|
||||
- `isphere_receive_files` list mode remains usable.
|
||||
- Real file download/copy remains blocked until a real cache mapping package produces accepted, non-ambiguous matches.
|
||||
- R11 should implement a download preview/blocked contract so digital employees get machine-readable status instead of a generic failure.
|
||||
|
||||
## Next node
|
||||
|
||||
R11: `Receive-file download preview contract`.
|
||||
@@ -709,7 +709,7 @@ git push gitea main
|
||||
- `-MsgLibDb` and `-SQLiteDll` accept copied DB/runtime paths when real copied DB is available; fixture tests do not require real DB files.
|
||||
- `-SanitizedOutputPath` writes committed-safe JSON summary to a caller-selected output file.
|
||||
|
||||
- [ ] **Step 1: Add fixture test for resolver scoring**
|
||||
- [x] **Step 1: Add fixture test for resolver scoring**
|
||||
|
||||
Fixture contains three DB-like file records and four cache-like file entries. Expected scoring:
|
||||
|
||||
@@ -719,15 +719,15 @@ exact size + source id in name/ref => score 80
|
||||
filename only => score 40 and not accepted
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Implement scoring and sanitized output**
|
||||
- [x] **Step 2: Implement scoring and sanitized output**
|
||||
|
||||
Output fields: `records_checked`, `cache_candidates_checked`, `accepted_matches`, `ambiguous_matches`, `raw_paths_printed=false`, `file_contents_read=false`.
|
||||
|
||||
- [ ] **Step 3: Write decision note**
|
||||
- [x] **Step 3: Write decision note**
|
||||
|
||||
`docs/source-discovery/2026-07-10-file-download-mapping-v2.md` records whether accepted matches exist. If not, download remains blocked and UI/client download connector becomes the next route.
|
||||
|
||||
- [ ] **Step 4: Verify and commit**
|
||||
- [x] **Step 4: Verify and commit**
|
||||
|
||||
```powershell
|
||||
git diff --check
|
||||
@@ -742,6 +742,14 @@ git push gitea main
|
||||
|
||||
**Acceptance gate:** 文件下载要么得到可实现映射，要么得到明确阻断证据。
|
||||
|
||||
**R10 Result:**
|
||||
|
||||
- Added v2 fixture scoring to `scripts/verify-file-cache-mapping.ps1`.
|
||||
- Updated `scripts/test-verify-file-cache-mapping.ps1` to prove exact filename/size/time gets score 100, source-id/size gets score 80, and filename-only gets score 40 without acceptance.
|
||||
- Fixture verification produced `records_checked=3`, `cache_candidates_checked=4`, `accepted_matches=2`, `ambiguous_matches=0`, `score_100_matches=1`, `score_80_matches=1`, `score_40_only_matches=1`, `raw_paths_printed=false`, and `file_contents_read=false`.
|
||||
- Created `docs/source-discovery/2026-07-10-file-download-mapping-v2.md`.
|
||||
- Real production file download remains blocked because this proves resolver logic, not a real iSphere cache mapping from an online package.
|
||||
|
||||
---
|
||||
|
||||
### R11: Receive-file download preview contract
|
||||
|
||||
Reference in New Issue
Block a user