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