Generated and pasted board backgrounds move into .backgrounds/ — the board root stops collecting the app's own pictures

New app-written background images (Theme tab ▸ Pattern, and Edit ▸ Paste
as Board Background) now land in a hidden `.backgrounds/` folder at
board root instead of beside index.md, matching the `.trash/` app-managed
pattern. `background.image` stores the qualified relative reference
(`.backgrounds/facets.png`); the resolver needed no change at all, since
it already accepted any relative path inside the board root — the same
mechanism that already resolved `art/backdrops/sunset.png` resolves the
new location for free. `BoardWriter.writeBoardImage` now creates its
destination folder if missing, since `.backgrounds/` won't exist until a
board's first generated or pasted background.

The Finder collision-ladder (`BoardStore.boardImageName`) is rescoped to
`.backgrounds/`'s own contents, and its overwrite-in-place check now
recognizes only the qualified form as "ours" — a legacy bare
`background.image: facets.png` from before this change is read as a
foreign reference rather than migrated, so a regeneration writes a fresh
`.backgrounds/` file and orphans the old one in place, per the no-migration
ruling. The Theme tab's Pattern/Solid mode-detection was updated to
recognize both the legacy and current spellings as the generator's own
output.

The board loader needed no change: `.backgrounds/` is a hidden,
non-UUID-shaped name, and `.skipsHiddenFiles` already keeps every hidden
entry off the lane walk before any name-based exclusion is consulted —
pinned with a new loader test. Deliberately did not add `.backgrounds` to
IntegrityRules' claimed-name/squatter-displacement table: that table
mirrors a specific existing DESIGN ruling this card doesn't amend.

Claude-Session: https://claude.ai/code/session_014PtZdPwqZuqEDLc6wZMtEy
This commit is contained in:
2026-08-09 08:38:07 -04:00
parent 0a01405ced
commit d0c546179f
9 changed files with 270 additions and 88 deletions
+14
View File
@@ -326,6 +326,20 @@ struct BackgroundImagePathTests {
== "/Users/someone/Boards/Work.kanban/art/backdrops/sunset.png")
}
/// **Both locations resolve through the one rule, unchanged** (ruled 2026-08-09): a legacy board
/// naming a bare `facets.png` at board root and a current one naming the qualified
/// `.backgrounds/facets.png` both land as ordinary nested-path resolutions `.backgrounds/` is
/// simply a subfolder name to this check, exactly as `art/backdrops/` already was above. No new
/// resolver machinery exists for the app-claimed folder; this is the "minimal change" the ruling
/// chose, pinned as its own test.
@Test("A legacy root-level image and a current .backgrounds/ one both resolve")
func resolvesBothLegacyAndCurrentLocations() {
#expect(BoardBackdrop.imageURL(named: "facets.png", inBoardRoot: root)?.path
== "/Users/someone/Boards/Work.kanban/facets.png")
#expect(BoardBackdrop.imageURL(named: ".backgrounds/facets.png", inBoardRoot: root)?.path
== "/Users/someone/Boards/Work.kanban/.backgrounds/facets.png")
}
/// The check is about where the path *ends up*, not how it is spelled: a climb that lands back
/// inside the board is an ordinary file in it.
@Test("A path that climbs and returns is still inside")