CR-2026-133 — Upload Interpretation: Format Support, Content Extraction, Non-Blocking Batches — v0_1

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).