A
?
← Handbook

Frame.io: never delete anything

Alex, twice in one session, unprompted:

"make sure to explcitly remind claude not to delete any of my frame io files" "do not delete any frame io files i repeat its our live workign files.."

The rule

Nothing in this codebase may delete a Frame.io file, version, folder or comment. Not temporarily, not behind a flag, not as cleanup, not to fix a mistake this system made itself.

Why it is absolute

Frame.io is not a scratch space for the pipeline. It is where the agency's delivered client work lives and where the team reviews it, and it is shared with clients. A deleted asset takes its comment threads and version history with it, and there is no undo that an agent can reach. The blast radius of a wrong delete is the agency's record of its own work; the blast radius of a leftover file is one row of clutter.

That asymmetry is the whole argument. If something should not be there, leave it and say so.

How it is kept

Not by intention. By the shape of the client, video-pipeline/lib/frameio.mjs:

  • ALLOWED is GET and POST. Every request passes through one gate that throws on anything else.
  • PATCH is admitted for exactly two bodies: {completed} on a comment, and {parent_id} when moving a just-uploaded file into its own version stack (V4 has no other way to add a version). Any other path or key is refused.
  • There is one fetch to the API, so there is no second unguarded path.
  • Writes are confined to the AI video editing sandbox folder. createFolder and uploadFile throw outside it.

src/lib/video/frameio-never-deletes.test.ts reads that source and fails if the ability to destroy reappears — verified to fail by adding DELETE to the allow-list, then restoring. This is the same guard the WhatsApp transport gets, for the same reason: a promise kept by a file's shape needs a test, because a file's shape is easy to change by accident.

What is fine to delete

The pipeline's own generated artefacts on the worker, under video-pipeline/work/ — proxies, audio, transcripts, style sheets, reconstructions. Even there, delete only what is provably wrong, and print what was removed and why. Those cost money and hours to rebuild.

See also data-safety.md (the app role cannot delete in Postgres either) and meta-read-only.md — the same pattern of making the dangerous thing structurally impossible rather than merely forbidden.