CR-2026-133 — Upload Interpretation: Format Support, Content Extraction, Non-Blocking Batches
Version. 0.1 · Date. 2026-07-02
Status. Drafted, not staged for build. Number 133 confirmed free at staging (highest prior: CR-2026-132). Base: engine main @ 2632037 (post-CR-2026-132 merge); OL main @ 3526385 (post-CR-2026-132 merge). No build yet.
Grounded on. Semantic-meaning foundation finding v0.3 (loomworks-record/investigations/loomworks-semantic-meaning-foundation-v0_3.md, commit 7500ad1).
Repos. loomworks-engine (interpretation/extraction) + loomworks (batch upload UI).
What this fixes
Three symptoms confirmed live, same root cause: uploads have no real interpretation layer.
- Common formats fail to read. HTML files, dotfiles (
.gitignore, .env.example), and extensionless files (CODEOWNERS) all return "couldn't recognize this file." Add readers for these common formats.
- Readable files are dumped raw. A file's full text becomes one held assertion, unsummarized. At any real file count this floods Memory. Extract meaningful content — summarize and/or chunk — rather than storing the verbatim file body as a single assertion.
- Unreadable files block the whole batch. Each unreadable file halts processing and opens an empty textarea demanding manual input before continuing. At 8 files with 3 unreadable this is 3 forced stops; at higher counts it is unworkable. Unreadable files should be skipped and batched into one follow-up prompt at the end, not block sequentially.
Seed check
No conflict. The seed commits Memory to accumulating contributions with provenance, naming "extracted from a document" and "described from an image" as contribution types. It does not specify extraction mechanics — that is specification-level. This CR builds the extraction layer the seed's contribution model assumes exists.
Out of scope
No change to the held-assertion confirm flow, folder-upload button, or structure preservation (CR-2026-132, shipped). No change to conversation turn persistence (CR-2026-131, shipped).