Folder-scoped file attachments for a project, backed by core PhoenixKit.Modules.Storage — the workspace's per-resource-folder convention (phoenix_kit_staff.Attachments is the reference this mirrors): no module-owned table, no migration.

Each project owns a deterministic root folder project-<uuid>, resolved by name on every read (never cached on the project row, so renames or deletions in /admin/media can't strand a dangling uuid) and created lazily on first use. Core's [:name, :parent_uuid] unique index makes find-or-create race-safe. Files live in core phoenix_kit_files — a file is IN the folder either as its home (file.folder_uuid) or via a FolderLink. Removal follows core's non-destructive convention: soft-trash a sole-home file, promote a link on a shared one, drop the link on a linked-only one — never hard-delete a possibly-shared asset.

Parent folder

A host can nest a project's folder under one of its own — e.g. a project linked to a sub-order keeps its files inside that sub-order's folder — via two config hooks, both nil/unset by default (today's root-only behaviour, unchanged):

• :attachments_parent_folder — {mod, fun} where fun(kind, actor_uuid, subject) (preferred) or fun(kind, actor_uuid) returns {:ok, parent_folder_uuid} or anything else for "no parent". subject is the bare %Project{} for read-only lookups (folder_uuid/2, render-safe: never creates a parent) and {:ensure, %Project{}} for ensure_folder/2, which may create the parent chain.
• :attachments_folder_name — {mod, fun} where fun(resource, actor_uuid) returns {:ok, name} or anything else to fall back to the deterministic project-<uuid> name.

A folder is found by its {parent, name} pair — core records no owning resource on a folder — so the pair a host's hooks answer must be unique per project. Two projects that resolve to the same parent AND the same host name share one folder, and each Files page lists the other's files. A per-project parent (a sub-order's own folder) with a fixed name is fine; a shared container needs a name carrying something project-unique.

Resolution order (read-only, no writes): host-name-under-parent → deterministic-name-under-parent → deterministic-name-at-root → deterministic-name-anywhere — so a legacy root project-<uuid> folder, or one left under a since-unlinked parent, is found and reused rather than twinned once a parent hook is configured.