01:08: when the official Owlbear store can be expected

01:08: when the official Owlbear store can be expected

• Written after a two-minute look that turned out to be the whole phase. Check where PR #174 sits in owlbear-rodeo/extensions and how quickly that repo merges, so I stop treating the official store as soon.

02:07: what a search for a deck plan tool finds

• events.sh since 23:00 has one from/ visit, too few to read. So I'll do the other half of "where people come from" instead. Run the searches a GM would type (starship deck plan generator, owlbear rodeo deck plan, derelict ship map free, dd2vtt spaceship) and note where Bulkhead's site, its itch page and the daily pages show up, and what shows up above them.
• If a page we'd expect isn't there at all, check the sitemap and that page's head before guessing at why. No noindex changes (refused before).

02:50: the boss's itch dashboard

• Written after the fact, as a reply to the screenshot. Record it in FACTS. Point the boss at task 3 on /press/ instead of the duplicate email I sent, and add the noindex line to task 3.

03:07: the 1.18 devlog, ready before task 1 is done

• itch's update posts get listed while the page isn't, so the 1.18 upload should go out with one. Write store/DEVLOG-1.18.md and check every claim in it against bulkhead-1.18.zip and bulkhead-eight-derelicts.zip as they sit on /press/: the adventure PDF, the paper sizes, the eight one-shots, and what's new since the 1.17 file on itch.
• Follow the rules for posts in the boss's voice: AI line first, no em dashes, plain text that pastes into itch's editor. Don't ask the boss for it yet. It goes on the task 1 step page as the last step once it's checked.

04:07: curated lists that take a pull request

• Search and itch both route through itch's review, so look for routes that don't: GitHub "awesome" lists and community tool lists for TTRPG, VTT, Owlbear and sci-fi RPG tools. Each one takes a single PR or form and puts a permanent link where GMs already look.
• For each, check that it's alive (merges in the last 3 months, open PRs not ignored), its rules for entries, and whether a paid tool with a free demo is allowed. Rank them and write the exact entry line each wants. Don't open any PR; that's a boss go-ahead, batched after task 1.

05:08: did the room step fix the Owlbear funnel

• Written a few minutes in. Check whether the Rogue Store re-indexed after last night's README change. Then compare manifest fetchers with panel opens and sends since 21:15 yesterday against the 12 to 2 before it. Log the first web demo save if there is one.

06:07: the four task 1 switches still apply after last night's changes

• Since the patches were last checked (30 Sep afternoon), main.ts (from/), obr.ts and obr.html (the hex grid), daily-derelict.mjs (the grid line) and store.md have all changed. In a throwaway copy of HEAD, apply adventure-on, oneshot-on, pack-on and obr-pack-on in order. Then tsc, build, the paid build, and the 45 tests. Fix any patch that has drifted, so "done" from the boss means minutes, not an afternoon.
• Nothing goes in the live tree.

06:17: the switch patches live in the repo, not only in this session

The four task 1 patches exist only in this session's scratchpad. If the session ends before the boss says "done", they are lost and the switch is an afternoon again. Put them in app/switch/, made with one line of context so no line carrying the public beacon token comes along (no key-shaped string in the repo). Check that they apply in order to a clean HEAD, add a README with the order and the steps for "done", run no-keys over the new files too, commit and push.

07:07: who presses Generate and leaves

LEARNED (30 Sep): 50 Generate presses on the web demo, no saves, and "find out who the Generate-and-leave visitors are before touching the card". Run events.sh for the week. Line up each Generate sitting (hour, country, device) with the editor visit's from/ in the same hour: Reddit, the zoo, our own pages (the daily, /maps/, the one-shot or generator landing pages) or none. Then check what the card shows them right after Generate on a phone and on desktop, logged out, with Playwright blocking the beacon. Write what the sources say. Change the card only if one source dominates and the card plainly fails it, and only with a test.

08:07: on an iPhone, the card hides the bottom of the ship it describes

Seen in the 07:07 screenshots: on an iPhone 13 (390x664), after Generate the card covers the lower rooms of the ship. fitView gives the ship at least a third of the stage, and the card is taller than what's left. Now that the whole story sits in the Room key just under the map, the card on a phone doesn't need room for it. First measure, for 5 ships on an iPhone SE, iPhone 13 and Pixel 7: how much of the ship's height the card covers. If it covers part of the ship on the iPhones, clamp the card's story to two lines with an ellipsis on narrow screens, so the card is shorter and the ship fits above it. Measure again, then check that the buttons and the $12 line are still whole (they were cut once, see style.css). Run tsc and the tests, deploy, and run status, smoke and the harness. Recheck that the switch patches still apply.

09:07: does a file download from inside Owlbear on an Android phone

Open since 30 Sep: a GM in Brazil on Android pressed the panel's .dd2vtt export three times. If Owlbear's extension iframe blocks downloads on phones, every phone GM's export does nothing, silently. Find out without the boss: look for public evidence of the iframe's sandbox (allow-downloads), from Owlbear's docs repo, other extensions' issues and source, and Chrome's rules for downloads from cross-origin iframes on Android. If it's blocked or likely blocked, give the panel a fallback that works anyway and doesn't break desktop, and test it in the harness. If it can't be known, write down exactly what to look for in the real-room test.

10:07: what the Owlbear panel looks like on a phone

The one stranger who has used the extension used it on an Android phone. Our manifest asks for a 1100x720 popover. I don't know what Owlbear does with that on a 412px-wide screen, or whether Send and the export are reachable there. Find how the archived room bundle sizes an action popover on a small screen, then load /obr at that size in the fake Owlbear host on an emulated Pixel 7 and an iPhone 13. Screenshot it, and check that Generate, Send and the export button can be seen and pressed without anything covering them. If something is broken, fix it in obr's narrow layout, test it in the harness and with the 45 tests, then deploy. If nothing is, write down what a phone GM sees.

11:07: the daily check, on the first day with the grid in the PNG name

Run the daily check as written. Today is the first daily since the PNGs got their grid size in the name (-WxH, 30 Sep). On the live day page, check that the PNG link resolves and is named -WxH, that the PNG's pixels match WxH at 100 px per square, that the Owlbear line about the name is there, that the Bluesky post's alt text still has the grid, and that status is clear. If the day is missing, run it by hand as the check says. Fix whatever breaks. Then, if time is left, itch views and downloads for the 30th.

12:08: who lands on the Owlbear page, and do they install

Since noon on the 30th, /owlbear-rodeo-dd2vtt/ is our second most viewed page (13 first-party views, 8 RUM loads, 7 of them with no referrer). Its job is to get a GM to copy the manifest URL into Owlbear, and that click isn't counted. So nothing says whether it works. Check with WebSearch whether the page ranks for what a GM types about dd2vtt and Owlbear, which would explain the visits. Then count the Copy button (/e/obr-copy) and the Rogue Store link the same way the page counts its view, check that a real click sends the ping, and deploy. Then events.sh can show the page's views, then copies, then panel opens (obr-view), then sends.

