Spelunking · prototype timeline ▶ latest, live◆ shape map

Can one taming engagement be as easy to start and as hard to master as Slay the Spire, as strategic and intriguing as Sonny, and as free as Noita's wand building, without luck and without killing?

• Full information and no luck still leave enough depth: the variety comes from scouting, the kit and procedurally generated animals, not from a draw.
• Moves with several effects, on a shared visible state (the team, the animal, the cavern), make combinations nobody wrote as pairs, and stay readable turn by turn.
• One engagement makes one game: scouting as team setup plus an automatic run in the simulation doesn't feel like a second, lesser game.
• Routes into a tame from different pillars keep bait from becoming a grind, even with a food chain of two or more tiers.
• Watchable replays let the user check that the simulator and its bot test the right thing.

• constraintNo luck in the engagement: every encounter must be solvable by construction.
• constraintTurn-based only; real-time engagements are an idea for meta-progression, not built.
• cutScouting: the next component; the food chain and the colony are content and balancing on the b4 system (D177; D188 in p12).
• cutLevelling, team size and slots: knobs or left out until the taming toy needs them.
• cutThe market part of stage 4 from p12: parked.

→ Not concluded. Next: pressure downward in the gauge model (actions with side effects, animal moves that lower its own needles) and the lines tuned; then a toy of the taming alone, played by hand.

