docs: record proposed Agent deliverable visibility rules

.project-docs/30-worklog/tasks/20261012-agent-chat-files-review-e87b41c6.md

@@ -31,6 +31,15 @@
 - The production Renderer was committed at `0d54690dd63de39e007f2e1f54f9aea157670f61`, staged and activated in the existing temporary app. Main PID 7459 and Host port 62864 were preserved, with all eight Main/preload/utility artifacts byte-identical to the previous confirmed stage; login remained active after native refresh. The original runtime and prior Renderer layers remain available for rollback.
 - Native UI verification saw the “整理小帮手” header showing 55 files and its right-side panel with uploaded/generated groups, readable file cards, save actions and return-to-chat footer. The existing “英语陪练aron” conversation subsequently showed 3 files, including its uploaded spreadsheet and generated summary, with independent grouping and unchecked reuse selection. The user navigated during verification; subsequent observations were read-only and left their chosen conversation in place.
 
+### File Visibility Discussion Follow-up
+
+- The user questioned the 55-file collection and agreed that internal process files should be hidden. This follow-up explains a proposed classification and implementation boundary; it does not implement or deploy that filtering change.
+- Same-task Concurrent/Planning Gates passed again: current ownership matches; 43 peers and 129 required sections read-only, including the new knowledge-picker discussion which explicitly isolates chat attachments. No concrete semantic conflict. The historical child-language peer remains undefined without a dependency.
+- Code review confirms `CloudFile` only has name/path/directory/size fields (`shared/cloud-agents.ts:163`) and messages/history have no structured delivered-file relationship (`shared/cloud-agents.ts:98–107`). Current UI recursively collects all files and calls every non-uploaded path generated. That includes scripts, caches and tool-call outputs. A downloadable path or an `outputs` directory does not establish delivery intent.
+- Recommendation: retain confirmed uploaded attachments; show Agent files only after explicit delivery to the user. Yuxi should validate and persist a stable delivered-file identity linked to the current conversation, run and assistant reply, plus display name and availability. The client should show/count that authoritative collection. Process files stay usable internally and are not deleted. Code files remain visible when explicitly delivered; no extension/name/directory heuristic should decide purpose.
+- A conservative interim client filter could use valid file links in persisted assistant replies, normalized and matched to actual files of the same conversation. Exclude reasoning, tool/system content, code examples and plain path mentions; unknown files stay hidden. This is only a compatibility bridge and can miss valid old deliverables lacking links. Formal delivery records and any legacy backfill require Yuxi assessment and must not be claimed implemented from this discussion.
+- No source, tests, cloud content or live app interaction changed in this follow-up. Existing build and runtime remain the delivered header/panel version; a docs-only handoff may update its source record without changing product payloads.
+
 ## Verification
 
 - Typecheck and production Renderer/Main/preload/utility build passed. Scoped ESLint passed with only the two existing CloudChat warnings (export/refresh and ref cleanup); no errors.
@@ -50,3 +59,4 @@
 ## Promotion Candidates
 
 - Target: personal-cloud-agent client interaction specification and integrated current state. Proposal: replace the vague inline file browser with the approved counted header entry and right panel grouped by uploaded/generated files, while keeping adding files in the composer’s plus menu. Evidence: explicit user approval, 47 focused + 48 related unit checks and 15 browser layout scenarios. Future impact: file access stays visible without crowding the composer, and generated output subfolders no longer require navigation. Semantic conflicts: earlier proposal’s folder-browser and trial-chat layouts are superseded by the user’s later simplification decisions. Human confirmation: already supplied for this UI behavior; canonical promotion still requires a serialized integration task.
+- Target: personal-cloud-agent client/API specification. Proposal under discussion: count/display only confirmed user uploads and explicitly delivered results, backed by Yuxi reply-linked delivery records; unknown and internal files hidden without deletion. Evidence: user screenshot of internal artifacts and contract review above. Future impact: clear deliverables and durable history without relying on filename guesses. Semantic conflict: narrows the current all-non-uploaded-files generated group. Human confirmation: the user agreed with hiding process files and asked how; the detailed registration/compatibility approach remains a proposal, not an implemented contract.