13:09: can players walk into every room the generator makes

• Why: the generator test only checks that rooms, doors and key ids exist. Nothing checks that a GM can walk a party from the corridor into every room through doors. A sealed room on a $12 map is a defect a buyer sees at the table.
• Do: a temporary vitest file walks each deck from the corridor, crossing a wall only at a door, airlock or hatch (not a window, not through a partition). 4 sizes x 2 moods x 25 seeds.
• If rooms are sealed: fix the generator, add the check to test/model.test.ts, tsc, vitest, deploy, status, smoke, harness.
• If none are: add the check as a guard test anyway, and log the numbers.

14:07: a hull hole is open in the VTT walls, as it is in the picture

• Why: at 13:09, 24 of 150 derelict decks had rooms reached only across a hull hole. The PNG tears the wall out at a hole, but the .dd2vtt line_of_sight and the Owlbear send come from wallSegments, which counts a hole's edge as hull. So in Foundry a token can't cross into those rooms, and in Owlbear Dynamic Fog the hole is a wall to sight. The picture and the walls disagree.
• Do: in buildUVTT, leave out every unit wall edge with a breach cell on one side, and re-merge the runs. Leave the drawing and wallSegments alone.
• Test: on a cut-off derelict deck (shuttle derelict seed 3), the .dd2vtt walls let a walk reach every room across the hole. Intact decks' walls stay exactly the same.
• Then tsc, vitest, deploy, status, smoke, and obr-harness ok and exports.

15:07: does Foundry's importer read our .dd2vtt the way the picture means it

• Why: the 14:0x hole fix came from the walls and the picture disagreeing. Foundry users import the .dd2vtt with the Universal Battlemap Importer (moo-man/FVTT-DD-Import). Its source is public, so I can check every field we write against what it does, instead of guessing.
• Do: read ddimport.js (v6.1.1) for walls, portals (doors, windows, airlocks), objects_line_of_sight, lights (range, colour, intensity), environment and resolution. List each thing we export, what Foundry makes of it, and whether that matches the picture.
• Fix anything that disagrees, with a test where the logic is ours. Then tsc, vitest, deploy and checks.

16:07: what Owlbear's Dynamic Fog does with our windows, from its source

• Why: at 15:0x I queued a real-room test to find out whether a token walks out through a bridge window, which we send as an open door. owlbear-rodeo/dynamic-fog is public on GitHub, so the source can answer it now, without asking the boss.
• Do: read how it turns FOG-layer paths and the doors metadata into walls: collision, open doors, and any window or one-way option. Check our walls and lights the same way.
• If a window lets a token walk out: send windows in whatever form Dynamic Fog has that passes sight and blocks movement, if there is one. Then test in the harness, deploy and run the checks. If there isn't one, weigh the choice and write it down.

17:07: the rest of the Owlbear send against Dynamic Fog's source, and today's use so far

• Why: the window bug was only found by reading dynamic-fog. The same source says how it reads walls (which layer, stroke width), how far an open door cuts, and which items carry lights. Check ours against it before calling the send right. Then read today's events, to see whether anyone is using the Owlbear path the last three fixes touched.
• Do: read WallReactor, DoorActor (cut width) and LightReactor/LightActor against src/obr.ts. Run events.sh from 00:00 today.
• Fix only what the source shows is wrong.

18:07: does a hull hole read as a way in, in the PNG and on a phone

• Why: since 13:09 we know some derelict rooms are reached only across a hole. If the picture draws that hole like a wall or a dark room, a GM sees a sealed room and the ship looks broken. LEARNED says to check how a breach draws before touching the generator.
• How: find derelict seeds where a room opens only on a hole (from the 13:09 test logic), at shuttle and corvette size. Render the editor canvas and the exported PNG headless (dev server, beacon/e/go blocked), on desktop and at phone width, and look at the hole edge next to that room.
• If the hole reads as open space: write it down, no change. If it reads as wall or floor: change how a breach draws (src/render), keep the .dd2vtt as is, run tests, deploy, check.
• Also, quickly: has itch lifted noindex (scripts/itch-indexed.mjs), and did the Brazil Owlbear panel at 15Z send anything (events.sh).

19:07: a derelict room reached only through a hole says so in its key

• Why: 8 of 24 small derelicts have a room you can only get into across a hull hole. The picture shows it (checked at 18:07), but the key doesn't, and the key is what a GM reads out. One line turns a "where's the door?" into a scene: suits on, cross the gap.
• How: move the 13:09 test's walk into model.ts as one function (rooms whose every square is off the main walk). At the end of the derelict story, after mend(), add one "Way in:" line to those rooms' notes. It uses no dice, so every ship still rolls the same, and only the notes of cut-off rooms change. The test uses the same function and checks that every cut-off room has the line and no other room does.
• Check: tsc, vitest (background), build, then the dev server for shuttle 3's Bridge. Deploy, status, smoke. generate.ts isn't in a switch patch; re-check the patches on a worktree anyway.

20:07: the one-shot's GM page names the rooms reached only across a hole

• Why: the one-shot is the main thing the $12 adds once task 1 is done. Its first page, "How it runs", sends the party along the trail, but it doesn't know that a trail room, or any room, may be reachable only across a hull hole. Since the last phase the key says so room by room, but a GM preparing from the first page would miss it until mid-session. A one-shot that plans the crossing is worth more than one that leaves the GM to discover it.
• How: in adventure.ts, collect the "Way in:" lines along with Hazard, Log, Salvage and Trail. Under How it runs, add one "Cut off:" paragraph naming those rooms (as the trail names them) and how to play the crossing, using the table the PDF already has. Test: on every derelict with a cut-off room the PDF says "Cut off:", and on every other one it doesn't. The free build doesn't export the one-shot (it's behind the task 1 switch), so nothing changes on the live demo until then.
• Check: tsc, vitest (background), build. Render one PDF page to an image and read it. Deploy (the full build is the same tree), status, then the switch patches in order on a worktree.

21:07: Eight Derelicts gets today's fixes before anyone buys it

• Why: the pack is half of task 1 and the reason the $12 is worth more than the free side. It was exported on 30 Sep, so every .dd2vtt in it draws each hull hole's edge as a wall, which seals the cut-off rooms in Foundry (fixed in the exporter today, 13:xx). Its keys and one-shots don't have the Way in or Cut off lines either. Nobody has bought it, so it's safe to fix now, and it gets harder once it's on itch.
• How: keep the eight ships exactly as they are (the pack is the folders, not the seeds). With a paid dev server on 5199, load each ship file, add the Way in line to rooms cutOffRooms finds (chained as the generator does), save the ship file, and export the .dd2vtt per deck, the key and the adventure PDF again. The PNGs don't change. Then re-zip with the same layout and README, check that each .dd2vtt's walls equal vttWalls, cmp the live zip, and bump ?v= on /press/.
• Also list, without fixing yet: other places that shipped old .dd2vtt walls (the Foundry module, the free packs, past /daily/ files).

22:08: the daily archive's .dd2vtt walls match their pictures

The 16 /daily/ days (16 Sep to 1 Oct) were exported before hole edges stopped being walls, so a derelict's cut-off rooms are sealed in Foundry and Owlbear when the PNG shows them open. Each day kept its ship.bulkhead.json, so the walls can be rebuilt from it.

• For each day's .dd2vtt, rebuild the deck's export from ship.bulkhead.json with today's src, and replace only line_of_sight. Keep the image byte for byte.
• Write a file only if the rebuilt portals, lights, objects and resolution match the old ones exactly. Anything else gets reported, not written.
• The daily run only writes today's folder (checked: past days get only the key's source line), so the fix stays.
• Then the two weekly derelict zips, rebuilt from the fixed days with weekly-pack.mjs, if it can rebuild a past week without touching latest.json wrongly.
• Deploy, status, smoke, switch patches in order, cmp a fixed file live.

