Bullet Heaven — Housekeeping Backlog

Standing backlog for infra/tooling debt discovered mid-session that’s worth doing but shouldn’t block whatever the current task is. Check this before starting significant new work — pick off anything cheap/important first. Not for gameplay/content tasks (those live in the roadmap memory + git log); this is specifically for “we noticed this is broken/awkward, fix it sometime.”

Convention per entry: date discovered, one-line description, why it matters, rough effort. Mark DONE (commit X) in place rather than deleting, until the next prune.

Open

✅ DONE (2026-07-04) — scripts/check-test-count.sh can’t complete on this machine: godot’s headless run SIGABRTs (exit 134) at teardown even when the suite is fully green. Cause is RID leaks at exit (“N RIDs of type CanvasItem were leaked” / “RID allocations … leaked at exit”), not a test failure — the suite prints 1518 passing / 0 failing first, then godot aborts on the way out. The guard’s set -euo pipefail catches that 134 on the out=$(godot …) line and aborts BEFORE printing its Scripts-count check, so a fully-passing run looks like the guard itself broke. (The bh-dev-chunk skill documents set -e aborting on a failing test; this fires on a CLEAN exit too — a distinct trigger.) Workaround used this session: verified the count manually — ls tests/test_*.gd | wc -l vs the suite’s ^Scripts line (204/204). Fix (~15 min): make the guard tolerant of godot’s exit code — capture out with || true (or set +e around just that one call) and decide from the parsed Scripts/Failing lines, not godot’s exit status. Why it matters: the count guard is the anti-silent-drop safety net; if it can’t run, that protection is effectively off. Fixed 2026-07-04: the guard no longer wraps the godot run in set -e — it captures the output with || true and judges purely by parsing GUT’s summary (Scripts count + a derived Tests − Passing − Risky failure count, since GUT omits a “Failing” line when zero fail). So godot’s exit-134 teardown can’t abort it, and it still fails loud on a count mismatch OR a real test failure. Verified: exits 0 with 204/204 test scripts ran, 0 failing on the green suite.

Done (kept for reference until next prune)

2026-07-04 — DONE: folded the tvOS Godot project into this repo at platform/tvos/, via SYMLINKS (the old separate ~/Claude/bullet-heaven-tvos repo is archived aside at ~/Claude/_archive/bullet-heaven-tvos-old/). The open symlink-vs-copy question was resolved empirically: an isolated probe proved Godot imports + boots + runs the full 203-script suite cleanly through symlinks, so symlinks won (zero duplication, and the concurrent-clobber problem is eliminated not just made recoverable — there’s only one copy). platform/tvos/ holds real project.godot (Metal), export_presets.cfg (now TRACKED — force-included past the global ignore, fixing the old “gitignored, re-add if missing” landmine), icon.png, and the gitignored build/+build-ios/ Xcode shells; the 3 hand-edited non-regenerable files (dummy.mm + two Info.plist) are tracked in platform/tvos/patches/. bh-deploy/bh-dev-chunk/ bh-live-debug-deploy/bh-appstore-release skills all re-pathed + the sync step removed. ⚠️ Import/boot/full-suite are green through the symlinks, but the actual on-device export→xcodebuild→devicectl was NOT re-run this session (needs the Godot fork + Xcode-beta) — the next real deploy is the final proof; the Xcode build shells were moved intact so it should behave identically.
2026-07-05 — minor: Godot’s editor auto-generates stray .import cache files for docs-site/’s binary/vector assets (e.g. docs-site/public/favicon.svg.import, docs-site/src/assets/houston.webp.import) whenever the project is opened in the editor, since Godot scans the whole repo tree by default and docs-site/ isn’t excluded. These are harmless (regeneratable, don’t affect the Astro build) but show up as untracked noise in git status. A targeted docs-site/**/*.import gitignore rule would fix it — NOT a blanket *.import rule, since ~97 .import files (audio assets etc.) are intentionally tracked elsewhere in the repo.