AttachmentAssociation.mimeType is a property expressed as a perspective (redundant post-#65)

[cuibonobo]

Post-#65, mimeType is a property of the fileId — established by the first _attachment@1 record, validated against conflicts on create, and served in download Content-Type resolution. But AttachmentAssociation still carries its own mimeType field (types.ts:45-50), a second per-reference claim that:

• is never validated against the fileId's established mimeType,
• is not part of association identity — associationEqual (stack.ts:1620-1625) and the SQL PK (sqlite-shared/src/schema.ts:31) both ignore it, so re-associating the same file with a different mimeType is silently dropped as a no-op,
• feeds nothing — download resolution reads the stored _attachment@1 mimeType, not the association's (confirmed: resolveAttachmentDownloadContentType takes storedMimeType, and no core logic branches on the association field).

Under the properties-vs-perspectives principle it's a property masquerading as a perspective: a second, unvalidated, inert copy of a fact with a single authoritative home.

Decided: delete the field outright

No install base beyond the owner (#57), and nothing consumes the field — so no deprecation dance, no additive-reverse phase. Just remove it. TypeScript will surface every touch point as the discriminated union changes shape.

Work items

• types.ts: drop mimeType from AttachmentAssociation ({ kind: 'attachment'; label; fileId })
• sqlite-shared: stop reading/writing mime_type — rowToAssociation (mappers.ts:37-44) and insertAssociations (record-logic.ts:553-576). The mime_type DDL column (schema.ts:29) can stay as a harmless vestige (no migration needed under the schema-in-place policy) or be dropped for new databases — pick one; leaving it is simplest
• Wire: WireRecord/association serialization carries Association verbatim, so this drops out automatically — confirm no fixture or serialize* path hardcodes mimeType on an association
• Spec §Associations + README: remove mimeType from the attachment association examples (and the wire association response shape in §API Adapter Wire Format)
• Update tests/fixtures that construct an attachment association with mimeType

Note

The authoritative mimeType path is untouched: _attachment@1.mimeType (the property) and the download resolver remain the single source of truth. This change only removes the redundant, inert copy on the association.

Refs

#65 (mimeType-as-fileId-property), #57 (no install base — change in place), #16 (association-model RFC). From docs/design-assessment-2026-07.md §F1.

[cuibonobo]

Ordering: independent of #106's security fix, but do this before #106 — deleting AttachmentAssociation.mimeType simplifies the attachment/association code that #106 then restructures, minimizing merge churn. (Also the moment to decide #16 if that RFC's direction is adopted, since both open the Association union.)

---

Generated by Claude Code