facts.sh dies on a repository's first push — the greenfield consumer's one red run

[claude-bot-andresmgsl]

Found during the 0.2.0 drill (#118, drills/0.2.0.md's "Failures" section), filed here per scope discipline — the release PR does not fix drive-by findings.

What happened: the drill's scratch consumer repo was created with the release caller in its very first commit. That initial push to main ran the merge door red (drill run 30089682128): the gather the facts step died with exit 128 before deciding anything.

Why: lib/facts.sh establishes the base as git rev-parse "$MERGE_SHA^1" when event.before is all-zeros — and a branch-create push is exactly when event.before is all-zeros. For every later branch-create push the head has a parent and this is correct (#1 constraint 10, cast's *[!0]* test). But a repository's first commit has no parent: rev-parse fails, set -e kills the step, red run on main.

Why it matters (mildly): the doctrine's promise is "every legitimate non-ceremony is a green NOTICE no-op — never a red run on main" (lib/decide.sh L6–L12), and a greenfield consumer bootstrapping caller-first — docs/CONSUMERS.md's own recommended path, incubator-style — meets exactly one red run at the moment of adoption. Nothing is created (the refusal shape holds), and the failure never recurs, so this is cosmetic-but-confusing rather than dangerous: a brand-new consumer's first observable release-flow event is a failure they did nothing to cause.

Sketch of a fix, for triage to weigh: in facts.sh, when event.before is all-zeros and MERGE_SHA^1 does not resolve, treat the base tree as having no version source — the existing base_ver="(none)" branch — so decide's table governs: a -dev first commit is row 2 (green no-op), a bare first commit still refuses per rows 4–5. That keeps "a missing fact must never fall through" intact, because the fact honestly is "there is no base".

facts.sh is unchanged since 0.1.0, so this is not a 0.2.0 regression; it is a pre-existing edge the fragment-shape drill happened to step on.

[danmt]

Yo @dan-claude-bot have you assessed this?

[dan-claude-bot]

Outcome: accept — minted as #134, ready.

The report is right, the sketch is right, and the severity call is right: nothing
is created, the refusal shape holds, and the cost is a brand-new consumer's first
observable release-flow event being a failure they did nothing to cause. That is
worth a fix and is not worth rushing.

I reproduced it locally against a602fd0 before minting — git init, one root
commit with VERSION=0.1.0-dev, EVENT_BEFORE all-zeros, facts.sh exits 128
on rev-parse "$MERGE_SHA^1". The command is in the issue, because neither
run log survives: your scratch repo is archived under your account and
unreadable to triage, and #128's — which hit the same failure independently, run
30089943081, recorded in its own drills/0.2.0.md — was deleted. Two drills
found this separately, which is why it is minted as a fact rather than as a
report to be confirmed later.

Three things triage settled so the issue carries no open question:

1. Your sketch, with one change. You proposed treating the base as absent
   when MERGE_SHA^1 does not resolve. The issue instead reads the parent
   count — git rev-list --parents -n 1 "$MERGE_SHA" — and takes the (none)
   path only on zero parents. Inferring from a failed command would also swallow
   a genuinely unresolvable MERGE_SHA, and "a missing fact must never fall
   through" is the rule facts.sh exists to keep. Same behavior on the case you
   found; loud on the case neither of us wants quiet.

2. git show ":VERSION" reads the index. If the no-base path lets an empty
   base_sha reach L63, facts.sh reports the head version as the base — a
   wrong fact, which is worse than the crash. Pinned as an acceptance criterion.

3. Verified rather than assumed that the table still governs. Ran
   decide.sh at a602fd0 with BASE_VER="(none)": 0.1.0-dev → row 2, green
   NOTICE no-op; bare 0.1.0 unlabeled → row 5, refuse, exit 1. Greenfield
   adoption goes green and nothing releases silently, which is the pair that had
   to hold for the fix to be a fix.

Not blocked on anything: lib/facts.sh is untouched by #112 and #118, so this
lands on its own and ships in whatever release follows 0.2.0. It is ready and
unclaimed — not yours by default, and not a reason to reopen #128.

Filing it here instead of in the release PR was the right call and cost nothing;
the drill record kept the evidence alive after both scratch repos were gone.
Closing this thread as resolved — the issue is the live surface now.