23:08: the Foundry module's derelict scenes get the open hole walls

foundry-module.mjs builds each daily scene from that day's .dd2vtt, but only once: a scene already in the pack is skipped, so the 7 scenes from 24 to 28 Sep keep the old walls across hull holes.

• Make the script refresh an existing scene's walls when its .dd2vtt says otherwise. Nothing else on the scene changes. A future export fix then reaches Foundry on the next Sunday run.
• Rebuild with next (1.4.0). That also adds 29 Sep to 1 Oct, which Sunday would add anyway.
• Check that only the affected scenes get new walls, then run Foundry v14 strict validation on the demo (--note), check the switch patches in order, deploy, status, smoke, and cmp the module zip live.

Next

• Real-room batch, after task 1: in Owlbear with Dynamic Fog, check that a bridge "Window" (now sent closed) stops a token and that the GM can open it with the door tool. The source says yes. This is just to see it.
• If a GM ever reports a room with no way in on a derelict: it opens on a hole (the 13:09 guard test proves it). Check how a breach draws at small sizes and in the PNG before touching the generator.
• itch support follow-up: it's task 3 on /press/ (a reply in the 18 Sep thread). After task 1, a 1.18 devlog replaces the unpublished 1.17 draft. Devlogs get indexed even while the page isn't. Once indexed: add the ttrpg tag and re-run itch-indexed.mjs.
• Tomorrow 11:07: the daily check. Bulkhead's itch views were 26 on 1 Oct; note the change. Today's Bluesky post had 0 likes at 11:12, against 1 or 2 every day since the 23rd. Read it again tomorrow before drawing anything from it.
• Owlbear path, from 4 Oct: views of /owlbear-rodeo-dd2vtt/, then obr-copy and obr-rogue (counted since 1 Oct, 12:10), then obr-view, then obr-send, in events.sh. If people view the page but nobody copies, the page is what to fix. If they copy but nothing opens the panel, look at the install step in Owlbear. After each daily, run the switch check on a worktree.
• Phone Generate sittings after the room key fix (deployed by 07:17): per sitting, do phones now press Another one, Save or Link? Group by hour, country and device as on 1 Oct (a temporary script in app/scripts/, removed after). Read from/ alongside it.
• Batch questions after task 1, all in one real Owlbear room. First, the .dd2vtt export from the panel on an Android phone: does a "downloaded" notice show, what is the file called in Downloads (it should end .dd2vtt), and does a two-deck ship bring up a "download multiple files?" prompt? (BR, 30 Sep: three presses, then a desktop save 25 min later. No sandbox on the frame and ~1 s to the download, checked 09:07.) Then a hex send and dragging in a -WxH PNG.
• Before task 1: after any src fix a buyer would get, rebuild bulkhead-1.18.zip (release.mjs), bump ?v= on /press/, cmp the live zip. Rebuilt 20:14 with today's fixes.
• Old .dd2vtt walls: done on 1 Oct (the daily archive, the weekly zip, Foundry 1.4.0). The /maps/ pages and both free packs (store/ = public/packs/; store/ is what I prepared for itch, but I can't see itch's uploaded files, so this is an assumption) already had the right walls, so the itch free packs need no re-upload. Drop that from the after-task-1 batch.
• Task 1 is still with the boss. On "done", follow app/switch/README.md: four patches in order, then map-pages.mjs, deploy and the checks.

01:08: when the official Owlbear store can be expected

• PR #174 is 32nd of 42 open, the same place as on the 30th. The repo merges in batches. The last ones were on 24 and 26 Aug, and they took PRs opened between 3 Mar and 8 Jun, so 2 to 6 months after they were opened. The ones before that were on 2 Jul (opened Dec and Jan) and 17 Jun. Ours was opened on 24 Sep, so on that pace the official store is around February, not this autumn. Some PRs get closed without a merge.
• So the Rogue Store and our own pages are the Owlbear channel for the next months. The README fix of the 30th matters more than it looked.
• Finished 01:08

02:07: what a search for a deck plan tool finds

• From/ data since 23:00: one visit (from our own site). Too few to read.
• WebSearch results: "starship deck plan generator" and "random derelict starship map generator online free" don't show us at all. Those are held by Arkenforge, Geomorph Shipyard, blog roundups and itch pages (delacannon's Derelict Ship Generator, itch "games like" lists). "spaceship deck plan maker online universal vtt" puts our home page 2nd. "owlbear rodeo deck plan extension" finds PR #174 on GitHub, not us. site: shows only the home page, with an older title.
• The itch pages are the reason. All three (bulkhead, deck-plan-pack-free, deck-plan-pack-2) serve <meta content="noindex" name="robots">, and two peer pages (delacannon, gurkenlabs) don't. So the review queue keeps us out of Google as well as itch's own search. itch-indexed.mjs: 0/3 in itch search, absent from both vtt-battlemaps tag pages. Day 19 since going paid on 12 Sep. itch's doc says "a few business days" and to contact support to be expedited. The boss's 18 Sep email has no recorded answer, and the ask planned for 29 Sep was never sent.
• Our itch tags don't include ttrpg (582 tools, the one peers use). We have "tabletop" (333). That only matters after indexing.
• Looked at the OBR Extensions Guide (onrender) as a listing route. Its repo was last pushed in July 2025 and has had two PRs ever. Not worth it.
• Finished 02:10

02:50: the boss's itch dashboard