• D196 The taming gauge's properties are share, default and inertia (user; Claude's merge, confirmed). Decay and volatility merged: "decay and volatility are very similar: they describe the efficiency of the Beastmaster's actions, just slightly differently... these nuances do not fit well into the 'simple approximation of reality' concept." Inertia is how heavy a motivation's needle is: an action moves it by 1/inertia, and it drifts back to its default by 5/inertia points a turn; shown to the player as calm ↔ jumpy. Also (user): small animals start with lower comfort, large ones with higher. The model, every other cell a draft: concepts/taming/gauge-model.html (motivations hunger, comfort, curiosity; dimensions size, agility, intelligence, diet).
• D195 Fight or flight depends on the team (user): "the animal's attack or flee reaction can depend on the team's strength. Stronger animals must retreat later if an animal attacks but also scare animals away." Against a stronger team the animal is more likely to flee, against a weaker one to attack; strong pets hold out longer when attacked, but scare animals away: team strength is a trade-off chosen before the taming. Open: team strength as the sum, the strongest pet, or the pets near the animal. Refines D194. Text: concepts/shape-exploration/build-principles.md → Pillars (trait space).
• D194 All models are wrong, but some are useful (user): "We can not model reality, but we can create a model that is interesting, intuitive, creates immersion, yet not overly complicated. So... I do not care at a micro-level. If the feature is interesting enough, the complexity comes from the permutation of a few systems, that's intuitive... I'm good." Applied: "Stats could explain what the animal does when scared, and that's one less dimension, always good." "When scared" is no longer a behaviour axis: an animal fights (strength leads), flees (agility leads) or hides (neither; freezing is hiding in place), the generator giving one stat a clear lead. Refines D193. Text: concepts/shape-exploration/build-principles.md → All models are wrong, Pillars (trait space).
• D193 Animals live in a trait space, not a list of families (user: "can we make this a space, instead of a list? like intelligence/agility/strength dimensions, social/solitary axis, diet, survival strategy"; on Claude's split: "yes, and make sure you record 1 and 2, this is a good categorization"). 1. Behaviour axes, discrete, each value a learnable rule: diet (plants, anything, meat), when scared (flee, hide, freeze, fight), social (solitary, pair, group). 2. Stats, numbers within the rules: size and strength, agility, intelligence, nerve (shy to curious). Values are a first set; families name common corners ("herd prey" is a social animal that flees). Direction: traits add up to behaviour, stats and, once tamed, pet skills; "how these translate into pet skills (and animal behavior) is still TBD, but the direction is great." Refines D186's families. Text: concepts/shape-exploration/build-principles.md → Pillars (trait space).
• D187 The taming gauge (user, with Claude's proposals the user OK'd): "this 0–100% IS the taming gauge. There are 3 zones in it: flee/attack, neutral, friendly." Intuitive "for even small kids, nothing you do not know already". "Motivations add up to the 100%, but each have their own zones and needle temperament, and decay. Pet action and consumable primary, secondary effects act on all these individually, and that makes a fun game to play." Each animal draws its own zones (snail picked up; a flea: "bottom of food chain does not necessarily mean easy capture"; bear); a filled need ignores more of the same; startled/territorial "is just scared, but for prey/predator". To test, not settled: the animal acts, its moves derived from its motivations ("we can check if this is fun/simple enough"). Idea, not decided: animal state shown through basic postures, "a MAJOR effort for the value it brings". Text: concepts/shape-exploration/build-principles.md → Pillars (the taming gauge).
• D186 How a new animal is learned (user; Claude's proposal, amended): more abstraction, less realism: "allow observation to fill everything, even if it did not happen in front of the scout, and engagements just put numbers (thresholds, cooldowns) on the skills. It's okay, and even fun, to leave gaps on the card when there was not enough time to observe everything; then that gap will be filled during the first engagement." Kept from the proposal ("I liked everything else"): lines shown, not told, with numbers; blanks visible; a failure says why. Animals come in families that share rules (procedural, "this is not a scripted game"); late game, an animal can bend its family's rules. Rejected: the prey taming teaches the predator ("a predator–prey engagement is not the same as a taming one"). Text: concepts/shape-exploration/build-principles.md → Pillars (the animal's card).
• D185 The animal's card and repeated attempts, without an all-tiers rule (user): D184 as written, except that attempts cost consumables some of which come from earlier tiers, not obligatorily from all of them. User: "Costs from all tiers: I've never said this, and I do not like these absolute rules. It makes the design rigid. Yes, costs come from some earlier tier, but not obligatory 'all' here." Text: concepts/shape-exploration/build-principles.md → Pillars (the animal's card).
• D184 The animal's card and repeated attempts (user): each animal has a card; scouting fills it by observation, a taming party brings back knowledge "not from observation, but engagement, completing the card of the animal". "Players will attempt taming a new animal several times; attempts should cost consumables (from all tiers), but not in a punitive way." "Failed attempts reveal information that simple scouting does not. That's a decision." Text: concepts/shape-exploration/build-principles.md → Pillars (the animal's card).
• D183 Routes into a tame come from different pillars (user; Claude's per-pillar cut, confirmed: "a pretty good shape"). Taming wild bait "will be a major pain point in the game, especially if the food chain has 2+ tiers. We got to give several, very different alternatives." Skipping bait "should be equally hard, but different shape", and "different shape means different pillar". Cultivation: bait from same-tier colonies; recreating the prey's environment in a colony stays only if really simple for both the player and the build, or it is dropped. Prospecting: flora that acts on the animal, and knowledge. The taming itself: team skills; driving prey is "just one (pretty good) skill to have in a team"; making the animal accept something else may be several skills ("hunger", "smells like": first ideas, not decisions). The gauges are where the routes meet; the gauge set is not decided. Text: concepts/shape-exploration/build-principles.md → Pillars.
• D182 Taming is the only engagement (user; Claude's restatement, confirmed): scouting as a second engagement "makes it two games, not one"; "scouts need only the team setup active, and the scout itself plays out in the simulation, automatically." The kit is built before the taming: "player arrives into the engagement with knowledge, and failure is just failure, not death: the animal got away, some bait was consumed." Refines D179 (no longer "taming and the breach") and D177's order (3 = scouting as setup + automatic run). Text: concepts/shape-exploration/build-principles.md → Pillars; idea-taming-and-breach.md → The breach.
• D181 The engagement is turn-based and truly strategic, never under time pressure (user): "all the cards are on the table, visible cooldowns (WoW style), turn-based, and environmental effects are also." The player acts every turn: Super Auto Pets also makes pets' effects on each other the primary strategy, but "the auto-battle nature attracted only a narrow niche, because it's like chess: you've got to anticipate the enemy and play the game ahead, in your head, from start to end. Too hard." An idea, not decided: real-time engagements unlocked in meta-progression. Refines D179. Text: concepts/shape-exploration/build-principles.md → Pillars.
• D180 The engagement (taming and the breach) is the core gameplay, the most critical element of the game (user): "We got to build something that is as easy to start and as hard to master as Slay the Spire, and as strategic and intriguing as Sonny, and as free as Noita's wand building." It is designed as its own piece, not settled as one open question. Text: concepts/shape-exploration/build-principles.md → Pillars.
• D179 Taming and the breach play like a deck-builder's combat, with simpler UX (user): "there's no shuffle and deck, but cooldown, so players do not have to memorize when a card will be back in play, and there's no luck, just strategy, just like in Sonny. And enemies telegraph their moves, sometimes multiple moves ahead. And moves have multiple effects, and that gives the complexity of the engagement." Within D171: the opponent is the animal being tamed, not an enemy to kill. Text: concepts/shape-exploration/build-principles.md → Pillars (the encounter); pattern in idea-taming-and-breach.md.
• D178 Every simulated run can be watched (user OK'd Claude's proposal; the user's concern: "I can not watch it to verify you are indeed testing the right thing"). The simulator and the view share one rules core; every run replays from its seed and the bot's actions; the report links each number to its runs; the bot shows its intent before acting; batches only after the bot has been watched playing sensibly. Text: concepts/shape-exploration/build-principles.md → The tool → Every run can be watched.
• D177 One component at a time (user): no end-to-end simulation of the lifecycle first; "there's no practical chance that you will pull this off if we do not flesh out the components first." Each component gets its own question, real content and isolated runs with stubbed neighbours, and is wired to the others only once it holds. Order: taming, the food chain, the breach as scouting, the colony. Text: concepts/shape-exploration/build-principles.md → Building it: one component at a time.

Which game goes around the toy, matched to an audience that will be thrilled by it?

• Candidate shapes and reference games can be compared on one motivation map, so the shape is placed instead of picked by taste. Held: the pillars were placed on the map around the audience (v9.4). post-hoc
• Successful small indies space their core and supporting loops apart, a swing between pillars that lets the player rest from one in the other. Held as likely: six of nine reference games show it; Stacklands and SUMMERHOUSE don't (findings). post-hoc
• The factors the audience decides stay open until the audience is chosen. Held: the audience mix came first (v9.3), the pillars after it (v9.4). post-hoc
• The three pillars weigh the same for this audience. Nothing has been played yet. post-hoc
• The lifecycle's rules read as natural and need no text: five stages, three decisions, the rest on autopilot. post-hoc

• constraintEvery position on the map is a judgement (the shapes', the reference games', the pillars'), not measured data. The user checked the games they had played.
• cutThe market part of stage 4 (competition and success rate per market) is not done; it is the next step.
• cutStage 5, loop times and complexity, is parked until the end, as the method says.
• cutNothing playable: the first prototype of the pillars comes after this.

→ Not concluded: reopened on 2026-10-04 for the game's shape. So far the phase went from "no clue what mechanics this game needs" to three pillars (The Unseen, Prospecting, Cultivation) placed around the audience's motivations, with every interaction an action, a condition and an outcome, and a lifecycle simple enough to code and natural enough to read. Complexity now comes from depth and lore, not from uninformed decisions. Decisions D173–D176, then D188 (an incremental idle game), D189 (climb differently, not faster), D190 (three loops, beastmasters) and D191 (a passive Simulation pillar). Next: more work on the shape, alongside p13.

• D191 A passive Simulation pillar (user): the three active loops sit in a dense zone ("I like this a lot: all our active loops are in a dense zone"); "add a passive Simulation pillar somewhere between discovery-design-story, and it will balance the pillars around the audience, as expected." Team management is Strategy, not Design: "design is 'building for aesthetics', that's why it is in that corner." Discovery needs no loop of its own: "the world's idle functions and the animal cards cover that perfectly." Text: concepts/shape-exploration/build-principles.md → Gameplay loops; map.html (v9.8).
• D190 Three gameplay loops, and beastmasters (user). "I do not call passive things a loop. Without direct control, they are spectacle and lore." The loops: engagement, core, "feels like a card battle" (learning or taming, and testing teams against the simulation: "this actually falls under the engagement loop"); pet management, core, "feels like a management game" (teams, pet levelling, sending them on missions); resource management, support, "feels like idle farming" (checking what is low and pushing the idle collection toward it: better forager teams, splitting them to the right biomes, more colonies in the right biomes). Pioneers are replaced: scouts open the Unseen, and the taming team are beastmasters ("lock in beastmaster"; "tamer is such a lame name"). Open: whether pets level up by using their skills. Text: concepts/shape-exploration/build-principles.md → Gameplay loops; lifecycle.html, map.html.
• D189 Long-term progression: climb differently, not faster (user; Claude's wording, confirmed). On prestige (resetting for multipliers that make the next climb faster): "Does Slay the Spire allow you to climb faster? No. It allows you to climb differently, with harder / more complex mechanics that require more mastery." Progress opens new, harder, more complex challenges the player chooses when to face; quantity piles up on its own, complexity enters only when the player goes looking for it. Refines D188 (no prestige). Text: concepts/shape-exploration/build-principles.md → Game shape.
• D188 The game shape: an incremental idle game (user): "it is an incremental idle game, where you come in, move the needle, reap the rewards: resources, lore, unlocks, and play the taming game." "Each session can be 1 or more runs, and a run can be anything that pushes the needle: levelling up pets, changing and testing teams, reviewing new info on scouted animals, deciding on what to tame with what strategy." While away, "colonies (auto-harvest), foragers (caverns foraging) and scouts (intel gathering) keep working". Candidate A (the short run that keeps only knowledge) is dropped; prestige is not decided. The food chain and the colony are content and balancing on the b4 system, not new components ("the colony: same as the food chain, just auto-harvests"), which refines D177's order. Text: concepts/shape-exploration/build-principles.md → Game shape.
• D176 The lifecycle (user): terrain, flora and fauna go unseen → wild → studied → foraged (fauna: tamed) → cultivated. Pioneers open the Unseen and tame up the food chain (a creature only once its natural diet is foraged; a predator once enough prey is tamed, exponentially more for a deep chain); taming the top predator turns the area into Caverns; the foragers build a colony there, which harvests itself. Only those decisions are named; the rest runs on autopilot. "Complexity is now depth and lore, and not confusing uninformed decisions." Text: build-principles.md → How an area moves; concepts/shape-exploration/lifecycle.html.
• D175 A taming game (user): "you find procgen living things (from slime mold to Arrakis sand worm), raise them, and send them to excursions"; the theme is ecology, nothing the player uses is technology; grinding is the difficulty setting. Two pet teams: pioneers and foragers. Colonies are claimed in place in every biome, never carried home. Refines D171. Text: build-principles.md → Direction and Ground.
• D174 Three equal-weight pillars (user), placed on the shape map around the audience and far enough apart to rest from one another: P1 The Unseen (Strategy, Power, Challenge), P2 Prospecting (Discovery, Story, the most kinetic), P3 Cultivation (the simulation). "Not all pillars will be identical, but they should weigh the same." Text: concepts/shape-exploration/build-principles.md → Pillars.
• D173 This game's audience (user): Discovery 30%, Strategy 30%, Power 20%, Story 10%, Challenge 10% of Quantic Foundry's motivations; a first version had Strategy at 20%. On the shape map as the green diamond. Text: concepts/shape-exploration/README.md.

Does exploring as a spider bot, mining on the way, and building rails node by node make a loop you want to repeat into the next cavern?

• b3's probe, pull, pack, light and bugs work unchanged on the new terrain once it's in b3's tile
• D078's lattice (3 cells apart, Gabriel, rock ×5, bend 15, overlap +100%, crossing 100) gives
• The player can't trap themselves (user: "we will have to adjust to make sure"): from wherever you

• cutThe shield timer (D077), walls, gates and buildables (small, big, titan): later (user).
• cutRendering stays b3's Canvas2D; it moves to PixiJS later.

→ The Question (does a scan-mine-build rail loop pull you into the next cavern?) was overtaken by the incremental turn (b4.3) and then by the ecosystem (b4.10 onwards: moss, vines, fire, ash, lizards, worms, beasts, gas, moths, predators, slime). What p11 found instead, in the user's words: "It is possible to build a very enjoyable and engaging cave ecosystem idle game, that both feels very involved, but at the same time, does not really need the player to run. It is possible to engineer it to make time spent rewarding - e.g. taming a lot of moths and pushing the game out of balance temporarily for a big fat resource reward, but the system can be designed to be resilient, and restore balance after the push."

• D192 Moth hatching capped (user: "moths only spawn near nodes if there's less than 2 of them there, and only spawns 1"; "keep the release no"): every swarm.mothTicks a built node with gas hatches one moth only while fewer than swarm.mothMax 2 moths are within swarm.crowd 32 px of it. Against b4.77's runaway (3,000+ moths). b4.77 refrozen under the same number. Refines D161.
• D164 The game is an intelligent idle game (user: "an intelligent, complex, systematically beautiful cookie clicker"; idle retention; Vampire Survivors' grind-unlock in n dimensions; "NOT […] a puzzle game" like Terra Nil). Rules: unlock moments explain what you did and where the resource came from (b4's ledger theatrics weren't enough); the level-up is pushing through clearly understood points of no return (seeding slime; "all the regenerating ore in the world to just spam nodes"); more levers than b4's two (nodes, taming); don't densify the interaction graph. Structure: endless, resource-producing environments kept; restoring a biome opens others; two restored → a transition zone (e.g. ice / dust) whose fixing unlocks new states in both; offline = the sim as numbers, stable while away, visuals on arrival. Callisto stays; a 6-year-old is the complexity floor, not the audience. Full text: concepts/callisto_design.md → The game: an intelligent idle game.
• D163 Slime (user: "Slime grows on EVERY surface that is not occupied and has a node nearby - built or not - that has gas. It grows aggressively, does not consume gas. On the other hand - it releases gas, when a tamed bug is nearby. Lichen can grow over it, replacing it. Fire does not kill it. It looks like a particle-thin layer of green gooey"; asked: the rock surface, not the back wall, so no competition with moss; lichen replaces it where lichen grows; a release uses the slime pixel up; "The purpose of moss is making the climate change seeded by the monster worm a permanent one-way change"). slime.js (knobs slime.*, g.slime.on): lichen.js's surface (open, rock among 8 neighbours), free of lichen, its station holding gas; every growTicks 30 each slime pixel spreads to one fed free neighbour, and a fed station with none seeds one 1 in seed 4 steps; it takes no gas. Every releaseTicks 60 each tamed bug turns the nearest slime pixel within reach 4 into 1 gas at its station (the evaporated wisp). Lichen placing a patch clears slime under it (unslime); fire never touches it. Drawn in the texture as a yellow-green film (SLIME_RGB, 55%) over the pixel, under the fog. Measured, seed 1, 16 built nodes, one meal, 10 bugs, 15 min: slime steady ~190–200 px, bugs tap ~11 a second, the cave's gas never runs out (7 000 at 15 min: moss had no bare wall left), tamed bugs swing 12–42 between gas-node moths and predators; 0.12 ms a tick. So a meal's climate change sticks while bugs visit.
• D162 Beasts eat far from you, where there's no moss (user: "megafauna should target areas with no moss at all, 'near user' is not a good target, I got stuck at an enclosure several times. in fact, attack something 30-100 away from the player in an area with zero or very little moss"). beasts.js edible: a built bulb nearMin 30 – near 100 px from you (was within 50) with at most mossMax 8 px of cover (green, vine, fruit) within mossR 12 px; the beast takes one of those with the least cover, at random. Claude's calls: "very little" = 8 px; none fits: it waits, as before; you walking within 30 px during its 5 s approach makes it look again.
• D161 No hives; gas nodes hatch moths (user: "delete the whole moth nest concept. I do not want moth nests. nodes, that have gas, should spawn their own moths every 30 seconds"). hives.js, its drawing and knobs are gone (supersedes D159's hives and D160; D159's moths hovering while they harvest stays). swarm.js: every swarm.mothTicks 1800 each built node whose station holds gas hatches a moth there (hatch: +1 bug on the ledger, event hatched). Claude's calls: built nodes only (the ledger's "nodes"); hatching takes no gas. Measured, seed 1, 16 built nodes, one meal's liquid (960 gas): 7 moths at 30 s, 3 at 60 s, then the moss has used the gas up (~90 s): 10 moths a meal.
• D160 Hives twice as often (user: "I want the moth nest spawn rate pushed up by 2x"): hives.everyTicks 1800 (30 s; was 3600), still 1 at a time.
• D159 Hives (user: "near a lot of ore, spawn hives. hives spawn 3 moths (tame bugs) before they shrink and despawn"; then "moths should stop, when they are harvesting something, now they just run past"). hives.js (knobs hives.*): every everyTicks 3600, under max 1, a random network node (the pod's from the start) looks within look 48 px for the wall pixel with the most ore within radius 12 (ore 20 or more), apart 32 from another; it hatches a moth every birthTicks 300 (swarm.js hatch: ledger bugs +1, a worker there that is a moth from the start), 3 in all, then shrinks for shrinkTicks 300 and goes. Drawn as a honey blob over the fog, swelling, beating at each hatch, shrinking. Moths with a unit in reach now hover till it's out. Claude's calls: the numbers; at 20 s and 2 hives an idle game hatched ~90 bugs in 10 min, now 27 (seeds 1–3, first hive at 1 min).
• D158 5× the gas per liquid (user: "5x the liquid / gas ratio, liquid should create much more gas"). gas.per 40 (was 8); Claude's call: gas.burst 5 particles a surface pixel each evaporation (was 1), so pools dry as fast as before and the gas comes 5× as fast, not 5× as long. A beast meal: 960 particles.
• D157 Bugs don't pick fruit (user: "bugs should not collect the fruit anymore, it will be way less common"); a returning tamed bug prefers a network node with gas (user: "bugs now should prefer spawning at a node with gas"): swarm.js spawnAt scores gas first, then no vine (D118), then the fewest bugs (D116).
• D156 Predators haul their catch (user: "the predator itself should pull back into the rock too with the prey, then slowly re-descend. The pink part should not glow, but the tip yes, and THAT should be pink"; "the pink predator must pull back with its last prey, THEN despawn"). predators.js: a string has len up to full; it comes down a px every descendTicks 30 (new ones too, from the rock); a catch hauls it up a px every retractTicks 3 with the prey on the tip, and the ore appears when it's in the rock (event predatorOre); hauling, it catches nothing, one catch a haul; after the last meal it hauls that one up, then goes. Render: the string dull pink [120, 62, 92] under the fog, the tip glowing pink [255, 70, 175] over it with the prey drawn below it.
• D155 Predators (user: "a pink predator, with a bright tip, that spawns at places with a lot of bugs, hangs from the ceiling like a string, and when a bug comes in contact with it, it pulls it back into the stone and creates 3 ores. Can repeat 5 times before despawning"; asked: both tamed and wild bugs, a tamed one gone for good; "at most 1 predator per 4 nodes at a time… this will be the main ore replenisher"). predators.js (knobs predators.*): every spawnTicks 600, while fewer than built nodes / perNodes 4, the bug with the most bugs within crowdR 24 px (crowd 6 or more), not near another predator, calls one: straight up at most up 32 px to the rock, anchored on the open pixel under it, hanging to the next rock or length 16 px. A bug on the string or beside it (flying too) is caught at once: tamed → off g.swarm and ledger bugs −1, wild → gone (its block refills later); the ore 3 soft/hard pixels nearest the anchor turn to ore (event caught, the view slides the bug up into the rock and repaints the ore). After meals 5 it withdraws (predatorGone). Drawn over the fog: pink pixels swaying a little lower down, a bright tip with a halo. Claude's calls: the numbers above; no randomness (the most crowded bug, then the first). Measured, seed 1, 16 built nodes, 20 tamed bugs, 5 min, no new bugs coming in: 16 predators (4 at once), 73 bugs eaten (18 tamed, 55 wild), 219 ore; the ledger's bugs 20 → 4.
• D154 Moths (user: "When a bug comes in contact of gas, it starts to behave like a moth - flies in circles with an element of random walk. Still sends everything to the ledger immediately, still lives for 30s. Let's change the jumper bug's color a bit less warm, so there's a visual difference too"). swarm.js: a tamed bug on a pixel whose station holds gas (checked in the air too) becomes a moth until it fades (b.moth, bounce.js becomeMoth/mothTick): it flies through open air at bounce.mothSpeed 12 px/s, its heading turning for a mothRadius 6 px circle, nudged ± mothJitter (60/6400 of a turn) each tick and turning the other way round 1 in mothFlip 120 ticks; rock ahead: it turns round. It never stops for a unit but pulls what's in reach as it passes (each to the ledger at once), greens what it flies over where there's gas, and fades after idleTicks with no unit, coming back a jumper. Render: moths amber (BUG), jumpers JUMPER [245, 222, 160]; the fade ghost keeps the colour. Claude's calls: a moth stays one once it met gas, even after the gas is used up (the user: "starts to behave"). Measured: a moth in a cave with gas flew ~430 px of loops across ~50 px in 30 s, laid 105 moss, mined nothing (it flies mid-cave) and faded.
• D153 Wall-bouncers and cheap taming, for an exciting loop until 64 nodes (user: "drop the wild bug taming cost to 1 and change its natural movement. Let's make it a wall-bouncer. It moves on the wall, and if there's no ore nearby to mine, it shoots itself in a low-gravity arch through the cave. If no ore found for 30s, fades away and spawns again randomly around a node"; asked: wild ones "do the same, but do not linger around ores, just walk around and sometimes do the wall-jump"; "send ore as soon as mined"; "make it a random arch, no logic or memory"; no free liquid). bugs.tame 1. New bounce.js (knobs bounce.*): crawl along the wall (open pixels touching rock), a jump at jumpSpeed 40 px/s in a random direction, gravity 18 px/s², stick to the last open pixel before rock; flight in 1/1000 px, integers. Tamed (swarm.js): stays while a unit is in reach, jumps when none within swarm.near 8 px (after restTicks 60 on the wall), each unit to the ledger at once (a haul event per unit), idleTicks 1800 with no unit → event faded, back near a node (the D116/D118 rules); no trips, no fruit carry limit; D133's pull to bare wall is gone. Wild: bugs.js g.wander hook (b3 unchanged); a wanderer crawls every bugs.moveTicks and jumps 1 in wildJump 40 steps; chasers drift to you as before; a wanderer may leave its block. Claude's calls: a jump needs 8 px of open air ahead (with 3 px, most flights ended in 0.23 s against the next rock; now median 0.35 s, max 2 s); a bug spawned in the air falls to the wall; fading drawn as a 1.5 s widening ghost. Measured, seed 1, 6 bugs, 3 min: 110 units (56 before), 0 ticks in rock, 91% of the time on the wall.
• D152 Moss costs gas (user: "tamed bugs place moss on cave back wall only in the presence of gas, every placed moss uses one gas"). garden.js greenAround: a pixel greens only while its station (gas.js stationOf, the node whose share of the cave it's in) holds gas.perMoss (1) or more, and takes it; no gas there, the bug passes and the wall stays bare. Claude's calls: the gas is the pixel's own station's, not the bug's or a neighbour's; bugs still head for bare wall (D133) with or without gas; gas.perMoss 0 = free moss, as before. Consequence, flagged to the user: gas comes only from beasts' pools (the first beast at 16 built nodes), so before that no moss, no vines, no fruit and no lichen fire.
• D151 Tamed bugs stop for fire (user: "tame bugs must stop moving if there's fire in their 6px vicinity"). swarm.js fireNear: a burning pixel within swarm.fireStop (6) px, round, and the bug skips its step; it walks on when the fire there is out. Claude's calls: it still pulls and its trip still ends on time (only moving stops); a still bug's 3×3 fire shield (D147) keeps its ground green through the fire.
• D150 Gas spreads (user: "all I'm seeing is that the gas stays at the closest node(s) without any consideration to saturation […] use the fire-spread algo to spread the gas particles? once a node gets saturated, it sends half of the surplus further, and it quickly settles"). gas.cap 8; every gas.spreadTicks (30, 0.5 s) each station over the cap sends half its surplus (rounded up). Claude's calls: stations are neighbours where their shares of a cave touch (every open pixel belongs to the node nearest it through open pixels, one flood from all nodes, ~12 ms once per map), not along roots (only ~30% of roots avoid rock: ~200 groups, a third of the nodes alone; the caves give ~80 groups, the biggest 60–124, ~40 nodes alone); the surplus goes a hop towards the nearest station with room (plain "to emptier neighbours" left cones of 14…9 behind stations stuck at exactly 8); a full cave evens out to within 1; stations take turns in node order (all at once, they swapped back and forth for ever). Measured on seed 1: 192 particles fill 26 stations in 4.5 s; 1887 in a 111-station cave even out in 22 s; a spread step ≤ 0.4 ms. Wisps drift between stations as gas moves.
• D149 Gas (user: "nodes will behave like climate stations. I want the mega-worm-made shimmery liquid to gradually evaporate, creating 8 particles per liquid"; "I want the vapor to be contained in these closed caverns"; "I do not need pressure, saturation, just gas presence"; "gas needs to be a visual particle effect, not something with persistence"; no cap per station, "we will do something with the gas levels"). Every node is a station, built or not, eaten or not: g.gas[node], a count, saved. g.liquid holds a drop's particles left (gas.per 8). Every gas.everyTicks (300, 5 s) each pool pixel with no wet pixel above gives one particle to its station and dries at 0 (the ledger's liquid −1). Claude's calls: the station is the nearest node through open pixels (a 4-way flood, memoised; b4's rock never opens, so gas stays in its cave); none within gas.reach 20000 px flooded → the nearest in a straight line; the pool shrinks from the top; drawn as a cloud of up to 48 pale specks round the station (wider with more), and a wisp drifting from the pool to it, under the fog like the liquid. No overflow between stations, so the cavern graph was never needed.
• D148 Worms glide (user: "can the red snake move in a less blocky way? it moves at a tile-resolution, please move it the same way the player moves"). View only (render.js drawWorms): each body pixel slides from where it was before the worm's last step to where it is, over the step's worms.moveTicks, drawn between ticks like the bot and the bugs; the sim still steps whole pixels, 8-way.
• D147 Tamed bugs suppress fire (user: "give tame bugs a 3x3 fire suppression area"). garden.suppress 1: no cover within the 3×3 round a tamed bug at work catches fire, whether from the spread, a lichen's ember or an ash disc's flare-up. Claude's call: a pixel already burning there burns on (no putting out), so the effect is green squares that come through a fire where the bugs were.
• D146 Loot is crystals (user: "let's rename internally loot to crystals"). Claude's calls: all of b4 (code, ledger row and field crystals, crystalPx, view.crystalPing, world.crystals, comments, concepts/player-influences-but-system-has-its-own-trajectory.md); the user's quoted words keep "loot"; b1–b3, the shared sim (Tile.Loot) and their rulesets keep it (b4's world.js: CRYSTAL = Tile.Loot). The save format is version 2: b4.62–b4.63 saves start a fresh game. Old links with k=world.loot or view.lootPing lose those knobs.
• D145 Tamed bugs from the network (user: "Detach the tamed bug count from direct user actions, every 4 automatically creates a new tamed bug, that acts exactly the current ones. Eating a loot does not tame a bug anymore"; asked, "4 built nodes"; then "let wild bugs get tamed by nibbling, I just wanted to make sure the player can not stop the progress by running away from bugs"). nodeTames in game.js: each nodesPerBug (4) built nodes reached is +1 bug on the ledger, a worker like the others (starts near you, b4.49); nibbling still tames (D060); b4.40's loot taming is gone (supersedes D122). Claude's call: a node a beast eats takes no bug back (nodeBugs follows the most reached). The lizard enclosure test now lays its own ash: since b4.54 it had passed only on ash from fires started by bugs tamed on loot other tests left in the shared map.
• D144 The game saves itself and comes back on the next visit (user: "how could you save game state, store in cookie, and reload it, when the site is visited again? all this without a lag spike of massive files stored?"; then "wrong assumptions, check b4.61 and try again. there's no terrain manipulation"; then "let's try to build it"). Claude's calls: localStorage, not a cookie (4 KB, sent with every request); one save per build id, seed and map knobs; saved on pagehide, on the tab going hidden and every 30 s. save.js: the cave never changes shape, so a save is the state over the map as made: per-pixel layers run-length encoded, tiles that changed kind (ore/loot pulled, worm ore) as a diff, the rest as JSON; generic over the game state, so new systems save with no change there. Randomness comes from the tick, so restoring tick continues the same game (a test runs a saved and a loaded game 4000 ticks on: identical). Seed 1 after 20,000 ticks: 25 KB, save 9 ms, load 2.5 ms. A save that won't load is dropped for a fresh game; the dev panel's "new game" wipes it. Not kept: a beast's shadow mid-approach (its bite still comes).
• D143 The mega beast's shadow in pixels (user: "make the bulb-eating giga-worm bigger and pixel-art, like everything else is on screen? I'm thinking of sampling the screen, and displaying the worm presence as shifting, darkened pixels"). Claude's calls: a 96 px body snaking behind its head (radius 12 px, tapering to 6), each world pixel under it darkened by how deep inside it is, hashed per pixel and re-rolled 12×/s so the ground crawls; a sparse dusty rim. No screen sampling: black pixels over the frame darken it the same way, cheaper. Over the fog, so on unlit ground mostly the rim shows.
• D142 Worms tunnel to fruit (user: "worms can tunnel towards fruits"). A foraging worm with a fruit within sense 24 px steps to the neighbour nearest it through rock as well as air (not the sheet, sea or space); the rock stays as it is, as on its way to a deposit site (D091). With no fruit in sense it wanders the open cave as before. So fruit in the next cave is reachable.
• D141 Mega beasts (user: "at 16/32/... node count add 1-1 mega beast to the pool. These are like Dune sandworms, you do not see them, just the massive tremor and a shadow as they tunnel below the surface. They eat one bulb every 5 minutes. You do not see them, they just pull the bulb back into the backwall and 24 shimmery liquid particle drops from the bulb's location and flows down and settles in natural cave pools"; answers: doubling thresholds; the node and its roots go; "not the nearest but a random, on screen"; the pools permanent, "I will want to use these pools for some interactions", the ledger counts them, nothing collects them yet; on screen = within 50 px of you, else it waits; a 5 s build-up then a jolt; never the bulb holding you or an end of the root you ride). beasts.js: a beast joins at 16, 32, 64… built nodes and stays; each eats every everyTicks 5 min; 5 s before, it picks a random built bulb within near 50 px and its shadow (a long soft dark mass with a dusty rim, over the fog) slides in from 48 px away while the screen trembles, growing; the bite: a big shake, the bulb sinks, the node and every root touching it are unbuilt (they can be built again); 24 drops fall and flow down (the sim settles them one by one: down, down-sideways, else along the row within 32 px to a way down) and stay as shimmering liquid pixels; a ledger row counts them. Claude's call: pod nodes are never eaten and stay on the network, else a fully eaten network would leave nothing to build from.
• D140 Tamed bugs eat 2× slower (user: "bugs outcompete every other animal, they should eat 2x slower"). A tamed bug pulls a unit (ore, loot, fruit) every swarm.pullTicks 120 ticks at most (2 s; was 60), still faster by the bug level's gain. Wild bugs' nibbles of the ledger are unchanged.
• D139 Lizards linger (user: "lizards should eat 3x slower, and stay on screen and zip around the walls 5x longer. they are cute, but I barely see them"). A lick every mineTicks 90 (1.5 s; was 30); a life is its licks, so 5× longer with 3× slower eating needs eat 27 before it burrows (was 16; still 5 loot). And after every rest it zips on along the wall (4–12 px), even with ash still in reach (before, it stayed put and licked on, and an empty route sent it on a 1 px "dash"). Measured on seed 1 with ash round the start: 8 s from spawn to burrow before, 40 s now.
• D138 Loot for the lizards, the bug level for you (user: "loot should upgrade lizard mining distance, not the player's"; "player reach, mining speed and light should depend on the bug level instead"). Loot buys lizard levels by itself (16, 32, 64…; lizardUpgradeCost), each +20% lizard reach (6 px → 7 → 9…); a purchase flies loot from the ledger to every lizard. The bug level (fruit, D094) now also makes your light, your mining radius (the light's) and your mining speed 20% bigger a level (the light grew with nothing before; the radius and speed grew with loot, D096). The bot row's dots follow the bug level.
• D137 Lizards dash for ash in the open (user: "lizards can leave the walls for a short dash to reach ash in the cavern centre, but goes back to the safety of the wall at the next movement"). When no wall pixel in its route range has ash within its reach, a lizard runs straight through the air towards the nearest ash within dash 16 px, stops within reach (6 px) and licks while it rests; its next move is straight back to the nearest wall pixel. No new state: a lizard whose head isn't on a wall pixel is out on a dash.
• D136 Lizards live off ash (user: "change lizard mechanics. it should spawn in areas with ash, have a 6 mining radius, eat up ash tiles, and when burrows, creates 5 loot resources"). A lizard spawns where density 24 ash pixels lie within radius 16 px (was reachable ore, D101); it seeks and licks ash within reach 6 px (was ore within 3); a licked ash pixel becomes bare back wall again, which bugs can green; after eat 16 it burrows into a 5 px site (lootPx) that turns to loot (was 1 px). So loot now comes from fire: lichen sparks, cover burns to ash (D102), lizards come.
• D135 Bulbs light up near you (user: "highlight a bulb when in the light radius"). A still bulb (a built node, or one that shows) within the light's radius of the bot (8 px, straight distance) is drawn in the held bulb's bright colours at r 2 instead of the dim 5 px plus; still under the fog, so one behind rock stays hidden.
• D134 A quicker bulb with a hold-off (user: "block the player for 50ms after entering the bulb from make a choice, and change the hold-release time to a total 1.5s (incl the no-decision time)"). For holdOffTicks 3 (50 ms) after a bulb takes you in, a drag or a release picks and confirms nothing; after that, a drag you're still holding picks (so the drag you walked in with picks at 50 ms, not at once as in D123). The bulb lets you go after ejectTicks 90 (1.5 s from entry, the 50 ms included; was 3 s).
• D133 Tamed bugs go for bare back wall (user: "tame bugs should be attracted to cave backwall tiles that are not green yet"). Before each step a bug counts, along each of its 8 ways, the open pixels with no cover in the next swarm.look 8 px (up to rock) and takes the way with the most (its heading on a tie); with none in sight it random-walks as before (D083). Measured on seed 1's start cave, 6 bugs: 1690 px greened in a minute against 1150 walking at random (look 4 gave 1304: the last bare nooks were out of sight).
• D132 Built nodes on the ledger (user: "add the built nodes as a ledger entry, below the ore counter, symbol is a bulb scaled down to visually fit the ledger's other entries"). A row below ore counts the nodes with a built root; its icon is the held bulb's pixels (r 3: core, body, rim) scaled into the icons' square. Like every row, it shows once the first node is built (D127).
• D131 A tamed bug starts near you (user: "tamed bugs should start their life right where they were tamed, so that the player sees it and connects taming -> green stuff"; then: "when a bug gets tamed, spawn a tamed bug near the player, that's it"). A new worker's first trip starts on an open pixel within swarm.spawn 12 px of the bot; its later trips start at network nodes as before (D116, D118).
• D130 Loot pings (user: "loot ore should rarely 'triple-ping': 5ms halo, 10ms gaps"). A seen loot pixel on screen flashes a white halo over the fog three times, once every view.lootPing 30 s at a phase hashed per pixel (Claude's reading of "rarely"). Claude's call: a frame is 16.7 ms at 60 Hz, so 5 ms and 10 ms can't be drawn; the halo shows for one frame, then one frame's gap, three times (~83 ms).
• D129 Phone zoom and brightness (user: "zoom does not work on phone, and the whole game is too dark to see - but only on the phone"). Found: b4 had no pinch (a second finger was ignored), and the zoom levels were device px, so a 3× phone started at ~4 CSS px a tile and could zoom in only to 8. Now: the levels are CSS px (2–24) times the device pixel ratio (desktop at 1× unchanged); the default is ~100 tiles across the short side but at least 6 CSS px a tile; a two-finger pinch zooms a level per 1.25× change of the fingers' distance (it ends the drive without confirming anything, even in a bulb). Claude's call for the dark: phone screens crush dark greys, so a knob view.bright (the canvas's CSS brightness, black stays black) starts at 1.5 on touch screens, 1 elsewhere, on the dev panel.
• D128 Scans don't scare wild bugs (user: "seismic events should not scare wild bugs anymore, delete that code"). b4's scan no longer calls bugs.js scare and its scareTicks is gone; the shared bugs.js keeps scare for b3.
• D127 Pink from burst light worms; ledger rows earned with theatrics (user: "if light worms have no FOW to lift, they instead explode into bright rainbow particles and give a new pink pixel resource. also - until you have at least one, elements of ledger do not show up, but when a new element shows up in the ledger for the first time, it does with theatrics: screen shake, and particle 8 streams of .4s duration from random positions of the new ledger element color flow to the new ledger item, and this lasts for 2s, with .2s overlap in particle stream source spawns. the player still just gets 1 new element though, the first one"). An ash worm (D119) that finds nothing unseen within 64 px bursts: a rainbow puff, +1 pink (a new ledger row, after fruit), its pixel flying there. A ledger row is hidden until its count first reaches 1, then stays; the bot's row shows from the start (you are its 1). A first show: the screen shakes, fading over 2 s; 8 streams of the row's colour, one every 0.2 s, each 0.4 s of particles from a random spot on the screen to the new row (drawing only: the ledger gets just the 1). Shown rows stack; the gap shows only between a shown resource and a level.
• D126 The bot row counts bots (user: "bot should have a number on the ledger too: 1, if you are alone, and more, if there are white flower bots active on the travel network"): 1 + the flower bots at work (D108).
• D125 The ledger regrouped (user: "fruit icon should be a pixel, just like other resources"; "ledger should be: ore, loot, fruit, a gap, then player and butterfly level"). Rows top to bottom: ore, loot, fruit, a row's gap, the bot's level, the bugs' level; fruit's icon is a red square like ore's and loot's. The level rows show what they did (a dot per level; the bugs' row also the tamed count).
• D124 Hearts and "?"s from bugs being tamed (user: "bug must release heart particles 50% of the time it gets taming ore, and "?" particles if the player has none"). A wild bug's bite (nibble) of the ledger's ore sends up 3 hearts half the time (drawing only, Math.random); a bug that would bite but finds no ore on the ledger sends up a white "?", at most once per nibbleTicks (event hungry, b4's ledger mode only; b3 unchanged). The 6 hearts when a bug is tamed stay.
• D123 Lichen light, no scan circle, and the bulb as the one way onto the network (user: "Lichen should have a permanent, faint, but large radius light"; "remove the white circle visual effect from the seismic test event"; "the navigation system bulb-entry-exit is still not great UX, let's try this: upon entry, bulb accepts the player, the whole pulsates dimly, local bulb local edges light up, local buildable edges light up in green. drag chooses, release confirms. bulb ejects the player in 3s to an 5px away open space from the bulb center"). Lichen: every patch lights 24 px round it by line of sight, forever; the fog there is 55% at the patch, easing to the seen dim at the rim; drawing only (nothing becomes seen). The scan's white rings aren't drawn (the scan itself is unchanged). Bulbs: held, the whole network pulses dimly over the fog, the bulb's built roots light up orange, the unbuilt ones the ledger can pay for show green; a drag picks one within 67.5° (it flashes), letting go confirms it; after 3 s the bulb puts the bot on an open pixel 5 px (ejectR) from its centre. Claude's calls: a bulb takes you in only when it offers something (a built root, or an unbuilt one with the price on the ledger), else the pod's nodes trap you at the start; confirming a built root rides it (on through the next nodes the way you dragged), an unbuilt one is built and ridden; a ride that stops at a node stops in its bulb; pointing along a root to board it (D107) is gone; a drag you were already walking with picks as soon as you're taken in; the bot is put out the way it came in.
• D122 Loot tames wild bugs (user: "When wild bugs find a loot, they become tame"). A wild bug within lootTame 2 px of a loot pixel in the rock is tamed: +1 on the ledger, gone from the world, hearts, as the ore-fed taming (D060). Claude's call: it eats that loot (the pixel turns to rock), else one loot pixel would tame every bug its fog block refills with, every 5 s.
• D121 Animals seen everywhere; a round mask (user: "all moving animals should be visible even in unexplored areas, but there should be a circular mask on the map with a gradient at the edge, that hides the repeating X axis"). Lizards are drawn over the fog again, in D111's dull greens (the worms, wild and tamed bugs, flower bots and ash worms already were; wild bugs keep their dark blinks, D061). The world gets a round mask round the screen's middle, as wide as the map (r = half its width), fading to the background over its outer fifth; it's off when the circle lies off the screen; flights and the ledger are drawn over it.
• D120 Slower rides you can leave anywhere (user: "travel network is too fast, can not get out where I want"): rideSpeed 40 px/s (was 80); a tap (Space) while riding gets you off at the next open pixel along the root, mid-root (it stopped you at the next node before).
• D119 A ragged fire and ash worms (user: "Fire spreads in a square shape, looks silly... can you trigger it at random 3 points around the lichen, probably it will break the shape? Also, ash areas should spawn 12s lifetime grey worms, that have a series of small lights on their sides and quickly burrow in a snake path towards unexplored areas and lift the fog permanently"). Fire: the ember lights 3 random cover pixels within 6 px of the lichen; and (Claude's call, since 3 squares still merge into a square) each step a burning pixel sets a side neighbour's cover burning 50% of the time, a corner one's 25% (over its 4 steps: 94%, 68%), so the front is ragged; about 1 px in 1000 of the connected cover is left. Worms (ashworms.js): 1 in 2 discs sends one from its centre once its fire is out; 8 px of grey with a twinkling warm dot on each side of every other segment, over the fog; 20 px/s through rock and air (not the sheet, sea or space; the rock unchanged), heading for the nearest unseen pixel within 64 px and swinging a step to each side in turn; everything within 3 px of its head becomes seen for good; gone after 12 s in a grey puff. Seen: a whole burned cave sends out about 8 and lifts a lot of fog.
• D118 Tamed bugs go where there's no vine (user: "prefer to spawn the bugs in areas with no vine"): a trip's start node is one with no vine or fruit within about swarm.crowd 32 px (vines counted per 16 px block, the blocks the circle overlaps) if there is one; among those, the fewest bugs (D116), then random.
• D117 Smaller ash patches (user: "make smaller ash patches, no room left for the vine to grow"): a disc is r 2–3 (was 3–5, D102), about a third of the ash; the centres stay 8–12 px apart, so there's bare wall between them for the bugs to green and the vines to grow into, next to the ash (D115).
• D116 Tamed bugs spread out (user: "tame bugs try to spawn in areas with the least amount of tame bugs"): a bug starting a trip picks, among the network's nodes, one with the fewest other bugs within swarm.crowd 32 px, ties at random (was a random node).
• D115 Flower bots grow the rim; ash feeds vines (user: "make the bots try to grow edges into new nodes in the network edge, not just increasing edge density in the centre. make vines that touch ash becoming hyper-productive, because with the ash invented, now there's not enough ore"). Bots build only edges to nodes not on the network yet; away from the rim they take the built root that starts the shortest way (in hops) to the nearest node with such an edge, and at the rim they wait for the ore and their 60 s. Asked, the user chose more fruit (not ore) at 10×: a vine pixel with ash among its 8 neighbours makes fruit 10× as fast (garden.hyper), and the next fruit lands on one with that weight.
• D114 The network under the fog, smaller bulbs (user: "network is still WAAAY too dominant visually. Draw it behind fog, make bulbs smaller"). Built roots and still bulbs are drawn under the fog: dimmed where seen, gone where unexplored. A still bulb is a 5 px plus (was r 2), a buildable one with a lit heart. The bulb holding the bot (r 2–3, was 3–4) and the edges it offers stay over the fog, so building works in the dark.
• D113 Lichen sparks 4× rarer (user: "lichen explosion should be 4x more rare"): 1 in 24 of its checks (every 5 s), about 2 minutes on average with cover near, was 1 in 6 (D102).
• D112 Fewer, dimmer flowers (user: "Let's halve even that number of white flowers, and do not make it this bright"): 1 in 8 ash discs (flowers.per 8, was 4); petals (168, 166, 160), heart (170, 150, 84), was white and (255, 233, 138). Still drawn over the fog.
• D111 Three fixes (user: "loot ore should be white; lizards should not glow; there should be 1/4 white flower per ash, this is waaaay too much"). Loot is white (240, 240, 240) in b4: the specks in the wall, the flights, the ledger (was b3's teal). Lizards are drawn under the fog, seen only where lit, in duller greens (104, 168, 78) head and (58, 128, 60) body. Flowers: read as 1 in 4 ash discs (flowers.per 4) grows one flower (D108 had 1 per 24 px of ash).
• D110 A dimmer network (user: "reduce bulb and network brightness, it outshines the whole map. only pulsate a bulb, when the player is inside it"). Roots (120, 64, 24) and (96, 50, 20), was (214, 118, 36) and (176, 86, 26); still bulbs dim, r 2, (128, 70, 26) with a (94, 50, 18) rim; one you can build from keeps a dim core (168, 110, 52), one only on a built root has none. Only the bulb holding the bot beats (r 3–4) in D103's bright colours.
• D109 A bulb lets go after 3 s (user: "'engulf' is okay, but it is not possible to leave the bulb… direction buttons select the edge to build, and it starts to blink green. This is the current behavior and it is good. But the bulb should eject the player in 3 seconds after not building an edge"). Replaces D103's "do not release until a path is built": 3 s (ejectTicks 180) after it takes the bot with nothing built, the bulb lets go (event eject, the aim dropped); a direction still held walks the bot on; the same bulb doesn't take it again until it has left its 2 px reach.
• D108 Brighter fire; ash flowers that become network-building bots (user: "the fire and the ash-splash is awesome, I love it. Flames can be brighter, more colorful, add some particles. The ash should spawn white, large flowers, 1/24 area. After 2 minutes, the flower becomes a bot, similar to the player, but without light, and all the touching ash reverts to open air. The bot lives on the network, zips around, and when there's enough ore, but minimum 60s apart, randomly extends the network from its current position. After 3 extensions, it pops into non-existence in a white particle puff"). Asked, the user chose: 1 flower per 24 px of a disc's ash; a new bot zips straight to the nearest node on a built root (the pod's before any), through rock; it spends your ledger's ore. Built: a pixel burns 4 fire steps (0.4 s), drawn over the fog in 7 colours from white-yellow to magenta by age, flickering, with rising sparks; flowers (5 px, white petals, yellow heart, over the fog) placed once a disc's fire is out, 5 px apart; at 2 min: a lilac-white bot pixel with no halo, the 8-connected ash round the flower cleared, a white puff; on the network it rests 0.5–1.5 s a node, zips 60 px/s along a random built root, and at a node with an unbuilt edge, with the price on the ledger and 60 s since its last, builds a random one (1 in 2 stops); after 3 it pops in a white puff. Knobs garden.burnFor, flowers.*. Seen: a whole burned cave gives about 30 flowers, so about 30 bots bloom at once and spend ore fast.
• D107 Travel along the roots, bulbs on the built nodes (user: "the network looks cool, but I still need to travel... when I said no carts, I meant, no blocky vehicles travelling on the edges. Keep the bulbs visible, where nodes are built, just not pulsating"). b4.22 boarded only on the node's own pixel, and built nodes showed nothing unless buildable. Now: pointing along a built root (within 67.5°, as at a node while riding) within nodeReach 2 px of one of its nodes rides it, the bot glides along it; this comes before the engulf, so riding into a buildable node carries on. A node on a built root always shows a still bulb; a node that can be built from beats (D103).
• D106 Lichen grows where the bugs' cover is large (user: "change lichen spawn criteria - it is triggered by large area of vine-cover"), no longer by loot (D096). Claude's numbers: 150 px of cover (green, vine, fruit) within 12 px of the tried spot (knobs lichen.density, radius); the rest as D096. Measured over 20 simulated minutes with 4 or 10 bugs at work (seeds 1–3, the bot still): the first lichen at 0.7–2.2 min, and it sparks (D102) within about 15 s, since it now always sits in cover; 2–5 lichens and fires each.
• D105 Lizards don't spawn in small enclosures (user): the spawn pixel's cave must hold lizards.room 400 open px (8-way flood). On seeds 1–3 that rules out about 80% of the caves by count (median cave ~100 px), a small share of the open area.
• D104 The scan fires on touch (user: "bot seismic pulse should activate immediately on wall touch, no need to wait"): at the rock pixel touched, the tick the bot touches it, also while sliding along the wall (before, only when fully stuck); scan.cooldown 0 (was 1 s). It still fires only if something within its radius is unseen (D086).
• D103 Roots and bulbs, not a metro map (user: "I do not like the node network look and UX. Drop the metro map look, use the eased grid to make it look like a wiggly orange root, keep the pixelated look consistent with everything. Also, do not show the node until the ledger has enough ore to build any edge in it. And then if the bot gets 2px close, engulf the bot, and do not release until a path is built. The node should be a pulsating orange bulb still pixelated"; then "no cart on the network, just the bulbs"). Asked, the user chose: routes walk the relaxed quad mesh's edges; engulfed, a drag aims and a tap builds; the price stays flat and isn't shown. Built: v8's mode A pairs routed by A* over the caves' mesh (roots.js: rock ×5, an earlier root's edges ×2, its vertices +40 px, other nodes closed); roots drawn 1 px, two oranges; a node shows only while the ledger holds the price and it has an unbuilt edge, as a pixel bulb of r 2–3 (3–4 holding the bot) beating; within nodeReach 2 px it holds the bot on its pixel (moves ignored) until a build, then lets go and doesn't take it again until the bot has left its reach; while held, its unbuilt edges show faint and the aimed one flashes green. No carts: stepping onto the end of a built root boards it and the bot glides along.
• D102 Lichen sparks fire (user: "lichen should sometimes spark an ember that eats through the bug-induced vine cover, leaving round r=3-5 ash patches about 8-12 tiles apart. lichen leaf withers, will not spark again, purple surface stays"). Asked, the user: the fire spreads "how fire does… any vine touching vine catches flame, and it spreads through the entire green cover like a cell automaton. it leaves empty open air and the ash patches"; ash is permanent ("we will find a function for it, should enrich the environment"); only a lichen with cover near it sparks. Built: a lichen with cover (green, vine, fruit) within 2 px sparks at 1 in 6 of its checks (every 5 s); the fire spreads 8-way, 1 px every 0.1 s, and burned pixels go back to bare wall (bugs can green them again). Where a pixel catches with no ash centre within 8–12 px, it becomes one: a disc of r 3–5 whose bare wall turns to ash at once and whose cover burns to ash. Ash stays; bugs and vines skip it. The leaf withers brown; the purple patch stays. Knobs: garden.burnTicks, ash/ashMax, ashGap/ashGapMax, lichen.spark, touch.
• D101 Lizards get to retire (user, after b4.19: "lizards are stuck, because they do not reach far enough"; asked for a higher spawn requirement). A lizard spawns only with 24 ore it can mine (within its 3 px reach of a cave surface) within 16 px, 1.5× its 16 (was 16 ore of any depth within 8). Measured, that alone didn't help (20 simulated minutes on seeds 1–3: 1 of 20 retired): they stalled 3–11 px from reachable ore, snagged on the cave's shape. So, Claude's call: at each zip a lizard floods the surface up to 32 steps and follows the route to the nearest spot with ore in reach, and stays put while ore is in reach. Then 163 of 176 retired (about 2–4 loot a minute near the bot).
• D100 The lichen's leaf is pixels, like everything else (user: "lichen is not pixelated… it should be"; D096 drew it as a smooth curve): up to 4 world pixels in the air from the patch's first pixel, 2 out from the rock (the nearest of 8 ways), then curling to a side; it stops at rock.
• D099 Soft and hard rock are much darker (user, after b4.17): soft (40, 30, 24), hard (22, 23, 28), was b3's (92, 70, 54) and (52, 54, 66); darker than the cave's grey-blue back wall (D097). b4 only.
• D098 The world generates with no loot; only lizards make it (user, after b4.16). The world.loot knob stays on the panel (default 0).
• D097 The cave's back wall (open pixels) is dark grey-blue, (36, 44, 62), not b3's near-black (8, 8, 12), so an explored cave doesn't read as unexplored (user, after b4.15). b4 only; b3 keeps its palette.
• D096 After b4.14 (user): loot works for the bot as fruit does for the bugs: spent by itself at 16, 32, 64…; each upgrade (bot or bugs) makes the mining radius and speed 20% bigger; the bot shows on the ledger (a bot icon per upgrade, loot as count/target); plentiful loot spawns purple lichen covering 6–8 pixels of cave wall, growing a single curly short leaf. Claude's calls: the 20% compounds (×1.2 a level) and also replaces b4.13's +1 px for the bugs; the bot's mining radius starts at 8 px but the light stays 8 px; lichen is decoration only (it takes no loot and gives nothing); a patch starts like a lizard spawn (a random pixel within 64 px of the bot with 8 loot within 8 px), on the nearest surface pixel with no lichen within 10 px, grows at random along the surface; the leaf curls out of the wall from the patch's first pixel, drawn under the fog. Knobs sim.lichen.*, sim.botUpgradeCost, sim.upgradeGain.
• D095 After b4.13 (user): taming a bug releases heart particles; plentiful ore spawns bright green lizards that zip-stop-zip round the cave surfaces mining ore, and after 16 burrow and make one loot in the wall; ore and loot in the wall are specks in the soft or hard rock, not whole pixels. Claude's calls: every 5 s a random pixel within 64 px of the bot with 16 ore within 8 px spawns a lizard on the nearest surface pixel (open, next to solid), 6 at most; a zip is 4–12 px at 20 px/s toward the nearest ore within 16 px, a stop 0.7–2 s mining an ore within 3 px every 0.5 s; the loot goes to a rock pixel with no open one within 2 (the worms' site finder, 1 px); lizards drawn 3 px, over the fog. A speck is half a pixel across at a hashed spot in its pixel, drawn under the fog (only seen ones); the pixel itself is drawn as the rock round it. Six pink hearts rise from the tamed bug for 1.2 s. Knobs sim.lizards.*.
• D094 After b4.12 (user): no particles for the ore fed to wild bugs when taming; wild bugs look like tamed ones, only blue (drawn the same way, over the fog, so they no longer blink out in the dark); red fruit is spent by itself on the tamed bugs' reach, at 16, 32, 64… fruit, the next target shown on the ledger (fruit as count/target), and each upgrade adds another bug icon next to the first on the ledger's bug row. Claude's call: an upgrade adds 1 px of reach (4, 5, 6…; sim.swarm.upgradeReach, cost sim.swarm.upgradeCost).
• D093 Your pull goes for the resource the ledger holds least of (user): among ore, loot and fruit in reach, the kind with the lowest ledger count first, the nearest of it; if none of that kind is in reach, the next lowest (ties: ore, loot, fruit). Bugs keep taking the nearest.
• D092 Fruit doesn't glow (user; replaces D089's glow): it's a red pixel in the world, seen when lit and dim when remembered, like ore. It's still harvested seen or not.
• D091 Worms (user, after b4.11): where red fruit is dense, dark red striped worms 12 px long appear; slower than bugs, they go from fruit to fruit; after eating 8 they burrow into the walls, never at the surface, curl up into an irregular 12 px shape wholly inside the wall, and become an ore deposit. Claude's calls (no pathfinding, like the bugs): every 5 s a random fruit with 6 fruit within 12 px spawns a worm there, 12 worms at most; 3 px/s; the head steps to the open neighbour nearest the nearest fruit within 24 px, else a random open one; the site is the nearest soft or hard rock pixel within 32 px with no open pixel within 2, grown at random into 12 pixels none bordering open (8-way); the worm goes straight there through the rock without carving it; it's drawn over the fog, so you see it burrow; the deposit is unseen until lit or scanned. Knobs sim.worms.*.
• D090 Tamed bugs mine and pick fruit within 4 px, not 2 (user, after b4.10; sim.swarm.reach).
• D089 The garden (user, after b4.9): tamed bugs turn the cave's back wall (open pixels) dark green where they pass; vines grow on green; 12 px of vine make 1 red fruit a minute; fruit is a resource on the ledger, collected by you and bugs like ore and loot. Fruit glows, and if it exists it can be harvested (user): your pull takes it within the light, seen or not; a bug takes it within reach whether you were ever near. A bug holds 8 fruit at most, returned to the ledger at its trip's end (user). Claude's calls, the user saying "keep it simple": a bug greens its pixel and the 4 next to it (green is for good); 1 in 40 pixels turning green starts a vine anywhere on green; a vine's tip grows 1 px every 5 s into green, 8-way, keeping its heading 2 times in 3, and stops with no green round it; fruit appears on a random vine pixel with none (the rate as an accumulator), stays until picked; the nearest unit wins, fruit or tile. All knobs sim.garden.*, sim.swarm.fruitCarry.
• D088 Node discovery (user, after b4.7; replaces D080's nodes near the bot showing): only the network's nodes ever show. The pod's glow until the first edge is built; from then on the network's are quieter (user: "easy to find, but should not overshine everything else"). Claude's calls: before the first edge, a pulsing ring with a soft halo (alpha 0.3); after, a thin ring at half opacity, no halo; the node held or selected still gets a small halo. Corrected after b4.8 (user: "the pod nodes are still visible after building the first network edge"): "the network" means the ends of built edges, so after the first edge a pod node with no built edge hides, and only a shown node can be built from (shipped as b4.9).
• D087 Tamed bugs' trips last 30 s, not 2 min (user, after b4.6: "lifespan" = the trip; bugs stay on the ledger), and they collect ore and loot with your animation (user): the nearest unit within reach is a bug's target, the dust stream runs from it to the bug, and after pullTicks the unit comes out and flies to the bug on your arc, following it as it moves.
• D086 The seismic scan triggers only if a hidden pixel is within its radius (user, after b4.5): pointing into rock with the scan ready fires it only when some rock or cave pixel within scan.radius of its centre is still unseen; the sheet, the sea and space don't count (the scan never shows them). Otherwise nothing happens and no cooldown starts.
• D085 The bot mines while walking (user, after b4.4; D062's pull only ran standing still): the nearest seen ore or loot within the light is pulled whether the bot walks or stands, one unit every pull.ticks of something being in reach; not in a moving car (Claude's call). The pulled unit flies to where the bot is as it moves.
• D084 After b4.3 (user): the bot walks every angle for real, not 8 (b4.3's Bresenham steps kept the average angle but moved in 8-way steps on screen): it has a sub-pixel position that glides along the drag's exact angle at walkSpeed, its pixel is where that position is (open only), and into rock it slides on the move's x or y part alone; keys stay 8-way. Explored but unlit areas are 50% darker: 17.5% bright (fog alpha 0.825), was 35% (D052's dim).
• D083 b4.3 turns b4 incremental (user, after playing b4.2; plan timeline/p11-rail-loop/next-b4.3.md, the last sections win): one ledger in the top-right corner holds every collectible (ore, loot, bugs); no pack. Your mining goes straight to it (user: "no bot > ledger particle stream"). Building: tap a network node, drag to select an edge, release; the edge flashes green; tap it: the price comes off the ledger at once and ore streams from the ledger's icon to the site; short of ore, a red pulse (user). Wild bugs (b3.7's) nibble ore from the ledger and 16 fed tames one (D060, user), which leaves the world as +1 bug on the ledger. Tamed bugs are abstract (user: "no pathfinding, just random walk"): each works trips near random network nodes, random-walking through open air, pulling ore and loot within reach, and sends the haul to the ledger's icons at a trip's end. The light is a fixed 8 px (half of b4.2's; upgrades later), the pull's reach with it; line of sight, rock lit only 1 px deep (user). Nodes are never in rock: a grid vertex whose tile centre isn't open is no candidate (Claude's proposal; user: no fallback). Mid-build, the user: the bot walks any angle, not 8 ways, and the scan's cooldown is 1 s. Claude's calls: the pull's stream from the wall to the bot stays; a trip lasts 2 min, a bug pulls a unit a second at most within 2 px, seen or not; line of sight by Bresenham lines (either way clear) plus the rock 8-bordering the air in sight (a line alone misses flat walls at a grazing angle); the light's last 3 px fade out (drawing only); the selected edge shows its price.
• D082 b4.2 as built (Claude's calls, for the user's play): lit rock faces 4 px deep (b3's one-tile face at 1 px a tile); the light +1 px per 4 ore or 2 loot; nodes drawn as rings so they don't read as tamed bugs; the pack drawn at the top of the screen, not on the 1 px bot; the bug-placing hold is 1 s within 60 CSS px of the bot (E on a keyboard); the sheet and the space above it are never fogged, the sea is. b3.7's bug numbers kept as they are (D081), with seek and the others on the panel.
• D081 b4.2's world is all of v5's map (user), about 240 × 516 px from the sheet down to the ocean, not only the ice layer: the network C and the ore cover the whole depth. At the 1 px scale (D080) what matters is the intent, not D079's numbers (user): the rails are much faster than walking (about 7×; the numbers get tested as knobs), and the light and the node detection radius grow with the scale, "otherwise the player will not find them" (user).
• D080 b4.2's direction, after the user played b4.1 (plan: timeline/p11-rail-loop/next-b4.2.md): the bot is 1 px of v5's painted world (user: "I want to be a 1px character in a world drawn in v5. not a 1 tile character. 1px"), so a b4 tile is one v5 pixel, 4 to a fine cell; D075's 2-tile character doesn't apply to b4's spider bot. p10's network C stays. v6's ice sheet on top, solid (user). b3.7's bugs; placing one is a 1 s hold near the bot, when a bug is tamed (user). b3.7's ore layer and loot, and its hard/soft rock split for how it looks (user: "the visuals of that hard/soft rock was natural, I need that"); it wraps (user). No digging and no rock in the pack yet (user): the pack holds ore and loot, drawn as b3.7's. Unbuilt travel nodes show only within 3 tiles; nodes on the built network stay shown (Claude's proposal, user: yes). Edges are built only from the existing network (user). Walk 3 tiles/s and ride 20 tiles/s, to be tested (Claude's proposal, user: "sure, test it").
• D079 The b4 Rail Loop, settled with the user before building (full loop in the p11 entry): b4 is not a copy of b3 (new generation: p7's quad caves + D078's lattice), reusing b3's probe, pull, pack, light and bugs. Empty pack at start; the pod is its interior open space only, no dome walls (they delete rock and ore); ore and loot from b3's CA ore layer over the quad rock. Drag / A W S D moves the bot through open tiles. Walking into rock scans at once, 3 s cooldown, radius 6; revealed ore in range is pulled by itself (the bugs' particles). A node glows within 3 tiles; a revealed node is close enough to build from. Build gesture on the node: hold = preview its edges (skippable); press and drag towards an edge = select, a red X and a green hammer appear (b3's cue style); release, tap the hammer = ore streams in, the edge and its travel pod get built, the far node is revealed. An edge costs 8–12 ore for now (tuned later). Walk onto the travel pod to get in; a swipe sets a rough direction and the pod runs node to node until it can't go on (stops at the last node), you tap (stops at the next node) or you swipe a new direction (turns at the next node). An edge needn't reach a new cavern, only room to mine the next edge's ore.

Do straight rails on a relaxed grid look good over the caves, and do they run mostly through open air rather than boring rock?

• The caves' own relaxed grid is too fine for rails (edges ~0.9 cells), so A takes chords between
• Nodes in the most open places (A) bore less rock than a grid that ignores the caves (B).

• cutNo buildables, no routing, no choosing: only the candidate rails and their nodes.
• cutHow the rail hangs (ceiling, pylons, free) isn't decided; rails are drawn as lines.
• cutOnly the ice layer.

→ open

• D078 The traverse node layer is v8 mode C (user: "this will be the traverse node layer"): nodes on the caves' relaxed-grid vertices in open air, the most open first, 3 cells apart; edges by the lune β-skeleton at links 1 (the Gabriel graph); each edge a monorail routed in the 8 directions on the tile grid, rock costing ×5 and bends 15 tiles per 45° (the user's settings, now the defaults), +100% for running along an earlier rail, a flat 100 tiles for crossing one.

Is the candidate lattice dense enough to offer real choices everywhere, while each build clears its neighbourhood enough that what's left stays readable?

• p8's candidate links (cheapest per pair of floors, direction and 4-cell stretch) are the right
• p8's clash rule (D073: a crossing, or running parallel within a storey for over 30% of the middle)
• Walls at waists (locally narrowest rock-to-rock crossings of open air, 4 directions) are the
• Airlocks placed automatically where walls cross paths, kept apart by a minimum gap, don't need

• cutNo character, no walking: builds are clicks on the map. Later.
• cutOnly the ice layer, as in p8.
• cutWalls don't change the terrain or the floors: they're drawn over it, and they don't create new
• cutA desktop tool page, not a phone layout.

→ open

• D077 Travel and interact (user): a vehicle travels the path with fast swipes; a spider-bot detaches, crawls everywhere (back wall, walls, ceilings) and builds (walls, gates, bridges); interacting is getting close, at worst a tap. Its shield drains from the environment and from moving; when empty, a visual warning and it returns to the chassis by itself (still casual). Free digging is out (phone-control UX). "Nothing vertical" (D068) applies to the vehicle path only. The back wall is visuals only.
• D076 Walls are 2 tiles thick, like the path (user: "for consistency"), and run in the 8 directions only (level, upright, 45°); where that is restrictive, a wall is built of 2 segments (user).
• D075 The lattice restarts from a blank slate of tile definitions (user; concepts/callisto_lattice.md): space, solid, semi-solid (bridge, gate), void; the path (tiles the character moves through) is kept apart from the floor (the solid it walks on), and we map the path. The character is 2 tiles high, and so are dig tunnels and the path (user: "I accept the side effects, I want to lock in the 2 tile high char"); 1-tile passages are no longer path until dug (supersedes the 1-cell headroom of D072). A gate is an upright 2 × 1 semi-solid block in the path, solid directly above and below, open on both sides; it closes level and 45° paths alike. Walls are built solid straight lines, both ends on solid, at most 24 tiles (config).
• D074 The lattice is shown as candidates, not as a chosen network (user: "a dense network of potential pathways (and walls), that the user can choose from"; p8 drew what good choices would build). Candidates: p8's links, plus walls at waists. A build collapses what clashes with it: p8's D073 rule for links (natural floors count from the start), no wall within a cell of a wall, no airlock within a gap of another. Airlocks are plank-behaviour blocks (pass through, stand on), placed automatically where walls cross paths, and discouraged in close proximity (user).

Does a storey pass over the settled quad caves give a lattice that mostly runs on natural cavern floor, reads as clean storeys, and needs few bridges and tunnels?

• The ½-storey follow rule keeps storeys on natural floor most of the way, with 3-cell storeys.
• One ramp per storey pair, near where the storey above started, is enough to reach the whole ice
• Every seed has natural floor for the pod (10 cells wide, level within a cell) near the centre,
• Merging storeys closer than ½ storey keeps the picture clean (no near-parallel lines).
• The pass is cheap: well under 50 ms a map on top of the WFC.

• cutNo character, walking, building, walls, airlocks or candidates: only the storeys. Later.
• cutOnly the ice layer. The pudding and brine come when the storeys hold up.
• cutCatwalks for prospecting (the highest storey under a ceiling) aren't placed yet.
• constraintStoreys follow floors column by column with a 45° smoothing pass, not cavern by cavern:
• cutA desktop tool page, not a phone layout.

→ open

• D073 Built links branch only when needed (user: "branch only when needed to, not before"; no X crossings; no paths "running in parallel 2 and 3 blocks from each other"): a link that crosses a chosen link, or runs within a storey of floor or a link going the same way for over 30% of its middle, is refused, unless nothing else reaches a floor. Walks got longer: detour median 1.63× → 2.09×.
• D072 A floor is any natural stretch the character crosses in one run (user), with 1 cell of headroom (user: the character fits). Cutoffs prefer removing rock to building walkway (user: "removal is preferred"). A floor piece running within ½ storey of a longer one for most of its length is left out (user: "only one path is needed"). Divergence points only at forks.
• D071 The lattice pass is floors first, links second (user's four notes on seed 5512; OK'd): cavern floors are the nodes; tiny cutoffs (up to 3 cells, end to end) first join floor pieces into longer floors (user's tip); then a spanning tree of the cheapest links (sideways within ½ storey, 45° ramps that may carry on sideways) from the pod; then links are added while the walk from the pod to a floor is over 1.5× the straight line; divergence points only at forks and ends. Storeys no longer span the map: they're as long as the floors they chain (amends D068). Supersedes the storey lines of D069 and D070.
• D070 The storey network grows up from the pod as well as down (user: "in early game, the player wants to manually collect a lot of materials, not picking up, what's above our head does not make any sense"): a second chain of ramps up, stopping when a ramp's foot has no headroom under the crust; an upper storey dips under the crust at 45° where it would break through. A storey merging into the one it came from now joins it at 45° (the dead ends were a bug).
• D069 The storey pass is built (p8, v6.html) over p7's settled caves, per D068. Storey height 3 cells (user). The pod is a dome 8 + 2 wide and 4 + 1 high that cuts into the ceiling and may sink up to 2 cells into a floor that rises under it (user: "cavern floor is not expected to be THAT flat and level"); placed on natural floor near the centre, in the ice under the crust, on every seed. Claude's calls while building: storeys follow floors column by column with a 45° smoothing pass; walkable floor needs 2 cells of headroom; floors under 2 cells aren't followed; one ramp per storey, a storey ± ½ long, within 15 cells of the storey's start, landing on floor; merged columns are dropped; the pod searches the central sixth first. Measured: 26% of storey length on floor, 36% bridge, 38% tunnel.

Can a hex WFC with code-generated tiles and Markov-weighted pairing produce layered, organic-looking, horizontally tiling caves, with no visible grid and few contradictions?

• Tiles generated by code from a few shape families give enough variety, with no hand-drawn tiles.
• Markov-weighted pairing makes structures continue (corridors run on, caves cluster), so the result
• Snapping each tile's edge band to its sockets, with noise only inside, hides the hex grid and still
• Layers emerge from depth-dependent weights and materials in one pass, with natural transitions.
• Contradictions are rare enough that restarting is fine (a few restarts per map at most).
• A 16 × 32 map generates in under 100 ms in Node.

• cutThe lattice: candidate tunnels, bridges and walls left uncollapsed. Next prototype.
• cutNo character, traversal, building, ecology, bubbles, relics or light. Later prototypes.
• cutReachability isn't enforced, only measured (cavity statistics per map). Enforcing it comes with
• constraintGraphics are deliberately crude ("a 6-year-old in MS Paint", user): flat colours, black
• cutA desktop tool page, not a phone layout.

→ The user: "Let's go with this one" (2026-09-27): the quad WFC on the relaxed Townscaper-style grid, with the defaults as they are now (seed 12227's setting, flat floors and flat ceilings 1.75). The hex WFC answered the Question with a partial fail (it works, fast and seamless, but the grid shows); the quad WFC passes the user's eye ("looks like real caves, not game design"; "great for gameplay"). The layer roles aren't judged yet, and the cave/tunnel skeleton wasn't needed for now: the user got rooms and thin walls from the knobs.

• D068 The navigation lattice is storeys (user: "humans think in storeys"): mostly horizontal paths across several caverns, linked by single 45° ramps; nothing vertical ("vertical paths literally break the flow"), so no ladders or shafts. A storey follows cavern floors: if walkable floor in the next cavern is within ~½ storey of its Y in the cavern before, it takes that Y, otherwise it crosses as a bridge or tunnel ("we want to run on cavern floors whenever it's possible"). Divergence points are set by the target (where a link lands best), not the start. The network grows from a large pod underground (never the surface): storey 1 from the pod, each deeper storey from the foot of the ramp above. The pod sits right below the map's thin surface layer with a rugged ice sheet drawn on top (drawing only). Catwalks exist for prospecting ceilings from below. Vents have no pipes. No "go there" taps ("it kills the immersion"). Generation: storeys are a pass after the quad WFC (Claude; the WFC can't see "the Y one cavern before"), superseding "the lattice is WFC". Claude's defaults: storeys closer than ½ storey merge; storey 1 runs on the pod floor. Full text: concepts/callisto_design.md, Storeys.
• D067 The caves come from a WFC on the small quads of a Townscaper-style grid, not on the hexes (user: the hex grid was "clearly visible, no amount of wobble fixes that"; then "build the WFC in the small 4-corner cells, not on the bounding hexes"). The pointy-top hexes stay as the base: each is cut into triangles (3 to a side), random neighbouring triangles in a hex pair into quads, every face is subdivided into quads, and the whole mesh is relaxed as one, so the big hexes bend too (user). A quad's tile is its 4 corners, open or rock, and neighbours agree on shared corners; weights by depth band and Markov affinities to collapsed neighbours; drawn by marching squares. The user: "looks like real caves, not game design". Claude's calls: the entropy order by a heap; saddles allowed but rare, so no contradictions; the quad knobs are their own set (QKNOBS); the hex-only corridor knobs have no quad equivalent yet. The hex WFC stays on the page as the other generator.
• D066 The hex cave generator is built (p7, v5.html), per the p7 spec: WFC on pointy-top hexes, 16 × 32 wrapping horizontally, 3 sockets per side, 486 tiles generated by code from shape families, Markov-weighted pairing by class, depth bands as weights and materials (surface, ice, pudding, brine, ocean), a 160 × 291 fine grid with the socket band snapped and noise inside. Claude's changes while building, not discussed: each class keeps its whole base weight among the tiles still in the domain (otherwise open floods the map); a "rock grows" knob symmetric to "caves grow"; openness weighs solid against open only; noise about 2 cells, not 1; a pocket stays a tile though its sockets equal solid rock. Measured over 100 seeds: restarts median 2 (max 21, no failures), 70 ms median, 176 ms p90. The user judges the Question from the page.

Does taming bugs that mine what you've revealed turn exploring into a loop you want to come back to?

• Losing wild-bug nibbles from your pack reads as cute, not as punishment: the hearts and the taming at 16 make it an investment.
• Tamed bugs mining only what you've revealed makes the probe a tool for your bugs, and gives exploring a purpose.
• Collection by running past (no stopping, no menu) is enough of a hand-over.
• Walking home without a teleport is a triumph, not a chore, once your own tunnels lead there.
• The friendly areas make your territory readable at a glance, and pleasant to come back to.
• Ore with no use yet doesn't kill the motivation to collect it, for now.

• constraintNo use for ore or loot, on purpose (D054).
• constraintNo teleport home.
• cutSave and offline piles at the base: step 5, after this.
• cutOutposts (the 1 s hold) and PvP uses for ore and loot: later.
• cutNoise, the other loadouts, and the "why go home" drill.

→ Open.

• D064 The TODOs after playing b3.6 (user's list; ruleset b3.7, the b3 default; next-bugs.md's eighth pass). The first to target an ore keeps it: you and placed bugs never pull the same cell; the others take their next nearest (user: "ok"). Reserved pack slots: 1 each for ore, loot, soft stone and hard stone, the other 2 free for anything (user: "1-1 for ore, loot, soft stone, hard stone, the rest is ffa"); a unit goes to its reserved slot first, a full one overflows into the free ones, and units are taken from the last slot, so the free ones empty first (packReserve). You leave home with 8 stone, every time (homeStone): banking tops the pack back up to 8, the 8 don't count as brought, and walking home with just them logs no dive. Taming progress fills the bar's next free slot as a 4×4 grid of ore, 1 cell per bite, like a pack slot (user: "perfect"). A placed bug whose area has run out (it has pulled, and no seen ore is left within its reach) comes to you through the caves, hands its ore over and goes back into the bar (user: "seeks: yes"); only when a bar slot is wholly empty, taming not even started in it (user, while it was being built: "tamed bug with no ore to mine left only seeks out char if 1+ bug slots are completely empty (not even taming started)"); otherwise it stays where it was placed. Its slot is held for it on the way, so no taming takes it. Claude's defaults, shown to the user with no objection: the 8 are soft stone; "run out" means no seen ore left within reach; a returning bug moves like a chaser down the field at the bar bugs' catch-up pace (6 ticks a cell), waits at its den while you're beyond the field (20 steps of open cave), jumps to you if the field loses it on the way, and joins the bar once it's empty and within the hand-over's 4 tiles (with your pack full it follows you until it can hand over).
• D063 Placed bugs mine, and the dust stream (session 3, second part; ruleset b3.6, the b3 default; planned in next-bugs.md's seventh pass, OK'd by the user: "a: ok", "2: R=4"). A placed bug pulls ore like you do (D062): the nearest seen ore within 12 of its den, through the wall, and the cell turns to the rock round it; ore only, loot stays yours to pull; 4 a minute (1 per 900 ticks). It carries 8; full, it stops pulling and waits, its halo swelling slowly. Hand-over (user: R = 4): you within 4 tiles (straight distance) of a placed bug with ore take it, one unit every 6 ticks, without stopping; with your pack full, it waits. The dust stream (user's addition): while a pull is under way, a thin trickle of specks in the material's colour flows along a slight arc from the cell that goes to the puller (you, from 0.5 s after you stop, so short stops don't flicker it; or a placed bug whenever it's pulling); none with nothing in reach, a full bug, or while you move. The sim keeps the target (g.pulling, bug.target), picked by the pull's own code, so the stream points at the cell that goes; the dust is drawing only, from time, on screen only. The existing flight shows each unit: wall → bug on a bug's pull (quiet, since it may be far off), bug → you on a hand-over (a soft tick). Claude's calls, not discussed: the numbers live in numbers.bugs.mine (ticks, reach, carry, hand, handTicks), so older rulesets' placed bugs only hover; a bug counts its 900 ticks only while it has a target, and a hand-over comes before its pull in a tick; the specks flow at 3 tiles/s, 3 per tile of stream. Refrozen after play (user: "the bugs particle stream is doing some back-and-forth movement, whereas the char stream is perfect"): a bug's stream ends at the middle of its bob, not at the bobbing dot, so the arc holds still. A way to take a placed bug back is still a TODO.
• D062 Pulling, and the bar calms the chasers (user's design, session 3; ruleset b3.5, the b3 default). Mining single ore cells by hand fights the "tidy, regular hallways" goal, since the controls follow loose intent. So standing still, you pull ore and loot out of the walls the way placed bugs will: 1 unit every 5 s, and the cell turns to rock, so no gap is left. Each tamed bug in the bar keeps one wild chaser away, so you can collect in peace: chasers = 3 − bugs in the bar, and the bar has 3 slots (user), so a full bar leaves you alone. Bar bugs roam round you like normal bugs instead of circling (user: circling is annoying). Claude's defaults, OK'd by the user: you pull seen ore or loot within your light radius (straight distance, through the wall, so buried ore a probe showed counts), the nearest first (ties to the lowest cell index); still means no step and no run, or a probe in progress; any move restarts the 5 s; with no room for it, a cell is skipped for the nearest one that fits; the cell becomes the most common rock among its 8 neighbours (soft on a tie or none); the ore flight (wall → you) in the material's colour is the only cue; manual mining is unchanged. Roaming, revised twice after play. First (user: the bugs were hysterical, their speed, random walk and need to stay close annoying; keep some distance, add inertia so they're not fizzing like gas molecules) Claude kept them 2 to 5 steps off with pauses, which jittered: a pause snapped the drawing back a cell (a bug, fixed). Then the user: fly 2 to 8 from the character, deprioritise 180° turns and 1-step runs. Now a bar bug keeps 2 to 8 field steps from you, a step every 12 ticks, twice as fast while catching up, and never pauses. It keeps its heading: a voluntary turn 1 step in 6, only after 2 steps straight. A turn it must make takes, by preference: a side turn with room for 2 steps, any side turn, straight back with room for 2, then straight back. Outside the field (a long fall, more than 20 steps) it jumps to your cell. It lights from its own cell. Wild bugs are unchanged. Over the cap, the farthest chasers stop chasing. The pull code (pull.js) is shared with step 3's placed bugs.
• D061 Wild bugs live in the fog (user's design after playing b3.3; ruleset b3.4, the b3 default). The world is cut into fixed 32×32-tile blocks (x wraps like the world; today's 384×71 world is 12×3 blocks, the last row 7 tall). The 64 blocks nearest you (by their centres) each hold 1 wild bug, in a dark open cave cell of the block: not lit now, not within 12 of a placed bug, at least 4 steps from you. Blocks beyond the nearest 64 lose theirs. The bugs live in the sim, so they're deterministic. At most 3 come for your ore at once, as in b3.3. Only bugs on screen are drawn, so zoom decides how many you see. Wild bugs go between a flicker of 3–5 s and dark for 5–9 s, each length drawn anew per cycle, so they aren't constantly visible; their R 2 light follows the flicker. The shared taming count, the bar, the hold and placed bugs are unchanged (D060). This replaces b3.3's spawning near you (max, spawnTicks, despawn). Claude's defaults, shown to the user with no objection: a block whose bug is tamed or gone gets a new one 5 s later, at a random dark cell of the block; wanderers drift around the open cells of their own block and never leave it, so they can sit in caves sealed off by rock and hint at them; the chasers are the nearest wanderers that can reach you through open cave within 20 steps; a chaser still counts as its block's bug (no refill while it's out); the flicker fades in over 0.5 s, flickers irregularly at 60–100%, and fades out; dark means no dot and no light; a bug next to you glows steadily, a scared one flickers fast, tamed ones glow steadily; the blink timings come from a hash of the bug's id and its cycle number, in drawing only. Claude's calls, not discussed: a block with no dark cell tries again 5 s later; a chaser the field lost wanders again if it's back in its block, and is gone otherwise (its block refills 5 s later); only chasers nibble; the numbers are block, blocks, chasers, refillTicks and near.
• D060 The tamed side, redesigned after playing b3.2 (user's design; ruleset b3.3, the b3 default). Several wild bugs split the nibbles, so none got to 16. Now every nibble by any wild bug counts toward one shared total; at 16, the bug that took the last bite is tamed, and the count restarts. A tamed bug goes into the bug bar: b1.1's row of slots along the bottom edge is back, 4 slots, filled from slot 1, drawn amber (the backpack stays on your back). With the bar full, nobody is tamed. A bar bug circles you and lights R = 2 like your light, seen for good; it doesn't mine. The 1 s hold is back (the charge ring at the finger): it places the bar's first bug at the open cell nearest to 2 above your head, and the bar shifts left; with an empty bar it does nothing. A placed bug is the mining utility, covering R = 12 (D056's den; it mines in step 3), keeps its R = 2 light, and no wild bug comes within 12 of it. Taking one back is a TODO. Wild bugs show everywhere, never-seen areas included, and light R = 2 like your light for the moment they blink on; that light never makes anything seen. This supersedes D059's per-bug count and taming on the spot, and D056's "tamed where it is" and wild bugs kept away from tamed bugs (now: from placed bugs). Claude's calls, not discussed: a bar bug circles in 12 cell steps two out, one step every 10 ticks, lighting from its cell when open, else from yours; placing looks up to 4 rings out; the hold's command is place (report code p); with the bar full, the count waits at 16; a placed bug plays a falling chime.
• D059 D056's wild bugs as built (ruleset b3.2, the b3 default), plus the user's addition: a tamed bug turns a warmer colour, so tamed and wild read apart at a glance (amber; wild ones are cool blue). Claude's calls, not discussed: a bug sits in an open cell (not the sky) and drifts one cell every 12 ticks (5 tiles/s, slower than your walk) down a flood through open cells, 20 steps deep, and stops next to you. Up to 3 wild bugs; one may appear every 5 s, in a cell you could reach, at least 4 steps away, not lit now, and never within 12 tiles of a tamed bug. Next to you (8 around), a wild bug nibbles 1 ore every 40 ticks, from the last ore slot: an ore flies from the pack into it and a heart pops. The 16th tames it on the spot, which is its den. A probe ring that passes a wild bug scares it for 4 s: it drifts away from you and doesn't nibble. A wild bug caught inside a new den area drifts out and doesn't nibble there. One the flood lost wanders, and it's gone past 28 tiles. Wild bugs blink like fireflies (1.4 s on, then dark), steady next to you and flickering while scared; tamed ones glow steadily. Tamed bugs stay at their den until step 3. The ore flight and the hearts stay on with the juice off, since they show where your ore went.
• D058 D055 as built (ruleset b3.1, the b3 default). ↓ on a floor is the meaning probeBelow and ↑ into rock is probeAbove: the probe's rings spread from the block under or above you, with the same reach, and the ceiling stays rock. Ring 1 now holds the centre cell too (your own cell before, already lit, so b2.1 plays the same). The number teleport: false turns the teleport off: the command does nothing, and a deep fall lands with the stop fell. Claude's calls, not discussed: stepping onto the home cell with anything in the pack counts it in and logs the dive (the dive log shows, the light goes back to base); walking past home with an empty pack logs nothing. Home is drawn as a plain orange pod, 2 tiles wide, on the home cell, since you now walk back to it. In b3 a long press does nothing (no ring), and Numpad 5 is a tap only (stop).
• D057 Not built yet. The friendly area (user's design): a tamed bug's area becomes friendly. It's a bit more lit, the walls get mossy, bulbs and red grass grow on the floor, and glowing lichen grows on the ceiling, drawn as basic as the character ("do not complicate it"). Claude's proposal, accepted: it covers the 12-tile radius, open cells and the rock faces bordering them; the lichen is its light, dim but lasting, between seen and lit; each cell's decoration comes from a hash of its position; it spreads out in a ring over a couple of seconds after taming; it marks where wild bugs never come. Claude's defaults: the whole radius, not only seen cells; tunnels dug later get decorated; overlapping areas merge.
• D056 Not built yet. Moon bugs (user's design). They're like fireflies: no physics, dim lights that blink in and out; they don't burrow, and they ignore planks. Wild bugs appear in the dark, never inside a tamed area, drift toward your glow and nibble ore from your pack, never loot, popping little hearts. The probe shoos them off for a few seconds. One that has eaten 16 ore is tamed. Tamed bugs work within 12 tiles of where they were tamed. They suck any seen ore in range (buried and hard rock included) through the wall at 4 a minute, carry 8, and the ore's cell becomes rock (the rock it was generated from, else its neighbours' most common). One simple particle effect shows every ore transfer: wall → bug, pack → wild bug, bug → you. You run past, and a bug's ore flies into your pack when you're close, without interrupting you; with a full pack, it keeps glowing. Offline: up to 32 ore per bug per 24 h, left in piles at the base, once saving exists (a later step, browser or portal storage).
• D055 Not built yet. The probe (user's design): it's centred on the probed block, not on you. ↓ probes around the block under you, and ↑ into rock probes the ceiling around the block above, with the same reach (replacing D043's mine-above). You build planks to reach a ceiling. The teleport home goes, and a deep fall just lands, with no damage (Claude's default for D035/D036, casual). When built, this changes D053 and supersedes D043's ↑-into-rock and D035/D036's teleport.

Does darkness, with a light that grows with your loot and a probe that sees into the rock, turn digging into exploring?

• Standing still while the probe's rings spread is enough of a cost while there are no bugs: you probe to choose, you don't spam it.
• A light radius that grows with the ore and loot in the pack is felt, and pulls you on.
• Light that spreads only through air (it shows surfaces, never inside rock) reads naturally, and the probe is the way into the rock.
• The dim "seen" layer is enough to find your way; no map screen is needed yet.
• Fixed zoom steps (the pack's pixel-exact tile sizes) feel fine with the wheel and with a pinch.

• constraintOne loadout (the Engineer), and darkness and the probe alone: no bugs, no noise.
• cutMoon bugs, noise, the Demolitionist and the Ghost, and the "why go home" drill: the rest of Bundle 2, after this.
• cutSoft light edges and glow: hard tile edges for now (user: "this is a prototype, not the game itself").
• cutA map screen or pause: the zoom levels are the map for now.

→ Open.

• D054 The theme pivots after playing b2.1 (user's call). Swipes make tunnelling and exploring easy, but mining by hand is messy, so tamed moon bugs do the mining while you explore, prospect and build the tunnel network. Bugs are cute annoyances and are never killed. Nothing teleports you home: walking home with the loot, through your own tunnels, is the triumph. The 1 s hold is kept for outposts (TODO). Ore and loot have no use yet, on purpose ("a gaping hole there is perfect"); PvP uses come later (King of Thieves-style). This pulls Bundle 3's idle production into Bundle 2, away from the vault and raid path. p6 builds it as b3, forked from b2.1. The design is in p5-darkness/next-bugs.md.
• D053 The seismic probe (user's design). ↓ while standing on anything but a plank reveals everything around you, rock interiors too, for good, in growing concentric rings. A flick probe reaches light + 2; a held probe keeps growing until light + 4, reached at 0.7 s (about 5 ticks per ring, Claude's), or until released, and it always reaches light + 2. A probe that started always ends; a tap doesn't cut it (user: don't complicate it). The character stands still while the rings spread: the probe's cost until noise and bugs exist (Claude's proposal, accepted). At a ledge edge, ↓ still climbs down over the ledge (the ledge wins, accepted).
• D052 Seen and lit (Claude's proposal, accepted): what the light or a probe revealed stays seen for good, drawn at about 35% brightness; what's lit now is full brightness; what was never seen is black. The lit edge is hard, whole tiles (user: fine for a prototype).
• D051 Light (user's design): a radius of 4 tiles, plus floor(ore / 16 + loot / 8) from what's in the pack (the sum is Claude's, accepted), so it resets when the pack is emptied at home. It shows surfaces only: it spreads through open cells within the radius and lights them and the rock faces bordering them (through air, Claude's proposal, accepted). The surface is always lit.
• D050 Zoom (user's call): the view steps through fixed tile sizes, 10, 12, 14, 16, 17, 18, 20, 24, 30, 40 and 48 device px (the sizes where the backpack is drawn pixel-exact), with the mouse wheel and a two-finger pinch, centred on the character. Never the browser's or the OS's zoom. The default is more zoomed in than b1, since there's little to see at first (user): the size closest to 24 tiles across the screen's short side (the 24 is Claude's).
• D049 p5 is b2 with one loadout (the Engineer) and the exploration mechanics only: darkness, light and the probe. No bugs, pets or idle play yet (user's call). p4 stays open and isn't called a success: the Rule Lab is a tool the tuning so far didn't need (user). b2 is a new bundle forked from b1.7; b1 stays as frozen.

Can the swipe table and stop rules live as a JSON ruleset, edited visually against small example situations, without losing any b1.2 behaviour?

• Every b1.2 behaviour fits a first-match decision table: (swipe, situation) → action, over a small, fixed vocabulary of named conditions (next cell open, floor below, headroom, standing / clinging, drop ≤ N, …). Held: 11 conditions, 18 rows. The one catch, "mine first, then look", fits by keeping sequencing inside a meaning.
• The data-driven sim stays deterministic and passes every current dig test unchanged. Held: identical to resolve() on 48,000 random actions, and the determinism hash is unchanged.
• Seeing a rule's situation (a small map, the swipe, the result) beside the rule makes changes faster and safer than editing code.
• A ruleset JSON is small and readable enough to diff in git and paste into chat, like a terrain recipe. b1.2.json is 73 lines, one row or situation per line. Is it readable enough for you?
• The same situations (small ASCII maps + the expected result) can be both the editor's previews and the test suite. Held: rules/examples.json (they're called examples now: "situation" became the name for a condition set).
• The timeline's "Rules at close" table can be generated from the ruleset instead of written by hand. Held: the <!-- ruleset: … --> line.

• constraintNo new mechanics: p4 only represents and edits the rules b1.2 already has. The Engineer is still the only character.
• constraintThe condition vocabulary is fixed in code. The editor combines conditions, it can't invent new ones. A new condition is a code change with a test.
• cutTerrain editing: that stays in the v2 / v3 recipes.
• cutZipline, chasm crossing, the chasm-cling fix, Ghost and Demolitionist: these go to the next dig playtest, built on rulesets.
• cutPhone layout for the editor: it's a desktop tool. The rulesets it makes are played on every device.

→ Open.

• D048 The hold check is 0.2 s, not 0.3 s (user's call, refines D046 and D047): at 0.3 s a held swipe walked 3 blocks before its first pause, since a walk step takes about 0.12 s; now it's 2. The same check covers hold+swipe, and the teleport ring now shows after 0.2 s of holding still and fills in 0.8 s (the teleport still fires at 1 s). The risk, accepted: a lazy flick whose finger stays down past 0.2 s becomes a hold.
• D047 Flick and hold as built (D046, ruleset b1.7). The teleport ring shows nothing for the first 0.3 s of holding still, then fills in 0.7 s, so a hold+swipe has 0.3 s with no confusing animation (user's call). Letting go of a hold cancels a dig or build in progress (nothing placed, no rock spent), while a move in progress finishes, so you always stop on a whole cell (user's correction of Claude's first reading, where the step always finished). Until the input says hold or release, a run takes the steps a flick and a hold agree on and waits where they differ, so the ramp mouth works; the cost is up to 0.3 s before a flick walks down a dip (Claude's proposal, accepted). A held run ignores the stop switches (wall, crossing and the rest), since every held step is already deliberate; the always-on stops still apply (Claude, accepted). It ships as b1.7, a new feature (Claude, accepted). Claude's calls, not discussed: a flick walks up a step you could walk up on any run, so a tunnelling run no longer stays level through one (D042's "a tunnelling run keeps level"); a flick that only a hold could continue stops with "?" (reason hold), never red; with keys, the keys down give the direction and letting go of one doesn't change it; a held run pauses holdPauseTicks (18) after each step. Examples take "hold": n (held for n steps, then let go).
• D046 Not built yet (next session). Flick and hold (user's design; the timing and input details proposed by Claude and accepted). A flick follows the world: it walks the terrain, tunnels into walls, and walks up and down steps and ramps. It never builds and never digs a step you could walk up; where it would have to, the run stops ("?"). A hold draws a straight line: it keeps the swipe's exact direction and height, lays a plank where the floor is missing (a 1-deep ramp mouth too) and digs a step in the way. It takes a step, pauses 0.3 s, and stops when released, always after a whole step. Nothing asks for confirmation any more. Building is a high-value precision action you don't do often, so holding feels like control, not a chore (user). A hold is a finger still down 0.3 s after the swipe registers. Walking and tunnelling start at once; a building or step-digging step waits for that moment, so the shortest hold is exactly one step. Hold+swipe is the same intent as swipe+hold. The teleport long press goes from 0.7 s to 1 s. Keyboard: tap = flick, held = hold, for every key (WASD no longer walks while held). The controls are unusual, on PC especially, so they need a tutorial (TODO). From a screenshot: there was no way to bridge over the mouth of a down-ramp. When built, this supersedes D041 and D044.
• D045 The crossing stop (the user's call, from a screenshot; the exact rule proposed by Claude and accepted). The only place two ways meet is where a plank path crosses yours; there's no natural crossing in the caves (user). A walking run stops in front of the first cell under a plank, so → (walk on under it) and ↗ (climb onto it) are both one swipe away. Walking on under a row of planks doesn't stop again. It's the stop switch crossing, on in b1.6 (example plank-crossing-stop).
• D044 A yes covers only what it was asked for (the user's bug report, tick 3900; the fix proposed by Claude and accepted). It allows the kind of action it was asked about (dig or build), and only while the run keeps doing it; once the run does anything else, the next thing that asks, asks again. A 5-wide bridge still asks once. Before, a yes to dig a step also let the same run bridge a gap without asking (example dig-yes-not-build).
• D043 The ceiling (user's design). ↑ into rock mines it and stays put. ↑ with a plank's tread just above your head (your cell holds one) climbs onto it (Claude read "a plank there" as this). ↑ into open air asks, then builds a plank ladder up. ↗ mines and stays only where the rock ahead-up has no floor under it (an overhang); with a wall under it, ↗ is a tunnel up as before (user's rule).
• D042 → and ↓ (b1.6). → never steps off a ledge: at a gap it asks to bridge, then lays a plank and walks on; ↓ is how you drop (user's call). A fresh → at the foot of a step you could walk up asks, then digs it; a run arriving there walks up it (Claude's proposal, user agreed: a fresh swipe is literal, a run follows the terrain). A tunnelling run keeps level through such steps (Claude). Clinging, → into open air still refuses (Claude). ↓ on a plank drops through it if the floor is within harmlessDrop, else asks and builds a plank ladder down, a rung per step, until the rest is a safe drop (user's call).
• D041 Asking first (user's design): a step that builds (a plank) or digs a step you could walk up doesn't happen straight away. The run stops, and the swipe disc blinks what it would do. The same swipe again does it; there's no timeout, so the player has time to learn it until it becomes a habit. Normal tunnelling into a wall 2 or more high never asks. Claude's calls, not discussed: any other command cancels the question; once confirmed, the whole run is confirmed (narrowed by D044); with no rock, a fresh swipe refuses at once (flash), while mid-run it asks first (D030). Holding a swipe will count as confirmation (precise mode, a TODO in input.js).
• D040 Fewer stops (user's call): breaking out into open space, harder rock, ore and loot no longer stop a run; they felt unjustified in play. The junction stop (D024) goes too (Claude's proposal; the user didn't object). A run stops only before it starts changing the world in a new way (walking reaches rock: wall), to ask (D041), or on the always-on stops (ledge, floor, falls). Walking includes 1-tile steps up and down, so a bumpy floor never stops a run (Claude, after the user asked for a simple fix to stopping at every lump).
• D039 Stairs are planks (refines D029; the user's stair, named "plank" by the user, the tread model proposed by Claude). A plank is a tread along the top of an open cell: you stand on it from the cell above, or walk through its cell under it. Nothing digs it, since moves pass through. Falls land on it, and it isn't a wall to cling to. Every build places a plank (user's call: all planks for now); solid Built stays for older rulesets. It fixes the tick-6659 crossing: ↗ lays a plank at the top of the ↘ tunnel, and the ↘ tunnel stays open under it (example plank-crossing). On a plank ramp, → follows the ramp you stand on; from the floor it walks under it (found in the examples, Claude). Ruleset b1.6 is the new default.
• D038 The backpack (user's design): 6 slots of 16 units, drawn as a rectangle on the character's back, 2 slots wide by 3 tall. A slot is a 4×4 grid that fills row by row from the bottom, and slots fill in the same order. It mirrors with the facing, and one unit is 1/12 of a tile. All materials are collected, and a Built tile mines back to soft. A unit tops up the first slot of its material with room, else takes the first empty slot; slots keep their place. Building costs 1 rock per tile, soft before hard, never ore or loot (refusal noRock, which was noOre). With no room, rock is dropped and mining goes on, while ore and loot refuse (packFull). The bottom strip is gone. Ruleset b1.5 is the new default; migrate() upgrades older rulesets. Later: zoomed out, the pack scales up past the character's proportions to stay legible.
• D037 Every playable version is on the timeline, at all times (user's call). Pushing a changed b1 freezes the next build (b1.N+1) onto the open entry's card with a tag. The pre-push check refuses an unfrozen b1 (R13), and npm run ship does the freeze and the push. A card can show several live-dev links (p4: the Rule Lab and b1).
• D036 A deep fall shows its way home (user's call): at the bottom, the character turns red and the teleport charge ring fills around it over 0.7 s, the long-press animation. Then it teleports home. The sim holds the character there for those ticks (42), so replays match.
• D035 Clinging above a chasm, and gravity (ruleset b1.3, the new default). Any mining is allowed, even the wall you hold, with the standard mine, check, move. ↗ ↖ toward the wall you cling to works like standing (climb the step, or mine up into it); ↘ ↙ into rock mines like any ↘. Gravity: after each step, if nothing holds you (floor below, wall left or right), you fall straight down to the first floor. Deeper than harmlessDrop, you land, then teleport home (the pack is banked). This is a deliberate exception to D011: it follows a series of choices, not one wrong button.
• D034 The stop cue is a plain "?" on the disc, in the run's direction, for every stop. A symbol plus a badge was too much to read in 0.6 s. The player wants to stay in the flow; the developer reads the exact trigger in the bug report.
• D033 Stops get the swipe cue too (user's call): when a run stops on its own, the disc appears in the run's direction showing what the next step would do (arrow, stairs or pickaxe), with a "?" badge. It's white, never red, because it isn't a refusal.
• D032 The swipe cue (user's design): a small opaque white disc appears one step from the character in the swipe's direction (beside, above, below or diagonal) and shows the attempted action as a negative symbol: an arrow for a walk or climb, stairs for a build, a pickaxe for a dig. It fades out in 0.6 s. It's red when the attempt is refused. The red flash moves from the refused cells to the disc, and the backpack flash stays for now. It shows on a swipe's first outcome, and mid-run only for flash refusals.
• D031 Bug reports remove the guesswork (user's call). The 🐞 button (bottom-left, key B) copies the last 5 swipes: the raw gesture, the intent, the ruleset row for each step, the stop and what it tried, the map where the last swipe started, a Rule Lab example, and a REPLAY line with every command and its tick. npm run replay reproduces the dive exactly and checks it. The raw gesture, replay and example parts were proposed by Claude and accepted.
• D030 A refusal for lack of ore or pack room (noOre, packFull) in the middle of a run gives way to the stop the run would have made anyway: it stops quietly, with no flash. It refuses (and flashes) only when the action would really have happened: on a fresh swipe, or when no stop rule catches it. Found from the first b1 report on the Rule Lab rules: ↗ up a staircase flashed red at the top.
• D029 Stairs (user's design): a normal block that the intent decides, walked through or climbed on, and some build or mine actions place one. It needs a per-intent tiles section in the ruleset and a new tile, so it comes after p4. p4 ships without stairs.
• D028 A dig ruleset is one JSON file with separate sections that refer to each other only by id: swipes (gesture → intent), situations (named all-of condition sets), the table (per intent, first match: situation → meaning), refusal signals, stops, numbers. The order is swipe > situation > meaning, because "ahead" is the swipe's side (proposed by Claude; the user asked for the separation and in-place validation, and didn't mind the order). Meanings are fixed code bundles that the table picks, so sequencing like "mine first, then look" never becomes data.

b1.1 rules b1.2 #1 59.0s ore 0 loot 0 depth 12 mined 11 built 0 | noOre:5 floor:1 wall:4 open:1 down:3 | preset d6525b