defaults.test.ts: filling a leaf-* seam breaks the BRIDGE's row, which the leaf guide's rule doesn't cover

[simonholmes]

Found while cutting the first leaf app (Lelañea) from daybreak-v0.2.0.

What bit

.context/framework/building-on-daybreak.md → "Two tests you are expected to adjust" gives this rule:

tests/unit/lib/app/defaults.test.ts — asserts every lib/app/* seam ships empty. When you fill one, pin the new value in its SEAM_DEFAULTS row rather than removing the row.

The rule is keyed on "when you fill one". But filling a leaf-* seam also breaks the row for the bridge above it — a seam the leaf never touched. The bridge reads the leaf seam, so the leaf changes its resolved value without editing its file.

Two instances, both confirmed by running them:

1. lib/app/brand.ts — hit for real on the first leaf.

FAIL tests/unit/lib/app/defaults.test.ts > 'lib/app/brand.ts' registers nothing by default
AssertionError: expected 'Lelañea' to be 'Daybreak'

lib/app/brand.ts:33 resolves leafBrandName ?? 'Daybreak', so a leaf that sets its name correctly makes this row report the leaf's name. The row (defaults.test.ts:418) pins the literal 'Daybreak'.

The part worth noting: the row's own comment two lines above anticipates the override and pins the literal anyway —

// PINNED (Daybreak fills this bridge): the framework's own identity, which a
// leaf fork overrides from the reserved-empty `leaf-brand.ts` (row below).
expect(seam.appBrandName).toBe('Daybreak');

2. lib/app/admin-nav.ts — verified with a throwaway probe (one registerNavSection in leaf-admin-nav.ts, then reverted):

FAIL 'lib/app/admin-nav.ts' registers nothing by default
AssertionError: expected [ { title: 'Framework' }, …(1) ] to have a length of 1 but got 2

The leaf-admin-nav.ts row failed in the same run, which is correct and covered by the guide. The admin-nav.ts row is the one the rule does not reach.

3. lib/app/data-export.ts — probable, NOT verified. Its row asserts expect(accounted).toEqual(frameworkModels) where frameworkModels comes from framework-*.prisma only. A leaf declaring its app_* models through initLeafSubjectSources() looks like it would add entries frameworkModels cannot contain. Lelañea has no app.prisma models yet, so this is a read of the code rather than an observation — flagging it as the likely third rather than claiming it.

lib/app/bootstrap.ts is safe: await expect(initApp()).resolves.toBeUndefined() stays true however much a leaf registers.

Why it matters more than the fix cost

Every one of these fails at exactly the moment a leaf does the right thing — fills its reserved seam, as the guide instructs. The failure names a Daybreak-owned file the leaf never edited, so the natural reading is "I broke the framework" and the natural repair is to go and edit brand.ts or admin-nav.ts — the bridges the same guide says never to touch, and the exact edit that collides on the next sync. In the data-export.ts case, resolving that the obvious way silently drops the framework's tables from every GDPR subject-access export, which is the failure mode building-on-daybreak.md already warns about in bold.

So the cost is not the two-minute fix; it is that the guidance points a leaf toward the one repair the framework most needs it not to make.

Suggested shape

Either would do; the second is cheaper and probably better:

1. Make the bridge rows resolve rather than pin — assert against what the tier below actually supplies, so the row keeps its meaning at both tiers.
2. Extend the rule in building-on-daybreak.md to say that filling a leaf-* seam also moves its bridge's row, and list the pairs (leaf-brand.ts → brand.ts, leaf-admin-nav.ts → admin-nav.ts, leaf-data-export.ts → data-export.ts), with the explicit instruction to pin the bridge row too, not edit the bridge.

Either way the guide's "Two tests you are expected to adjust" undercounts — within defaults.test.ts a leaf adjusts a row per seam it fills plus a row per bridge above those.

What Lelañea did

Pinned all three affected rows to the resolved values rather than deleting them, so the seams still empty keep their protection, with the reasoning recorded in place so nobody restores them on a sync.

---

Filed from the first leaf cut on daybreak-v0.2.0 (Sunrise 0.11.2).

🤖 Generated with Claude Code

https://claude.ai/code/session_01CneMwAfmx471CoA4sepW8q

[simonholmes]

Cross-reference found while looking for prior art: Sunrise #480 (closed 2026-07-30) is the first-order version of this, and its framing is the one to reuse:

the test lives in core and asserts a property that every fork is expected to violate. Filling a seam — the one thing the seams exist for — turns a fork's CI red, and the fix is an edit to a Sunrise-owned test file. That's precisely the merge conflict the seam model is designed to prevent, reintroduced at the test layer.

That is exactly this issue, one tier down — with one difference that matters for the fix.

Sunrise #480 is about the seam you filled, and the SEAM_DEFAULTS "pin the row" model resolves it: fill X, pin X's row. building-on-daybreak.md inherits that rule verbatim ("When you fill one, pin the new value in its SEAM_DEFAULTS row").

This issue is about a seam you did not fill. Fill leaf-brand.ts, and brand.ts's row moves. Fill leaf-admin-nav.ts, and admin-nav.ts's row moves. The pin-the-row model still works as the repair, but the rule as written never tells you to apply it there, because you did not fill that seam — so a leaf meets the failure without having been warned, on a file it is told never to touch.

So the two-tier bridge/leaf split Daybreak introduced re-created #480's problem in a form #480's fix does not reach. Worth resolving in the same spirit rather than differently: the rule should key on which rows a change moves, not on which files you edited.