Version. 0.1
Date. 2026-07-02
Status. Drafted, not staged for build. Number 132 confirmed free at staging (highest prior: CR-2026-131). Base: engine main @ 1afc723 (post-CR-2026-130 merge); OL main @ 4566233 (post-CR-2026-130 merge, Operator Layer). No build yet.
Grounded on: CC Step-0 diagnosis 2026-07-02 (read-only, both repos at current main).
Repos: loomworks (composer, uploads.ts, types.ts, UploadResultCard) + loomworks-engine (uploads.py, upload_event.py).
UploadAttachmentButton (already live and correct in ChatView.tsx). Near-zero-risk, mechanical, frontend-only.relative_path is stubbed to filename. Fix:webkitRelativePath from the client (Starlette already preserves / in multipart filenames — verified, no engine parsing change needed).filename variable into basename (for original_filename/source_artifact_filename) and the full path (for relative_path). No schema change — relative_path field already exists.folder_manifest. Fix so an explicit folder selection always preserves folder_manifest, even for one file.relative_path is typed on the frontend but rendered nowhere. Add minimal display of the relative path per file in UploadResultCard (or equivalent), so preserved structure is visible to the Operator, not just stored.
put_blob always uses a generated storage key, never the client-supplied path. The path is metadata only.
No seed commitment on folder structure — specification-level, not seed-level. No conflict. Restoring the button aligns with "only show what is available" (the button vanishing was a rebuild casualty, not a deliberate absence).
No new upload types, no change to interpretation/description pipeline (CR-130/131 territory, already shipped).