• The boss sent a screenshot of the Creator Dashboard with no text. It's in FACTS: 32 views, 1 download, 1 follower, all three projects published, no indexing notice. There's also an unpublished devlog draft, "1.17: Generate a fleet, and share any plan as a link".
• My mistake: the itch support nudge has been task 3 on /press/ since the 30th, so the email I gave at 02:xx was a duplicate. My earlier actual says the 29 Sep ask "was never sent". It wasn't sent, but it is on the list. Added "all three pages also carry a robots noindex tag, so google can't list them either" to task 3's email instead. Deployed, and the live /press/ has the line.
• 32 views is double the 16 on the 29th.
• Finished 02:50
• (Boss asked "What was the download".) It was me. itch-stats: Bulkhead 1 download, 0 purchases, and both packs 0. The only file that can be downloaded without paying is bulkhead-examples.zip (v1.1.0, the free file on the $12 page). My actual for 29 Sep at 23:23 says I downloaded it logged out through itch's "Download demo" button. No real visitor has downloaded anything from itch yet.
• The boss opened the unpublished 1.17 devlog draft ("it was in as a draft"). Checked it against the 1.17 file on itch: /press/bulkhead-1.17.zip is 49,183 bytes, matching itch's 48 kB. It has Generate a fleet (5/10/20 ships), FLEET.md, .dd2vtt and Copy share link. The live demo has Copy share link too. The draft's last line ("the demo has everything except the fleet generator") has been wrong since the 23rd, because .dd2vtt and PDF are $12-only now. The draft also has no AI line. Gave the boss a corrected body to paste.

03:07: the 1.18 devlog, ready before task 1 is done

• Before writing it I found a mistake in the 1.17 body I'd given the boss. The 1.17 file on itch builds share links from location.origin plus pathname, so a downloaded copy copies a file:/// link. That's the bug 1.17.1 fixed, and 1.17.1 never went up. The body said "Share links (both versions)", which isn't true for the file people would buy. Checked that the post wasn't published yet (the devlog list has only 1.14), then sent a corrected body with that paragraph cut and the title shortened to "1.17: Generate a fleet".
• Wrote app/store/DEVLOG-1.18.md. Every claim is checked against /press/bulkhead-1.18.zip (bulkhead.html and its README) and bulkhead-eight-derelicts.zip: - the One-shot button and Export adventure are both in the build - the adventure's sections match its README - paper is A4 or Letter (the Paper type in export.ts) - the fleet zip has an adventure.pdf per derelict - the share link uses the hosted editor when the protocol isn't http(s) - the eight ships and their threats come from the pack README
• AI line first, no em dashes. Not given to the boss yet. It goes on task 1's step page after the upload.
• Finished 03:08
• Added the post to task 1's step page (/press/itch-description) as the last step: copy buttons for the title and body, the tags, and "delete the 1.17 draft if it's still unpublished". Checked at 390 px (no side scroll) and deployed. The live page has it. Updated: 03:09.

04:07: curated lists that take a pull request

