RFC-0002: Foreign-field carriage (ext) for every record kind (format 1.2; prerequisite for RFC-0001) #13

Summary

The lossless-superset promise is kept for unknown record kinds (verbatim passthrough) and for unknown fields on episodes (ext), but unknown fields on every other kind — entity, edge, fact, context, … — are silently dropped by both reference readers (Python from_wire decodes declared fields only; Swift's synthesized Decodable ignores extras). A vendor field on a fact, or a format-1.2 visibility on an entity read by a 1.1 reader, disappears on re-export.

Proposal (short form — full text in Spec/rfcs/0002-ext-for-all-kinds.md)

No wire change. Readers MUST split every record of every kind into native fields + a foreign remainder, hand the remainder to the host keyed by record identity (the id, or the sha256 of the canonical native line for id-less kinds), and merge it back on export — the existing ext mechanism, generalized. Store seam: two generic methods (export_ext(kind) / import_ext(kind, key, ext)) with no-op defaults instead of fourteen method pairs. L1 gains "foreign fields on every kind round-trip verbatim"; the shared fixture gains foreign fields on an entity, an edge, a fact and a context.

Input wanted

1. Sidecar key for id-less kinds: canonical-line hash (proposed) vs giving factLink / episodeLink / preference real ids.
2. A per-record size bound for foreign remainders?
3. Advertise capabilities: ["ext:all-kinds"] in the manifest?

Relationship: RFC-0001 (#11) places visibility on non-episode kinds and SHOULD NOT be adopted before this lands. Comment period to 2026-10-05; decision by lazy consensus per GOVERNANCE.