Hub: PersonaBot attachment file operations

Goal

A PersonaBot's Orchestrator receives an arbitrary-format attachment, accesses its current file under trusted source authorization, saves a working file in a Human-authorized writable directory, processes it using existing native file tools and approved Shell operations, and returns an explicitly selected result as a new downloadable Attachment. Preserve ordinary file ownership and the current Messaging authority.

Confirmed design

• Use current originals and explicit save-as working files; no automatic processing snapshot or generic document parser.
• Keep the message original and its reference when saving a working file. Normal moves affect that independent working file.
• Allow explicit local-original writeback with ordinary current-file semantics; introduce no application locking, compare-before-write protocol or file version archive. Keep native Tool integrity checks.
• Keep the sender's upload-source and remote platform original independent. New output files have independent Attachment identities.
• Human explicitly authorizes writable work directories. Existing read-only Workspace Grants do not automatically expand; native file and Execution World write permissions must agree. Retain Shell approval and saved rules.
• Authorize source reads under current source visibility and exact attachment association. A file ID, provider URL or path-looking text is not authorization.
• Preserve Source Event provenance with optional Channel placement. Future Inbox-only bridge attachments need no fabricated DM or Channel.
• External metadata is visible on receipt; Provider-authenticated download happens at first access. Host retains credentials. Local processing and platform sending remain independently authorized.
• Saved files are governed by target-directory authority. Leaving the source Channel blocks future source reads without deleting an explicitly preserved independent file.
• First Consumer: Orchestrator. Direct Assignment attachment access follows separately.

Approved ticket index

1. Process a received CSV ZIP in an authorized work directory and return a new ZIP. No open implementation blocker; prior real-file storage and trusted forwarding are already merged.
2. Explicitly edit a received original and show the current contents through message references. Blocked by ticket 1's authorized file-access integration.

Both tickets are native sub-issues of this hub. Publish dependencies natively and retain readable body references. Work one concrete ticket at a time; claim before coding; include real-model E2E screenshots or recording in each PR; pause the goal for Human QA after every issue PR. Merge remains a separate Human action.

Coordination

Project: Roadmap (Project 1), covering the local file and Workspace permission boundary. Local tickets: v1.0. Labels: scope:hub, feature:messaging and feature:workspace; children also ready-for-agent and scope:tracer with appropriate area labels.

Existing boundaries and future bridge slices

#560's tool-contract train is separate; #570 supplied trusted forwarding. #572 owns Human file-open surfaces and the real-file semantics delivered in #577, rather than this model-facing processing path. Reuse their owners without duplicating their work.

#48 / #629 own external Bridge coordination and Channel/Inbox target behavior; #12 owns integrated Lark text ingress/reply, and #117 owns compatible provider adoption. Respect existing claims and the pending Human QA of #624. Do not enlarge or close those issues.

After local feedback and a runnable external ingress baseline, derive a narrow Lark attachment acquire/process/same-source file-reply tracer, then the corresponding Slack tracer. Both reuse the file-operation contract and authenticated adapter transfer capabilities. They require independent real-provider evidence and v1.1 coordination. Do not pre-create unqualified provider or routing variants, or claim them delivered from local ZIP proof.

Delivery acceptance

• The first ZIP path is Human-operable through the real owning Host, native tool permissions, Client authorization and attachment transfer seams.
• The returned archive has independently verified CSV totals and can be downloaded from the reply; the original is preserved.
• Explicit original writeback is independently verified through current message reads/downloads and shared attachment references.
• Unauthorized sources and destinations, transfer failures and unapproved Shell actions retain their existing refusal/approval behavior.
• Formal ADR, living architecture, relevant English/Chinese glossary and release ledgers describe the changed permission boundary and actual delivered scope.