• Dropped once I reread LEARNED. I'd already done this on 26 Sep ("GitHub awesome lists are not a way in": the TTRPG and VTT lists are dead or off-topic, and the OBR guide was last pushed in July 2025). I should have grepped LEARNED before writing the plan.
• Also looked for whether Owlbear's extension iframe allows downloads on Android (the BR triple export from the 30th). The GitHub issue search found nothing relevant. That stays a real-room test.
• Did instead: an item LEARNED had left open on 30 Sep, "walls and doors already set, fog works on import" in the opening of the itch description (Owlbear GMs' "I'd pay extra if fog is set up"). Task 1's description now opens with "...and the walls and doors already set, so fog of war works the moment it lands in Foundry, Roll20 or Owlbear Rodeo". Also corrected "about 175 KB" to "under 200 KB", since the 1.18 bulkhead.html is 193,323 bytes. Deployed, and the line is live.
• Finished 04:08

05:08: did the room step fix the Owlbear funnel

• The Rogue Store re-indexed our listing at 9/30 10:37 PM CDT (03:37Z). It now shows the new How to use (turn Bulkhead on in the room first) and the Grid in Owlbear note, at version 1.17.2. Its own counter says "1 Download".
• Since 21:15 yesterday: 3 distinct machines fetched /obr/manifest.json (9 fetches, 8 of them from one Android phone). Panel opens (obr-view) 3, a generate 1, a send 1, .dd2vtt exports 3. All of the panel events are that one Android phone in BR between 23:03 and 23:06. Before the fix it was 12 fetchers and 2 panel opens. This is one person, so it isn't a rate yet, but the one new installer did reach the panel and sent a scene.
• The first save from the web demo since counting began on the 23rd: BR, Windows desktop, 23:31, a generate then brief-png (the story card) and brief-link. Not mine (my runs are US, headless or iPhone-shaped). It's 25 minutes after the BR Android phone's three .dd2vtt presses inside Owlbear. My inference, not proven: the same person, moving to a desktop after the phone export didn't give them a file.
• from/ so far today: 3 from bananafest-destiny.com (the zoo; one US desktop pressed Generate 7 times in 3 minutes), 1 none (a US iPad), and a DE Firefox phone from the zoo. No visit from Reddit or a search engine yet.
• Finished 05:09

06:07: the four task 1 switches still apply after last night's changes

None of the four applied to HEAD as they stood. Last night's live edits had moved the lines they patch. All four are rebased now, in a throwaway copy, and nothing went in the live tree.

• adventure-on: one hunk in daily-derelict.mjs was rejected, because the line's surroundings had changed (the PNG grid sentence above it). The line itself was the same, so the one-shot sentence went in by hand.
• oneshot-on: the Owlbear page and daily-derelict.mjs were rejected. Both were the same $12 paragraph: on the Owlbear page it had moved below the new "turn Bulkhead on in the room" paragraph, and in daily-derelict.mjs it waits on adventure-on. Both fixed by hand.
• pack-on: it applies cleanly once the two above are in. Its failure was a knock-on.
• obr-pack-on: the hunk in obr.ts was rejected, because the send block now ends with the hex count. The pack hint now goes after that line.
• tsc, the build and the paid build pass. The tests: 44 of 45 passed. The one failure was real. The entry-page test reads any unguarded getElementById('x') in obr.ts as an element obr.html must have. So the pack hint's "is it already shown" check, if (!document.getElementById('obrPack')), counted as a requirement, and obr.html has no obrPack. That is a false positive, but it would have failed the switch on the day. The check now uses querySelector('#obrPack'). All 45 pass.
• The four refreshed patches apply in order to a clean copy of HEAD. They are in the scratchpad, and the old ones are kept as .bak-1001.
• The itch devlog page still shows only the 1.14 post. Neither the 1.17 nor the 1.18 post is up yet.
• Finished 06:16

06:17: the switch patches live in the repo, not only in this session

• app/switch/ now holds 1-adventure-on, 2-oneshot-on, 3-pack-on and 4-obr-pack-on, plus a README with the order and the steps for "done". The folder is outside public/, so it is not deployed.
• The patches are made with one line of context. With three, oneshot-on and pack-on carried the public beacon token in context lines. With one, nothing key-shaped is in the folder.
• Applied in order to a clean copy of HEAD, the four give a tree that matches the tested copy file for file. Tested means tsc, both builds and all 45 tests.
• New step found: map-pages.mjs is one of the patched files, and the /maps/ pages only change when it is re-run. In the patched copy it rewrote the 11 map pages, /maps/ and the sitemap. On a map page, the only text change was the new one-shot sentence. It is step 4 in the README. Without it, the map pages would have kept the old $12 paragraph after the switch.
• Finished 06:18

07:07: who presses Generate and leaves

• From 24 Sep there were 28 web demo sittings with a Generate in them (grouped by hour, country and device, no ids kept). Most were one press on / and nothing after. Two were long: Poland on the 24th (9 presses and 12 share-link opens) and Denmark on a phone on the 29th (11). The landing page is almost always / itself. The free plan has no referrer field in the request log, so where they came from before 1 Oct can't be recovered. from/ has 5 since it started: 3 from bananafest-destiny.com (the zoo) and 2 none. No source dominates, so I made no change to the card's offer or its buttons.
• 9 of the 28 sittings were on a phone (6 Android, 3 iPhone). There the story never showed in full. On a Pixel 7 and an iPhone 13, across 5 intact and 5 derelict ships each, the card showed 74px of a 142 to 264px story. Every time the text was cut mid-line and the hook was hidden. The Room key box that showBrief scrolls into view under the map, to show "the whole story", was 48px tall and cut it off too.
• Fix (src/main.ts, in showBrief): on a narrow screen, the Room key's story box grows to fit the story. It is a layout fix and nothing about the offer changed. Checked on a local preview and then live: on both phones the whole story is on screen under the map, intact and derelict, hook included. Desktop is unchanged (its card already shows the whole story).
• tsc, the build and all 45 tests pass. Deployed. Smoke: 41/41 pages, 41/41 links. obr-harness ok: the send works. Status: 5 failures, all today's derelict, which is due at 11:07.
• Finished 07:17

08:07: on an iPhone, the card hides the bottom of the ship it describes

• Measured on the live demo, 5 ships per phone, by finding the ship's white walls on the canvas and comparing them with the card's top edge. Before: the card was always at its 210px cap, because the scrolling story filled it. It hid 33 to 35% of the ship's height on an iPhone 13 (390x664) and all of it on a first-generation iPhone SE (320x568). Pixel 7 (412x839): 0%.
• Fix (src/style.css, narrow screens only): the card's story is clamped to two lines with an ellipsis. The whole story is in the Room key just under the map since 07:07. The card is now 177px (192 at 320 wide), and fitView gives the freed space to the ship.
• After, live: iPhone SE 3rd gen (375x667) 0% hidden, iPhone 13 0%, Pixel 7 0% and the ship drawn larger. A 320px-wide Galaxy S9+ is 13%, and the first-generation SE is still 78% (a 2016 phone, left as is). On every phone the buttons and the $12 line are whole inside the card.
• tsc and all 45 tests pass. None of the switch patches touches style.css. Deployed. Smoke: 41/41 pages, 41/41 links. obr-harness ok: the send works. Status: the same 5 failures, all today's derelict before 11:07.
• Finished 08:15

09:07: does a file download from inside Owlbear on an Android phone

• Owlbear's docs, its SDK repo and other extensions' issues say nothing about sandboxing. The room bundle as archived on 15 Jul 2026 does: it builds the extension frame with document.createElement("iframe"), sets allow from the manifest's permissions and the src, and sets no sandbox. With no sandbox attribute, a download from inside the frame is not blocked.
• Speed isn't it either. On an emulated Pixel 7 inside a fake Owlbear host (cross-origin iframe, CPU slowed 1x, 4x and 6x), the panel's .dd2vtt export started its download 0.2 to 1.0 s after the press, every run. The click's activation window is not missed.
• File name: Chromium keeps a download's own extension unless the URL has a query string, and a blob URL never does. So the file should arrive as name.dd2vtt, not .json. That is from Chromium's source, not a real phone.
• Nothing is blocked, so no fallback went in, and nothing in src changed. What can't be known from here goes into the real-room phone test (Next): does a "downloaded" notice show, what name the file has in Downloads, and whether a ship with several decks brings up a "download multiple files?" prompt (the export sends one file per deck, 400 ms apart). Three presses in three minutes, as the GM in Brazil did, fits a download that worked without them seeing it as much as one that failed.
• Finished 09:14

10:07: what the Owlbear panel looks like on a phone

• How big is the panel on a phone: Owlbear's room code (archived 15 Jul 2026) gives an action popover the manifest's 1100x720, capped at 100vw - 72px by 100vh - 200px. That is 340x639 on a Pixel 7, 318x464 on an iPhone 13 and 248x458 on a 320-wide Galaxy S9+. A fake Owlbear host with a device-width viewport framed /obr at those sizes (a temporary app/scripts/obr-phone-tmp.mjs, removed after).
• What a phone GM gets: the welcome card fills the map area, and Generate a ship and Generate a derelict are on it. After Generate, the panel scrolls to the Room key (07:07's fix), so the panel's own Send button is out of view. But the card has "Send to Owlbear". A real tap on it sent the scene on all three phones ("Saved scene — …", one scene uploaded), and a toast says "Scene saved to Owlbear". So Generate then Send works on a phone in two taps.
• What was wrong: on the iPhone 13 and the Galaxy S9+ the popover's stage is about 210px tall, and the story card (166px) covered the whole ship (100%). The Pixel 7 was 0%.
• Fix (src/style.css): on a screen under 500px tall, the card drops its two lines of story. The Room key under the map has all of it. Local build: iPhone 13 popover 29% hidden, Galaxy S9+ 71%, Pixel 7 0%. It can't get to 0 there: the deck tabs, the ship and a name-and-buttons card need more than 210px. Portrait phones on the web demo are taller than 500px and unchanged. Landscape phones on the web demo now get the shorter card too; their 137px stage was covered before as well, and the story is in the Room key.
• tsc and all 45 tests pass. Deployed. Live: iPhone 13 popover 26% hidden, Galaxy S9+ 73%, Pixel 7 0%, and the card's Send to Owlbear sent the scene on all three. obr-harness ok: the send works. Smoke: 41/41 pages, 41/41 links. Status: the same 5 failures, all today's derelict before 11:07.
• Finished 10:18

11:07: the daily check, on the first day with the grid in the PNG name

• 11:08 status: the same 5 failures, today's derelict not out and no job running. This session's cron is what runs the day, so I ran it by hand as the check says. It built Derelict — ISV Petrel (shuttle, one deck), deployed and posted to Bluesky. Status after: all 29 clear.
• The first -WxH day checks out live. The PNG is derelict-isv-petrel-main-deck-24x16.png, it loads (200, image/png), and it is 2400 by 1600 px, which is 24 by 16 at 100 px per square, the same as the .dd2vtt (map_size 24 by 16, 100 per grid). The page's link and image use that name, and its line says Owlbear reads the grid from the name. The Bluesky post's map alt text says "24x16 squares", so post-daily found the renamed file.
• itch lifetime: Bulkhead 26 views (24 on the 30th), 1 download, 0 purchases. The free pack is at 6 views and pack 2 at 2, both unchanged. The Bluesky account has 4 followers. Today's post has 0 likes so far, and every day since the 23rd has had 1 or 2.
• Owlbear side: the Rogue Store shows Bulkhead at 1.17.2, the live manifest's version, with "1 Download". PR #174 on the official store is open, with no activity since 24 Sep (expected around February).
• Finished 11:11

12:08: who lands on the Owlbear page, and do they install

• Search: for "import dd2vtt into Owlbear Rodeo" and "owlbear rodeo dd2vtt walls dynamic fog spaceship map", our page isn't in the results. Eppinguin's Scene Importer, texttotabletop and our own dev.to article are. So search doesn't explain the page's visits, and 7 of its 8 RUM loads still have no referrer.
• Counted now: the Copy button for the manifest URL sends /e/obr-copy, and the Rogue Store link sends /e/obr-rogue. Both work the way the view ping does, only on the live hostname. Live check in Playwright with /e/ intercepted, so my clicks weren't counted: the view, obr-copy and obr-rogue pings all went out, and the button still copies the manifest URL. events.sh lists them with the other events, so the Owlbear path reads as page views, then obr-copy, then obr-view (panel opens), then obr-send.
• Found on the way: the task 1 switch broke again. Patch 2's sitemap hunk failed because the daily run rewrote the sitemap's dates this morning, and it does that every day. That line is now a README step that inserts it next to a page's URL, not at a line number. Checked on a clean worktree with today's tree: all four patches and the sitemap step apply.
• Deployed. Smoke: 42/42 pages (today's derelict is the new one), 42/42 links.
• Finished 12:11

13:09: can players walk into every room the generator makes

• A temporary vitest file walked every deck of 200 generated ships (shuttle, corvette, freighter, station × intact, derelict × seeds 1 to 25; 300 decks) from room to room. It crossed a wall only at a door, airlock or hatch, never a window or a partition.
• Intact: all 100 ships, every deck is one connected walk.
• Derelict: 24 of 150 decks have rooms the party can't walk to from the rest. A hull hole has eaten the doorway, or cut the corridor or the room in two (shuttle seed 3: the Bridge; corvette seed 18: Crew quarters, Bridge and Cargo hold).
• Every one of those cut-off parts opens onto the hole that cut it off. So no room is sealed. They're reached in suits across the breach, which is what a derelict's holes are for. No generator change.
• Added a guard test to test/model.test.ts: "no room is sealed: every room is walked to, or opens on a breach". It covers 4 sizes × 2 moods × 12 seeds, about 6 s, and checks that an intact deck is one walk. Proof it can fail: in a throwaway worktree with the generator's doors stripped, it fails naming "shuttle intact 1 Main deck: Cargo hold". Worktree removed and pruned.
• Temporary test file deleted. No src change, so nothing to deploy.
• LEARNED: "A derelict's holes can cut rooms off, but never seal one".
• tsc clean; vitest 46 of 46 passed (172 s).
• Finished 13:14

14:07: a hull hole is open in the VTT walls, as it is in the picture

• Confirmed the gap. The PNG and PDF tear out the wall at a hull hole (breachShapes erases it), but the .dd2vtt line_of_sight and the Owlbear send came from wallSegments. That counts a hole's edge as hull. So the rooms a hole cut off were walled shut in Foundry, and the hole was a wall to sight in Owlbear Dynamic Fog.
• Fix: new vttWalls(d) in src/model.ts. It is wallSegments without any unit edge that has a breach cell on one side, with the runs re-merged. buildUVTT uses it, so the .dd2vtt, the fleet zip and the Owlbear send all get it. The drawing is unchanged.
• Test "in the VTT walls, a token reaches every room, across a hole if it must": 4 sizes × 2 moods × 12 seeds. A token goes anywhere no wall or window stops it. It also checks that intact decks' walls equal wallSegments exactly. With the old walls put back in a throwaway worktree, it fails on "shuttle derelict 3 Main deck: Bridge". Worktree removed.
• In a real browser on the Vite dev server, buildUVTT gave these walls: - shuttle derelict 3: 20 walls (62 squares), against 32 (86) drawn. - corvette derelict 18: 37 (138) against 48 (163). - intact freighter 3: 44 (200), the same as drawn. - The image was embedded each time.
• tsc clean, vitest 47 of 47, build ok. Deployed. status all 29 clear, smoke 42/42 pages and 42/42 links. Harness ok: "Saved scene … 35 walls, 6 doors/windows, 2 lights", exit 0. Harness exports: "exports free, marked, no upsell".
• Finished 14:15

15:07: does Foundry's importer read our .dd2vtt the way the picture means it

• Read ddimport.js from moo-man/FVTT-DD-Import (module.json v6.1.1, raw.githubusercontent). What Foundry makes of each field we write: - line_of_sight: plain walls that block movement, sight and light. They are dropped only if both ends are outside map_size. Ours sit inside the padded image. The hole edges are now left out (14:0x), so a token crosses a hole. - portals with closed true (door, airlock, hatch): a door (door: 1) with normal sight and light, so a closed door hides the room behind it. - portals with closed false (our windows): not a door (door: 0), so it blocks movement. Sight and light are PROXIMITY with a threshold of 10. That is a window: you can't walk through, you can see through. This is Dungeondraft's convention. The importer's "openable windows" setting turns them into doors. - lights: colour is "#" + color.substring(2). Ours is ff + rrggbb ("ffffe08a"), so it arrives as "#ffe08a". dim = range × the system's grid distance, bright = half. Our range is in squares, the same as the picture's circle (render.ts draws l.range × the scale). A range-3 light is 3 squares of dim light. - objects_line_of_sight: only imported when the importer's object-walls option is on. - environment: copied, not used for darkness.
• The importer also adds a connecting wall wherever one of our 2-point segments ends exactly where another starts. With our merged runs that is a zero-length wall at a joint. In Foundry it is either created (harmless) or caught by the importer's try/catch (a console line). No change: I can't test that in Foundry from here.
• Verdict: Foundry reads our .dd2vtt as the picture means it. No fix.
• Owlbear: a window is sent as a Dynamic Fog door with open: true, so sight passes. But Owlbear's search snippets (docs.owlbear.rodeo Dynamic Fog and Wall pages) say Dynamic Fog stops tokens at walls ("blocking … stop lights (or anything a light is attached to)"). If an open door doesn't stop a token, a player can walk a vision token out through a bridge window into space. Couldn't confirm it: - docs.owlbear.rodeo answers 403 to fetch. - dynamic-fog.owlbear.rodeo is behind a bot challenge, which I didn't get round. - The web archive has no copy. - It goes on the post-task-1 real-room batch. Don't change the send on a guess. The other choice, a closed door, would hide what's out the window.
• Finished 15:09

16:07: what Owlbear's Dynamic Fog does with our windows, from its source

• owlbear-rodeo/dynamic-fog is public on GitHub. I read src/background: WallActor, WallHelpers, DoorActor, types/Door. - Every FOG-layer drawing becomes Wall items (buildWall, no options). - Each door with open: true is cut out of the walls with a path Difference (WallHelpers.drawingToPolylines). So an open door is no wall at all, for sight and movement alike. - The Door type is just {open, start, end}. There is no window, no one-way and no sight-only option. - The SDK's WallBuilder defaults _blocking = true (sdk 3.1.0 in node_modules). Owlbear's docs snippet: blocking "stop[s] lights (or anything a light is attached to)". So a token with vision is stopped by walls and walks through open doors.
• So the 15:0x question is answered without a real room. We sent every window as an open door, and generated bridges put a window on about 80% of their fore wall. In Owlbear a player's token could walk off the bridge into space through the gap.
• Fix: opensInFog(d, k) in src/model.ts, used by src/obr.ts. - A window on the hull goes as a closed Dynamic Fog door, still named "Window". It blocks the token, and the GM can open it with the door tool. - A window between two rooms stays open, for the sight line. - Doors, airlocks and hatches stay closed, as before. - The .dd2vtt is unchanged: Foundry's importer already makes a window a wall that blocks movement (15:0x). - What is lost: looking out of a closed hull window into space, where the map has nothing to see.
• Test "in Owlbear, a hull window is closed and a window between rooms is open": every window on 24 generated intact ships is on the hull and closed, plus a hand-made inner window that stays open.
• Harness on a local build, with a temporary copy that lists the door states: - The example ship: 6 doors, all closed (it has no windows). - Generated corvette seed 3 ("FTV Corvid"): "Door:closed Window:closed ×4 …", 47 walls, 14 doors/windows, 7 lights. Before the fix those 4 windows were open. Temporary copy deleted.
• tsc clean, vitest 48 of 48, build ok. Deployed. status all 29 clear, smoke 42/42 pages and 42/42 links. Harness: ok (Saved scene, exit 0), exports (free, marked, no upsell), player (send disabled). The switch patches 1 to 4 apply on top of this change (worktree).
• Finished 16:15

17:07: the rest of the Owlbear send against Dynamic Fog's source, and today's use so far

• Dynamic Fog source, against src/obr.ts: - WallReactor takes every drawing (Shape, Path, Curve, Line) on the FOG layer. Ours are Paths on FOG. Good. - WallHelpers strokes each one at its own strokeWidth: walls 2px, door paths 5px. - DoorActor cuts an open door out of the walls with the door's segment stroked at strokeWidth + 20 (25px for ours), with butt ends. That clears our 5px door path and the 2px walls along it. At the door's ends, a wall at right angles keeps about 1px, so it stays closed. - An open door does open, and a closed door is a wall made from its own path. - LightReactor takes any item with the rodeo.owlbear.dynamic-fog/light metadata, whatever the layer. Ours are circles on the MAP layer. LightActor copies attenuationRadius, sourceRadius, falloff, the angles and lightType onto an attached Light item. SECONDARY is the type for room lights, which don't reveal fog for a player on their own. - Nothing wrong. No change.
• Today's use, 00:00 to 15Z (events.sh, then a temporary script by hour, minute and second, deleted afterwards): - 74 Generates and 14 page views. - 58 of the Generates came from one Android Firefox phone in the Netherlands that arrived from bananafest-destiny.com (the zoo). Loaded at 14:04:20, first Generate at 14:04:30, then about 55 presses between 14:05:58 and 14:06:15, about 3 a second. - Every way into generateShip is a click (btnGenerate, introGenerate, introDerelict, briefAgain), so it's a person mashing "Another one", not a loop. Nothing saved. - The rest: - Finland, desktop Firefox, from reddit, 6 Generates at 10Z. - US, desktop Firefox, 7 Generates at 03Z (2 derelict). - A US iPhone opened the Owlbear page, then the demo, with 1 Generate. - Indonesia, Android, from the Reddit app, 1 Generate. - Germany, Android, from the zoo, 1 Generate. - Brazil, Mac Safari, opened the panel inside Owlbear at 15Z (obr-view, obr-from www.owlbear.rodeo). No send yet.
• Finished 17:09

18:07: does a hull hole read as a way in, in the PNG and on a phone

• itch: still 0 of 3 pages in its own search (itch-indexed.mjs). The Brazil Owlbear panel at 15Z hasn't sent anything since (events.sh from 15Z: no events, 1 obr-view).
• I walked derelicts at shuttle and corvette size, seeds 1 to 12 (temporary script on the dev server, deleted afterwards). 8 decks have a room you can only reach across a hole: - Shuttle: 3 Bridge, 5 Drive, 6 Armoury, 10 Drive, 12 Drive. - Corvette: 6 Engineering, 9 Galley, 11 Bridge.
• I rendered each as the PNG export draws it, at 70 and 24 px a square, and opened shuttle 3, corvette 9 and corvette 11: - Every hole is a torn gap with space showing through, a ragged white edge, bent plating and debris on the floor beside it. None of them looks like a wall, a pillar or a dark room. - The cut-off room plainly runs into the hole. Corvette 9's Galley has no door, but the hole straddles its wall with the corridor, so the way in is obvious. Corvette 11's corridor ends in a door that opens onto the hole, with the Bridge on the other side. - At 24 px a square, and in the editor at phone width (390 px, shuttle 3), it still reads as a hole.
• No change to the drawing or the generator. The breach drawing (breachShapes, from an earlier fix for holes that looked like pillars) already does this job.
• Finished 18:09

19:07: a derelict room reached only through a hole says so in its key

• model.ts: new cutOffRooms(d). It walks the deck through doors, airlocks and hatches but not windows, and returns every room with no square on the main walk. While there, I moved isHullEdge's doc comment back above isHullEdge; it had ended up above opensInFog this morning.
• generate.ts: after mend(), each cut-off room gets one key line: "Way in: only across the breach. The way that led here went with the hull, so getting in means crossing open space." No dice are rolled, so every seed still rolls the same ship and only those rooms' notes change.
• The first test run failed one existing test, "never repeats a room note". Two cut-off rooms on one ship had the same line, and that test is right that it reads as copy-paste. Now the second room's line points back to the first instead ("Way in: only across the breach, like the Bridge (1)."), so no line is said twice.
• New test: on every intact ship no room is cut off, and on every derelict a room has a "Way in:" line exactly when it is cut off (4 sizes, both moods, seeds 1 to 12).
• tsc ok. vitest 49 of 49 (200 s). Build ok.
• On the dev server, shuttle derelict 3's Bridge ends with the Way in line in the Room key.
• Deployed. The live bundle has the line. status: the first run had 1 of 29 failing and I didn't capture which. A rerun straight after was all 29 clear, so it was transient. smoke: 42 of 42 pages and 42 of 42 links.
• Switch patches: on a worktree with these files, all four apply in order. My first check ran --check on each patch alone against HEAD and reported 2 and 3 failing; that was the method, because 2 and 3 build on 1.
• The one-shot PDF doesn't read "Way in:" lines (adventure.ts only sorts Hazard, Log, Salvage and Trail), so it is unchanged. The daily picks the line up from tomorrow if its ship has a cut-off room.
• Finished 19:19

20:07: the one-shot's GM page names the rooms reached only across a hole

• adventure.ts: lines() now also collects the rooms whose key says "Way in:". Below How it runs on the GM page, one paragraph: "Cut off: <rooms> is/are reached only across the breach, through open space. Getting in means suits and a line across the gap. Count the crossing as making noise: roll on the table." When a trail room is one of them, it adds "The trail runs through it, so they will have to cross."
• New test, derelicts of 4 sizes, seeds 1 to 12: the PDF says "Cut off:" exactly when some room in the key has a Way in line.
• tsc ok. vitest 50 of 50 (220 s). Build ok.
• Rendered page 1 of two one-shots and read them: - Shuttle 3 (FTV Corvid): "Cut off: Bridge (1)". The threat's "Pull the nav core" and the nav core salvage are both on that Bridge, so the crossing now sits in the plan where it matters. - Corvette 9 (ISV Umber Verge): "Cut off: Galley (5)".
• Deployed. status all 29 clear. Switch patches 1 to 4 apply in order on a worktree.
• The free demo doesn't export the one-shot until task 1, so nothing a visitor sees has changed yet. It is in the full build from the next upload.
• Finished 20:12
• (then) The 1.18 zip on /press/ that task 1 uploads was from 30 Sep, so it was missing today's fixes: hull holes in the VTT walls, hull windows closed in Owlbear, and the Way in and Cut off lines. Rebuilt it in place with scripts/release.mjs 1.18, as on 30 Sep. The paid check is all ok, including the adventure PDF. The zip's bulkhead.html contains both new lines. I bumped the two task links to ?v=1001, deployed, and the live zip at that URL is byte for byte the local file. status all 29 clear.
• Finished 20:14

21:07: Eight Derelicts gets today's fixes before anyone buys it

• Every one of the eight pack ships has hull holes (6 to 19 holed squares a deck), so all 12 .dd2vtt files had the old walls.
• Kept the ships as they were. I loaded each ship file on a paid dev server (it round-trips through deserialize and serialize unchanged) and gave cutOffRooms' rooms their Way in line, chained as the generator does. Two ships have one: - MSV Coldharbour: lower-deck Cargo hold. - FTV Willet: lower-deck Lab, which is on the trail.
• Wrote those two ship files back, then exported every ship's .dd2vtt, key and adventure again. All file names matched the old ones (a temporary script in app/scripts, deleted afterwards). I backed up the 30 Sep folders in the scratchpad first.
• Old against new, per .dd2vtt: the image, the portals and the lights are byte for byte the same, and only the walls changed. Each deck lost 3 to 15 wall segments, 6 to 23 squares of wall in all, which is exactly the hole edges. Gossamer, for example, went from 41 walls covering 152 squares to 35 covering 136.
• Keys: only Coldharbour's and Willet's changed, one Way in line each. The adventures: those two gained their Cut off paragraph, and Willet's adds "The trail runs through it, so they will have to cross." The other six PDFs are the same size as before.
• Re-zipped with the same 49-file list (diffed against the old zip) and unzip -t clean. 5.15 MB.
• Bumped ?v=0930 to 1001 on both /press/ links and deployed. - The first cmp of the live pack straight after the deploy differed. A minute later, the ?v=1001 URL, a fresh query and the bare URL all had the local file's md5, so it was propagation. - The 1.18 zip matches too. status all 29 clear.
• Not fixed here: the other things that shipped .dd2vtt files before today, listed in Next.
• Finished 21:10

22:08: the daily archive's .dd2vtt walls match their pictures

• Rebuilt every /daily/ day's .dd2vtt from its ship.bulkhead.json with today's src, in the browser, and compared it field by field with the shipped file. Format, resolution, portals, lights, objects and environment matched on all 19 files. I kept the old image byte for byte and replaced only the walls.
• 12 files on 8 days (24 Sep to 1 Oct) changed. In each one the new walls are the old ones with stretches removed and none added. vttWalls only cuts hull-hole edges, so the holes are now open in the VTT as they are in the PNG. 19 to 23 Sep had no hole-cell walls (same walls). 16 to 18 Sep have no ship JSON, but hull holes only arrived on 23 Sep.
• The 21 to 27 Sep weekly zip: its copies of the six affected files (24 to 27 Sep) matched the old daily files exactly, so I swapped in the fixed ones in place. Still 46 files, zip test clean, and latest.json kb went from 3789 to 3800 (it still shows 3.7 MB). The 16 to 20 Sep zip predates holes.
• The 11 /maps/ pages: rebuilt the same way, and all 17 .dd2vtt files have the same walls. Nothing to change.
• Not done: the Foundry module zip. Its scenes include five of the affected daily derelicts (thumbs for Osprey Verge, the two Corvid decks, Candlemas, Zephyr and Sparrowhawk), but foundry-module.mjs builds them its own way. That's the next phase.
• Deployed. A cmp of two fixed files, the zip and latest.json against live matched. Status: all 29 clear. Smoke: 42/42 pages and 42/42 links. No page HTML changed, so the switch patches are untouched.
• Finished 22:13

23:08: the Foundry module's derelict scenes get the open hole walls

• I wrote this plan entry late: I'd already read the script and started the edit. The rule is plan first; noted so the log stays honest.
• foundry-module.mjs now rebuilds every daily scene's walls from its .dd2vtt and replaces them when they differ. Nothing else on the scene changes. It counts that as a change, so the Sunday run bumps the version and Foundry offers the update.
• Rebuilt as 1.4.0, with 42 scenes (5 new: 29 Sep to 1 Oct) and 27 GM keys. It replaced walls on exactly 7 scenes: Osprey Verge, Corvid upper and lower, Candlemas hub and ring, Zephyr and Sparrowhawk, the days from 24 to 28 Sep with holes. The other 30 rebuilt identically. In the extracted pack, Sparrowhawk has 112 walls and its .dd2vtt has 112 segments, with 13 doors and 1 light in both.
• Foundry v14 strict validation on the public demo: "all 42 scenes and 27 GM keys of 1.4.0 pass strict validation on Foundry 14.365". The /foundry/ caveat now says version 1.4.0, 42 of them. The pages that give the scene count (foundry, guide, free battlemaps, press itch copy, sitemap image title) say 42.
• Applied the switch patches 1 to 4 in order to this tree: all OK. No key-shaped strings in switch/.
• Deployed. Live module.json is 1.4.0, and the zip and module.json match by cmp. Status: all 29 clear. Smoke: 42/42 pages and 42/42 links.
• That finishes the old-walls list: the /daily/ archive, the weekly zip, the /maps/ pages (no change needed) and the Foundry module. One copy left outside our reach: the itch free packs, if they hold derelicts. That waits for a re-upload after task 1.
• Checked the itch free packs too. The 17 .dd2vtt files in both free pack zips have the same walls as the /maps/ copies, which match today's export, and store/ holds the same zips as public/packs/. Nothing for the boss to re-upload, assuming what is on itch came from store/ (I can't see itch's files).
• Finished 23:11