Artifact [6c76222c26]

Artifact 6c76222c26d9c89016ddf401b41205fd80e420b9a640a2ad3eb8fcb7cb13353a:

• File internal/deck/rcard.go — part of check-in [5036cae392] at 2026-07-19 22:27:35 on branch trunk — Enforce card occurrence classes and intra-run ordering (#94)

  * Enforce card occurrence classes and intra-run ordering

  The deck parser enforced card-type ordering and nothing else. Each of the 14 single-occurrence card types was handled by a case that assigned, so a second occurrence silently overwrote the first, and the repeatable types were appended with no sort check at all. draft-fossil-artifact-format-00 §4.5.1 and §4.5.2 define both rules; implement them.

  Duplicate rejection covers A, B, C, D, E, G, H, I, K, L, N, R, U and W. The guard is separate from the card-type check because that check permits equal consecutive letters. F, J and M gain a strictly-ascending check against the preceding entry, T the two-level (name, target hash) rule with the full sign-prefixed name as primary key. P and Q deliberately get neither: P order is semantic — primary parent first — and Q is unordered-repeatable. P also now appends across cards instead of replacing, which is what §4.5.1 means by repeatable. Z belongs to neither class, so it is accepted with no duplicate or last-card rule; the authoritative checksum is the trailing 35 bytes VerifyZ already verified.

  All four ordering checks route through one comparator, deck.Compare, which is §4.5.3: unsigned octets, locale-independent, no normalization, no case folding. §4.5.3 exists because the same ordering underlies the delta-manifest merge walk and baseline binary search of §8.2, so a second copy would resolve a delta manifest wrongly rather than merely fail validation. The F check runs on the decoded filename, per §4.5.2.

  Malformed input is reported through the error return, never a panic -- these bytes arrive from peers.

  Two writer-side defects surfaced, both of which let this package emit artifacts its own parser now rejects. Marshal emitted J cards in caller-supplied order while already sorting F, M and T; it now sorts them. Marshal also sorted T by the concatenation name+target, which lets the target's leading hex digit compete with the tail of a longer name and reorders tags whose names are prefixes of one another; it now uses the two-level key. The F and M sorts and the R-card file enumeration route through deck.Compare as well, the latter per §6.3.

  Closes #70

  * Order T cards by decoded name and type the Z payload

  Review found two ways the first pass diverged from canonical fossil in the accept/reject direction.

  The T ordering key used the raw wire name. §4.7.16 says the name is escape-decoded and that the primary ordering key is the full name token including its leading sign character; manifest.c defossilizes the name before the ordering compare. Because "\s" begins 0x5C and a space is 0x20, the two forms order oppositely, so a run like

  T *sym-a\sb aaaa... T *sym-a-c bbbb...

  is valid, fossil accepts it, and we rejected it. Branch names may contain spaces, so this is an ordinary tag, not a corner case -- the same post-decode trap already handled for F. tagOrderKey now builds the decoded key and both the parser check and the marshaller's sort call it, so the two cannot drift apart.

  The Z card accepted any payload. Accepting a Z line inside the body is right -- §4.5.1 puts Z in neither occurrence class and treats an earlier Z as content covered by the final checksum -- but §4.7.19 still fixes the payload at exactly 32 hexadecimal characters. Validating nothing left an arbitrary-byte channel in an otherwise fully typed grammar and would have stored and forwarded artifacts canonical refuses. Upper-case digits are accepted, matching fossil's validate16.

  Also: the T sign prefix is now checked against {+,-,*} per §4.7.16, both because canonical checks it and because an unvalidated sign byte >= 0x80 would UTF-8-expand to two bytes when the ordering key is assembled and silently corrupt the comparison. Two stale §4.7.20 citations corrected to §4.7.16, and the two-level T test gained the prefix-name case that actually distinguishes a two-level comparison from a concatenated one.

  * Cite the normative grammar for the case-insensitive Z token

  The Z payload's case-insensitivity was justified by inferring it from the word "hexadecimal" in §4.7.19. §6.1 states it normatively: md5-token = 32hexdig-ci, a parse-accept grammar admitting both 0-9a-f and A-F. Cite that instead, and record the split it implies -- the structural check is case-insensitive while §6.2 keeps verification byte-exact against the lowercase form.

  Also soften deck.Compare's claim that the delta-manifest merge walk relies on F ordering to the future tense parse.go already uses: the merge walk is a map overlay today with no comparator to share. (user: [email protected], size: 869) [annotate] [blame] [check-ins using]

package deck

import (
	"crypto/md5"
	"encoding/hex"
	"fmt"
	"sort"
)

func (d *Deck) ComputeR(getContent func(uuid string) ([]byte, error)) (string, error) {
	if len(d.F) == 0 {
		return "d41d8cd98f00b204e9800998ecf8427e", nil
	}
	sorted := make([]FileCard, len(d.F))
	copy(sorted, d.F)
	// "Filename order" in the R computation means the file-enumeration
	// order under the canonical comparator of §4.5.3 (§6.3).
	sort.Slice(sorted, func(i, j int) bool { return Compare(sorted[i].Name, sorted[j].Name) < 0 })

	h := md5.New()
	for _, f := range sorted {
		if f.UUID == "" {
			continue
		}
		content, err := getContent(f.UUID)
		if err != nil {
			return "", fmt.Errorf("ComputeR: fetching %q: %w", f.UUID, err)
		}
		h.Write([]byte(f.Name))
		h.Write([]byte(fmt.Sprintf(" %d\n", len(content))))
		h.Write(content)
	}
	return hex.EncodeToString(h.Sum(nil)), nil
}