Erratum — draft-fossil-sparse-cone-00 §3

Document	draft-fossil-sparse-cone-00
Section	3.2 — Normalization; 3.4 — Patterns Are Deliberately Absent; 3.6 — Literal Prefixes Only
Type	Technical (§3.6 puts exclusions out of scope while §3.3 specifies them; §3.4 and §3.6 duplicate each other; one MUST in §3.6 has no conformance test)
Status	Applied in draft-fossil-sparse-cone-00 (2026-10-19)
Reported	2026-10-17
Submitter	Dan Mestas
Found via	Writing an implementation of the sparse-worktree section against the draft text

1. Summary

Section 3 contradicts itself and repeats itself. §3.3 defines exclusion members normatively (most-specific member wins, polarity normalization, dead exclusions refused, both polarities on one path refused), and zit implements them (src/cone.zig); §3.6's last paragraph calls exclusions "a candidate extension ... out of scope for this revision". §3.4 and §3.6 make the same argument against pattern members, once each. The 64-member/255-member requirement appears in §3.2 and again, with different prose, after §3.4. And §3.6's rule for pattern metacharacters, "MUST reject ... only if its platform's operators would plausibly expect expansion", has no test an implementation can apply to itself.

2. The text in error

§3.4, second paragraph: "Implementations MUST support at least 64 members and SHOULD support 255; a member set is operator policy, not data, ..." (the duplicate of §3.2).

§3.6, whole section: the second statement of literal prefixes; the conditional MUST; and "Exclusion members ... are a candidate extension ... out of scope for this revision and MUST NOT be improvised incompatibly."

3. What the implementation does

zit implements §3.3's exclusions, serialized under the cone's versioned format. It treats every member as the literal path it spells and never expands metacharacters.

4. Corrected text

Delete §3.6. Replace §3.4 with one section carrying the literal-prefix argument once, retitled "Literal Prefixes Only":

Members are literal path prefixes. Pattern members (globs, character classes, suffix matches) are not part of this document: every efficiency claim herein -- sub-manifest range pruning (Section 1.3), server-side interval classification (Section 6.2) -- rests on a member denoting one contiguous key interval under sorted-path order, and a pattern denotes scattered intervals, degrading every classification to a full scan. An implementation wanting patterns would be defining a different, slower mechanism, and should say so rather than extend this one. A metacharacter in a member is a literal character of the path: an implementation MUST NOT expand it, and MAY refuse the member.

A member names a directory subtree or a single file with equal standing: file members are how a profile picks individual files without adopting their directories.

The 64/255 requirement stays in §3.2 only. §3.3 governs exclusions.

5. Observable consequence of the uncorrected text

An implementer reading §3.6 omits exclusions and refuses a cone that zit writes and §3.3 defines, or treats a member with a * as a pattern on one platform and a literal on another, with the same text licensing both.

6. Implementations

zit's behaviour is the specified one; no change.