Tracer: Process a received CSV ZIP in an authorized directory and return a new attachment

Parent

#631 — PersonaBot attachment file operations.

What to build

Human uploads a ZIP in a local conversation and asks the PersonaBot to summarize its CSV into a new ZIP. Human explicitly authorizes a writable project/work directory. The Orchestrator acquires the current attachment under source authorization, saves a separate working file in that directory, unpacks and reads it using ordinary native tools and approved Shell operations, creates the summary, and returns an independently stored downloadable Attachment to the original conversation.

Complete the narrow path through the existing file owner, durable directory authorization, native Tool/Execution World permission boundary, Host/Client authorization interaction and model-facing file acquisition/result import. Retain the Orchestrator's Memory working-directory contract and existing Assignment authority. This is not a backend-only upload foundation or a mock Client.

Acceptance criteria

• Human can authorize and revoke Orchestrator write access to the selected work directory through a runnable Client surface. Existing read-only Grants stay read-only unless explicitly authorized, and another PersonaBot gains no access.
• The Orchestrator sees attachment information and can acquire the current exact file; current source membership/visibility and attachment association are checked. Missing, wrong-owner or unavailable attachments are not successful reads.
• Saving creates an independent working file. Native file tools can read and modify it inside the authorized destination; ordinary file moves within authorized scope work. The source attachment and message reference remain unchanged.
• Native file policy and the Execution World write boundary both honor the authorized directory without globally widening permissions. Shell retains existing approval/saved-rule behavior; attachment receipt grants no automatic Shell approval.
• The real model unpacks the ZIP, reads CSV records, computes totals, creates summary files, repacks them and explicitly selects the produced ZIP for return. No test-only response injection replaces model processing.
• Import of the selected generated file uses the existing attachment owner and trusted result identity; the reply uses current send authorization and the original conversation. The output is downloadable and has an independent Attachment identity.
• Fixture has three records with quantities 2, 1 and 4, unit prices 10, 20 and 5. Each row amount is 20; summary reports three rows, quantity 7 and total 60. Download and unpack the returned result to verify these values.
• Verify preservation of original bytes; source/destination denial and revocation; missing input; transfer limits/cancellation; failed result import/send. Distinguish failure from success using production seams.
• Include real DSH model interaction and Human download/contents verification as GitHub-rendered screenshots or recording in the PR. Include required before/after UI evidence for the authorization surface.
• Record the accepted architecture decision, updated Orchestrator write authorization meaning, living architecture and bilingual release/documentation changes under repository workflow. Public guidance distinguishes implemented local files from future bridge support.
• Record task claim/commit/PR trace, complete required checks and pause the goal after PR creation for Human QA.

Blocked by

None — can start immediately after ticket publication and claim. Real-file storage and trusted forwarding are merged prior art, not new open dependencies.

Scope boundaries

Original-source writeback is the next sibling. Lark/Slack transfer adapters, direct Assignment attachment access, universal document parsing, arbitrary Host paths, attachment versioning, automatic Memory writes and automatic remote-original updates are excluded. Shape trusted source identity so later Channel/Inbox bridge integration does not require a second file authority.