---
status: accepted
---

# Request attachments are draft-release assets, not git objects

A `create` or `comment` may carry a file (`spt shell send --file`), and GitHub's REST API has no official endpoint for issue attachments — the web UI's drag-drop rides an unofficial CDN endpoint we refuse to depend on. Committing attachments to an orphan branch was considered and rejected: blobs entering git history bloat every clone of the work repo forever, and dispatched agents clone constantly. Instead, each bound repo gets a single rolling **draft** release named `alchemy-attachments`; files upload as its assets (`attachments API`, up to 2GB each), and the issue body links the asset.

## Consequences

Attachments live outside git history — zero clone impact. A draft release carries no tag and is invisible to the published-releases surface, so Phase 2's release sweep (which reads published releases) never sees it and the Releases surface stays clean. Private-repo access works for members in the browser and for agents via the API with their token. Stale-asset GC is a non-goal until it hurts.