Progress Report

The second sitting of the Claude24 run was set up to test whether hooks were being gated on a PERSON. They
are not, and the real answer is more useful. Market Row has three NPCs standing in it and fires on the
first attempt; the Ashfen Moor was empty and fired on the first attempt. What every two-attempt case
shares is that the scene offered a plausible extra requirement and the Game Master took it. The South
Gate guards defer to "the old man's to tell, not mine". The Barrow Entrance runes draw an invented "you
cannot read them; that would want Runecraft". Neither authored key names a person or a skill. Both ask
for an examination and a sentence.

So the model appears to treat an authored condition as necessary but not sufficient, and to supply the
missing sufficiency from whatever the scene makes available. Where there is nothing to defer to, the same
condition stands alone and the hook fires at once. If that is right the repair belongs in the rule that
says what a key IS — that the authored condition is the whole of the gate and no further requirement may
be invented — and 13e's missing nudge is a second fault sitting on top of the first rather than the whole
story. Nine attempts, four refusals, no nearMiss in any of them.

One refusal still spent most of the secret. The Barrow Entrance narrated the runes chiselled from the
dark side, the lines set to be read from inside, "nothing about this arch speaks to a visitor" — the
authored lore minus only its last clause, that the runes are a binding. So 13d's fourth commitment held
at the South Gate and did not hold here. Nine-tenths of a giveaway is cheaper than all of it and still
not the rule.

Three verifications of the substance design, and they are the good news. A Sound Emberdust — the 1.2
grade, carried to the model only as a sentence appended to its description — did 24 damage where plain
did 20, so the multiplier reached the model as prose and came back as the right number. Blinding Ash
thrown at the Shade in a thunderstorm did nothing at all, and the Game Master gave back both limits the
description states, in as many words: the rain slaked half the lime in mid-air, and there was never
anything in that hood for the lime to take water from, because the light is not eyes. And offered a
wraith, the character reasoned that acid needs something to eat and a fog has nothing, and the Game
Master accepted the substances as different in kind rather than as interchangeable damage.

The best moment was emergent. Having established that the runes are a binding cut to hold something in,
the player stepped back outside them, and the Shade was held at the line — "as if it had walked into
glass" — and switched to a Wail because its blade could not reach. Nothing in the authoring says the
binding works on the Shade. The Game Master drew that consequence itself.

The expansion notes take five more entries from the same sitting, the sharpest being that past the Bog
Wraith at 55 HP the very next thing is a 70 HP guardian hitting for 14 through armour, one room further
on, which a level-2 loadout cannot kill. Between the village gate and an unkillable guardian there is one
room and one creature.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

A running note kept while playing rather than while designing, started during the Claude24 alchemist
run and meant to grow on every later one.

The useful framing turned out not to be that the world is small. It is that the world is small in ways
it has already promised not to be. Wenna's lore buys from woodsmen on the Northern Road and spinners in
the cottages, and neither exists. Hesk's lore puts him downwind of tanning pits that Market Row's own
description can smell and the map does not have. Limestone comes off hills west of the moor that a
player can never walk to, which is where the Alchemist's Blinding Ash chain starts. The wine cellar's
far wall is authored as the corner of a shrine facing the mound with a draught out of a space nobody has
opened in four hundred years — a door the world built and attached nothing to, in a world that declares
no religions at all. Every one of those is an expansion the world has already written the advertisement
for.

The counts are worth stating plainly because they are starker than they feel in play: fourteen rooms, of
which four are the inn and three are the barrow, and zero regions, districts, biomes, religions,
heraldry, folklore, languages and dungeons. Seven world-shaping systems with working editors, and the
world that ships to demonstrate the game populates none of them. One armour piece. One faction.

It also records what the smallness already costs, since each of those names a direction: no container
lock exists anywhere, so lockpicking, container traps and the newly widened rule 5a are untestable in
play without staging something; the crafting suppliers have stock but no workshops; and with no homes
and no evening rooms the routine system has nowhere to send anybody, so the world reads the same at
midnight as at noon.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Both tables carried $3/$15 for claude-sonnet-5, taken from the model table this pricing file was first
built from. The published figure is $2/$10 and has been for some time, so every Sonnet 5 call metered
since then was reported half as dear again as it was. Corrected in Server/pricing.js and in the client
ledger's mirror of it, which a test holds together.

Nothing already recorded moves, and nothing should. A Claude text call banks its dollar figure when it
is recorded, so a total on disk states what the meter believed at the time; re-deriving an old one
would need the per-call cache TTLs nothing stored, and an old total reading high is an honest fact
about the old table rather than a debt. That is also the answer to whether either meter models a price
that changes over time: on this path it needs no rate timeline, because the row carries the price.

The correction costs a guard, which is the part worth knowing. While the two Sonnets differed, deleting
claude-sonnet-5-5's row surfaced as a wrong NUMBER — rateFor resolves by longest prefix, so 5.5 would
have inherited 5's dearer rate and any cost assertion would have moved. At equal rates that deletion
changes no arithmetic anywhere and every figure in the vault's usage test stays green through it. The
row itself is asserted instead, there and as the general prefix-pair rule in Tests/test_model_roster.js,
and sabotaging the deletion now fails by name in both.

It also settles the file's one assumed row in passing. Fable 5.1's $10/$50 was a copy of Fable 5's,
assumed on the reasoning that a point release keeps its family's rate; the published table now lists
5.1 at exactly that, so the row is sourced rather than guessed. The reasoning it rested on does not
survive, and is kept as a warning rather than deleted: both families have since broken it — Opus 5.5
came in under Opus 5 at $4/$20, and this commit moves Sonnet 5 below the Sonnet 4.6 it used to match.
A future point release gets a looked-up rate or no row at all.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The owner asked what happens if the portal's ledger is simply gone, because that and not a taste
for managed services is what decides between a SQLite file on the server and a hosted database. The
answer turns on which records somebody else also holds. Purchases are held by Stripe and Steam and
come back through the reconciliation sweep, so no sales record is ever lost. Spends are held nowhere
else, since a provider invoice is organisation-wide, so a restore from an older copy hands players
back credits they already used: every call was covered when it ran, and what is lost is the record
that part of a prepaid balance was spent. The error runs in the player's favour and the markup pays
for it. Ordering cannot close that gap, since the hold already confirms before the call and every
record lives in the same ledger; only durability can, which is why C19 settles on SQLite on EBS
streamed by Litestream to a versioned S3 bucket, a window of seconds for pennies, with RDS kept for
when availability rather than durability is what is missing. A purchase now names the Auth0 sub or
SteamID in its Stripe metadata, so it still points at a person if the accounts table is lost.

A four-layer watchdog finds what leaks: the ledger against its own invariants, the vault's own call
count against settled holds (the layer that catches a route escaping metering), Anthropic's Usage
and Cost API against the ledger per model per day, and revenue against cost. The owner asked for
one figure an admin can read, so the watchdog rolls these into a leakage report in dollars and as a
share of cost and of calls, split into named causes and an unexplained residual, with rate drift
shown apart because a stale price table is not a lost call, and the required multiplier, the store
floor grown by the leak rate, drawn beside the realised one so margins can sit clear of failure.

The owner also asked whether the margin could reprice itself in near real time. It can, since the
multiplier that keeps a target is target / (1 - leak share), but C22 leans against it: a repricer
passes structural leaks, which are bugs, on to players and silences the alarm, chases late and
noisy figures, and has no lever that neither shrinks bought credits nor looks like surge pricing.
The governor that should act on its own is a circuit breaker that suspends a leaking route; a
bounded automatic band is recorded as the alternative.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019qV1VfoJrQ74Z4rrLGrHWz

Both Sonnet notes added yesterday gave the same reason for leaving Sonnet 5's stale $3/$15 alone —
that correcting it would reprice spend already recorded — and that reason is false. A Claude text call
banks its dollar figure at the moment it is recorded: recordGM folds computeTextCost's answer into the
running total, recordGmUsage writes it into the row as `c`, and every reader downstream takes the
stored number rather than re-deriving it. Measured rather than reasoned about, on both ledgers: with a
million tokens each way recorded at $3/$15, halving the rate in the live table leaves the vault total
and the /usage total both reading $18, while a fresh call prices at $12.

Worth writing down because it is the answer to a question the notes provoked — whether either meter
models a price that changes over time. Neither holds a rate timeline, and neither needs one on this
path: the row carries the price it was billed at, so the table never has to. The generate rows are the
deliberate opposite and usage.js already explains itself there — their token cost is derived at read
time from the aggregate counts, so a rate landing today prices tokens recorded last month and a
correction corrects the chart instead of leaving a seam at the hour it changed. The asymmetry is forced
rather than chosen: a text call's cost cannot be re-derived from aggregates, because the cache-write
multiplier is 1.25x or 2x depending on a TTL the ledger never stored, while a generate row pins one
model, carries no cache tokens and is linear in two counts.

The consequence for the row that prompted this is that editing it is cheap and safe rather than a
decision about reporting, so the note now says that instead, and says what the real reason for leaving
it is: nobody has decided to move it.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The owner asked two questions of the credits portal design that it did not answer. Should payment
webhooks be received by a serverless function, apart from the server running turns, for uptime? And
can the hosted vault spread across CPUs under pm2 once many signed-in players use it?

Webhooks stay on the portal (C17). The portal is already a separate process from the vault, so a
burst of GM traffic cannot delay a credit. What a serverless receiver would add is less than it
looks: Stripe redelivers an undelivered live-mode event for up to three days, a credit is idempotent
on the Checkout session id so late or repeated events land once, Steam sends nothing inbound at all,
and a function elsewhere could not write a ledger that lives on the portal's own disk without
forwarding to it or queueing, which rebuilds Stripe's retry at a cost. The owner set the idea aside
for exactly that reason, that a familiar pattern is not a reason. A daily reconciliation against
Stripe's list of paid sessions covers the outage longer than Stripe's window.

The vault's answer is measure first (C18): a turn spends most of its life waiting on a provider,
which costs the event loop almost nothing, so the first ceiling is likelier the provider's rate limit
than the CPU. When it is time, pm2's cluster mode is the tool, but only after the vault stops
assuming it is alone. usage.js, world-store.js, settings.js and descriptor-store.js each read a JSON
file, change it and write it back per request, which in several workers loses increments silently;
the call log is per-process memory. So usage moves into the portal's ledger, which it is settled into
anyway, shared admin state gets one writer, and only then cluster mode. Reading the code for this
turned up a precondition that is not about scale: the generation scratch keeps the last fifty world
generations as one list for the whole vault, so it must become per-account before many authors
share a vault.

Section 08 is also re-worked. 684bee37 made Sonnet 5.5 the model a new player gets, at $2/$10
against Sonnet 5's $3/$15, so a turn at cost is now about two cents, the assumed hour about $1.18,
and the mock-up's free allowance about fifty minutes. Sonnet 5's figures stay beside them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019qV1VfoJrQ74Z4rrLGrHWz

Seven lists spell the roster out across two programs, and a model reaches nobody until it is in all of
them: the Settings menu, the World Builder's, the shared label map, the client's rate table, the
vault's sanctioned set, the vault's fallback walk and the vault's rate table. Tests/test_model_roster.js
exists for exactly that and named the two that were still missing after the first pass, both in the
DM's Guide. Sabotaging each of the eleven placements in turn produces a distinct failure naming it,
which is the property that makes the eighth model cheaper to add than this one was.

Two of the placements decide behaviour rather than visibility. The rate table needs its own row because
rateFor resolves by longest prefix and claude-sonnet-5 is a prefix of claude-sonnet-5-5, so an inherited
rate would bill the newer model at the older one's $3/$15 and over-report every Sonnet call by half —
the Opus 5.5 trap again, the same way round. And the mid-turn system roster is the first entry on it
that changes what goes on the wire: Sonnet 5 refuses a {role:'system'} message and Sonnet 5.5 accepts
one, so the dossier travels unforgeably on 5.5 where on 5 it folds into the player's own turn and can be
written in the same voice a player types in. Nothing about the id says so, and the prefix arm could not
have found it — Sonnet 5 is not on that list, so the family name would have kept the newer model out
rather than letting it in unexamined, which is the Fable 5.1 accident pointed the other way.

Leading the gameplay menu makes it the default, since getSelectedModel falls back to the first offered
model. That is a decision and not a side effect: it is the current Sonnet, it bills below the one it
leads, and it is the one with the stronger prompt integrity, so there is no axis on which the old
default wins. Only a player with nothing stored moves; a saved pick is honoured as before. Both guides
and the Field Guide say so, and the DM's Guide and Field Guide stamps are refreshed with them.

One thing found and deliberately not changed: Sonnet 5's $3/$15 is stale — the published rate for it is
now $2/$10, the same as 5.5. Correcting it would reprice calls already sitting in ledgers, which is a
decision about reporting rather than a consequence of adding a model, so both pricing files now record
that the row is known stale rather than merely unverified.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

BUG-101's entry refused to call its own fix proved and asked for a run of fresh hooks under the
strengthened rule. This is that run, and it missed — but the shape of the miss is the finding.

The South Gate hook was attempted with the wording that failed the day before. It was performed and
articulated, it did not unlock, and no nearMiss was set, which is BUG-059 unchanged. What changed is
what the Game Master did with the secret. On 28 Sep it narrated the authored lore in full — the named
stones in two rows, the smith's mark under the crossbar — and left the field null, spending a condition
that cannot be earned twice. On 29 Sep it revealed none of it: it invented notches where the mark is,
and declined in the guard's voice, "where they went into the ground is the old man's to tell, not mine."
Attempt two then fired and delivered the authored mark verbatim.

So rule 13d's fourth commitment is holding and the expensive half of BUG-089 did not recur. What is left
is 13e, cleanly isolated: a hook judged satisfied and held back must set nearMiss, and it does not, so a
player who performs an authored condition is given nothing whatever to act on. The report also records
an observation it cannot settle — both refusals routed the knowledge to a person the condition does not
name, which would explain why it reads as unmet and would put the fix in the dossier rather than in 13e.

Rule 5a verified on its first attempt, after the run turned up that the built-in world authors no
container lock anywhere: its one Locked Chest is a bare item with container=false and lock=null, so the
name is scenery and both the widened clause and the Rogue's lockpicking are untestable in play without
staging one. Staged at DC 18, the acid opened it with containerChanges set and the flask consumed.

BUG-104 is filed from the same run: two of three Emberdust thrown, and both the narration and the
engine's own action line called the supply gone while the pack held one. The engine was right and the
correction was accepted, so nothing was lost — but the wraith was at 20 of 55 and draining ten a round,
and a player who believed the line would have run with the winning throw in the pouch.

And the two numbers Reagents & Concoctions §16.5 was waiting for. Three flasks kill the world's first
real monster, which is half the starting kit; Emberdust did exactly the 20 its own description states,
so the Game Master is reading the figure off the prose rather than inventing one. Two flasks cost about
twelve in-world hours to replace at concoction level 1. Coin was never the constraint. The clock is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Regenerated with Tools/gen-progress-report.js from a full, unshallowed history so every commit
since the last refresh is listed.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hd6iG4YtEtGVxnV1XJeHm1

Rev. 1 read as though the portal might adopt more of Pollinations than was ever wanted. The owner
has said what is actually of interest: its credit system, its payment integration and the
bookkeeping that ties a provider call to a debit. Not its GitHub login, because the game already
signs players in with Auth0 and that stays as the answer to whose balance it is; not its portal
UI, because Web/AccountPage is the game's own; and not what Pollinations is, a generative-AI API
sold to developers, because players here are playing a game and should only ever need to care
about a balance and their usage.

That split between audiences is new in section 13. A player sees credits left and what the sitting
spent, and never a model name. A DM chooses providers where Settings already lets them, one picker
per generation slot filled from the vault's providerCatalog, and in credits mode each option carries
its price in credits, which is the one thing a DM choosing between a cheap draft and an expensive
final lacks today. C15 asks who pays for that choice and leans towards whoever presses the button,
so no author's taste in models becomes a visitor's bill; the vault's existing model ceiling stays
the hard bound.

C16 records the owner's decision to run the portal as one Node process on an ordinary AWS instance
rather than serverless, and keeps the reasoning so it can be reopened as a decision: API Gateway's
thirty-second timeout cannot carry a GM call, DynamoDB conditions do no arithmetic, and its TTL is
too lazy to release a hold, none of which argues against Lambda, and on Lambda the internal
hold/settle API would have disappeared altogether.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The game can only be played today by somebody holding provider keys, either pasted into the
browser or into the desktop app's own vault, and a storefront build wants a single credit system
instead. Designs/credits-portal.html works out what that takes, by reading Pollinations (commit
e76a62b, and its portal run locally in WSL) for the bookkeeping, the Server Vault for what already
exists, and Valve's and Stripe's published rules for what a Steam build must obey.

The shape is a small separate plain-JavaScript service that owns accounts, the wallet, purchases
and an append-only ledger, beside a hosted vault in a new credits mode that stays the only thing
calling providers and reports usage rather than an amount, so the portal alone decides a price.
From Pollinations it takes price as data (cost times a multiplier), billing only from the usage a
provider reports, credits idempotent on the processor's own id, and free rewards keyed on the
external identity so a re-created account cannot re-earn. It fixes three things rather than
copying them: a debit there leaves no ledger row behind it, the wallet has no hold so parallel
calls overdraw it, and a refund never takes the credits back.

Two findings change the premise. No published Steam rule forbids bring-your-own-key, and genre
titles ship with it; what Steam requires is that a purchase made inside the Steam build goes
through Steam Wallet, which is why the ledger takes several payment rails and why BYOK stays as a
mode. And the vault's missing piece is identity rather than money: every AI route is behind one
shared token and never reads the player's login, so phase P1 is putting a verified account on
that path, which is worth doing even if nothing is ever sold. The arithmetic on Prompt Economics'
figures puts a Sonnet 5 turn near three cents at cost, shows Steam's 30% setting a 1.43x price
floor, and shows the account-page mock-up's free allowance buying about thirty-five minutes of
play. Fourteen decisions are left open with leanings; nothing is built.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The reagents design doc gained the arithmetic under the craft on 28 Sep 2026 (a natural 1 spoils, a
natural 20 lands best, missing by one or two yields half the doses, and hours are discounted by
proficiency rather than fixed), and the Player's Handbook, Field Guide and DM's Guide still described
a flat-hours, margin-only brew. The DM's Guide also says which recipe fields are authorable.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BrvmXsFzTcRrFxjHTHxSM6

Regenerated from the full, unshallowed history (4,446 commits across 92 days) with
Tools/gen-progress-report.js. Only the index and the September month page moved.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QQKwokYqJf3SnzGPx6fjp1

The sweep that fails on media the inventory does not scan was scoped to Web/, and the reason written
beside it was wrong. It read: "A new TOP-LEVEL directory is already a decision somebody has to make
(test_static_denylist), so it is the nested ones under Web/ that arrive unannounced." Encyclopedias
falsified that the week it was written. The directory landed with 133 images, test_static_denylist did
exactly what it promises and made somebody decide about it — and the decision it forces is whether the
VAULT SERVES the directory, which is a question about routing with nothing to say about who made the
pictures. The serving question was answered, the suite went green, and 133 images stayed invisible.
One gate had been mistaken for two.

So the sweep now covers the whole repository, over git's index rather than the filesystem. That second
part is not incidental: Book, Models, Music, Saves and Worlds are gitignored and exist only in the
owner's working copy, so a filesystem walk would fail on the owner's machine and pass in CI — the worst
possible split, since the material least appropriate to ship is exactly the material one machine has.

Its first run found twenty-five files in five places besides Encyclopedias, and not one of them was
new. The app's own PWA icon, the site mark and the favicon at the repository ROOT. The desktop shell's
icon and its settings cog. The Dungeon Builder's icon. The entire Style reference kit — emblems, the
login plate, the portrait and scene studies. And a favicon sitting one level above two directories that
had been scanned since 13 Sep. Some of the most visible files in the tree, shipped with every build,
invisible to the one tool whose job is to say who made what, for the whole life of the repository.

They were invisible for one reason with two shapes, and the fix has two halves to match. Style/assets
is pure assets and simply joins DIRS. The other seven sit BESIDE SOURCE — Electron/, Modules/Dungeons/,
Web/Website/ and the root itself — and naming their parent is not available: pointing DIRS at any of
them fills the inventory with .js, .md, .webmanifest and README files, every one reported UNREVIEWED,
every one a file nobody should be attributing. That was tried with '.' for the root and is what it
does. So LOOSE_ASSETS names those seven one file at a time, and the sweep accepts a directory whose
media is all individually named — checked per FILE, so adding one icon to Electron/ and forgetting the
other still fails, which is sabotage C below.

Everything the run found is now declared, and the declarations are measurements rather than testimony
wherever the repository could supply one. Six are byte-identical copies of already-declared files,
hashed rather than name-matched, because this tree holds different files sharing a filename and a name
match would carry the wrong attribution. Style/assets/logo-lostrealms.svg is icon.svg after a DOM
serializer round-trip: strip comments, collapse <stop></stop> to <stop/>, and the two normalise
byte-identical, the 158-byte difference being exactly the comments — a hash cannot see that, which is
why it is written down. Electron/icon.png is rendered from icon.svg by Electron/tools/make-icon.js and
is reproducible with npm run icon. Modules/Dungeons/dungeon-icon.svg is a sibling rather than a copy:
same gradients, same viewBox, the same hand-written note about maskable cropping, its own flame
gradient and its own aria-label. Web/Website/favicon.ico hashes to nothing and was parsed instead —
three PNG-compressed images at 16, 32 and 48 where every other declared favicon is a single 32x32 BMP,
so it is filed as a mark in use and the entry says plainly that the pixels were not compared.

The encyclopedia's own 133 split perfectly along file format, which decided the entry's scope before
anyone was asked anything: all 111 .jpg carry a signed manifest, 107 of them reading Google Generative
AI, and all 22 .png carry nothing at all. So only the 22 are declared. The JPEGs are deliberately left
out — their bytes already say what made them, the inventory reads that unaided, and listing them would
convert a signed manifest into testimony, which is a downgrade. The owner's statement that the
encyclopedia images are generated with Nano Banana Pro is the whole basis for the 22, and it is
corroborated BY FAMILY rather than by those bytes: Nano Banana Pro is Google's, and the siblings say
so under signature. That distinction is kept rather than rounded off, as the WorldBrowser entry keeps it.

Sabotaged four ways — Style/assets dropped from DIRS, icon.svg dropped from LOOSE_ASSETS, one of
Electron's two icons dropped while the other stayed, and a brand-new top-level directory shipping an
image. Each is caught, and the last is the case that started this.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Every door into the task system assumed somebody had written an errand first, and for a world built
the ordinary way nobody ever had. The one-shot generation directive never mentioned tasks; neither
did the room fill nor the `//` being addition. Only the Beings ask-bar did, which meant errands
existed for a Dungeon Master who already knew they existed and asked for them one person at a time,
and for nobody else. A world came back with an empty Journal and nothing anywhere to say that
something was missing.

The obvious fix is a paragraph in the generation prompt and it is the wrong one, because an errand is
about the REST of the world and the rest of the world is not there yet when the person asking is being
invented. It routes through other people who may not exist; the two ends of a delivery must both be
nameable to share an id; it sends the player to a room, which wants the map finished; and a reward
names a catalogue id, which giveTaskReward refuses when the world does not have it, so an errand
authored too early promises something that fails an hour later at the table. So the generation prompt
is left alone and this is a second pass over a finished world: it reads the rooms by id, the ordinary
people by id with their occupation and the room they stand in, and the item ids a reward could name.
Routines are deliberately not in it — a generated world carries none, the one-shot schema having no
routine field, so promising the model a person's daily round would be promising nothing. That is the
first thing to revisit when generation learns to author them, since what somebody does all day is most
of what decides what they would ask a stranger for.

Most of the directive's words go on whom to skip. A village runs on small unfinished business and a
stranger with time on their hands is a gift; a mummy in a crypt is not going to ask anyone for
anything. The roster does half of that mechanically, listing no monsters and no Enemy-classed beings
at all, and the directive does the rest, ending on the line that matters most: skip most of them, or
the world is a notice board rather than a place.

Ticked, the checkbox runs the pass inline the moment the world is forged, on the status line the build
was already using, and opens no dialog — a modal in the middle of a run nobody asked to interrupt is
an interruption. Unticked, the button beside it becomes pressable once there is a world in the box,
and that path draws a summary, which is the whole point of the button: without one, knowing what an
added step did means reading raw JSON or clicking through person after person in the editor to find
which of forty now has an errand. So it is drawn rather than dumped — who was given what, with their
trade and the room they stand in, each errand's steps as chips and what it pays in the words a player
would hear. The linked errands come first and on their own, because a two-ended delivery is the thing
an author most wants to check and the least likely to be spotted by scrolling, and the links are
computed here rather than trusted: two entries sharing an id ARE one errand whatever the model meant.

The apply is additive and never a replacement, which is what makes the button safe to press twice. A
person who already has errands keeps the ones they have, whether from an earlier press or written by
hand, and the count of who was passed over is on the summary so a thin run explains itself. A reward
may need an object the world lacks, so the pass may mint a catalogue entry alongside, added before the
errands so a ref written in the same breath resolves; an existing id is never overwritten, because a
reward pass that re-prices the world's own goods is a balance change nobody asked for. A ref naming
nothing at all gets its own heading, since that one cannot be paid at the table and the alternative to
naming it here is finding out mid-session.

Three things the suite found on the way in. The reward-item schema spelled an item-type union by hand,
which is the defect two other prompts had and a test already pins, so it interpolates the roster and
carries the taxonomy's own subtype rule. It also asked for items and never said where they could be
worn — the Region Builder's exact bug, where every piece of gear a region built arrived silently
unequippable — so it names the slot roster too. And the field-help test caught the new checkbox's
info icon carrying an aria-label with no data-tip behind it, which would have shown a native browser
bubble that ignores the app's own tooltip switch.

test_world_errands.js is written the way §8 explains: every assertion above it drives the pass
functions directly and every one passes unchanged with the checkbox reading nothing and the button
wired to nothing, so the last group forges a world with the box ticked and then unticked and looks at
what actually happened. Twelve sabotages were run against it — the enemy filter dropped, the
already-has marker dropped, the apply overwriting authored errands, links counted by entries rather
than by shared id, items applied after the errands that name them, escaping removed, the dialog opened
on the inline path, generation no longer reading the box — and each is caught by a distinct assertion
that names the failure rather than the symptom.

Designs/tasks.html §03d and decision Q record the reasoning, with a playtesting group H for the pass
and a note on the one question a desk cannot settle: whether it actually skips the people who would
not ask.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The denial is unchanged; what the comment said about it was too narrow in one direction and too strong
in the other, and both matter to whoever reads that line next.

Too strong: it claimed a reason unlike any other entry's. It is not. It is exactly Web's shape — the
repository is the DEPLOY PATH and not the serving path. The directory is pulled to the web server and
published there by NGINX through soft-linked directories, with the root not served even there. Calling
that novel invites somebody to look for a novelty that is not present; the useful sentence is that two
entries are denied for the same reason, which is the reason a game server is not a web server.

Too narrow: it framed the World Browser only as "the easy wrong guess" and stopped. The World Browser
does link to these pages and that is worth keeping, but the real answer to why a game repository holds
content no game server serves is the deploy path above, and the comment now leads with it.

And the part that was missing entirely: this is the first entry on the list EXPECTED TO CHANGE SIDES.
What is in the directory today is starter content, a first-draft encyclopedia, and the intent is for it
to become the bundled worlds' encyclopedias with a static presence on the website for browsing. Not
every world in the World Browser will have one; those that do will have it on the web server either
from this repository or generated there from a world export JSON, and that workflow is still being
drafted. Nothing else on this list is provisional in that way — the tests, the design docs and the
owner's gitignored material are all permanently not the running game. So the line now says it records
what is true NOW, that nothing in the game fetches any of it, rather than a judgement that nothing ever
will; and that if the bundled worlds do start fetching these pages same-origin, moving the entry is a
decision rather than a correction. Unrecorded, a future session either flips it without knowing why it
was denied, or leaves it alone without knowing it was always meant to be revisited.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Section 16.4 writes down what skill actually buys, because the notes below it ask whether restocking is
practical and nothing anywhere said what a working costs.

It records where the three dials live and that all three are authorable with no engine change — dc
defaults to 12 and hours to nothing, neither has an upper clamp, and 0 hours is legal — so a DC 25
working at 12 hours and a DC 8 cure at 2 are both a matter of typing them.

Then the measurement, which is the part worth having, and it is less flattering than the change felt
while making it. Against Emberdust at DC 15 with an Alchemist's CON 16, the expected cost of one usable
dose goes 5.45 to 5.00 hours at skill level 1, and 4.00 to 2.19 at level 5. So the ladder barely helps a
beginner and the hours help a master: a +5 character against DC 15 misses by three or more most of the
times they miss at all, and the near-miss rung only rescues the ones that were close. What levelling now
buys is two distinct things where it used to buy one and a half — reliability from the ladder, and time
from the curve.

Which leaves the note the section ends on: the level-1 lever is still the DC, and no ladder fixes that.
A first-day specialist writes off a third of their Emberdust workings because 15 against +5 is what it
is. The shipped spread is 12, 14 and 15, set before any of this existed, so the cheapest working is 20%
spoiled at level 1 and the one in the starting kit is 35%. Whether that reads as a difficulty curve or as
a beginner being punished for reaching for the good one is a table's finding, and it is the first number
to move if the answer is the second.

The document had never nested past h3, so it needed an h4 rule adding — the same addition containers.html
and abilities.html each needed when their own Playtesting sections first went a level deeper.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Two other skill checks in this file grade on five rungs with two absolutes, and one says so in its own
comment: "Nat 1 always fails and nat 20 always lands, the same two absolutes the item ladder keeps."
Brewing graded on margin alone, so the craft had no natural 20, no natural 1, and no near miss — every
total under the DC was a total loss of the hours AND the reagents, and nothing told missing by one from
missing by nine.

The cost was measurable rather than a matter of taste. A first-day Alchemist — the character who has just
chosen to specialise — spoiled 45% of Emberdust workings at DC 15, and a master at skill level 5 still
spoiled 25%. Being spoiled was the most likely single outcome of the one thing the class exists to do. It
is 35% and 15% now, with a ten per cent band of thin batches taken off the top of each.

The near miss is a reduced YIELD and not a reduced strength: half the batch, floored, never below one, at
the plain grade. Missing by two is a working that came out thin rather than one that went wrong. Strength
is left alone because the grade ladder already owns strength, and two dials driven off one roll is how a
number stops meaning anything.

Hours now fall with skill, keyed to proficiency rather than to the grade. A grade is discovered after the
working is over, so grade-scaled time would be a number nobody could plan around — and the clock is
advanced before the roll is known, which the progress sweep depends on for refresh safety. Proficiency is
level+1 capped at five, so it runs 2 to 6: no discount at all for a first-day worker and four steps of a
tenth for a master, quantised to the quarter hour because the banner prints the number. Six hours becomes
three and a half at the cap. An off-class learner has a reduced proficiency already and so earns a smaller
discount, which is the right answer and cost nothing to arrange. The same curve applies to preparing a
reagent, since a preparation is the other half of the hours an Alchemist spends and a master who grinds
faster at the bench but not at the quern would be a rule with a seam in it.

Three assertions in the test were written wrong before they were written right, and the notes stay in the
file because each was found by sabotage rather than by review. An assertion that the clock moved by the
scaled hours read "4h vs 4h" and would have passed against an implementation ignoring the curve entirely,
because the fixture brewer sat at proficiency 2 where scaled and base are equal; it levels the brewer
first now. An assertion that a batch-1 working still yields one compared Math.max(1, Math.floor(1/2))
against 1, which tests JavaScript rather than this code. And its replacement counted pack doses with
`Number(quantity) || 1`, which launders the very zero it was hunting — an absent quantity means one and an
explicit zero means none, and `|| 1` cannot tell them apart.

That last one also corrected a claim: the max() is NOT load-bearing on its own, because `if (doses > 1)`
never sets a zero quantity either. Removing either guard alone is survivable and the suite says so;
removing both hands the player nothing. The test pins the property rather than the line.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The Alchemist ships six thrown workings of three kinds, three health potions, no mana potion, raw stock
for about four more and a third inherent skill. A starting PICK could not be granted — the creator holds
one selection and a second would mean changing the dialog, the confirm path and creation — so Field
Medicine is inherent instead, which also evens the class up against Rogue and Druid.

The entry records what stays broken on purpose: no weapon and no armour. That is the bargain rather than
an oversight, and whether it reads as different or merely as a poorer Rogue is a table's finding and not
a desk's. It points at the five questions written up in the design doc, chief among them how many flasks
one fight actually costs and whether restocking is practical — which turns out to be a question about
hours rather than about coin.

Two bugs remain open: BUG-103, that reagent preparation is only reachable from an item card while the
tab named Crafting says nothing is on the bench, and BUG-059.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Section 16 writes down the premise the Alchemist was rebuilt on, because it decides the balance and
nothing else is tuning it: the class harnesses substance where a Druid reaches for earth magic, and the
earned skill is in the compounding rather than in the application. An Alchemist holding a Vitriol Flask
has already passed the test; throwing it at a slime or pouring it on the wards of a lock is spending a
thing that was hard to get, not a second test.

That is already the engine's cost model rather than a rule laid over it — concoction rides CON because
the gathering and the preparation are what it costs, and a preparation costs hours and always succeeds
while the working costs the roll. Nothing needed changing to hold it. What follows is the dial: a flask
fits many locks, so the number carried IS the balance, which is the argument for six rather than ten.

It also records that the description is the mechanic, since consumable effects here are prose and the
Health Potion has no effects field at all — and that the limits are the important half of such a
description, because a substance written only by what it can do becomes the answer to everything and a
table that has found the universal answer stops looking for the interesting one.

The playtesting notes carry the two questions the owner raised when the counts were set, both genuinely
undecidable at a desk: how many flasks one fight actually costs, and whether restocking is practical —
which is a question about HOURS rather than coin, since a preparation is three to eight and a working
three to six more. If a fight's worth of flasks costs two in-world days the class is gated by the clock,
and that is a dial nobody has been turning. Three more ask whether the Game Master reaches for the acid
at all now 5a permits it, whether the one working that deals no damage is ever worth a slot, and whether
an Alchemist who cannot fight reads as different or merely as a poorer Rogue.

The tuning principle is recorded with them because it decides which way a fix goes: the world should be
consistent with itself and should not raise artificial barriers, so where a class comes out wrong the
answer may be to tune the world to meet it rather than the class. Widening rule 5a for every class was
exactly that choice, taken in preference to giving the Alchemist a permission nobody else had.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The class shipped a health potion and a mana potion and nothing else, which made it the only one of the
seven that began unable to affect anything: four ship a weapon, and the Cleric and Druid ship no weapon
but do ship a spellbook AND Spellcasting. It now carries six thrown workings of three kinds, three health
potions since it also ships no armour, and the raw stock for about four more.

Emberdust was already the fire one — its own comment calls it a thrown dust that costs a fight's worth of
damage — so it is reused rather than given a rival. The two new ones are a Vitriol Flask, which eats hide,
horn, rope, a hinge pin or the wards of a lock and does nothing at all to stone, and Blinding Ash, which
takes the water out of an eye and is useless in rain and against anything that has none. Both are written
as SUBSTANCES with their limits stated rather than as a single use, because consumable effects in this
game are prose the Game Master reads: the description is the mechanic, so it has to describe what the
stuff IS and let the table find the uses. Naming follows the world's own register — meal, grist, salt,
crust, dust — and refuses "salve" for a thrown thing, which is already in correct use on Knitbone Salve
and would not survive being poured on a lock.

Both new recipes bind with grave-salt, as both existing ones do, because that is this world's binder and
inventing a second would be inventing away from it. That is only affordable now the Barrow Entrance is not
the sole source of Barrow Crust: the wine cellar's far wall is already authored as a barrow-facing shrine
corner with a draught behind it, so the crust sits there and the whole craft stops depending on the
deepest room in the world. Green Vitriol is sweated off Aldric's bog iron, which is the ore his own lore
says has been coming up wrong, and Quicklime is burnt from limestone off Wenna, who sells what every other
trade needs and none of them makes.

The kit carries plain ingredients rather than pouches, and that is load-bearing: a recipe reads reagents
by id and a reagent reads its ingredients by ITEM id, so a "Pouch of Ember-Stone" would be a catalogue
entry the preparation cannot see and the Prepare button would never appear.

Field Medicine is granted rather than a second starting PICK, which the creator cannot give — it holds one
selection and a second would mean changing the dialog, the confirm path and creation. A third inherent
skill costs nothing, evens the class up against Rogue and Druid, and makes a ladder out of a pair:
herbalism to concoction and field medicine to apothecary, which needs exactly those two, with venomcraft
off concoction as the other end.

Rule 5a is widened for every class, not for this one. The engine had always allowed it — applyContainerChanges
takes "open"/"unlock" without ever looking at the lock method, and springs an armed trap on the way in —
while the contract said a locked container opens "only via" key, pick, button or sealed. A Game Master
following that had to refuse an Alchemist eating a hasp off, and the likely failure was not a refusal but
a narration: the hasp giving way, containerChanges null, the flask spent and the chest still shut. So the
clause carries the same binding rules 13b and 13d now carry, says outright that the route is not the
thief's alone, and says that defeating a lock does not dodge a trap.

`Tests/test_class_can_act.js` asks the question of all seven classes rather than of the one that failed,
because the Alchemist was the seventh added and the six before it happened to be fine. Its supply check
was widened after a sabotage walked through the first version: counting a kit copy as a source made one
refill look like a chain, so the world has to supply it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The entry as filed measured the unarmed character against the Bog Wraith and stopped there, which
overstates it: a reader would come away thinking the class is unplayable rather than unequipped. The
village sells a Spear at 18 copper, a Dagger at 20, a Crossbow at 22 and an Iron Sword at 30, against a
starting purse of 15 gold. Arming an Alchemist costs about two per cent of what it begins with and one
visit to Aldric or the gate watch, so this is not a difficulty complaint and the entry now refuses that
reading in as many words.

What survives the correction is the part that is actually about the kit: the class begins unable to act
and nothing tells the player so. Four classes ship a weapon; the Cleric and the Druid ship no weapon but
do ship a spellbook AND the spellcasting skill. The Alchemist ships neither, and has no spellcasting
either, which makes it the only one of the seven with no means of affecting anything on turn one.

The trade half is worse and money does not fix it, so it is now stated separately. The kit holds no
ingredient, so both of the class's own skills have nothing to work on. A comfrey root is four copper and
settles the first tier — but both of the world's recipes require grave-salt, whose only ingredient is
Barrow Crust, and the only Barrow Crust in the world is in the Barrow Entrance. No concoction can be
completed from the village at any price by any character however well funded. That is a placement
consequence rather than a kit one, and it is mine: I put the crust there this morning.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

BUG-101 records the rule 13d gap and its fix, and says plainly that this run is the one BUG-089 asked
for and did not get: a run of fresh hooks under the strengthened rule. It missed twice out of six, on a
newer model and a different world, and both recoveries carried the same confound BUG-089 had already
refused to count — a second, more explicit attempt.

BUG-102 is the Alchemist starting with nothing to brew with. The Game Master found it rather than the
evaluator, reaching into the pack for a mortar that is not there, while the Gatekeeper's own opening line
to that class calls it a brewer's kit. Filed with the balance half stated as a measurement and not as a
complaint: one unarmed encounter is not a difficulty curve, and the other six classes were not measured,
but a class that cannot perform its own defining verb on the equipment it ships with is decidable without
more play.

BUG-103 is that the only way to work a reagent is a button on the ingredient's card, while the tab named
Crafting is a different system and tells a character holding the root and knowing the preparation that
there is nothing on the bench. Filed rather than fixed because the two remedies point different ways and
picking one is a design decision: teach the Crafting tab to list workable preparations, or tell the Game
Master in the rulebook to name the surface it is sending the player to.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Found by playing the built-in world on 28 Sep 2026, and it is BUG-089 recurring in the one place that
bug's fix never reached.

BUG-089 was the Game Master narrating a lore discovery and not recording it — the player is told the
secret, the engine writes nothing, and the condition is spent and unrepeatable. It was diagnosed as a
contract problem rather than a model weakness: rule 13b asked for the field AND the vivid narration in
one sentence, the two halves came apart, and the model reliably did the vivid half. The remedy was three
sentences added to 13b binding them, naming the failure outright, and stating that the cost is permanent,
plus a fourth closing the other side so an unmet condition may not be narrated as met either.

Rule 13d opens "rule 13b, for the five kinds that are not items" and carried none of them. Places,
beings, factions, races and ailments were still governed by the exact wording BUG-089 had already found
insufficient. Nothing caught it because the assertions that would have are in `test_item_lore.js`, and
they only ever read 13b.

It reproduced twice in one short run, on Opus 5.5. The South Gate and Ashfen Moor hooks were performed
and articulated, and the Game Master narrated them back in the world's own authored words — the named
verge stones in two rows facing the moor, the smith's mark under the crossbar where nobody looks, the
wisps keeping to a line over something straight and buried — and then withheld only the confirmation.
`loreUnlock` was null both times and no nearMiss nudge was set either, which is BUG-059 in the same
breath. Both fired on a second, more emphatic attempt. That is precisely the recovery shape BUG-089
recorded and explicitly declined to count as proof, because the re-attempt wording was more explicit than
the first: this run is the "run of fresh hooks under the new rule" that entry asked for, and it missed.

13d now carries the same four commitments, worded for hooks rather than items. The test pins them as four
separate properties rather than one quoted paragraph, so the wording may still be improved, and adds the
assertion whose absence is the actual defect: every commitment 13b makes about the field, 13d must make
too. Not that 13d was written badly — that its declared twin was strengthened and it was not, with
nothing anywhere comparing the two.

Deliberately still no engine net, for the reason BUG-089 gives: the engine cannot tell a narrated
discovery from any other prose without reading it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Three gaps found by comparing the guides against Sept 24-28's Tasks/Errands and Merchant
Restocking work: the being-fields table never named restock, restockTo or restockHours,
though the per-item Restock control has sat on a being's Inventory card since 23 Aug next to
Respawn; the Field Guide's Region Builder section stopped one paragraph short of what
commit 27e9807 added to the DM's Guide about a region's own materials, the reuse-before-mint
rule, and where it will and won't add a vendor; and the Player's Handbook's Journal chapter
described the Tasks tab as it worked before this week without saying the milestone boxes are
a GM-only indicator now, or that an errand can arrive from a conversation with no card written
for it ahead of time, or the five-open-errand cap, or that none of it gates the story.

Bumped both guides' Last Update stamps. Left test_asset_provenance.js's and
test_craft_balance_pass.js's failures alone — confirmed pre-existing against origin/main by
stashing this change and rerunning, and both look to already have fixes landing from other
sessions in the same window.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HqSbDUzcehgS1WQZWxcPc7

The built-in world's only armour carried no "ac", so nothing could weigh its 40 coins against what it
protects, and — more to the point — wearing it did nothing at all. `playerAC` reads `ac` off equipped
armour and there was none to read.

It is 11, which is the authoring directive's own band for partial mail (padded and leather around 11 to
12, full chain around 14). A coif is chain over the head and neck and nothing else, so it sits at the
bottom of that range.

It is `ac` and not `acBonus`, and the distinction took a wrong turn worth recording. The taxonomy's
one-line summary for armour reads "Body armour carries ac; everything else worn carries acBonus", which
invites the reading that a head piece takes the bonus field. It does not. The split is by TYPE, not by
where a thing sits: the Wearable entry says so outright — "Protective gear is armor: the line is what
the thing is FOR, not where it sits on the body" — and `makeItem` enforces it, dropping `acBonus` from
anything typed armor. A coif authored with `acBonus` therefore carries a field the engine discards on
load, which is worse than carrying nothing, because the world then looks armoured and is not.

Left alone deliberately: `playerAC` sets `base = a` for each equipped armour piece in `Object.entries`
order rather than taking the best, and its own comment assumes "one armor slot, so the equipped piece
wins". A world with a coif AND a hauberk would have a base AC that depends on key order. This world has
one armour piece so it cannot bite here, and guessing at the intended rule — best piece, or sum, or
head-pieces-are-not-base — is an author's decision rather than a repair.

The built-in world now reports nine findings, all `info`, down from forty-six when this began, with no
warning or error of any kind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Every one of the fourteen beings carried hidden history and not one of the fourteen places did, which
the pass reported as a shape rather than a defect: a world may keep its secrets in its people on
purpose. The owner's answer was that this one should not, and the reason is on the map — the plot is a
barrow, a moor and a vault sealed from the inside, so the locations are the story and were saying
nothing.

All fourteen now carry lore, a key and a price. Each is written against something already in that
room's own description rather than beside it, so the hook has a physical thing to hang on: the dry
fountain that stopped the night of the Skirmish, the milestone whose scratches are a tally of wardings
rather than damage, the dressed cobbles at the Herbalist's end of Market Row that turn out to be the
buried road running out to the mound, and the runes over the barrow that every generation reads as a
warning to trespassers and that are cut facing inward. Several of them tie the three time-scales the
world already had — four centuries since the Shattering, thirty years since the Border Skirmish, now —
to one another, which is work no room was doing before.

The keys follow the same rule as the beings': a concrete act and the articulation, because the hook
fires on the player saying what a thing means rather than on having looked at it.

Objectives go 110 to 124 and findings 11 to 10, and the ten are all `info`. The built-in world now
reports no warning and no error of any kind.

Three tests had been resting on the shipped world's defect and are repaired rather than relaxed.
`test_lore_shape` took the untouched built-in world as the fixture for the very finding it is about, so
fixing the world falsified the test; it builds the shape now, and applies it to the live world as well
as the serialized copy, since its last section re-evaluates the live one. `test_decision_branches`
gains an explicit fixture for the kind it was covering by accident, beside the one added for the
economy this morning for exactly the same reason. `test_lore_reach_player_self` searched for a room with
NO lore to use as its far hook and died on undefined when there stopped being one; it never needed a
blank room, only a different one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Web/AccountPage/images shipped seven images into a directory DIRS in Tools/build-asset-inventory.js did
not reach, which is the sixth new leaf under Web/ to arrive invisible to the inventory. It is also the
first one a person did not have to notice: test_asset_provenance.js walks Web/ for media and fails on a
directory DIRS does not cover, and that guard — added after the fifth — named this one. The failure mode
it exists to prevent is the quiet one, where a file the scan never walks is not reported UNKNOWN but
simply absent, so --check passes while the report stops describing the tree.

Three of the seven then reported UNKNOWN and are declared here. All three were settled by hashing rather
than by looking: each is byte-for-byte an already-declared file, so its provenance is that file's and
nothing here is a fresh determination. The night panel matches the landing page's key art, and the mark
and favicon match the Brave You Worlds mark. The other four never reached the ledger at all — the char-*
studies carry their own C2PA naming Google Generative AI, which the inventory reads unaided.

The owner's answer offered two possibilities for these files, either copies of images already in the
repository or new work generated with Nano Banana Pro, and hashing settled which: all seven are copies,
so no generator claim is recorded that the originals do not already carry. That distinction is worth the
care, because two of these filenames are traps. Web/WorldBrowser/images/VillageSquareNight.png and
Web/WorldBrowser/images/logo.png are DIFFERENT files under the same two names, declared separately as
Nano Banana Pro work — a night panel the landing page has not got, and a crossed-swords device that is
not the company mark. Matching on filename would have carried the wrong attribution onto both of these,
complete with a generator statement nobody ever made about them, and it would have looked right.

The regenerated report also picks up the World Browser set, which landed after the last regeneration: the
committed inventory was itself two days stale, describing 255 files where the tree holds 279.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Every count assertion in Tests/test_craft_balance_pass.js is exact — one finding for the world that is
meant to produce one, zero for the four that are meant to be silent — and the filter behind those counts
is `/^working-/`, which was the whole family when the file was written. It is not any more.
`working-unsupplied` landed afterwards and reports a recipe whose ingredients nothing in the world
supplies. The fixture's room held no items, so it fired on every case, and nine assertions went red at
once while the check they are about was answering correctly in each of them. The failure read as a
balance regression and was nothing of the kind.

Placing the two ingredients on the floor is the fix rather than narrowing the filter, and the difference
matters. Narrowing would have restored the counts by teaching this file to look away from a finding kind,
which is how the collision comes back the next time a kind is added, and §4's assertion that a broken
working is reported once and not twice depends on the filter seeing every working finding there is — it
is the one place the count is load-bearing in the other direction. Stocking the bench also happens to be
the honest reading of the question the file asks: whether making a thing beats buying it is only a
question about a world where the making is possible at all, so a fixture that asks it over ingredients
nobody can obtain was asking about a world that does not arise.

Checked by sabotage against the corrected fixture rather than by the suite going green, since a fixture
change is exactly the kind of edit that can quiet a test instead of fixing it: removing the
working-destroys-value finding, flipping its severity to error, and stripping the rival off its subject
each still produce two distinct failures naming the cause. `working-unsupplied` keeps its own coverage in
Tests/test_working_supply.js, so nothing that was tested here has stopped being tested anywhere.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Twenty-three records in the built-in world carried authored lore and no loreKey: all fourteen beings and
nine of the objects. The writing was in the world and nothing could reach it. In the evaluation plan
those twenty-three objectives — a fifth of the whole plan — read `intent: (GM discretion — no authored
key)` with confidence `needs-phrasing`, which means a graded run could only ever score them on whether
the Game Master happened to improvise the right moment.

Each key names a concrete act AND the articulation, because that is how the hook actually fires: doing
the thing is not enough, the player has to say what it means. So Aldric's is not "show him the bog iron"
but showing him the iron and saying aloud that it is coming up wrong the way it did before the Skirmish.
Every key was written against that record's own lore rather than invented beside it, which is why the
Gatekeeper's names his son and the signet's says outright that the ward is not a ward.

They are written into WORLD_DATA rather than run through the Lore roster in the browser, and the reason
is worth recording: the built-in world is source, not a save. A Fix World pass authors into the world
object the editor holds, which for every other world is the thing that persists and for this one is a
copy that dies with the tab. The roster path is right for a vault world and cannot reach this one.

Pricing followed, because the pass then said the quiet part: all fourteen being hooks paid the same
12-XP default, which is a default wearing the clothes of a decision. They are priced now against the
barrow plot — the dead king at 90 and his regalia behind him, the three named narrative threads next,
the moor's signs after that, village colour last — in the band the pass itself uses, 12 as the default
it complains about and 100 as the ceiling it prices against.

The built-in world now reports eleven findings, every one an info, down from forty-six. Objectives stay
at 110 throughout: none of this adds anything to grade against, it makes what was already there
reachable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Two of the built-in world's three remaining decisions, answered by the owner and written down.

The eleven catalogue items nothing referenced — Bronze and Silver Ingot, Silver Wire, Gold Leaf, Niello
Paste, Enamel Frit, Gemstone Chips, Green Timber, Birch Bark, Raw Silk, Setter's Pitch — are in-flight
stock for crafts other sessions are building, and the intent for them is that vendors will carry them or
the Game Master will spawn them as task rewards and emergent loot. That intent already has a name in this
codebase: `pooled`, the flag whose whole purpose is the author saying outright that an object enters play
through the GM rather than by sitting in a room. Marking them is not silencing the finding, it is
answering it, and it buys the thing the flag exists for (BUG-045): the pool BOUNDS the improvisation, so
a model reaching for a silver wire finds the authored entry with its real value and weight instead of
minting a plausible near-miss. The denominator does not move — 110 objectives before and after — because
a pooled item was never something a run was graded on reaching.

The economy is declared Mercantile. The world is a village built around a market row, a herbalist, a
smith and two new crafting suppliers, and it measured a 100 fit against both Mercantile and Patrician, so
the tie was broken on what the place actually is. Declaring it converts three parked checks —
cost-locked, too-little-loot, no-wealth-progression — from prose into measurements, and it scores clean
against the archetype, raising neither the off-archetype warning nor the leaning note.

It has to be written as `{ "archetype": "mercantile" }` and not as a bare string: `normalizeEconomy`
refuses anything that is not an object and returns null, silently, so a bare id reads as undeclared. The
generation brief carries the bare id and converts it on the way in, which is why nothing had noticed.

`Tests/test_decision_branches.js` gains an explicit fixture for an undeclared economy. Every fixture there
starts from the built-in world, so `economy-undeclared` was being triggered by that world happening to be
silent, and declaring one left the kind covered by nothing. The fixture that needs an undeclared economy
now says so instead of inheriting it.

Findings on the built-in world: 46 to 34, with unplaced-item and economy-undeclared both cleared.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

A correction to yesterday's ref-only rule, which was right about one case and wrong to make it the only
one. The distinction that matters is not about ids: it is about WHO HOLDS THE OUTCOME, and the author
chooses that when they write the errand.

Where the author has DECIDED — ten copper's worth of bread, that shortsword — the reward names catalogue
ids and the Game Master hands one of them over. It may pick another id this world has where the note
asks for a choice the list could not spell out, and it may not invent an object at all. That refusal is
the coral_reliquary failure: a beat whose reward was an authored object delivered a freshly minted
look-alike, every surface on screen read correctly, and the player held a duplicate carrying none of the
real item's lore, value or XP, which the quest wanting the real one could never be satisfied by. Where
an original exists, a mint is a counterfeit of it.

Where the author has deliberately NOT decided, a note alone is the whole promise, and that is authoring
rather than an omission. The right answer depends on something only the moment of handing over can see,
so the Game Master authors the object then — and there is no original for it to counterfeit, which is
exactly why the same act is refused above and invited here.

What the choice turns on is the note's business and is not always the player. One shape leans on who is
RECEIVING it — "an iron weapon suited to their class" — where a cleric and a druid should not walk away
with the same object, and the delivering turn can see who finished the errand while the author could
not. The other leans on who is GIVING it — "the herbalist offers something from her cabinet" — where
what matters is that the thing is characteristically hers, a salve or a tincture, whoever she happens to
be paying. The engine has no opinion about which, so the rule carries it and says plainly not to
substitute the player for a note that was talking about somebody else. The two failures look alike in a
session and are opposite mistakes: a Game Master that hands every class the same weapon, and one that
hands a herbalist's cleric a mace because it has learnt that rewards are about classes. The playtesting
notes ask for both errands to be run for that reason.

One mechanical rule keeps the shapes from crossing: a string is always a ref and an object is always an
item to author. A bare name sent where an item was meant is read as an id, found to be nothing, and
refused with a note back saying which shape that errand wanted.

An authored reward's VALUE is logged and never checked, on decision O's reasoning: the engine pricing a
reward would be the second payer this design refuses, and the figure is there for a Dungeon Master
reading the Logs to see what the Game Master thought the work was worth. The Errands card makes the note
a field in its own right — it was gated behind having ids, which made the deferred shape unauthorable
from the card — and says on the card which shape an errand is in.

Nine sabotages, each caught by its own assertions, including a deferred errand that may not author after
all, a named one that accepts a counterfeit, a bare string read as an item, and the rule losing its
sentence about the giver.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The encounter finding's twin, and it had to wait for the supply check to be right before it could be
written at all. A concoction is obtained by brewing it, so it stands in no room by design, and
`unplaced-item` was reporting both of the built-in world's concoctions as oversights — telling a DM to go
and place the thing the crafting system exists to produce.

The obvious rule is "a recipe's yields is reachable", and on the day this was written that rule was
FALSE. Every ingredient under both workings was itself obtainable nowhere, so the two concoctions were no
more reachable than any other orphan, and a flat exemption would have hidden two true findings behind a
sentence that reads as plainly correct. So the exemption is conditional: an output counts only when the
chain under it bottoms out in something a player can hold, which is the same question `working-unsupplied`
asks. It is asked once, by a predicate hoisted out of the craft pass to where both checks can reach it,
so the two can never give different answers about the same world. The test builds a world with one
supplied working and one unsupplied one and asserts the second product is still reported.

`craft-placed` says which items are obtained by making them and what each is brewed from, as an info,
exactly as `encounter-placed` says which beings arrive without standing in a room. Naming the
ingredients is not decoration: a bare "this is craftable" is the pass asking to be trusted about the one
thing it had just got wrong.

`Tests/test_pooled_items.js` is re-anchored while here. It pinned the guard line verbatim and broke on
this change for the second time — the line had already grown a rebinding exemption — although pooling
itself was untouched both times. It now finds the finding it is about and walks back to the guard above
it, and removes the one `it.pooled` clause rather than the whole line, which is also a sharper sabotage
than deleting three exemptions to test one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The built-in world shipped a complete concoction chain that nobody could use. Four reagents, two
workings, a skill to run them and a book teaching one of the preparations — and all four ingredients
underneath (Comfrey Root, Barrow Crust, Ember-Stone, Spider Gland) stood in no room, no container, no
reward, and nobody was holding one. Every record existed; not one of them could be obtained. The world
had three crafting suppliers by then, Hesk for leather, Wenna for wood and cloth, Aldric for metal, and
the chain the reagents system was built for had none.

Each ingredient is placed where the world already says it belongs, and deliberately by a different
route, because the three routes are the thing worth teaching. Comfrey Root goes to the Herbalist, who
already sells Nightshade and whose own written secret is that she is missing an ingredient she believes
exists only in the barrow. Barrow Crust lies in the Barrow Entrance, which is where the Venomer's
Receipt already tells the reader to bed a gland down in it. Ember-Stone joins Aldric's ores. Spider
Gland comes off the Giant Spider in the Ruined Watchtower, which is the only way an animal part should
ever be got. So the chain is bought, gathered and butchered rather than three visits to one shopkeeper,
and every placement was already implied by prose somebody wrote before the reagents existed.

`WORLD_DATA.version` is deliberately not moved. This adds content and removes no mechanic, so no save
written before it can fail to resume, and the gate exists for breaks rather than for changes. The
placements do not reach existing saves — `backfillWorldFromBuiltIn` merges records the save lacks by id,
and these rooms and beings are already in every save, so their contents stay as they were. That is the
documented additive-only behaviour and not a regression: a save whose player has emptied a room must not
have it refilled underneath them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Evaluating the built-in world turned up two workings — Knitbone Salve and Emberdust — that passed every
check the craft pass had. Every reagent declared, every ingredient present in the catalogue, the product
real, the skill in the skill list, the deal fairly priced. Neither can be made by anybody. All four of the
ingredients behind them (Comfrey Root, Barrow Crust, Ember-Stone, Spider Gland) stand in no room, no
container, no reward, and nobody is holding one. The pass reported nothing, because everything it looked
for was there: it was asking whether the world DECLARES each link, and never whether a player can ever
hold the bottom one.

`working-unsupplied` asks the second question. It is a warning and not an error, and the distinction is
the Game Master: `working-unmakeable` is for a name the world does not contain, and nobody can improvise a
reagent record into existence, while an item that exists and sits nowhere can still reach a player through
a merchant the GM invents — which is exactly what the `unplaced-item` finding beside it already says about
that same item. Grading this as unmakeable would say something false about what a GM can do, and saying
nothing leaves the gap the worldgen supply prompt exists to close sitting unreported in the shipped world.

Reachability is read from the sets `unplaced-item` uses rather than rescanned locally, because a second
scan is a second definition of "obtainable" and the two would disagree the first time either grew a case.
That is not free: it means the pooled flag, beat rewards, class kits and the rebinding chain all count as
supply here, and the test exercises each of them through a fixture where it is the ONLY route to that
ingredient, so deleting any one exemption fails one named assertion rather than shifting a total. The
check also runs only after the chain is whole — a missing ingredient is already reported unmakeable, and
telling a DM to go and stock it as well is asking them to place a record that has no entry to place.

The denominator does not move: supply is a finding, never an objective. An objective no run is sure to
satisfy is BUG-062 arriving from a new direction, and the test pins the count across a world with the
defect and the same world with it fixed. The card stays with the DM because the edit is trivial and the
judgement is not — which room, and whose stock, is a claim about who trades in what, and the built-in
world has a Herbalist already selling Nightshade with nothing anywhere recording whether comfrey is hers
to sell or grows on the hedge outside the gate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The region rule went into the DM's Guide with the change that added it, in the crafting chapter. That is
the right book and the wrong chapter: a DM who is about to press Build Region is reading World › Geography
› Regions, and that section described the brief, the eight fields and what the build writes without ever
mentioning materials.

So the same three points now sit where they will be met. What a region contributes — ore and cut stone
from mining country, timber and pitch from forest, hide and horn where the herds are — since what comes
out of the ground is part of what makes two regions different places rather than different scenery. That
the build is told to REUSE before it mints, with the reason stated plainly, because this is the one a DM
needs to recognise after the fact: the catalogue keys on a slug of the name, so an Iron Bar authored beside
an existing Iron Ingot has split one material rather than added one, permanently, and the guide now says
what to do when you see the near-twin (delete the newcomer and repoint what used it, rather than keep
both). And that a vendor appears only where the region has somebody to sell from, which deliberately
differs from the whole-world build's requirement of at least one — a world without a materials trader is
broken, where a region made to produce one grows a shop in a swamp.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Decision P, and the same arrangement as the coin beside it: the errand carries a promise, nothing pays
it, and the Game Master hands it over in the scene. `reward.refs` names catalogue ids and `reward.note`
carries the author's own words about which one and how; the Game Master picks at the moment of delivery
and sends the id back, and the engine grants that object once and records which.

Refs and never an inline item is the load-bearing half. An id names an object that already exists in
this world, authored and priced by whoever built it; an inline item is one minted at the moment of
payment, and two items can share a name while only the ref says which one is real. Rule 10a's third
paragraph is that failure observed in play — a beat whose reward was coral_reliquary delivered a freshly
minted look-alike, and nothing on screen looked wrong while the player held a duplicate carrying none of
the authored item's lore, value or XP. So an id this world does not have is refused outright, nothing is
granted, and the refusal is queued back before the scene can claim the player is holding it.

A LIST rather than one, because the interesting reward is shaped to the player: fetch Aldric his ore and
he pays with a weapon made from what is left of it, and which weapon depends on who is standing in his
forge. That forces one deliberate soft edge — an id outside the listed ones is allowed and logged as
not-listed, because the list is examples as often as an enumeration and no author writes out the whole
armoury. Refusing it would make the shaped reward unauthorable. The hard rule is the world's catalogue,
not the author's list.

Only an authored errand carries one. An errand the Game Master invents in conversation has its reward
stripped, on the duty fields' reasoning: ref-only is what keeps minting out, and an improvised errand is
exactly where a guessed-at id would come from. The Game Master may still hand something over in the
scene with the fields it has always had; there is simply nothing on the record for the engine to grant.

The authoring half matters as much as the field, and is what was asked for: a person writing an errand
may have to create the thing that pays for it, so the NPC directive now says to define it in the
top-level items object — the same mechanism, in the same breath, that already creates the item an errand
asks the player to fetch — and to list several with a note where the right reward depends on the
finisher. The same directive had never mentioned `coin` either, which is fixed here. The Errands card
gained both fields and marks an id the world does not have in red, rather than leaving it to surface on
the turn somebody tries to hand it over.

Recorded as a limit rather than glossed: the evaluation pass reads no tasks at all. It counts quest beat
rewards as findable wealth and prices a world against them, which is the reasoning behind stripping
rewards from promoted beats, and it has never looked at player.tasks or ent.tasks. So an errand's coin
and its goods are both outside the wealth model and the fixed-pool argument does not reach them.

Twelve sabotages. Two of them found holes in the test rather than the code, both fixed here: every
reward assertion drove markTaskMilestone directly and would have passed with the turn field never wired
up — the hole CLAUDE.md names — and the invented-errand strip has a sibling guard in the named-field
construction, so removing it alone changed nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The region build is a second, separate directive with its own assembly, and it had the same gap the
world-generation one did: the item taxonomy's labelling rule, and a single mention of "materials" in the
list of things that take no equipment slot. Nothing asked a region to contribute anything a craft could
use.

But the world's words would have been wrong here, in two directions, and getting that right is most of
this change. A region joins a world that ALREADY has a supply, and the directive hands it the list a few
lines above under "Existing items" — so its first instruction is reuse rather than authorship. A region
that mints "Iron Bar" beside the world's "Iron Ingot" has not added a material, it has SPLIT one, and
nothing merges them afterwards: the catalogue keys on a slug of the name, so two names are two materials
for ever and a craft written against either is unbuyable wherever the other is stocked. The dismantle
directive already guards that exact failure with that exact example, which is how the shape was known
before it was looked for.

The other direction is the vendor. The world rule requires at least one materials trader because a world
without one is broken. A REGION made to produce one grows a shop in a swamp. So the region gets a trader
only where the place has somebody to sell from — a settlement, a camp, a waystation — and is told plainly
that a wild region's materials are found rather than bought, because without that sentence "author a
vendor" reads as unconditional and the model obliges. What it does ask for is what this place actually
yields: ore and cut stone from mining country, timber and pitch from forest, hide and horn and sinew where
the herds are, salt and shell and gut off a coast. That is one of the few things that makes two regions
economically different rather than only different to look at.

Ten more assertions in Tests/test_worldgen_crafting_supply.js, including two that compare the two
directives directly and assert they are DIFFERENT rules rather than assuming it — the world requires a
vendor and the region does not; the region requires reuse and the world has nothing yet to reuse. Proved
against three more sabotages: the region rule built and never referenced, reuse softened to a suggestion,
and the region handed the world's vendor requirement.

Worth recording that the first of those sabotages is a bug this change actually committed, in both
directions within ten minutes: a rule referenced before it was defined, and then a rule defined and never
referenced. Neither is a syntax error, both survive a parse, and the second is invisible in the source —
which is exactly why these files read the directive back out of a stubbed gmFetch instead of grepping for
the text.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Found while evaluating the built-in world, and found by the owner rather than by the pass: the Villager
was reported "placed in no room - the player can never meet it", and it is in fact spawned by an
encounter at fifty per cent into five rooms. A world's encounters put beings into rooms on a chance and
an interval, so they sit in no room's entities list because that is not how they get there, and the
pass was reading that absence as absence from the world. It never looked at world.encounters at all,
though serializeWorld has always carried them.

It matters more than a miscount because the action plan turns findings into work. Two remedy cards were
telling a DM to place a being that is meant to roam, and a false finding is worse than a missed one
wherever a plan is generated from it.

The asymmetry in the fix is the part worth keeping. Encounter spawns are kept in their own list rather
than folded into placedEntities, because placedEntities feeds the monster objectives and an encounter
is not a guaranteed meeting - a run can finish without ever seeing a twenty per cent spawn, and
counting one would put something in the denominator no run is sure to satisfy, which is BUG-062
arriving from a new direction. Lore is different and is counted: a being met at all gives up its lore,
and an encounter that repeats on an interval will be met. So the Villager's lore objective now carries
a real room and depth instead of the null-room "weak" confidence it used to have, and the denominator
does not move - verified by diffing the plan before and after at 106 objectives either way.

A new info finding says which beings arrive this way and names every room they can appear in, because
a DM told "arrives by encounter" and not where has been told it is not a bug and nothing else.

Five sabotages, each caught: encounters ignored again, the unplaced check no longer consulting them,
encounter beings folded into placedEntities so the denominator moves, the finding no longer naming
rooms, and the finding raised from info to warn. Section 5 builds the same world with the encounters
removed and asserts the being is reported unplaced again, which proves the suppression follows the
declaration rather than the name.

The new kind took the count from 62 to 63 and the infos from 19 to 20, so test_remedy_coverage failed
until the prose in world-evaluation.html and README.md agreed - which is exactly what that check is for.

App suite 949/950; the one failure is the pre-existing Encyclopedias build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Everything up to here fixed the built-in world — thirty-four materials, three traders — and left a
generated world exactly where the built-in one had been. The generation directive asked for none of it.
The word "materials" appeared once in the whole prompt, in the equipment-slots note, as an example of
something that does NOT take a slot, so a generated world arrived with the six crafting skills (the
standard set is ticked by default) and, unless the model volunteered them, nothing whatever to craft with.
A player who learnt Metalwork had a skill and no iron.

The part that looked like coverage and was not is worth recording, because it is what made the gap easy to
miss. itemTaxonomyPrompt is interpolated into this directive and already carried "ALWAYS include the
subtype material when the item is stock a craft consumes". That is a rule about SPELLING, and it does
nothing at all until something asks for the thing to be spelled. A test searching the directive for the
word would have passed against the gap — and two assertions in the new file did exactly that on the first
draft, staying green when the whole rule was deleted, because "mineral", "animalpart" and the ref row
appear elsewhere in the prompt. They slice the block and assert inside it now.

The rule asks for a working stock of two or three materials per craft the world actually practises, typed
by what they are rather than by what they are for, and in that world's own register — a realm of ash and
bone does not sell oak planks, and the materials are one of the fastest ways a setting reads as itself
since they are what everything in it is visibly made of. It asks for the stages where a trade has them,
because that is what gives a craft something to do TO a material rather than only with it. And it asks for
at least one being whose stock is materials rather than gear, placed where the player passes early,
stocked by ref, with a routine the room's description agrees with. It ends by bounding itself: two or
three lines per craft, nothing for a trade nobody here practises.

It sits with the ECONOMY rather than with the items, which is where it belongs. §8 of the crafting design
bounds this economy at the INPUT end; the economy brief above it measures a world in "kits" of a weapon
and a piece of armour; and cannotBeAKit deliberately excludes materials from that measure. So the supply
side of a world's crafting was measured by nothing and asked for by nobody.

And "crafting" turns out to be load-bearing in the way "spellcasting" is. CRAFT_GATE_SKILL,
DISMANTLE_GATE_SKILL and REPAIR_GATE_SKILL are all that one literal string, and the directive has always
said so for magic and never for this — so a world authoring its own skill set and keying its smith-craft
"Smithing" lost making, mending and dismantling for the length of the game, silently. The rule is written
in the same words as the magic one, on the same branch, with the family crafts explicitly free to be named
anything since they buy proficiency and never permission.

Tests/test_worldgen_crafting_supply.js is new: seventeen assertions reading the directive as its siblings
do, by capturing it from a stubbed gmFetch rather than regexing the source — which matters here, because
this rule was written as `craftingSupplyRule` and left unreferenced on the first attempt and the source
would have looked perfect. Proved against three sabotages: the rule built and never concatenated in, the
gate rule naming the wrong id, and the vendor half softened from a requirement to a suggestion.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Rev. 33 recorded the two Market Row traders in this doc's history and left the sections anybody actually
reads unchanged. Three of them were stale, and the first is not housekeeping.

§8 is the one that matters. Its whole argument is that an open crafting system should be bounded at the
INPUT end rather than the output end — no value ceiling to tune, just the rule that a craft combines what
exists and never creates it. A bound on inputs does nothing while there are no inputs. For thirty-two
revisions the built-in world held three material-ish items and sold none of them, so "the materials are in
the world" was a condition almost nothing could meet and the section's central claim was true and inert:
every craft had to begin with a dismantling or with a DM opening the editor. Thirty-four materials and
three traders turn the principle from a statement into a supply, and it starts working in the direction
§8 argues for — the ceiling on what a player can make is now literally what the Row has in stock and what
their purse will reach, which is a number the world sets rather than one anybody tunes.

§13's staging told a playtester to get materials into the pack and did not say that the shortest way is
now to walk to Market Row in daylight and buy some, which is the least ceremony this system has ever asked
for. It says so, with the daylight part flagged, since all three traders keep the herbalist's hours.

And there is a sixth continuation group under I, which is unusual in having NO ENGINE BEHIND IT. There is
no shop screen and no shop record: a vendor is an NPC carrying stock, the room dossier hands the Game
Master what each being has on it, and the sale is entirely the model's to narrate. So every step in that
group tests whether the Game Master reaches for what it has been handed rather than improvising over it,
and a failure there is a prompt finding rather than a bug — which is why the two Notes that come with it
ask for the wording back verbatim. The second generalises well past crafting: both Row traders are asleep
after dusk and the room says so, so asking to buy at midnight is asking whether a routine is a schedule or
a suggestion, and the same machinery moves every NPC in the world.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The vendors themselves went into both books with the change that added them. What neither book had, and
what the being-fields table walks past, is the part a DM needs the moment they want a trader of their own:
what actually makes somebody a shop. The answer is worth writing down because the obvious one is wrong.

A vendor is an NPC who CARRIES the stock. There is no shop screen and no shop record; the Game Master
adjudicates the sale out of what the being has on it. Putting `merchant` in a being's classes does not
create that — it files them under Merchant in the Compendium and is what the GM attaches when you ask it
for a trader, which is useful and is a label rather than a mechanism. A DM who adds the class and no stock
has made somebody who stands next to nothing.

Two traps follow it into the guide. Stock goes in by `ref` rather than written out inline, because a ref
hands over that catalogue entry and an inline copy is a second definition of the same thing that drifts
the first time either is repriced. And a mistyped ref is SILENT: it neither warns nor fails, because the
engine mints an empty entry under the id it could not find, so the stall sells something with no name but
the id, no description and no worth — which reads exactly like a shop the player has already cleaned out.
That is the trap this session fell into while writing the vendors' own test, and it has cost time twice
now, so it belongs in the book rather than only in a test comment.

The third note is about prose rather than data: a trader's routine genuinely takes them out of the room,
and the room's own time-of-day descriptions are separate text that will not follow. A description still
hawking at midnight while the routine has them asleep is a contradiction the player meets and the engine
never notices — which is exactly the state Market Row was in until the vendors landed.

The Field Guide gains the player's half of the same shape: materials are a morning errand, and the fine
engraver's stock is sold nowhere on purpose, so a player who cannot find gold leaf has found the answer
rather than a gap. Both stamps refreshed.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

A catalogue of materials nobody sells is a catalogue of materials nobody has. Thirty-four of them landed
yesterday and there was nowhere to buy one, so the Row gains two traders beside the herbalist. Hesk is the
tanner — hide through cured to tanned, calfskin, sinew, tallow and bone toggles. Wenna is the chandler,
who sells what every other trade needs and none of them makes: board, haft, glue, pegs, charcoal and
rivets, and cloth from flax fibre through thread to the bolt. Both keep the herbalist's hours, which the
room itself had already insisted on — its midnight description has the stalls standing empty and skeletal
under the moon — and all six time-of-day descriptions now mention the three of them rather than describing
one stall while the room holds three.

The metal went to Aldric rather than to a third stall. The brief allowed two and the forge is where ore,
ingots, charcoal and flux belong; he already sells what he makes, and these are what he makes them from.
That is stock added to an NPC rather than a vendor added to the world, which is why it fits inside a
request for two.

Engraving is deliberately unserved, and the test asserts the absence rather than leaving it to be
re-litigated. Gold leaf, niello and enamel frit are not village-market goods, and standing them on a
cobbled row beside the bread would let the catalogue settle a question about the world by accident. The
materials exist; where a character buys them is a question for a city.

THE TRAP FOUND WHILE PINNING THIS IS WORTH MORE THAN THE VENDORS. The obvious assertion for a shop is
"every ref it stocks resolves", and that assertion cannot fail. A mistyped ref neither warns nor throws:
registerInlineItem mints a husk under the missing id, so the catalogue always agrees and the stall quietly
sells a nameless thing worth nothing. The first version of the check passed against a deliberate typo and
was caught only because a second assertion happened to fail on the same sabotage. It reads the AUTHORED
roster now, captured at bind time before any world is built, because that is the only thing left that
still knows a typo was a typo.

Tests/test_crafting_stock.js gains ten assertions over the vendors and the claim the roster makes — that
each craft has stock somebody sells, asserted through a material the craft plainly needs rather than by
counting, since a count passes while a whole trade is missing. Proved against four sabotages: a mistyped
ref, a vendor missing from the room, a craft losing its finished stock, and a trader who is not a merchant.

One test needed fixing rather than satisfying. test_lore_shape.js asserted the built-in world's lore
sentence matched /12 of 12/, and two new beings carrying lore made it 14 — a hand-written count inside a
test, which is the failure this repo keeps paying for in prompts, one level down. It reads the number off
the coverage the finding reports and asserts the sentence and the data agree, which survives the next NPC;
sabotaging the message's wording in build-evaluation.js confirms it still bites.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Regenerated from git history via Tools/gen-progress-report.js: the September
month page and the index now cover the run through 2026-09-28 (4,401 commits,
91 active days).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WsUzeH9SFxorZdZ4r1gnr2

A player who learnt Metalwork had a skill and no iron. The built-in world held three material-ish items
between them — an ingot, a lump of bog iron, a fang — all typed misc with no subtypes at all, one of them
described as "Raw crafting material" and worked by nothing in the game. There are thirty-four now, one set
per craft: ore through ingots and charcoal for the forge, hide through cured to tanned for the tanning
pit, timber and plank and glue for the bench, fibre through thread to cloth for the needle, and gold leaf,
silver wire and enamel for the graver.

The roster is the easy half. The interesting question was where each label had to live, and the answer
moved two of them. A material is TYPED BY WHAT IT IS rather than by what it is for — an ingot is a
mineral, tanned leather an animalpart, a bolt of linen misc — which costs nothing to say because the
taxonomy already carried it: mineral and animalpart both have a `state` facet, so ore → refined and hide →
tanned were expressible without inventing anything. And `material` had to become a UNIVERSAL label to be
usable at all. It existed already, as a role value on `misc`, and a facet value belongs to its type, so
while it lived there only the misc half of any world's materials could carry it. It moves beside wearable,
quest, masterwork and broken, and misc gives it up — the same trade the wearable entry records for jewelry
and clothing, for the same reason: a label listed twice gives an author two reasonable ways to write one
thing.

That needed the rename to make room. The dismantler stamped every part `crafting material`, which is
exactly the phrase somebody cataloguing ore and planks reaches for — so both piles would have worn one
label and the distinction that stamp exists to draw, a pile of salvage tellable from a pile of shopping,
would have quietly stopped being drawable. It stamps `salvage` now, which is what it always meant: this
came out of something that used to be something else. Nothing branches on either label, so the cost was
prose rather than code, and salvage already stamped into saves keeps the old string — inert, and not worth
a migration for a label.

Three things broke on the way in and all three were already written down somewhere. Iron rivets and wooden
pegs were labelled `component`, which is the right English word for a small fitting and routes an item
into allIngredients() — the concoction recipe picker and the ingredient roster the model is shown. They
were alchemical ingredients for about ten minutes. Second, 2c charcoal became one of "the two cheapest
purchases" build-evaluation.js prices an opening kit from, dropping the budget and silently clearing a
too-little-loot warning on a world too poor to equip anybody; that is the third time that hole has opened,
and the tool's own comment had already named what ought to be excluded — "anything spent in the using, or
consumed as an input to a craft" — with no label for the second half until now. Its coverage assertion
caught it exactly as its comment predicted. Third, the new universal label's first draft explained itself
in 370 characters and pushed the taxonomy block the GM carries EVERY TURN from 1,270 to 1,730 against a
1,500 ceiling; the reasoning moved to a comment, and the thirty characters of headroom left mean the next
universal label will not fit without somebody deciding what to spend.

Tests/test_crafting_stock.js is new — nineteen assertions over the roster, the label's single home, the
two rosters being disjoint, and salvage and material being different words — proved against three
sabotages: the two words collapsing back into one, misc offering material a second home, and a material
routed as an ingredient again.

Both guides carry the pair and the `component` warning, and both say how to ask for the set in a world of
your own, which is exempt from the built-in merge and therefore has neither these materials nor the
crafting skills.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Three things, and the third was found rather than looked for.

BUG-072 closes. Its last obstacle was one stale save and it was never a sighting: Test2, a test
character standing in northern_road, a room its own world does not contain, unloadable as it stood and
undated because saves carry no timestamp. It has been MOVED rather than destroyed - copied to a
quarantine key, verified byte-for-byte, and only then removed from the library. The audit and the load
menu no longer see it; the bytes remain for anyone who wants to examine the artefact the entry is
about. The login audit now reports zero faults over eleven saves, and the tripwire has been silent for
twenty-five days, which meets both conditions this entry set itself. The two firings three hours after
the fix stay on the record rather than being argued away, since a tab open since before it would have
run the old code until reloaded and nothing settles which it was.

Claude20's contaminated capture is dropped by the same method: the 181 turns baselined on a Bladeward
are quarantined, and the save itself is byte-identical in every field that matters - name, class,
level, xp, room, inventory, world - and still passes snapshotIsResumable. The tape was mislabelled; the
game was never touched.

BUG-099 files the login-screen shuffle the owner reported, and it earns an entry for the diagnosis
rather than the defect. "Loads Claude22 first, THEN shuffles to Malina" is two paints rather than one
wrong read, and the red banner they could not read separated two causes that would otherwise have been
treated as one. The entry records that the first fix passed its own tests and changed nothing, because
populateLoginScreen runs at top level and the paint it hid happens while the script is still parsing;
and that an earlier draft would have disabled the Begin button for ever by raising the entry-button
latch during module evaluation, on a resolve that can hang.

And while reconciling the counts, two different bugs turned out to be sharing BUG-089 - the lore
discovery that is narrated but not recorded, filed 3 September, and the below-ground turn directives
filed today by a concurrent session. This is the hazard CLAUDE.md warns about and which the BUG-072
entry already records happening once to BUG-070. The earlier entry keeps the id, the later moved to
BUG-100, and the collision is written into that entry rather than quietly erased. Every chip now
reconciles with the divs it counts: 100 ids, 100 entries.

App suite 947/948; the one failure is the pre-existing Encyclopedias build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The first fix for the stale-name shuffle did not work, and the reason is the useful part.
populateLoginScreen() is called at TOP LEVEL, line 44891, so it paints the stale SAVED_NAME_KEY name
while the script is still parsing. Every veil the previous attempt raised was raised inside boot -
after the player had already been looking at the wrong character for the whole of startup. The veil was
real, the tests passed, and the symptom was untouched, because the thing being hidden happens before
any function boot calls.

So the dialog now ships veiled: setup-box carries is-resolving in the markup and _loginResolves starts
at 1 to agree with it, and boot's finally is the single release. Raising it again in boot would take
the counter to 2 and leave it at 1 afterwards, veiling the screen for the life of the window, so boot
only releases. The detached editor releases too, having no save to resolve and no dialog to be entered
through - without that it would sit veiled for ever.

The red banner nobody could read was the BUG-098 collision warning, and it was firing correctly on a
wrong premise. During the stale paint the name field holds the last character CREATED and New Game is
momentarily ticked, since it defaults to ticked until resumableSaveCached says otherwise - which is
exactly that warning's trigger. It fired, in red, about a collision with a save the player was not
opening and a new game they had not asked for. It is now suppressed while the screen is still resolving
who it describes. Veiling it would only have hidden it; suppressing it means it was never wrong, which
matters because a warning that appears and retracts itself teaches the reader that red text here means
nothing.

Two assertions in my own test had to be repaired, both the mistakes this file keeps recording. One
bounded the boot block by a margin past its first release and swept in a beginLoginResolve() belonging
to the next function. The other matched beginLoginResolve as an IDENTIFIER, so the comment saying "No
beginLoginResolve() here" read as a violation of itself - the same fault a sabotage caught against
resetSessionState earlier in this session.

Verified in the browser as far as it can be: the served markup carries the class, and after a reload
the screen settles on the active save with the veil off, the counter back to zero and no banner. The
transient itself is too short to sample from outside the page, so whether the shuffle is gone is the
owner's observation to make.

App suite 947/948; the one failure is the pre-existing Encyclopedias build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

`ent.tasks` was written by the editor's ask-bar, read into the authoring roster, and — since rule 10g
— sent to the Game Master at the table. It was shown to the Dungeon Master nowhere. The being card
drew Description, Attributes, Profile, Abilities, Inventory, Routine, Personalization, Ambient
Behaviors, Respawn and Restock, and nothing at all for the errands, so one could be authored and then
neither checked nor corrected nor deleted except by asking the bar again and hoping, with a `// list`
in the story as the only way to see what had landed. That is the same shape as the two defects rule
10g was built out of, and it was found the moment somebody tried to follow this doc's own playtesting
steps.

The section is always drawn on an NPC card, on the Inventory section's reasoning: an empty list is
exactly where somebody goes to add the first one, and a section that appears only once it has contents
cannot be the place you go to give it some. Name, description, XP, coin and a steps summary, editable,
with an Add and a delete, and a line saying what coin does here — a promise the Game Master hands over
in a scene, not something the engine pays — because that is the thing most likely to be assumed wrong.

The id row is what earns the section on its own. Two people carry the two ends of one delivery by
sharing a task id, and nothing anywhere showed a Dungeon Master what the id was, let alone let them set
it — so the feature decision N describes could be authored and not verified. Typed text is slugged, and
a blank falls back to a slug of the name rather than leaving an errand rule 10g can never name.
Renaming deliberately does NOT renumber the id, which would break the join under the author's hands
while they were doing something else. A collision within one person's roster is refused and logged,
because two errands on one person answering to one id cannot be told apart when one is offered; the
same id on a DIFFERENT person is left alone, because that collision IS the feature, and a guard that
treated the two alike would make the thing unauthorable.

Deleting removes the template only. A copy already on the player's sheet is theirs — they agreed to it,
and the author changing their mind later does not un-agree it.

Tests/test_editor_errands.js drives the real renderer rather than asserting over the source, which is
what catches the version of this that gets built and never reaches the card — the first of nine
sabotages, all caught. The others include drawing it only when non-empty, hiding the id, giving it to
monsters, renaming renumbering the id, allowing a collision within one person, refusing one across two,
and a delete that took the player's copy with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Two findings from the first session anybody spent actually playing this, both reported from the bench
rather than from the code.

THE HOURS NEVER APPEARED. §9 spends four sections arguing that the cost of a craft is time and §9.2
settles that the time passes a sitting at a time; on screen the clock simply jumped and nothing said a
week had gone anywhere, so the mechanic the whole dial turns on was the one thing the player could not
see happening. A sitting now plays the timed banner sleeping uses — the clock face at each end, the span
in hours, a bar that sweeps while the header clock fast-forwards over ground it has already covered. That
ordering is the arrangement every other timed act here uses and is not an accident: the authoritative
clock jumps to the finish instant first, so a player who refreshes mid-sweep keeps the hours instead of
working for free, and fatigue runs off that same clock. This is a fifth caller of machinery that already
had four; nothing new was built for it.

AND "AUTO ROLL SKILLS" WAS OFF WHILE THE BENCH ROLLED ANYWAY. All three crafting verbs called
Math.random() straight out and never read the setting, where itemIdentify and the ailment diagnosis have
honoured it since the day each shipped. The general form is worth more than the fix: a setting obeyed by
some features and not others is worse than one obeyed by none, because a player who has seen it respected
twice has no reason to suspect the third — and the question to ask of any new verb that rolls is not
whether it rolls correctly but whose die it is rolling. Each act now asks for the player's d20 and
resolves it locally rather than through the Game Master's skillRollRequest, because once the directive has
named the subject, the craft and the DC there is nothing left for the model to adjudicate.

A craft asks PER STAGE, not per sitting, chosen from three options. A sitting makes one check per stage,
and "the player rolls their skill checks" is a promise about checks rather than about turns: one die
applied to four stages is not four checks, and §9.1's partial credit — the whole case for the long gamble
being worth taking — exists precisely because the stages fail independently. So the sitting is walked
rather than resolved; each die settles one stage, plays that stage's hours and prints that stage's row,
then either asks again or closes the sitting. The banner follows the same unit, which is why it is one
card per sitting with the engine rolling and one per stage without: a stage the player stops at to roll is
a span of hours they have just paid for, and the moment between them is real.

Two things the building forced, both about keeping the modes from drifting. craftSittingBudget is
extracted so each path counts a sitting the same way, and N manual passes charge exactly what one auto
pass would — the setting is about who holds the dice, not what the work costs. And the manifest numbers
its rows from where the pass began, because one stage per call means one row per manifest and without it
every row of a seven-stage craft reads "stage 1".

Twenty-six assertions across the three test files, proved against five sabotages: each verb ignoring the
setting again, one die taken for the whole sitting, and the next stage never being asked for. One of them
had to be guarded first — a die taken for the whole sitting COMPLETES a two-stage craft, craftComplete
strips `project` off the item, and the assertion then threw on the missing field and killed the run with
no FAIL line at all, which reads exactly like a pass.

Rev. 30 and 31 record both findings and the three-way choice; §13 gains an eighth step group under I that
runs the whole thing twice, once with the setting each way, since a fault in one reading is invisible in
the other. Both guides carry it and both stamps are refreshed.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

BUG-089. Below ground the crawler owns the party's position and `room` is still the surface room they
descended from, several levels up. Five turn directives reached for "what is lying here" by reading
room.items directly — dropItem, pickupItem, revealItem, identifyItem and senseItem, with identifyFlora
alongside them. The DM console found this first and left a note beside its own fix, that an item placed
without the check sat several floors up waiting until they climbed out, but the note stayed local to the
console and the turn path never learnt it.

Losing the item is the mildest of the three shapes it takes. pickupItem is the one that did damage,
because it splices out of the list it searched: a player reaching for the ring at their feet could be
handed a different ring of the same name off a shelf upstairs, and that room quietly lost it — a
teleport and a theft in one directive, with the right name on the object so nothing on screen looked
wrong. The three lookups resolve by name over the same wrong list, so a blade identified in a dungeon
could have been the one lying in the hall above, and the player is told its true name either way. Every
one of them succeeds while doing it, which is why none of this ever surfaced as an error and why it was
found by reading rather than by playing.

One helper rather than five guards. itemsUnderfoot(room) answers with the party's square below ground
and the room's own list above it, so every lookup asks one question and gets the right floor; placing
goes through dropOnDungeonFloor, which answers false above ground and is therefore a drop-in. No
stacking on a dungeon square, matching roomUpdates.addItem and the console — a square is a plain list
of loose things, taken back by name. The two above-ground branches of the drop and the pickup still
read room.items directly, because by then they have chosen their floor, and the test counts them so a
sixth directive written against the room trips the tripwire.

Seven sabotages, each caught by its own assertions, including restoring the reported bug and a pickup
reading the room again — which fails on the assertion that the ring upstairs is still there rather than
on the one saying the right ring came up, since those are different claims. Two assertions passed for
the wrong reason on the first run and were fixed in the same pass: the dungeon floor is module state
that outlived a section, leaving a ring from an earlier one on the square, and an ordinary misc ring
carries no identity gate at all, so the identify negative was passing against an item nothing could
ever have identified. It has a positive control now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Run behind a proxy at /worlds with WORLDBROWSER_BASE_PATH unset, this service emits
src="/world-browser-auth.js". The browser resolves that against the site root, where this service is
not, collects somebody else's 404, and never runs the sign-in client — so the button falls back to the
href it carries for visitors without JavaScript, which is a link to the website. That is the entire
fault, and it has now cost two debugging sessions, because every visible symptom belongs to something
else: the page renders, the server log is clean, the tenant is correctly configured, and the button
"just links to the website" as though no code had been written at all.

The service cannot see the prefix, since the proxy strips it before the request arrives, so it gets two
detectors rather than one. X-Forwarded-Prefix, where the proxy sends it, is compared against the
configured base path on the first request and the mismatch is reported with the variable and value to
set — the log line is the remedy, pasteable. Most proxies do not send it, so the fallback is the
absence of a request: a browser that received the page asks for the script within milliseconds, so a
page served with the script never once fetched means the tag points somewhere this process does not
answer. That is the only universally available signal and it is a good one.

Both are asserted in both directions, because the half that matters for a diagnostic is the silence. A
warning that also fires when the prefix and the base path agree, or before any page has been served, is
one people learn to scroll past, and then it is not there on the day it is right. The sabotage run
covers the false-alarm direction for each.

The .env.example now leads with the variable instead of listing it among the rest, and the nginx
example carries a proxy_set_header for X-Forwarded-Prefix, which is what buys the immediate version of
the check rather than the eight-second one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

The Field Guide's Journal figure caption still said "five subtabs" and named four of them,
left over from before Languages and Gallery shipped — the prose paragraph right above it already
correctly said six. A screenshot caption that undercounts its own screen is exactly the kind of stale
line a player notices and a design doc never will, since nothing outside the page checks it against
the tab strip.

The Dungeon Master's Guide's World tab overview still introduced Geography by its pre-merge names,
"Regions, Districts", in the section heading, even though the paragraph directly under it already
explains the merge. And its ordinal count ("An eighth, Evaluate... A ninth, Culture") no longer matched
anything: the World tab has grown Calendar, Weather and Login subtabs since those ordinals were
written, so "eighth" and "ninth" now assert a total this section never claims to reach. Reworded to
name what is covered elsewhere without counting a total that isn't backed by the rest of the chapter.

The Player's Handbook's Crafting section (Ch. 9) covered the skill gate, the sitting-based build loop
and repair, but never caught up with the shipped condition ladder as it applies to a player's own
choices: that a dismantling yields one rung below the item's own condition, that a chest has to be
emptied first, that the first successful dismantling of an unknown item settles the answer for every
later one of its kind, that a failed craft returns its materials a rung worse rather than losing them,
that a crafted item can be no better than its worst material (barring a critical), and that a
self-made item can be renamed. The Field Guide and DM's Guide already had all of this from the crafting
and dismantling commits earlier today; only the Handbook, which speaks to the player rather than the
author, had fallen behind.

Both guides' Last Update stamps are bumped to match.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BA4om3emStEZLzYoEgVLTX

The owner's design, and the shape is the point. An errand may carry an authored "coin" promise and
nothing pays it: the Game Master decides whether, when and how much, and sends the amount alongside the
step the money is for. The engine applies exactly that and writes down what it applied.

The proposal this replaces had the engine paying the promise at completion, with a prompt line telling
the Game Master not to pay it as well — and the objection to it is worth keeping, because it is a
general one: that manufactures the collision it then guards against. Today there is one payer; an
engine that pays on a schedule of its own is a second, and every "the engine did X, now tell the Game
Master" line is a synchronisation point. Three such pairings already exist here — beat coin in 10a,
duty standing in 13c, task XP in 10e — each with its own hand-written "do NOT also set…" warning, and
not one of them has ever been measured. Adding a fourth before testing those three is the wrong order.

So the engine is a notebook here rather than a purse of its own, which is what the dossier already is
for everything else the Game Master cannot remember across a transcript trimmed 40 to 30. The fee lives
on the task as data so it survives a save and an hour of play; the dossier prints it as "Promises: N
copper" and says plainly whose job paying it is, instead of leaving it buried in a description that is
reprinted every turn with no idea whether it has been acted on.

The measuring had to come first and was missing entirely. A payment INTO the purse was applied and
returned before any logging — charges are logged on refusal and even queue a note back to the Game
Master, but money arriving left no trace except the purse total and the prose. So "was this errand paid
once or twice" could not be answered from the Logs even in principle, and no argument about model
behaviour could be settled. Every coin credit is logged now, with the task the Game Master attributed
it to where it named one.

One guard is kept and it is not a second payer: a step already paid is not paid again. A settled-debt
flag on a single payer, the same shape as `awarded` beside it, guarding the case a model genuinely
cannot see — the description goes on promising five copper for as long as the errand is listed, and the
turn that paid falls out of the history. It is logged under "Double payment refused" and queued back,
so a narration saying coin changed hands cannot stand over a purse that did not move. Deliberately not
tied to the tick: the loaf is handed over at the forge and the coin comes when the player walks back to
the inn, so a payment lands on a step finished turns earlier and only a second one for that step is
refused.

Two dossier statements were simply wrong and are fixed alongside, neither of them a guardrail. The
ALREADY IN HAND marker printed after the errand was finished, because the set it tested was built from
every task the player carries rather than the open ones — so the Game Master was told to ask after
something done. A finished errand now reads as the gratitude hook it should be, carrying what was paid
rather than what was promised. And the player's own dossier says what has been paid, as state.

The playtesting notes carry the claim this is all waiting on, with the log phrases to filter for and
the two shapes worth contriving — the two-turn payment, and a step re-opened after being paid.
Tests/test_task_coin.js pins the lot and was sabotage-checked eight ways, including an engine that pays
at completion, which is caught as the second payer it would be.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The concrete path added an hour ago was Encyclopedias/cyc3/weather-conditions/rain.html. That
directory was renamed to Ashgard the same day, and the assertion went on passing while naming a page
that no longer existed anywhere — resolveStaticPath denies on the first path segment and never reaches
the filesystem, so a stale path there is green, silent, and indistinguishable from a real one to
anybody reading the output.

That is the failure this whole test was written to prevent, arriving in the test itself. The point of
a concrete path beside the set-membership check is that a reader can go and look at it; a path nobody
can look at is worse than no path, because it reads as evidence. So the check now walks the directory
for an HTML page and asserts against whatever it finds, printing the path it used. A rename cannot
stale it, and a directory that is absent or empty skips rather than fails, the same allowance the
hasContent filter makes further down for a directory git cannot track.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The Encyclopedias directory arrived in c586dd8 with 309 files and turned the suite red on
test_static_denylist.js, which is that test working: the vault serves the repo root through a
DENYLIST, and a denylist defaults open, so a new top-level directory is served from the moment it
exists without anyone having decided that it should be. The test exists to make somebody decide.

The decision is to deny it, and the reason is a new one for this list. Every other denied entry is
material that simply is not the running game — the tests, the design docs, the owner's gitignored
models and print PDFs. Encyclopedias is different: it is published content, served by NGINX through
soft-linked directories configured on the web server, with the root directory not served even there.
No game server serves any of it and the app fetches no path under it. So the question was never
whether the content is public; it is whether the vault should become a SECOND route to something that
already has one, and answering yes would have meant a game server quietly re-publishing a web
server's material under a different origin and a different set of rules.

That also makes it the first entry that could legitimately have gone the other way. The five entries
beside it are gitignored, so they cannot be listed as served on purpose at all — the test checks that
list against what exists and a clone without them would fail. Encyclopedias is tracked and present in
every clone, so SERVED_ON_PURPOSE was genuinely available to it. Being able to serve something is not
the same as it being ours to serve, and both comments say so, because the next session reading a list
of gitignored directories will otherwise infer a rule that is not the rule.

The test gains a concrete path beside the one that pins Evaluations, for the same reason that one is
there: a set-membership assertion passes against a near-miss, and a real page under a real
subdirectory is what a reader checks by hand. Sabotaged twice — the entry removed, and the entry
misspelled as the singular, which is the failure nobody would see in review — and both are caught.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Every sign-in failure on this service so far has been in the tenant, and the tenant is the one place
this process cannot see. Worse, each failure wears somebody else's symptoms: a missing Allowed Callback
URL is a login that dies at the last step, a missing client grant is refused in a sentence naming
neither the client nor the setting, and a missing Allowed Web Origin breaks SILENT AUTH ALONE — so
signing in works, an already-signed-in visitor is never recognised, and it reads as the page forgetting
people rather than as a setting. So the service now says what it is configured with, proves the half it
can prove, and prints the half it cannot as strings to compare by eye.

At boot: the tenant, audience, client id and base path it will use, then a JWKS fetch. That probe is
the only part of the Auth0 setup checkable without a Management API token — a credential this service
has no other use for and should not hold to improve a log line — and a failure there is a typo in
AUTH0_DOMAIN, DNS, or blocked egress, each of which otherwise surfaces as every token being refused,
which sends somebody to read verification code that is working perfectly.

On the first page request, once the proxy headers reveal the public origin: the exact Allowed Callback
URL, Allowed Logout URL and Allowed Web Origin this deployment needs, computed the same way the browser
computes them. Once per process, because a configuration note printed per request becomes an access log
and stops being read. The forwarded headers are read for THIS AND NOTHING ELSE, and the comment says so
— they are client-controllable, so a value that decides anything must not come from them; the browser
still builds its redirect_uri from its own window.location, which is the only authority on where it is.

The browser half matters more and was entirely missing, because the server sees a page request and then
a token that never arrives. The client now logs the callback address it will ask for, the tenant and
audience it holds, and what silent auth actually answered — with login_required, the ordinary
signed-out case, logged as information rather than as a warning, since crying wolf on the commonest
path is how a diagnostic teaches people to ignore it. Any other silent-auth failure names Allowed Web
Origins, and a token this server refuses names the audience and the grant.

Nothing in the report claims a verdict. A green line reading "Auth0 configured correctly" over a tenant
nobody has looked at would be worse than no line, because it ends the investigation — so the tenant
section is headed with the sentence saying it has checked nothing, and test_diagnose.js asserts the
absence of a verdict as a property rather than trusting the wording to stay honest.

Two incidental repairs. The test suite silences the service's log, since anything printed between
assertions is somewhere a failure can hide. And test_service.js stopped hardcoding a world's name out
of sample-data.json — it broke the day that world was renamed upstream, which is a test failing over
content it was never about, and the surest way to teach somebody that a red suite is normal. It reads
its needles out of the fixture now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

`ent.tasks` is the roster a Dungeon Master authors in Editor › Beings — the little errands and favours a
person has in them to ask. It was written by applyNpcSpecToEntity, shown to the AUTHORING roster so a new
one would not duplicate an old, normalized on load by reEntityObj, and read by nothing that reaches a play
prompt. So an innkeeper with a written errand stood behind his bar holding it while the player asked him
for work all evening, and the whole authoring surface was decorative. It is the same defect §06 was built
to end for the player's own tasks, sitting one object along and undetected for a fortnight afterwards,
because both halves looked complete from where anybody was standing: the editor wrote the field and the
editor read it back.

Every living person in a room now brings their open errands into the turn's dossier, and the listing is
deliberately unlike the player's own in two ways that come from what each list is for. A finished errand
is dropped, because this is a menu of what is still available to ask and a finished one on a menu is an
invitation to ask twice; an errand already in the Journal stays, marked in hand, because "gone" and "in
hand" are different facts about a conversation — gone means nothing to offer, in hand means there is
something to ask after, which is the whole reason the player's tasks were put in front of the model. The
heading says plainly that the list is the Game Master's and never the player's, because a model handed a
list will tend to read it out, and a person reciting what they need doing is a board of notices.

taskOffered takes one, and it is dutyTaken's shape rather than taskTaken's: it NAMES and never describes.
The errand is authored and its price with it, so the description, the steps where the author wrote any,
and the XP are all copied off the record — a model that cannot invent the work cannot inflate it. The one
thing the Game Master may bring is this occasion's steps, and only where the author wrote none, because
the shape an author actually writes is a line of prose and somebody has to turn that into something that
can be ticked. A coin fee named in that prose is not copied and cannot be: a task pays XP, and the five
copper is the scene's to hand over with copperDelta.

A delivery has two people in it and an author may write it on both, so whichever the player reaches first
sets it going — visit the smith and he asks you to fetch the loaf, visit the inn and the innkeeper asks
you to carry it. What makes them one errand rather than two is the task id, which the copy keeps, so the
second person is refused by name and the dossier marks both ends in hand. Nothing new was invented for
that; matching on prose similarity was considered and rejected, because it would collapse two errands an
author meant as two whenever they happened to read alike.

Both doors share stageForTask for the props, which places the creatures AND the objects an errand is
about before the task exists, so a bad room or creatures that all fail to spawn refuse the whole field
and leave nothing behind. The items half only became possible yesterday: before roomUpdates.addItem the
engine had no way to put an object on a floor at all, so an errand about a thing could stage a creature
carrying it and nothing else. For a delivery the truer move is still the innkeeper handing over the loaf
in the scene, and rule 10g says so.

Tests/test_npc_errands.js pins all of it and was sabotage-checked eleven ways; the first attempt at the
face-to-face sabotage was a no-op comment that proved nothing, and the real one — widening the search
from the room to the world — is caught. Rule 10f now points at 10g before inventing, which is asserted
too: without it the inventing door simply out-competes the author's own content, and that is the failure
the playtesting notes are told to watch for, since a near-duplicate invented beside a written errand
reads perfectly well in the scene.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Building Rev. 28's salvage return meant deciding where a per-attempt condition is written, and the answer
— on the instance, never through applyItemSpec — was one dismantling had been getting wrong since the
ladder shipped. Its yields put their computed rung on the spec, and applyItemSpec is an editor for the
CATALOGUE ENTRY: so taking one ruined sword apart set Scrap Iron's own condition to ruined, in that world,
saved with it, and inherited by every copy minted afterwards.

Two things about why it lasted a fortnight through two rounds of tests are worth more than the fix. The
grant on the very next line copies the type it has just corrupted, so every item any dismantling put in a
player's hand was correct and the defect had no symptom anywhere a player or a test was looking — the only
reader that could see it was some OTHER one: a copy from a shop, a room, an addItem. And the first
assertion written for it passed against the restored defect, because it asserted that the NEXT dismantling
was unaffected, which it always had been: each one overwrote the type again on its way past. An assertion
aimed at the symptom you assume rather than the one the defect has is the shape this repo keeps paying for,
and the only thing that caught it was putting the defect back and watching the test not care. It asserts
on a fresh copy minted from the type now, which is where the damage actually showed.

Both rules about handing a thing over at a rung live once, in acquireAtCondition, which crafting's salvage
return needed last night and which dismantling should always have used: the condition goes on the instance,
and the pack entry it lands in takes the worse of the two rungs, because acquireItem merges by name and
keeps the entry it already had — so ruined scrap dropped into pristine scrap would otherwise let a player
launder the damage through stock they happened to hold. An authored yield condition is still honoured and
still does not reach the type: the Game Master was told something about a scrap, not about scrap iron.

Four assertions in Tests/test_condition_ladder.js §5b, proved against three sabotages: the drift restored
exactly as it was, the rung dropped from the instance as well, and the merge reconciliation removed. The
DM's Guide gains both rules where it explains the ladder — including the note that a Compendium condition
nobody wrote was this bug — and the Field Guide the part a player can act on, that a stack is only ever in
one state so salvage worth keeping should be kept apart from salvage that is not.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

One real conflict rather than the usual stamp: both sides edited the Field Guide's Journal paragraph.
The other session added two passages to it — that the milestone boxes are an indicator and not a
control, and that an errand agreed to in a scene arrives on the Tasks tab with a five-at-once cap —
while this side was removing Professions from the same sentence. Resolved by taking their paragraph
whole and reapplying the two Professions edits on top, so neither change is lost.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

It has been in the strip since the Journal's first day and has never held anything but a static "No
Professions Yet" panel. No data model, no renderer, no branch in switchJournalTab, no design doc — the
whole of it was one sentence in Designs/quests-and-journal.html §08 naming it as a slot for trades and
crafts and their progress. Every tab beside it arrived and shipped in that time: Factions, Tasks,
Legends, Languages and Gallery are all live views now, and Professions was still advertising a system
nobody had started.

Removing it is not a refusal of the idea, and the design doc keeps the idea rather than the tab. §08's
Decision A is rewritten as settled, because its two halves went opposite ways and that contrast is
worth more than either half alone: the same paragraph proposed Legends, which was built close to what
it described, and Professions, which never was. The entry now records what the slot was for and what
picking it back up would actually cost — which is not the markup. Three lines and a render branch is
the tab; the real cost is deciding what a profession IS against two systems that already occupy the
ground. Skills carry tiers, prerequisites, a governing stat and a class gate. Crafting carries recipes,
stages, condition and grade. A profession that is a bag of skills is a view over the Skills tab; one
that is a progression track is a second experience curve beside the one the character already has.
Neither is obviously wrong and neither was ever chosen, which is exactly why this stayed a slot for as
long as it did.

Nothing migrates, and the reason is worth stating so nobody goes looking for a guard. activeJournalTab
is a plain module-scope value that starts at quests on every load and is in no snapshot, and
switchJournalTab already falls through to quests for a name not on the roster — so a save written while
the tab existed cannot land on it.

The test pins the ABSENCE rather than dropping its assertions, because the markup for a dead tab is
three lines and comes back easily, and the failure it would cause is silent: a button in the strip with
no branch in the switcher renders nothing at all and leaves the previous subview on screen, which reads
as a tab that does not work rather than as a bug. So one assertion says the button and subview are gone
and another says the name is off the roster. A third is new and general: every name in JOURNAL_SUBTABS
must have a render branch, which is the property Professions violated for its whole life and which
nothing checked. Sabotaged three ways — the button restored, only the roster entry restored, and an
unrelated tab's branch deleted — and each is caught by distinct named assertions.

Both books and two design docs said the tab was coming. The Field Guide called it seven subtabs with
one waiting on a system still to come, and named it in Appendix D as a seam where the game was most
likely to grow next; the Player's Handbook carried the same parenthetical; the journal doc's subtab
table still listed it, and listed Legends as a placeholder although Legends shipped. Reagents &
Concoctions justified its generic recipe shape by pointing at "the Professions lane", which now points
at the removal instead — the reason for the shape outlives the tab, and is the only groundwork a trades
system would inherit if one is ever designed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Designs/crafting.html §9 ended with a callout asking whether there is a result so bad that the materials
are gone. It named two candidates — the stock comes back a rung worse, or you have nothing — said the
first was the better answer and needed §7's ladder to express, and closed with "§12 carries it". §12 never
did. There was no card for it among the forty-seven, so the one genuinely open question in the design was
the one tracked nowhere, while the doc's own footer reported that nothing was open. The finding underneath
is worth more than the mechanic and is recorded in §12: a question handed to another section is only
carried if somebody checks that section took it, and nothing here checks that.

Meanwhile the engine had answered it in passing. craftComplete on a null grade consumed the partial and
returned, under a comment stating the harsh answer as though it had been weighed — "the materials are
gone, that is what the gamble was". It had not been weighed; it was what the function happened to do
before the ladder existed, and it has been the shipped behaviour ever since.

It is the gentler answer now, which is what the design argued for when it first weighed the two: an
interim that is too gentle is recoverable, one that is too harsh teaches players not to use the mechanic.
The gamble survives intact. The week is spent, the fatigue was real, and stock a rung down bounds every
craft it goes into through §7's material bound — so a smith who botches twice is working ruined iron and
can make nothing better than ruined out of it. The retry loop closes itself rather than needing a rule,
and conditionStep clamps at ruined, so the bottom of the ladder is a floor rather than a hole.

Three things the building forced, none of them in the brief. The materials are rebuilt from their
catalogue TYPE, because the instances were spent turns ago and a namesake minted from a bare string is the
counterfeit with invented stats that the addItem rule warns the Game Master off; what is not catalogued
has no type to rebuild from, so craftBegin now samples a little more than the condition when it spends an
input and that is what comes back. The condition goes on the instance and never through applyItemSpec,
which writes the catalogue entry — a per-attempt rung sent through it would follow every copy of that
material minted afterwards, in every save of that world. And a stack holds the worst rung in it, because
acquireItem merges by name and keeps the entry it already had, discarding everything on the incoming item:
a worn ingot returned into two good ones would vanish into them and the damage would be cancelled by the
player having had spares. One entry cannot hold two conditions, so it holds the worse one, which is §7's
own rule for a thing made of several things applied to a pile of one thing.

The player's line said the materials were gone and now names what came back and in what state. Between a
sentence and an inventory, the sentence is what gets believed.

Eleven assertions in Tests/test_crafting_assembly.js §11, proved against eight sabotages: nothing
returned, returned at the same rung, the merge swallowing the damage, the quantity forgotten, the rebuild
falling back to the sample, an uncatalogued material dropped, the condition sent through applyItemSpec,
and salvage on a successful craft. Two of them needed sharpening first — the type rebuild was originally
asserted on value and icon, which craftBegin samples and which therefore come back either way, so it is
asserted on the ref, the description and the kinds the sample never holds.

Rev. 28 closes the callout, adds §12's forty-eighth decision, gives §13 an eighth step group under I (how
to stage a botch at all, since a fair DC almost never produces one) and two notes on what only a table can
settle. Both guides carry it, and both stamps are refreshed.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Regenerated with Tools/gen-progress-report.js against the full, unshallowed
history on main: 4,371 commits across 89 active days. Only September's month
page and the index changed, since earlier months are already complete.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAKcKiGsciJBREDKytMUM7

Reported from an ordinary reload: the dialog came up as Claude22, then shuffled over to Malina, every
single time. Both halves are the code working as written. populateLoginScreen fills the name field
synchronously from SAVED_NAME_KEY, a localStorage hint written only when a new game is started with a
typed name - so it holds the last character CREATED, not the one whose save is active.
refreshResumableCache then reads the real snapshot out of IndexedDB and overwrites it. Its own comment
already said the hint "can be stale or absent". It was: Claude22 was created by typing that name,
Malina holds the active slot.

The swap itself cannot be removed. The truth lives in IndexedDB, IndexedDB is async, so something must
happen after the first paint. What can be removed is showing the player a name the app is about to
retract, so the fields that describe the SAVE - character, class, location - are veiled for that window
and revealed once, already correct. The API key row, the model picker and the admin buttons are
deliberately outside the veil: they belong to the browser rather than to the save, and grefying them
would claim they are loading when they are not. The veil is opacity and pointer-events only, never
display or visibility, because a mask that collapses the fields makes the dialog jump when it lifts -
a worse artefact than the swap it hides.

A second cache of the active save's name was considered and rejected. Writing the name beside the
snapshot on every save would make the fast path usually right and would be wrong in exactly the case
that matters, two windows on one origin, where this codebase has already been bitten twice by
duplicated state. One source of truth, briefly veiled, beats two that agree most of the time.

The veil gets its OWN counter rather than riding the entry-button latch, and that separation is the
part worth keeping. The first version drove it from loginContextBusy() and wrapped boot in
withLoginContextLoad to match. That raised the latch during module evaluation, and since boot's resolve
is precisely the one that can hang - a wedged IndexedDB was observed on this origin the same day, every
await against the store refusing to settle until the tab was closed - Begin would have been disabled
for ever. A cosmetic flicker traded for a login screen nobody can get past. Four login tests said so
within minutes. A veil stuck down is ugly and the fields are still legible through it; a latch stuck up
is a door that never opens, so the two now fail independently. Boot's resolve also races a six-second
ceiling: a hung store costs a stale name, never the door.

Three sibling tests needed repairing and all three pinned literals rather than properties - two on the
exact text "await refreshResumableCache();", one on an ordering index into the same string. Wrapping
the call broke them on code that still awaits the refresh exactly as asserted. One of my own assertions
had the same fault and failed on a true statement, slicing 1600 characters from a comment longer than
that; it is bounded structurally now. The wrap in preloadSaveIntoLogin was reverted as redundant, since
both its callers already wrap it.

Seven sabotages against the veil, each caught. Server/set-env.ps1 needed an SPDX header, which is a
local ignored file rather than anything in the repo.

App suite 940/942, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Two edits to the same complaint. The name-collision warning ran to three sentences naming the
character, the world, the replacement and the two ways out; it now reads "Name already in use.
Delete existing save to use this name and world again." And #newgame-note, a paragraph under the
checkboxes carrying four alternative sentences plus a fifth for a missing API key, is gone.

The paragraph was redundant by the time it was removed, though it had not been when it was written.
Each of its sentences had acquired a second home as the controls around it learned to explain
themselves: the two locked states are on the checkbox's own title, written where a player who cannot
move it is already looking; continue-against-begin is the button's own text; that a fresh game
discards the save is the collision notice under the name, which fires in exactly that state and says
it harder; and a missing key turns the button into Configure API Keys with the reason in its title.
A login screen stating the same fact twice is how a screen stops being read, so the surviving channel
is the one attached to the control the fact is about.

One of its writers was not redundant, and moved rather than went. startGame refuses a Continue when
another window has replaced the save slot between the screen's repaint and the click, and that
refusal repaints and returns — so with nothing said, the player presses Continue, watches the fields
change and has no way to tell the press was heard. It now writes through setLoginNotice into the
collision box, which is the same subject in the same place. Consulted by syncNameCollisionNotice
rather than assigned into the box, and consulted ahead of the early return for "no collision":
a refused Continue is usually a state where the typed name collides with nothing, and the repaint
that follows the refusal would erase a message written straight to textContent. Cleared at the top of
startGame, so the second press it asks for is what clears it.

The shorter warning names the remedy where the long one named the consequence, which is a real
change and not only a trim: a player who ticks New Game anyway still loses the save, because this
notice alerts and never refuses. Recorded in the comment beside it so the long form is not restored
as a regression. The assertions that pinned the old wording were retargeted rather than deleted,
since the claims they protect — the screen says the name is taken, and says what to do — are
unchanged. Tests/test_login_notice_channel.js is new and covers the moved message, including the two
orderings that would make it silent again with more code than before.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Two defects with the same shape: a promise in the prompt that nothing in the engine kept, and a rule the
tooling written to police the rulebook could not see.

Rule 10a has told the Game Master since it was written to place a beat's reward in the room "via
roomUpdates.addItem" when it is found in a chest or on a body. Nothing read that field. It was not even
in the response skeleton, so a model following the instruction it was given produced a reward that went
nowhere and no log line anywhere said a directive had been dropped, because none had been — there was
nothing to drop it with. A documented field with no implementation fails more quietly than an
undocumented one, since the prompt is itself the evidence that it should work. It is built now as the
third corner of a triangle whose other two corners already existed: stateChanges.addItem puts a thing in
the pack, dropItem moves one out of the pack onto the floor, and this mints one onto the floor directly.
It takes the same item vocabulary as its siblings and goes through makeItem unwrapped, so a bare string
and a stray "ref" resolve to the catalogue entry rather than minting a look-alike — which is the defect
10a's own third paragraph is about. Stacking follows dropItem's rule exactly, containers never merging
because each keeps its own contents. Below ground it lands on the party's square: the DM console learnt
that one the hard way and left a note, and `room` is still the surface room several floors up.

The duplicate rule is the sharper find. Task promotion was numbered 10d the day it shipped, written in
place between 10c and 11, and INDENTED FOUR SPACES. Every scan run during the numbering pass six days
later was anchored to column zero — including the label collector in test_rulebook_numbering.js, the file
that pass added to catch exactly this — so the paragraph was invisible to the tooling, the pass concluded
the rule did not exist, and it wrote a second 10d directly beneath the first. The two shipped side by side
for ten days: seven hundred words of near-duplicate instruction in the cached prefix, each telling the
model something the other left out, with nothing anywhere able to see it.

They are merged rather than one deleted, because each carried instruction the other did not. The older
had "give it a trigger anyway", the three-or-four-beats figure, and the note that the task's own XP still
pays and copperDelta is still there for a purse the scene invents; the newer had "the task is not
replaced", the refusal for a promotion with no beats, and the argument that the rarity IS the feature.
Nothing instructional was dropped except the inline JSON shape, which the field spec already carries
verbatim.

Both holes in the tooling are closed with the defect they missed. The label collector tolerates leading
whitespace and reports an indented rule as a smell of its own, since a checker anchored to a column is
checking the formatting. And test_task_promotion's three assertions about 10d grepped the whole file for
three literal sentences, so they passed contentedly while two rules answered to the name and would have
failed on any rewording that kept the meaning: they read the single 10d out of the built prompt now,
insist there is exactly one of it, and ask what it tells the model rather than how it happens to say it.
Re-introducing the indented duplicate is caught by four named assertions across the two files.

Designs/gm-rulebook.html records that pass and states as a finding that rule 10d did not exist. That was
wrong, so the section keeps its text — what the pass believed is the point — and carries the correction
above it. The Field Guide's roomUpdates table gained the new field and moveEntity, which it had never
listed either.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The masthead read "Sign out (google-oauth2|114066051812484949349)". An access token carries a subject
and scopes and, unless an Auth0 Action puts one there, no email at all — Designs/website-login.html §09
says exactly that and says discovering it late costs an afternoon. It was discovered late and on
screen, because displayName's last resort was claims.sub, so the one thing an access token always has
became the thing that always rendered. A subject is an identifier; returning it from a function called
displayName is how it ends up drawn as a name.

The server answers honestly now and the browser decides. Namespaced claims are still read first and
still win, because an Action CAN put them on the access token and that source is signed and was
verified here. With no Action configured the server reports no name beside a sub that is still exact,
and the client falls back to the profile the SDK already holds from the ID token — which is the same
place Web/LandingPage/auth.js gets the email it shows, so the two pages now agree rather than merely
looking similar. The subject remains the last resort, which is what it always should have been.

The fallback is cosmetic and the split matters: authorization is the sub on the session the server
verified, and a profile the page assembled decides nothing and is sent nowhere. getUser is called only
when the server had no name, so the ordinary configured case costs nothing.

Three sabotages. The first — the server calling a sub a name again — was not caught by the client
tests at all, because they stub the session the server returns, so the function that actually shipped
the bug was never exercised by them. That assertion now lives beside the route that serves it, which is
where the evidence has to be for it to be evidence of anything.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

The auto-learn went into both guides with the change itself; this is the clause that was missing from the
DM-facing half. A parts list carries names and counts and no condition, which is the one field a DM reading
the read-only card would reasonably expect to be there — and its absence is what keeps the ladder honest.
The state parts come out in is decided per attempt, one rung below the thing taken apart, so a pristine
sword and a ruined one give the same parts in different states off the same list. Stored on the list it
would outrank that for ever: a first dismantling that happened to yield pristine scrap would have every
later ruined sword giving pristine iron. A per-turn yield may still name a condition and is honoured; it
just does not join the record.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Auth0 matches redirect_uri against Allowed Callback URLs exactly, so anything variable in that value is
another entry somebody has to add by hand, and the one nobody thought of is a login that dies at the
last step with "The provided redirect_uri is not in the list of allowed callback URLs". This service
was minting a variable one.

The value has now been wrong twice, in opposite directions, and both are worth recording because the
second was introduced while fixing the first. It began as window.location.origin, copied from
Web/LandingPage/auth.js where it is correct because that page IS the origin; mounted at /worlds/ that
returns somebody who has just signed in to the landing page instead, which reads as the button throwing
them out of the application. Changing it to origin + pathname fixed that and made it variable, because
this service answers the page on three routes — /, /index.html and /worlds — so the callback differs
by how the visitor happened to arrive, and only the spelling that was allowlisted works.

The base path is what this process actually knows about where it lives, so the address is built from
that: origin + basePath + '/'. One string per deployment, and the test proves the property rather than
the string by arriving three ways and asserting all three ask for the same callback. Sign out returns
to the same place for the same reason.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Mounted at /worlds/ behind a reverse proxy, sign-in did not work at all: the button went to the website
and a visitor already signed in on the site was never recognised. Two symptoms, one cause, and the
cause is that this service emits absolute URLs while only ever having been run at a host root.

A proxy with a prefix strip hands the process /api/session, not /worlds/api/session, so every route
matched and the page rendered perfectly. What did not survive is the URLs the page CARRIES, because
those are resolved by the browser against the public address. The injected script tag read
src="/world-browser-auth.js", which at https://thelostrealms.ai/worlds/ is a request to the landing
page's root for a file that is not there. The client never ran. With no client there is no silent auth,
so an existing login is never picked up, and the sign-in anchor keeps the href it carries as its
no-JavaScript fallback — so clicking it goes to the website. Both reported symptoms, from one 404 that
nothing reports: the page is a 200 and looks right.

So there is a base path now, and the thing worth keeping in mind about it is that the ROUTING does not
use it. The proxy already stripped the prefix; routing on it would 404 everything. It is used only
where a URL leaves this process — the asset root, the injected script's src, and the address the client
fetches /api/session at — and all three are derived from one value in createConfig. An earlier version
of this change read the module-level default for the asset root while taking the override for the
script tag, so a caller that passed a base path got a page whose images and whose sign-in script
disagreed about where the service lives. Half correct is the hardest kind to notice.

The second defect was found by reading the client back rather than by a report. redirect_uri was
window.location.origin, copied from Web/LandingPage/auth.js where it is right because that page IS the
origin. Here it means somebody who signs in at /worlds/ is returned to the landing page, which reads as
the button throwing them out of the application. It is the page's own origin+pathname now, which is
also a single stable string for Allowed Callback URLs — the world browser is one page — and carries no
?filter into the callback. Sign out returns to the same place for the same reason.

Four sabotages, each caught by a distinct assertion: the asset root ignoring the base path, the script
tag ignoring it, the client fetching /api/session without it, and the service routing on a prefix the
proxy has already removed. The third of those needed the test rewritten: it first asserted that the
base path appeared in the client's configuration blob, and passed against a client that carried the
value and then ignored it — the same defect as matching a word in a comment, one level further in. It
watches the fetch now. Verified end to end through a prefix-stripping proxy standing in for the nginx
clause, where the old build's script URL 404s at the site root and the new one resolves under /worlds/.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

The control was an anchor to the website. It was also the only thing there: browser-session.js was
served but nothing loaded it, and what it did load wanted a window.getWorldBrowserToken that no page
ever defined, so the whole identity path was inert end to end. This replaces it with a client that
begins a real login in the same tenant and the SAME SPA application the landing page uses, and that
recognises a visitor who is already signed in without prompting them again.

Recognition is getTokenSilently — a hidden iframe to the tenant, answered by the tenant's own cookie.
That is the whole of honouring an existing login, and it is also the part with a deployment condition
worth stating rather than leaving to be discovered: the cookie is same-site only while the tenant and
this service share a registrable domain, so *.thelostrealms.ai works and localhost does not. There is
no code that fixes that, which is why Designs/website-login.html §07 calls the custom domain
load-bearing rather than cosmetic, and why the README and .env.example both say to expect a manual sign
in during local development. Three tenant lists have to name the origin, and the failure modes are not
alike: Allowed Callback URLs and Allowed Logout URLs announce themselves, while Allowed Web Origins
breaks silent auth ALONE — signing in still works and an already-signed-in visitor is simply not
recognised, which reads as "it keeps forgetting me" rather than as configuration.

The script is injected into the rendered HTML rather than written into the template, because the
template is design-tool output and an export drops a <script> without a trace: the page still renders,
and the button is a plain link again. That is the same failure Web/LandingPage/auth.js exists to avoid,
and it is the exact state this commit found. The masthead has no signed-in branch at all — the template
only hides the Sign in link — so the client writes one, or signing in makes the control silently vanish.

Two things came out of building it rather than out of reading it. The client's audience is now read off
the verifier instead of the environment a second time: the page asks the tenant for a token for audience
A, the tenant mints one happily, the server accepts only audience B, and every request is refused with
both halves individually correct and neither end naming the other. A browser run showed the page asking
for `undefined` while the server wanted a real string, which is that bug in miniature. And the client
shows the name THIS SERVICE agrees to, from /api/session, rather than the SDK's own answer — they match
when the tenant is configured, and when they do not, the one that will authorize anything is the one
worth putting in the masthead.

The test file is worth reading for how it failed first. It asserted /getTokenSilently/ against the
script text, and passed against a sabotaged client that never calls it, because the word survives in the
comment above the call explaining what it is for — the assertion-matched-the-paragraph defect this
repository has already written down twice. It now runs the generated script against a stubbed SDK and a
hand-rolled DOM and asserts which methods it reached for. Restructuring for that introduced a worse
defect and caught it: a `return` inside a .then() at module scope exits the MODULE, so three sections
and the summary never ran and the file exited 0 whatever happened. Everything is inside one async main
now, and the file was checked to fail on a deliberately false assertion before being trusted.

Nine sabotages, each caught by a distinct named assertion: dropped injection, drifted audience, no
silent auth, trusting the SDK over the server, dropped audience parameter, no masthead swap, local-only
sign out, localstorage cache, and reordered script tags. The end-to-end flow was also driven in a real
Chromium against a stubbed SDK in both states, since Playwright is not a dependency this repository is
going to take; the test pins the properties that run proved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Web/WorldBrowser/server/world-browser.js serves worlds.mustache.html over HTTP, with no dependencies,
and identifies the visitor from the Auth0 login the landing page already performs. Three files, because
the two decidable halves are worth reading apart from the socket: mustache.js renders, auth0-bearer.js
decides whether to believe a token, and world-browser.js is what happens to a request.

THE DATA IS A FILE AND THE SEAM IS THE POINT. loadWorlds() reads sample-data.json and is the only thing
that touches it; every route goes through cfg.loadData(), so replacing that body with a query is the
whole migration rather than the start of one. test_service.js injects a fake loader and asserts a page
renders from it, which is what stops the seam rotting in the months before the query exists. The file
is re-read per request deliberately — the point of sample data is that somebody edits it and reloads,
and whether to cache is a real question for a database that gets answered then, on its own evidence.

Two values in that file are overridden rather than trusted, and both for the same reason: the same
fixture is what server-template/preview.html renders statically, so it is written to look signed in.
`signedIn: true` spread into a live response gives every anonymous visitor a signed-in masthead on a
page that looks entirely normal. The per-card `liked` and `favorited` flags are the half that is easy
to forget — they are facts about a person, a request with no person cannot carry them, and the buttons
render disabled in that state, so a leaked heart is a claim the visitor cannot even undo. The shipped
fixture sets three of each, and the anonymous page was rendering all of them before this. The image
paths are rebased the same way: "../images/…" is correct from server-template/ and wrong from the
served root, and a page of broken portraits still answers 200.

IDENTITY IS A RESOURCE SERVER AND MUST NOT BECOME ANYTHING ELSE. Designs/website-login.html §09 states
the rule — no login begun, no authorization code, no client secret, no callback URL — and §11 is the
argument against the cookie session this template's csrfToken might suggest: that means a confidential
client, a secret to rotate and an authentication flow we wrote, all to put a name in a masthead. So the
service verifies a bearer access token and does nothing else. The consequence is written down in the
file rather than left to be discovered: a top-level navigation cannot carry an Authorization header, so
the first paint is signed out, and the page asks again with a token. browser-session.js is served by
the process instead of being written into the template, because worlds.mustache.html is design-tool
output and anything added to it dies silently at the next export — the same reason auth.js exists.

The ID token is refused by name. It is genuine, unexpired, from the right tenant and sitting in the
same browser as the right token, and its audience is the SPA's client id, so the audience check catches
it; the refusal then says which of the two to send, because "invalid audience" sends somebody to
re-read tenant configuration that is perfectly correct. §10 of that doc recommends NOT hand-writing
token verification — "the part where a subtle mistake is an authentication bypass" — and this does,
because the service has no dependencies and no API gateway in front of it. That trade is only
defensible with an adversarial test, so test_bearer.js mints alg:"none", mints HS256 signed with the
public key the tenant publishes, swaps a payload under its own signature, and checks that a bad
signature cannot drive unlimited JWKS refetches at the tenant.

One finding about this repository's own habits, recorded because it took three attempts. The comment on
safeFile claimed the resolved-path-against-root check was what stopped traversal. It is not:
path.posix.resolve('/', rel) cannot climb above "/", including for a bare relative path, so every
traversal that can arrive is stopped there and the root comparison is unreachable for any string input.
That was established by deleting the named check and watching every assertion still pass — twice, since
the second version of the comment was wrong in a new way. The check stays, as the thing that fails
closed if somebody edits the clamp, and the test now says out loud that it does not exercise it rather
than carrying a reassuring name over an assertion that measures nothing.

Tools/spdx-headers.js sweeps the server directory rather than Web/WorldBrowser, on the argument already
written there for Web/LoginApi and one level further: the parent holds design-tool output, and stamping
a licence header onto a file whose first line says "GENERATED … do not edit" is both a false claim and
one that reverts at the next export. CI runs the suite by name, since Tests/run.js walks only Tests/
and a suite nothing invokes is one that rots without ever going red.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Decision I in Designs/tasks.html said the tick belongs to the Game Master and the player is not meant to
click it at all. Nothing in the engine agreed: toggleTaskMilestone was a click handler, a player's mouse
was the only thing in the game that could advance a task, and the turn-result schema's sixty-odd fields
had dutyTaken and taskPromoted and nothing that finishes a step. Decision G was the other half — an
errand agreed to in conversation had no path from ent.tasks to player.tasks at all, so it was played
entirely in fiction and reached the Journal only if somebody imported a file. Both are built here,
together, in the order section 09a sets out, because they are the same change: a Game Master that can
tick a box but cannot create the checklist only ever reaches faction duties and imported files, and
taking the box away before the Game Master has a verb freezes every task at Accepted with nothing left
to unstick it.

The cascade came out of the click handler first. Stamping dateFinished, awarding the XP and paying an
order's standing all lived inside it, which was fine for exactly as long as a mouse was the only caller;
a second caller either routes through the handler or duplicates three things, and the one that gets
missed is a duty that pays its XP and silently never pays its regard. setTaskMilestoneDone is that
applier, and it SETS rather than toggles — a flip is the right verb for somebody who can see the box and
the wrong one for a machine, which re-reports what it believes to be true and would otherwise un-do a
step by mentioning it twice. A step is named by its TEXT, which is what the dossier already prints
behind [done] and [open]; minting ids would have meant inventing one for every task in every existing
save, and a looser matcher is the wrong fix for the reason the import merge matches by text rather than
position. Duplicated steps resolve by what is left to do, so a re-report is a no-op while the second of a
matching pair advances.

The errand field may invent where dutyTaken may only name, and the guardrail is what it may PAY rather
than whether it may exist. It pays XP and the scene's own coin; every duty field is stripped, because
standing is what rank ladders are priced against and a conversation cannot be allowed to mint it, and
incoming done/awarded flags are cleared so a step cannot arrive pre-ticked and pay itself. The world half
rides the same call and is placed before the task exists, so a room the world does not have, or creatures
that all fail to spawn, refuses the whole field and leaves nothing behind — the errand and the thing it
is about cannot arrive apart, which is the one failure nothing downstream can narrate around. Five open
errands rather than the duties' three, counted separately, because a duty comes from one order while an
errand can come from anybody.

The checkbox became an SVG indicator last, with the state as a visually-hidden sentence beside the step
rather than an aria label on a control nobody can reach. The input is gone from the file entirely: an
onchange left behind would make it clickable again however the function were renamed.

Tests/test_task_progress.js pins all of it and was sabotage-checked ten ways; two of those passes found
holes in the test rather than the code — a paraphrase assertion loose enough to survive a word-overlap
matcher, and a strip whose sibling guard meant removing it alone changed nothing, which the test now says
out loud. Section 5 exists because every assertion above it drove the engine functions directly and would
have passed with the turn field never wired up, which is exactly the hole the import merge's tests had.

The two guides carried claims that are now false — the Dungeon Master's Guide said in as many words that
no engine path copies an offered task onto the player's sheet — and both are corrected with their stamps
moved. The playtesting steps were rewritten rather than left telling a reader to tick a box that no longer
exists, and the notes gained the four readings only play can settle, the sharpest being whether the Game
Master copies a step's wording or paraphrases it: a paraphrase is refused by name, so a habit of rewriting
produces a game where nothing ticks and the narration insists it has.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Rev. 26 gave an item a dismantlesInto list and told the Game Master it may settle an unanswered one by
setting that field through addItem in the same turn it supplied the yields. That is the same fact authored
twice by the same actor in one breath, which is not redundancy but a coin flip: the model that remembers
does it, the model being brief does not, and the world ends up holding the answer for some swords and not
others with nothing anywhere to say why. So the engine writes it, from the yields it already has, on the
pass it already knows about. The directive now tells the model the opposite of what it did — the answer you
give becomes the world's, so weigh it as you would an authored one — and no longer asks it for the record
alongside the yields.

Three conditions gate the write and each is a decision. On a pass only, because a failed attempt taught
nobody anything and the guess at what was inside was never put to the test. On the catalogue TYPE rather
than the instance, because the instance has just been consumed and what a sword is made of is a fact about
swords. And nowhere at all if the item or its type already answers, which is one condition rather than a
gate plus an emptiness check — there was an emptiness check, and removing it broke nothing, because by the
time it was reached it could not be false. A guard no sabotage can break is not a guard; it is a comfort to
the next reader bought at the price of their trust when they find out. A thing with no catalogue entry — a
minor prop, a crafted one-off — comes apart exactly as before and simply has nowhere for the lesson to live.

A declared parts list deliberately carries no condition, and that is the one field a reader would expect to
survive. The list says what a thing is made OF; what state the parts come out in belongs to the attempt,
since the yields are a rung below the subject and that is what stops dismantle-and-rebuild being free money.
A condition stored on the record would outrank that for ever: a first dismantling whose yields happened to
say pristine would make every later ruined sword give pristine iron. A per-turn yields entry may still name
one and is honoured; a record may not.

The write is logged and said to the player in a line of its own, because a world-data write nobody asked for
otherwise has no symptom at all until the next one of these comes apart the same way, and every other exit
in applyDismantle prints something for exactly that reason. A DM who disagrees with what the first
dismantling decided can have the Game Master revise it, through applyItemSpec's edit-in-place path — the
same one that wrote it.

Writing the tests turned up that ITEM_CATALOG is WORLD_DATA.items itself and not a copy of it, so a lesson
taught in one test section was still there in the next, surviving every buildWorld() in between. Two
assertions in test_dismantle.js and one in test_condition_ladder.js, all written before any of this existed,
were being graded against an answer an earlier section had taught and were passing on it. Both files now
unteach the catalogue in fresh(), which is safe because the built-in world declares no parts lists of its
own: there is nothing to scrub but what a test put there.

Designs/crafting.html Rev. 27 records it in §1 and §11, adds a seven-step group under §13's D and two notes
in the shape that section wants — whether a model's first answer is good enough to be the world's permanent
one, which no desk can settle and four items in one session can. Its footer's status line was stale by four
phases and now says what shipped. The DM's Guide gains the correction path and the Field Guide the player's
half; both stamps refreshed.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Section 03a settled that an emergent errand is authored in the turn it is agreed to. This records the
escape hatch beside it: the Game Master tells the player to come back tomorrow, mints the world the
errand needs while they are away, and has the story ready when they walk back in. The owner's framing
is that this is the extreme case and an option rather than a requirement, since a simple errand should
mint inside the ordinary thinking time of a conversational turn — so the section is on record for
whoever needs it rather than as something 03a depends on.

Two things came out of reading the code rather than the design, and both change what the pattern is.
A narrated tomorrow buys no real time at all: timeSkipHours, timeSkipUntil and an eight-hour sleep or
camp all resolve inside one synchronous turn, so the innkeeper's tomorrow can be twenty seconds away
in wall-clock terms and a curtain with nothing running behind it has only moved the pause somewhere
worse. What the fiction actually buys is permission to be late. And the out-of-band call the pattern
needs is already built — requestAmbientBehavior runs off conversationHistory specifically so it can
sit alongside a player turn without racing it, and the only difference between it and an authoring
call is the sentence in its own directive telling the model to change nothing, plus two guards (drop
the result if the player left the room, fail silently) that invert along with the contract.

What is missing is the promise, not the call. Nothing remembers that an NPC said tomorrow: there is
no scheduled-event map and no pending-task state, so a curtain needs new persisted state and with it
either the three-place rule or a line in reEntityObj. The section says plainly why this stays an
option — a slow turn is slow and then it is done, while a broken promise is a defect the player can
walk back to, and every way the background authoring can fail lands on a scene the fiction has
already committed to. Hence the build order it suggests: mint the errand's record in the turn the
promise is made, even as a stub, and let the curtain cover only the world half.

Decision L settles it as an option held in reserve, and the playtesting notes gain the two readings
that only apply if it is built — whether the delay carries a reason and a when the way section 05's
declines must, and whether the promise survives a late return, a different NPC in the room, and a
session resumed from a save written before it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Three changes asked for on Web/WorldBrowser, and one of them turned out to have a reason behind it
worth writing down. The footer already carried the landing page's shape — logo, Progress Report link,
tagline, copyright — and was missing only the three terms links, so it gains Privacy, Terms of Service
and Licence beside the copyright line, exactly where the landing page puts them and where a reader
looks. Back to the Realm now points at https://thelostrealms.ai, and the Progress button is gone from
the masthead.

THE LINKS ARE ABSOLUTE, AND THAT IS NOT A STYLE CHOICE. The legal pages sit beside index.html in
Web/LandingPage and are served from the site root; this app is served from its own directory, so the
relative "privacy.html" that would have matched the landing page resolves inside the world browser,
where no such page exists. Back to the Realm had the same defect already and it is the reason the
change was wanted: it shipped as href="index.html", which is the page the button is on, so it rendered
correctly and went nowhere. The footer's existing Progress Report link was relative for the same
reason and is absolute now too — a footer brought over specifically so its links work is not worth
delivering with a dead one left in it.

THE PAGE HAS THREE COPIES AND ONLY ONE OF THEM WAS NAMED. index.html is the dc-runtime template, and
server-template/worlds.mustache.html is what a server actually renders, with preview.html its static
twin; all three carry the same masthead and the same footer. A change made only to index.html would
have looked right in the repository and reached nobody in production, which is the hand-copied-roster
failure this codebase already pays for elsewhere, so all three carry all three changes.

Tests/test_site_terms.js grows a section over them, because the hazard here is the one it already
exists to catch: these are hand-added links in generated markup, and an export from the design tool
drops them without a trace — the landing page lost them that way twice. It asserts the absolute form
specifically, so a later tidy-up to match the landing page's relative hrefs fails rather than quietly
producing dead links; it asserts the Progress button's absence, since an export restores what the tool
owns; and it walks all three copies, because the point of a roster in three places is that two of them
go stale without a word. Each of those five breaks was tried and is caught by exactly one assertion.

One thing the new block does that the older one beside it does not: it finds the footer in the markup
rather than in the file. The landing page block slices from the last "Brave You Worlds" and gets away
with it; here that lands in the dc-script at the bottom, whose stub catalogue lists Brave You Worlds
as a world's author, so the slice was the script tail and all six link assertions failed over a footer
that was entirely correct. Scripts come off first and the copyright symbol anchors it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Until now a dismantling's parts were invented per attempt, so the same sword gave iron and leather on
one turn and steel scrap and a grip wrap on another, and neither answer was wrong. An item may now
declare `dismantlesInto`, and where it does that is what the dismantling yields -- the directive's own
`yields` are ignored entirely, because the world has already answered and two answers to one question
are worse than either.

It is the Game Master's to write, at creation or onto an existing item afterwards, and the DM editor
shows it read-only in both places a DM looks: the row on the item card and the row in the item dialog.
That is a decision and not a missing control, and the code says so where somebody will meet it. The
list has to stay plausibly the object, which is a judgement about that object's own description, and a
free-text grid is an invitation to put a ruby in a sword -- the rule the model is held to has nothing
to hold a typist to. The dialog renders it as a read-only line rather than a disabled input, so it does
not read as a field that has been switched off.

An omitted list is an answer rather than a gap: it means the parts are worked out at the time, and for
a thing that genuinely does not come apart the directive already says to yield nothing. So an EMPTY
list is refused and reported through the spec applier's warnings rather than stored, because an empty
answer and an absent one would otherwise read identically while meaning opposite things.

Every part handed back is marked with a `crafting material` subtype, whether it came from an authored
list or was worked out on the spot -- the label records where the thing came from, not how it was
decided. Added to whatever the part already declares rather than replacing it, because subtypes are
additive and a scrap of iron that lost its own kind to gain this one would be worse off.

And the pack dossier tells the Game Master when an item already answers this, in the same brackets as
its description, with an explicit instruction to omit `yields` for it. Without that the model goes on
writing a list the engine throws away, which is a disagreement neither end can see.

Eight sabotages, each caught. One of them was my own mistake rather than the code's: replacing the
guarded assignment left a dangling `else`, so the file stopped parsing and the test reported no
failures at all -- which looks exactly like a passing sabotage and is worth knowing about when a check
comes back suspiciously clean.

Also moved: the new field's spec text first landed immediately after the phrase
test_being_inventory_ref.js slices from, pushing that test's target out of its 900-character window. The
text is now at the end of the addItem rule instead, which leaves the neighbour's anchor adjacency
intact -- the same fragility that bit the foreign-languages test earlier, met from the other side.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Decision G is settled, and settled further than the leaning recorded under it. The entry proposed a
taskTaken field with the governance duties already have. The owner's decision goes past that: the
errand AND the world it needs are authored together, in the turn the player agrees to it. An innkeeper
says the storms have made game scarce, the player agrees to bring some back, and a beast is standing
somewhere in the region that was not there a minute ago and will leave meat when it falls.

THE CHEAPER VERSION WAS PROPOSED AND REJECTED, and the reasoning is recorded because it is the whole
argument for the expensive one. Drawing the meat from fauna the world was authored with moves the
burden rather than removing it: every need a conversation might produce would have to have been
anticipated at authoring time, which is a cycle with no end, and a world is finite while a conversation
is not. That objection is already written into this repository in another voice — the playtesting rule
that a step which assumes the world already contains what it needs is a step nobody can run — and the
proposal I made contradicted it. A simple errand is cheap to author in a turn, and the authoring IS the
content: what the player is playing for is a world where needs arise and are exchanged, not a menu of
them fixed in advance.

§03a is the design, and it marks each link of the chain against what exists. Three are missing — the
task cannot reach the sheet, no turn field places a being (roomUpdates handles removeEntity and
moveEntity and nothing else; placeBeingsInRoom exists but only the console's "// add a goblin" reaches
it, through a separate call), and nothing ticks a step. Three are already there: the judgement half has
a working precedent in the faction-duty clause, dutyTaken already has the Game Master invent an
occasion's milestones, and giveItem already hands the thing over.

The objection that looked strongest turns out not to apply. §07 strips rewards from a promoted beat
because an item reward has to exist in this world and is priced into a fixed pool of wealth — which
reads as a general prohibition on inventing things in a turn and is not one. It governs authored
STRUCTURE, the things a world's balance is measured against. Ordinary play has never worked that way:
stateChanges.addItem takes a whole item including its value, and the only guard on it is whether the
player paid for a purchase. The Game Master mints objects in turns already, so an emergent errand
extends a power rather than introducing one, and the guardrail it needs is not "do not mint" but what
the errand may PAY — XP, which the task model already guards against double-granting, and the scene's
own coin, never an authored reward or standing against an order's ranks.

The playtesting note that used to ask whether an unrecorded errand matters is replaced by the two
readings that are now worth taking, both of which need playing rather than arguing: what authoring an
errand costs the conversation it happens in — and specifically whether a slow turn still reads as the
innkeeper talking or as a system taking over the room, which are a tuning problem and a design problem
respectively — and whether the world it authored holds up an hour later, or whether the Game Master has
put a deer in a cellar and called it game.

No engine change. This is the specification reaching the point where the build can start, and §09a
remains the order it has to happen in.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Three decisions the owner settled today, which together finish a design that had been half-specified
since the checklist shipped.

The player is not meant to click the box at all. It is an INDICATOR — somewhere to see what they have
done, in the way the Journal's unlocked beats are somewhere to see what they have found — and not a
to-do list they maintain. Decision I said the Game Master owns the tick; it now also says the player
does not share it.

When the Game Master does not tick, that is trusted and narrated. There is no player override and no
engine reconciliation: a step it has not marked done is a step it has judged not done, and the scene is
where that gets said. The alternative — a player who can force the box when they disagree — makes the
checklist a second opinion about the fiction, and two opinions about whether a thing happened is worse
than one that is occasionally wrong. That closes the missed-tick question §09a had left open, and
closes it by accepting the cost rather than by solving it: a Game Master that quietly fails to notice a
finished step leaves the player stuck with no recourse, which is the shape of the withheld-beat problem
rule 13e already exists for. If it happens in play the answer is the same one quests reached — make the
Game Master SAY it is withholding — rather than handing the box back.

And it should not be a native checkbox. An <input type="checkbox"> is a control, and every affordance
it carries becomes a lie under the two decisions above: it takes focus, answers the space bar, draws a
hover state, and is announced to a screen reader as something the reader cannot do. An SVG box whose
mark appears when the step is done is what an indicator looks like, and the accessible state moves onto
the list item as text rather than sitting on an input nobody can reach.

THE ORDER MATTERS AND IS EASY TO GET WRONG, so it has its own callout. Taking the control away is the
obvious first move and must be the last: a player's click is currently the only thing that advances a
milestone, and decision J leaves nothing behind it. Turn the box into an indicator before the Game
Master has a verb and every task freezes at Accepted for good — no milestone XP, no completion XP, no
duty standing, nothing to unstick it, and an indicator that is permanently blank. The swap lands in the
same change as the field, never before it, which is why it is now the sixth and final step of §09a
rather than the tempting first one.

Nothing in the engine changed. This is the specification catching up with the intent, and the work it
describes is still ahead.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Both conflicts were the Last Update stamp in the two guides, as they usually are when two sessions
touch the books. Resolved to the current UTC time rather than to either side's, since the merged
content is newer than both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The panel has read "Regions map — coming soon" since the Map tab grew inner subtabs. It now holds a
card per region: the region's map, its own map prompt, Generate and Upload, with the shared Style once
above the grid and a head that counts how many regions are still to draw.

The point of it is a question that could not be asked before. World > Geography > Regions shows one
region at a time, which is the right shape for AUTHORING one and the wrong shape for "do these look
like sheets out of one atlas?" — that is a question about the set, and answering it meant selecting
each region in turn and holding the previous one in your head. Region and district maps are also the
only image class in the game with no audit surface at all: Art > Missing scans fifteen kinds and Art >
Review galleries the same object types, and maps are in neither.

The cards call buildRegionMapEditor() and buildRegionMapStyleEditor() rather than reproducing their
markup, so every writer behind those controls is the one the other screen already uses and there is no
second copy to drift. Both builders were already DOM-relative — the prompt's writer button finds its
textarea through btn.closest('.region-map-section') and the status line through itemMediaStatusEl(btn)
— so they work unchanged in a second mount. The one thing that was not is why refreshMapViews() exists:
their success paths called renderRegions() or renderMapArt() by name, which was correct while each
control had exactly one home and silently wrong the moment a second screen drew them. Generate a map
from the board and the image landed in world data while the card went on showing its placeholder,
because the only thing redrawn was a hidden panel on another tab. The failure leaves no trace in the
save, which is why the test drives the real writers and then reads the board's own markup rather than
asserting that a refresh function was called.

refreshMapViews redraws all three surfaces rather than guessing which is mounted, and that is the
load-bearing half. The map Style is a single world-level string on world.regions.mapStyle drawn on all
three screens at once, so a preset chosen on any of them changes what the other two are showing: there
is no such thing as the surface that edit belongs to. Each render is one innerHTML against an element
that always exists in the markup, so the two nobody is looking at cost nothing and cannot be stale.

The Style sits once, above the grid, and not on each card. It is one value, so a copy per card would
be N editors for one string, and editing the third would leave the other N-1 showing text that is no
longer true. Putting it above the set it governs is also the better audit: the style is the thing being
tested and the grid below is the result. A caption states its scope, because the only thing that said
so was the field's own placeholder, which disappears the moment somebody types — which is exactly when
it starts to matter. Editing that box while looking at one region restyles every other region's map,
every district map and the world map, and while it holds any text it replaces the world Art Style for
all of them rather than adding to it.

The order of the card's own parts is flipped against the detail panel, with CSS rather than a second
layout: there you are writing one prompt and the box is a field, here you are reading every prompt at
once, so the picture comes first. The prompt box is taller here for the same reason — two rows clipped
its third line mid-sentence, which defeats the whole purpose of a board.

Regions only, deliberately. Districts carry maps too, under this same shared Style, but they are
reached from World > Geography > Districts and this tab is named Regions; a board quietly holding both
would be the third thing called Regions in this editor.

Both guides were stale about this tab in ways the change makes worse if left. The DM's Guide told a DM
the Regions subtab was a placeholder and not to confuse it with the region-map editor, and listed two
inner subtabs where there have been three since Background landed; it now describes all three and
carries the Style warning. The Field Guide's Editor table never mentioned the Map tab's inner tabs at
all, and still called the World tab's Geography subtab "Regions", which is what it was before it grew
Regions and Districts of its own — so the row a reader was sent to for the calendar cross-reference
named a tab the app does not have.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Playtesting steps for the container rule, as two continuations under D rather than new letters, since
both are dismantling and renumbering twelve groups to append two would be worse than the nesting.

The container steps open with the thing a playtester meets before they meet the rule: a dismantle
subject has to be IN THE PACK, and most chests are room furniture, so the chest in the corner answers
"you are not carrying it" and says nothing about containers at all. Staging therefore wants a carryable
one -- a coffer, a satchel -- authored in the Save Editor, and the Dungeon Builder's chests are the
wrong subject because they are fixed.

Then full refused, empty allowed, and a third step written out as its own instruction: check the
container is actually GONE from the pack, not merely that the parts arrived. That is exactly what the
two disagreeing guards produced while they disagreed -- the chest surviving its own dismantling with
the parts granted beside it -- and it is invisible to anyone who reads the narration and stops. Plus
the locked-and-full case, because the rule reads contents rather than whether the player has looked,
and the container with no contents list at all, because an absent list is an empty box.

The second continuation covers the plausibility rule, which had shipped with no steps. It is a prompt
rule with nothing enforcing it, so the steps turn on authoring the wording yourself and reading the
answer: a chest whose description names its parts against one with an empty description; a clay pot,
which must give shards and never clay; a pot set with gemstones, which must give shards AND the stones;
and a candle, which must give nothing and say so.

While reading group D to place these, its staging line turned out to be false. It said both console
lines were local and cost no turn -- but `// give me an iron sword` matches nothing in the console's
own verb list, so it is sent to the Game Master to interpret: it spends a turn, needs a key, and mints
an item from the NAME rather than the catalogue entry. Corrected, and the correction points at the
groups where that distinction now matters.

Also a thirteenth note, and an h5 rule in the stylesheet because this is the first place the document
nested that deep.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The dismantle gate refused every container while telling the player "you could break it apart -- but not
with everything still inside it". An empty chest therefore met a reason that was not true of it, and of
the two it was the rule that was wrong: the message had been describing the rule the code should have
had. A chest somebody has emptied is boards and iron bands, which is exactly what this system is for.

It reads off the CONTENTS and not off whether the player has looked inside. A locked chest nobody has
opened still weighs what it weighs, and a character with their hands on it knows a full box from an
empty one without needing to see in.

Narrowing that exposed a second guard of the same shape, and the pair is the interesting part.
applyConsumeItem refuses containers too, for a reason that is general and correct -- destroying a full
one takes its concealed contents with it and says nothing, so the player loses what was inside and never
learns why -- and dismantling reuses that function deliberately rather than growing a second removal
path. So the gate said READY, the removal said no, and the chest survived its own dismantling with the
parts granted beside it. A duplication bug, which is worse than the refusal it replaced, and one that no
test caught because nothing pinned either half of the container rule at all.

That guard is narrowed the same way, and it is worth being exact about why this is not the widening §8
warns against. Welding a refusal onto the general spend-this-object path for crafting's sake would be
that. This is the opposite: the guard's own justification is entirely about contents, and an empty chest
has none, so refusing it protected nobody and only meant an emptied container could not be got rid of
through the path everything else uses. Dismantling gates emptiness itself before it ever reaches there,
so the craft path is covered twice rather than leaning on this.

Four sabotages, each caught: refusing every container again at either guard, and dropping either guard
entirely so a full chest comes apart or is silently destroyed.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The import merge was Object.assign(existing, incoming), which is wrong in the one way a merge can be.
An imported file is an AUTHORED TEMPLATE — a name, the steps, what they pay — while done, awarded,
completionAwarded and the dates are PLAY STATE the file has never seen. Assigning the whole object
replaced the milestone array wholesale, so re-importing the same file silently un-ticked everything.
Worse, it cleared the awarded guards along with the ticks: the XP for a milestone already paid could be
earned again by importing and re-ticking, which made the Import button on that tab a way to farm
experience out of a checkbox. Measured before the fix — two ticks paid 5, a re-import of the identical
file paid 5 again.

mergeImportedTask now carries the play state across and updates only the authored half. Milestones
match BY TEXT rather than by position, and the two failures are not equal: matched by text, a step the
author renamed arrives fresh and the player re-ticks it, which is a nuisance; matched by position, a
step inserted above a completed one silently inherits its tick, which marks work nobody did and pays
for it. Duplicated text is consumed in order. A stamped dateFinished is cleared when an import adds a
step, because taskState reads that stamp as authoritative on its own and would otherwise report
Completed over a list with work left in it. A duty binding made in play survives a file that carries
none, or re-importing an edited export would unbind the task from its order and payDutyStanding would
quietly stop paying.

THE ENTITY-SIDE UPSERT IS DELIBERATELY NOT CHANGED, and the comment says so where somebody would go
looking to make them match. addTasks on a being does assign the whole task, and that is the right
contract there: the Game Master re-sends it with its done flags as the current state, so the sender
owns them. Here the sender is a file that has never seen this character.

The sabotage pass found a hole in the test before it found anything else: every assertion drove
mergeImportedTask directly, so all of them passed with the importer reverted to the Object.assign the
function exists to replace — the function pinned and its wiring not. There is now an assertion that the
importer calls it, at source, because the importer's own path runs through a FileReader the harness has
no File for.

AND THE CHECKBOX HAS A RATIONALE NOW. Asked why a milestone is ticked by hand, the honest answer was
that nothing anywhere said — it was described in the code comment, the test header and this document's
own §02 and §08, and argued for in none of them. The owner's intent is that the checklist reflects what
has happened rather than being a to-do list the player maintains: the box ticks when the step is done
in the fiction, and the Game Master is the party that knows. That is decision I, settled.

The engine does not do it, and §09a is the distance between the intent and the build — five steps in
dependency order, because the first of them is a prerequisite for the rest. The cascade that stamps the
finish date, pays the XP and pays the duty standing lives inside the UI's toggle handler, so any second
caller duplicates three things; the verb flips rather than sets, so a Game Master re-reporting a step it
already reported would un-complete it; a milestone has no id to name it by; the turn-result schema
carries about sixty fields and nothing that advances one; and a field with no directive behind it is a
field never set. Two questions are left open on purpose — what reconciles a tick the Game Master missed,
and whether the player's own click survives as an override — because both want settling before the
thing is built rather than after.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Three corrections to the dismantle directive, the first of which was the rule asking for something the
dossier could not supply.

The parts do NOT have to exist in the world already. That was true in code from the day dismantling
shipped -- the yields are item specs and the engine creates them -- and §1 says so, but the directive
did not. It sits directly above "craft" in the rulebook, whose rule opens A CRAFT COMBINES WHAT ALREADY
EXISTS AND NEVER CREATES IT, so a model reading the two in order has every reason to carry that over
and reach only for items somebody has already authored. The two are opposites and the directive now
says which is which and why: a craft may not conjure its materials because the player is asking the
world for something it may not have, where a dismantling only takes out what the subject was already
made of, and the subject is a real thing the engine has just checked is in the pack.

Then the constraint that replaces inventory: plausibility. Which the model could not apply, because the
pack dossier listed a NAME and nothing else. "Chest" does not tell anybody it is a wooden chest bound
with iron. That is the same shape as the defect §4 shipped to fix -- an instruction the dossier cannot
support -- so each carried item now brings its own description and a truncated detailed description
with it. The two are affordable for different reasons and the code says so: a description runs a median
of 22 characters across the built-in world ("A sturdy iron sword.") and rides free on every item, where
a detailed description runs 317, so it is capped at 180 and carried only where an author wrote one. It
goes in `live` and must stay there, the pack being different every turn.

And the distinction that decides most cases, which a blanket rule gets wrong. An ASSEMBLY comes apart
into the parts it was assembled from -- a chest into boards and iron bands, a sword into blade and grip
and pommel. A SINGLE WHOLE does not revert to the substance it was shaped from: a clay pot does not
dismantle into clay, a bead not into sand, because that is unmaking rather than taking apart. Where
breaking one still leaves something usable, the yield is the BROKEN FORM and never the raw material --
pottery shards, not clay. And a whole may still carry separable things: a pot set with gemstones yields
shards AND the stones, because the stones were fitted to it and were never part of its substance.

That last case is why an earlier draft of this rule was wrong. It forbade gemstones flatly, along with
coins and potions, as a guard against dismantling becoming a way to hand out treasure -- and it would
have suppressed exactly the right answer for the pot. The useful negative is "nothing that was not on
the object", not a list of forbidden nouns.

The Dungeon Master's Guide carries the consequence for authoring, which is the practical half: an
item's Description is now the field that decides what it comes apart into, so a thing with parts worth
recovering should say what they are. It costs a clause and it is the difference between the parts being
yours and being invented.

Three sabotages on the dossier half, and the prompt assertions check the thing they usually forget --
that `live` really carries the fields the rule tells the model to read, and that none of it leaks into
the cached half.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The calendar note in the player's half linked to "#dm-world", an id nothing in the file defines, so
the one cross-reference explaining where a world's month and weekday names come from went nowhere.
The World tab has no section of its own in this guide -- it is row fifteen of the Editor's subtab
table -- so the link now targets the Editor section that documents it.

That alone would have landed a reader on a row that says nothing about a calendar. The row lists the
World tab's inner tabs as "among them" and named six of the eleven, and Calendar was not one of them,
although the guide refers to the Calendar tab by name further down. So the row names it now, with what
it holds: the months, the weekdays and the year, and the fact that renaming any of them renames what
the header clock and the month view show. The link and the sentence it serves now agree.

Found while auditing anchors for the Fame documentation; it predates that work.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Writing Designs/tasks.html turned up an engine gap: an NPC's offered `tasks`/`addTasks`
roster is a catalogue the Game Master plays from, and nothing copies it onto
`player.tasks` the way a duty's `dutyTaken` field does. The guide's own row on that field
said the opposite — "Accepted tasks surface on the player's Journal › Tasks tab" — which
reads as a mechanism that does not exist. Corrected it to say what actually happens (an
import or a DM edit, not acceptance in conversation) and pointed at decision G, still open,
for whether that should change.

The same row picked up the item-instance disambiguation naming that shipped alongside
crafting's other recent work: two genuinely different crafts of the same name no longer
merge silently, the second taking the next free ordinal off its base name. And the being
table gained the Age/Born row it never had — every being, animals included, has carried a
derived-from-birthday age since the aging work shipped, and the guide only ever described
the free-text profile.age beside it.

The Player's Handbook's Crafting section said repairing a worn item's condition was "still
designed rather than built" — false since the `repair` directive landed; corrected to
describe what it actually does. Last Update bumped on the DM's Guide for the content change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012NTFgq5Pw2nP1KLCFeFAXX

The task system was documented nowhere as itself — its reasoning was spread across quests-and-journal
for the quest boundary, factions for duties, and a dozen code comments for everything else. The pieces
that only existed as comments are the ones worth having somewhere findable: why the state is derived
from the milestones rather than stored beside them, why a duty instance copies its own price instead of
looking it up at completion, why the repeating reward is bounded by the order's rank ladder rather than
by running out of work, and why a promoted quest does not point back at the task it grew from.

WRITING THE STEPS FOUND SOMETHING. The house rule is to write a playtesting Steps section by checking
the code rather than from the document's own prose, and doing that turned up a gap the prose would have
papered over: there is no engine path from an NPC's offered errand to the player's sheet. `ent.tasks`
is a catalogue the Game Master plays from; only a duty instance or a JSON import ever writes to
`player.tasks`. Confirmed three ways rather than assumed — `applyDMMetaDirective` has no task field
(enumerated), the `//` local parser has no task command, and the tab's toolbar has no Add button. So an
ordinary errand is agreed in fiction and never reaches the Journal. That is now decision G, open, with
the leaning written down: a `taskTaken` turn field shaped like `dutyTaken`, with the same engine-side
governance, weighed against the argument that duties already cover the repeating case with real
structure and a free-form field invites the Game Master to author errands nobody authored. The Notes
section carries the observation that settles it, because it is not settleable at a desk: play an
ordinary errand, then open the tab, and see whether its absence actually costs the player anything.

Every figure and every refusal in the document was measured rather than read off the source. The import
JSON in step 1 was run through normalizeTask; the XP arithmetic (5 + 5 + 0 milestones, 25 on
completion, 35 total, nothing on a re-tick) was run; the five duty refusals are quoted verbatim from
takeFactionDuty; the promotion strip was checked by sending a beat with xp 99 and an item reward and
watching it arrive as 0 and []. The one that changes a step's usefulness: the built-in world ships one
faction and zero duties, so the whole duty group needs authoring before any of it runs, and the section
says so rather than leaving a playtester to discover it.

Decision H is open too and leans the other way — nothing ages a task out, and it should stay that way
until there is somewhere for a deadline's consequence to live, since half a promise is worse than none.

The document needed an h4 rule in its style block, as containers and abilities did before it, because
the Playtesting section is the first thing in it to nest a fourth level.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Both sides edited the two guides that carry a Last Update stamp, so both conflicts were the stamp and
nothing else. Resolved to the current UTC time rather than to either side's, since the merged file's
content is newer than both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The Fame ladder shipped without a word about it in any of the three books, which is how a player ends
up staring at a Profile chip reading "Unknown" and reasonably concluding the field is broken. Unknown
is rung one. It is the state every character starts in, and nothing anywhere said so.

So each book gets the account its own reader needs, and deliberately not the same account three times.
The Player's Handbook gets what a player can act on -- the ladder, the persuasion bonus each rung
lends, and the fact that the number itself is never shown -- written into Chapter Fifteen beside
Factions, since standing with a person and standing with an order are the same question at two scales.
The Field Guide gets a Reputation & Fame section explaining the two scales the interface actually
draws, because the Guide's job is to say what the chips and badges mean. The Dungeon Master's Guide
gets the mechanics: both tables, the accrual rules with their figures, the console lever, and a
warning that unlocking quest beats by hand pays no Fame and no XP, which is measured rather than
assumed -- the beat toggle in the editor moves neither, and it does not hand over the beat's reward
item either, while still chronicling the arc in Legends. A DM staging a scene that way gets a record
of a finished quest, a Renown chip that never moved, and a spoil chip naming an item nobody received.

The design doc then gains the PLAYTESTING section the 22 Sep convention asks of a built system, in
both halves. The Steps are grouped by scale -- reputation first, which needs no API key at all, then
fame, then alignment -- and writing them by reading the engine rather than the doc's own prose is what
made them worth having, because four of them contradict what the prose would have led somebody to
expect. The reputation notice's headline is the boosted figure and the bonuses are only a receipt, so
a base +3 at CHA 18 reads "+7 (+4 CHA)" and a transcript read the other way makes the model look like
it sent a 7. The one fame line a player ever sees is emitted at the end of a Game Master turn,
comparing the label the turn opened with against the label it closed with, so the console moves fame
silently and a playtester watching the story pane would call it broken. The three surfaces that draw a
reputation disagree on purpose -- word and number in the close-up, number alone on the narrow sidebar
badge, and a Present-line tint whose saturation is scaled by distance from zero, so a neutral is
colourless by design. And there is no alignments panel in the Editor at all; the map is world data,
and the Character Sheet's Alignment row is where its descriptions can actually be read.

Two staging facts are stated up front for the same reason: the built-in world contains no
treasure-typed item, so the treasure half of Fame cannot be exercised until one is authored, and the
console has no reputation command, standing being set on the being's card instead. A step resting on
either is a step nobody can run.

The Notes half is six observations, all of them about whether the Game Master uses the room it has
been given, since that is the only part of this a desk cannot settle. The one worth the most is the
pair of neighbouring fields: fameDelta nudges the hidden value, while stateChanges.fame overrides the
visible label outright, and the override is sticky with the persuasion bonus still following the value
underneath -- so a character the GM has christened Legendary can walk around with an Unknown's +0. The
two are one line apart in the contract and the distinction between them is entirely in the prose.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Auditing the two guides against what has actually shipped found the same shape of problem the
playtesting section had, plus one outright contradiction.

The Dungeon Master's Guide had notes for dismantling, repair and the condition ladder, and NOTHING for
assembly, half-made things or the notebook -- three shipped phases, one of which is a capability the
guide never told a DM they had. It now carries all three. Making a thing sets out what the Game Master
emits and what the engine owns after, and the two figures that are the whole of the player's decision:
the grade sets the stages, and the hours are weighed against what the job wants, short by a quarter
costing +2 a stage to a ceiling of +6 (which is all the arithmetic allows, not the +8 an earlier draft
of the design claimed). Half-made things says what a partial is and, more usefully, how to author one
-- the subtypes, the minor flag, the fields of the project block -- with the rule that binds a DM the
same as anyone: an unfinished thing is not a loophole, and its target must be something they could have
authored outright. The notebook covers where a player sees any of this, that a method lives on the
character rather than the world, and the authoring consequence of instances: a made thing never merges
with a bought one of its name, so authoring a sword called what a player's own forged one is called
collides with nothing.

And the section explained the mechanics before the thing they are mechanics of. Three overview
paragraphs -- the three acts, the two rules, what the hours buy -- had ended up after every operational
note, because each phase appended its note wherever was convenient and the prose stayed where it was
first written. They are lifted above the notes, which is the order somebody reading to learn needs
rather than the order the material was produced in. Its status line also listed seven shipped phases
while saying "phases 1-6".

The Field Guide contradicted itself. Its opening paragraph said repairing was "still designed rather
than built" while three paragraphs later it explained how to mend something -- a leftover from when
that was true. It now says plainly that all of crafting is built, and it tells a player the thing it
had never told them: what the half-made item is actually CALLED, "Short Sword (partial)", and that a
second project is "(partial 2)" so the two are never confused. A player who does not know the name
cannot find the thing in their own pack.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Asked whether §13 was thorough enough for somebody else to pick up and test the system in play, the
honest answer was no, and auditing it found three faults rather than one.

The subsections were in the order they were WRITTEN. Each phase appended its steps at whatever anchor
was convenient, so a reader met "whether a smith can beat their materials" before the dial it depends
on, and mending before dismantling. They are now twelve groups, A to L, in build order: the skill
catalogue, dismantling, assembly and the dial, the notebook and its tab, two of a kind and naming, and
mending. Every one of the thirty-six original step items survives the reorder; the letters moved and
nothing else.

Two shipped phases had no steps at all. The recipe notebook and the Crafting tab -- a whole phase with
a UI surface -- and the naming and instance ids that came with it. Both now have groups, and both lead
with the thing that is hardest to see: a re-run that finishes instantly rather than a sitting per turn
is the bug that phase was most likely to ship, since the design it came from described re-use as
atomic; and every failure in the naming group is a quiet one, so the instruction is to check the pack
count rather than to read the prose.

And the Notes half covered two phases of seven. Every claim in it dated from when the skill catalogue
was the only thing built -- not one word about assembly, the sitting, partials, the dial, the material
bound, repair or the notebook. Six new notes in the house shape, each saying what to watch for, what it
would mean and what a fix would cost. The most useful of them is probably the material bound, because
the cap is invisible in the manifest by design: the dossier hands the model the materials' condition
and whether it USES that is exactly the sort of question only play can answer.

The new cold-start callout is the part aimed at a stranger. What to stage once rather than twelve
times; which groups need the Save Editor because the console has no verb for granting an item or
setting a condition; that A-C can be read off the prompt without playing a turn while everything from D
needs a key; and which three failures are quiet ones that look fine if you only read the narration.
Plus the one habit worth more than any individual step: read the manifest, because a narration claiming
a roll with no manifest above it is the model having emitted something the engine discarded.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The two files that were declared yesterday on the strength of having been looked at — the village
square's night panel and the prototype's crossed-swords mark — now carry the half only the owner could
supply: both were generated by them with Nano Banana Pro. Their entries said so was outstanding, and
this records the answer where it outlives the session it was given in, which is what this ledger is
for.

What is worth keeping separate is that here, unusually, the bytes partly corroborate it. Neither file
names a generator in its own C2PA: both carry c2pa.opened and com.anthropic.claude.provided with
com.anthropic.origin-confidence "unknown", which records a file passing through a conversation and
makes no claim about what produced the pixels. But five of their siblings in the same directory and the
same push do carry c2pa.created reading "Created by Google Generative AI." with IPTC digitalSourceType
trainedAlgorithmicMedia, which the inventory reads unaided — and Nano Banana Pro is Google's. So the
owner's answer and the set's own signed manifests agree. That is better than the bare testimony most
generated entries in this ledger rest on and still short of these two files saying it themselves, so
the entries record it as corroborated BY FAMILY rather than by these bytes.

The string is kept exact, as the age-* entry already insists: the tool is Nano Banana Pro, which is not
the "Nano Banana" of the square-* entry, and the two are not collapsed into one on the assumption that
they are the same grant. The terms behind it are still not read into this record — what is known is the
owner naming the tool, and what nobody here has seen is the grant, which plan and the output-ownership
clause in force on the generation date. Adding these paths does not move that question.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Main went red on the two commits that added the World Browser prototype and the env-dump script. Both
breaks are the kind the guards exist to catch, and neither is interesting in itself; what the fixing
turned up is.

Server/dump.ps1 had no SPDX identifier. Written by the tool, as the failure message says to.

Web/WorldBrowser/images was the fifth new leaf directory under Web/ that DIRS has not reached. That is
the failure mode the directory-walk assertion was added for: a file the scan never walks is not
reported UNKNOWN, it is absent, so --check passes while the report quietly stops describing the tree.
Added, with a note recording that this is the fifth time, because the pattern is the argument for the
assertion existing.

Declaring the fourteen images it then surfaced turned out to need almost no judgement, which is worth
recording because it will be true again. Twelve of the fourteen are BYTE-IDENTICAL to files already in
the repository -- hashed against every other tracked image, matching exactly rather than resembling --
so each one's provenance is its original's, already established by whoever looked at that file. The
prototype copied the landing page's art into its own directory instead of referencing it, which is a
duplication question rather than a provenance one. They are filed in three entries by the authorship
they inherit: eight AI-generated, three screenshots, one brand mark.

Two are genuinely new and were opened and looked at. VillageSquareNight.png is the night panel of the
village-square time-of-day set -- the same fountain and the same arched gate as the Clear, Snow and Day
images, under a full moon, with a guard under the arch. logo.png is a crossed-swords device in gold on
dark brown, a mark rather than a picture, and it matches nothing else here, so the already-declared
logo.png is a different image and this is not a copy of it.

Both of those carry a C2PA manifest, and what it says is worth separating from what it appears to say.
It records c2pa.opened and com.anthropic.claude.provided with com.anthropic.origin-confidence set
explicitly to "unknown", whose own description reads "Claude provided this file at the request of a
user and may have created or modified the file contents." That is a record of HANDLING, not of
creation, so it does not establish a generator -- unlike the five JPGs in the same directory, which
carry c2pa.created naming Google Generative AI and which the inventory reads unaided. The entries say
so in their doesNotClose rather than rounding the Anthropic assertion up into an authorship claim it
does not make. Which generator made those two is a question for the owner.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The last parked decision in the crafting design, and the leaning was right: the output takes the worst
rung among its inputs, with a critical success beating it by one. Nothing in this design is open or
parked now.

Two axes meet in item.condition and neither may overwrite the other. The GRADE says how well a thing
was made and is the player's own doing -- their hours, their ambition, their rolls. The MATERIALS say
how good it was ever going to be, and no amount of craftsmanship makes scrap into silver. So the
condition is the LOWER of the two, which leaves the grade free to go on naming and pricing the piece: a
"Pristine Short Sword" in good condition is not a contradiction but an honest description of a
beautifully made thing out of ordinary iron.

The critical is read off the FINAL STAGE only, and that is a decision about rarity rather than a
shortcut. The reward is meant to come from a rare roll -- one grounded in stats, buffs and modifiers,
paying out beyond the sum of its parts -- and "any critical among the stages" sounds like the same rule
while being nothing like it. At a ten percent chance per stage it fires on 52% of seven-stage crafts,
and for a master at an easy DC it approaches certainty, so the bound would end up loosest for exactly
the smiths who least need the help. One roll keeps the rate flat however long the work is, and it gets
RARER as the job grows more ambitious, since a pristine craft's DC is higher and its critical
correspondingly harder: roughly 10% for a master on a pristine piece against 35% on an ordinary one. It
also reads as what it is -- the last pass, the finishing, the moment a thing can come out better than
its stock. And it compounds with the bound only binding at all when the materials are poorer than the
work, which is already the uncommon case.

Two details the building forced rather than the brief anticipating them. The materials' conditions are
sampled when the work BEGINS, because the inputs are spent at the start and by completion -- turns
later, across sittings -- there is nothing left to read; a rule that reads them at the end reads
nothing. And materials that declare NO condition are ignored rather than counted: an unstated condition
reads as `good` by design, so treating it as a bound would cap every craft in every world at good and
put the top of the dial quietly out of reach, a nerf to the hours-and-stages dial delivered by the
condition ladder saying nothing at all.

Nine sabotages, each caught by a distinct assertion. Two of them needed the test rewritten rather than
the code: asserting the unstated-condition case took a craft that finishes on a PLAIN success, because
the critical bonus lifts an unstated bound from three to four and hid the very thing being checked --
so that section now probes its own DC the way the half-credit section does, and asserts first that no
stage came out critical, or the assertion below it would mean nothing.

Both guides carry it: the Dungeon Master's Guide on the Condition box now being a real constraint on
what a smith can make from a thing, and the Field Guide on good stock being the reliable answer and a
great roll at the very end being the rare one.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Re-ran Tools/gen-progress-report.js from a full, unshallowed clone of main
(4,328 commits, up from 4,280) so the index and the September month page
carry current totals rather than a stale snapshot.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C1fDLwAPt1pSXM574rbPK8

The route redaction was implemented as `shelfKey === 'rooms'`, which was true for exactly as long as
rooms were the only records in this engine with contents in them. They are not. A being carries
`inventory` and an encounter carries `entities`, so a `player` build of the world committed to this
repo printed the full carried inventory of every NPC and monster in it, and the spawn roster of every
encounter — a loot table with the names filled in, on a site whose whole reason for making --audience
a required flag is that a site gets served. The existing assertion passed throughout, because it only
ever looked at a room.

The reason nothing reported it is worth writing down, because it is the cost of a design decision that
is still the right one. A record page's field list is a DENYLIST over whatever keys the record happens
to carry, and it has to be: a per-shelf roster would be forty lists to keep in step with an engine
that adds fields weekly, which is the equipment-slot roster again. The price of that is that a field
nobody wrote down is PRINTED, so the sets are the only place the rule lives and anything added to the
rule has to be added there. Widening the gate to every shelf is strictly more correct rather than a
trade — there is no shelf where a room's exits or a creature's inventory is player-facing.
`startingInventory` is deliberately left out, a class's kit being published so a player can choose a
class knowing what they get, and `ingredients` likewise being the recipe rather than a secret about it.

Two further kinds came out of the same reading, both found by looking at a generated page rather than
by anything failing. A faction's `reveal` is the sentence saying what a player has to do to discover
that faction, which is a hint filed under the thing it is a hint about, so it joins the GM's working
fields. And a disguise turns out not to be a field you can redact at all: the built-in world's
Barrowking's Signet is found as a plain iron ring and identifies as a "Ring of the Warding Hand" with
+2 AC, so dropping `falseName` and `falsePayload` off the page still leaves a page TITLED with the true
name carrying the true effects, which anyone wearing the ring reads straight off the shelf. An item
carrying a false identity is by construction one the player is not meant to be able to identify, so the
whole record goes — the same call `seen: false` already gets, for the same reason. A reagent marked
`secret` is that claim in one word and gets the same answer. The assertions for all of this sit on
three different shelves and include the over-correction, so dropping a shelf instead of a record fails
too; each break is caught by exactly one named assertion.

Separately, the vault-reading path was giving advice that cannot work. It told a refused caller that a
vault treats loopback as an admin and to run the tool on the machine serving the vault — for both 401
and 403, in one paragraph. `adminGateDecision` reads `loopback` only in its Auth0-OFF branch, so on a
vault with Auth0 configured, which is now the expected configuration, an unauthenticated caller is told
to log in whether it came from loopback or not. The tool was sending people to the right machine to be
refused there in identical words, with no hint that the answer was never geography. The vault already
distinguishes the two and says so in the body — 401 with `reason: 'login'`, 403 naming the email it
knows — and those were being discarded; they are relayed now, and the 401 branch names the export or
Vault Pack route that does work. The test asserts the distinction rather than the wording, since a test
matching a fixed sentence cannot notice that the sentence became false.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Phase 7, and with it all seven. Assembly makes a thing better than its parts, dismantling makes parts
worse than the thing, and repair moves one thing back up at a cost -- all three on the same dial,
hours in, quality out, risk rising with ambition. It was the shortest phase in the list, as advertised,
because everything it needed was built for something else: conditionStep took a signed delta precisely
so this could exist, since a ladder built as a one-way street to serve dismantling is one repair cannot
use.

A repair directive names the thing, the craft, a DC and the hours. The engine checks it is really in
the pack, adds the difficulty its current state deserves, spends the materials and the hours, rolls the
shared ladder, and moves it one rung on a pass or two on a critical -- clamped at pristine by
conditionStep, so the ceiling needs no rule of its own here. The wear penalty is the same +2/+4/+6
figure dismantling already reads, from the same table, so bringing a ruined thing back is +6 over the
job the Game Master judged and easing a merely average one is +2. A second scale for mending would be a
second thing to keep true.

Materials are optional but verified when named. A dented pot wants an afternoon and a hammer rather
than a shopping list, and the grounding principle does not stop applying because this is the third act
rather than the first.

A failure does not make the thing worse, and that is the brief rather than an oversight. The design
asks for hours and a check and says nothing about degradation, and a botch that drops a rung turns an
honest attempt at a worn blade into a way to ruin it -- a rule to add on purpose if play asks for it,
not one to smuggle in while building. The cost is real without it: the hours are spent whatever
happens, the world moves through them, fatigue accrues, and the materials go too, because a working
that failed still consumed the rivets. Without that last part the cheapest way to test a die would be
to fail with the makings still in hand.

Charged in hours rather than under a once-a-day gate, which puts repair with assembly rather than with
dismantling: dismantling gates a subject somebody keeps picking at, where repair is work. A thing
already at pristine is refused in words with no roll -- a check the player can neither win nor lose is
a turn spent on nothing with a die to dress it up -- and an unfinished craft is refused too, because it
was never whole and wants resuming rather than mending. The picture is cleared when the thing actually
moves, for the reason a craft's sitting clears it: the portrait path bails when an image is already
set, so the battered picture would outlive the battering.

Eleven sabotages, each break caught by a distinct assertion, including the two that matter most for a
rule like this -- that the ladder is walked upward and not down, and that a failure leaves the thing
exactly as bad as it was.

The one parked decision is still parked, and now carries the interaction its leaning has to answer.
Whether a craft's output takes the worst rung among its inputs cannot simply be added beside the dial,
because the dial already writes condition from the grade reached: the two would be writing one field
from different premises. The shape that reconciles them is a cap rather than a replacement -- the grade
says how well a thing was made, the inputs say how good it was ever going to be, and the condition is
the lower of the two. That is a real decision about whether a smith can beat their materials, and it is
the last one this design has left.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

# Conflicts:
#	guide.html

The Damaged gear group was on the character-sheet dialog and the printout but not on the Profile
subtab, so the one place a player edits their character showed a torn tunic only by its name. The
Profile now draws the same group under Marks. It uses the same body as the dialog, now split out as
damagedGearBodyHTML, so the panel, the dialog and the printout list the same pieces in the same
places.

Its names needed somewhere to open. openInventoryCardItem's panel fallback is #charinv-item-popup,
which lives in the Inventory subview and is hidden while Profile shows, so a name clicked there
would have opened a popup nowhere at all: the failure charsheetPopupHost was written about. The
Profile gets its own item host, #profile-item-popup, beside its skill popup, named in the shared
popup CSS and in ITEM_POPUP_IDS and ENTITY_POPUP_IDS so an open one refreshes in place. The opener
picks it when the click came from Character > Profile and otherwise behaves as before.

Tests/test_worn_damage.js drives all three routes (Profile, dialog, Inventory card) and asserts the
section and its absence, each checked against its sabotage. Test_character_sheet_modal's pin on the
opener's source text now accepts the per-surface fallback. The Field Guide (stamp moved), the
Player's Handbook and the design doc each mention the new section.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Phase 6. `item.condition` was a caption: every reader in the file was a display -- two spans on the
character sheet, a tag and a row in the editor, two lines in the dossier, the item popup -- and
nothing branched on it, compared two of them, or knew that worn is below good. It has an ordering now,
and two things that read it.

Five rungs, ruined through pristine, with the index as the rung, and a NORMALIZER over free text
rather than a closed enum. The direction the failure runs is the whole argument: a validator that
rejects an authored string is a world that will not load, where an unmapped word landing on a defined
rung is only a missing penalty. So a world that wants "waterlogged" or "rune-etched and humming" in
that box still gets it, and it reads as ordinary. `good` is both the default and the no-penalty rung,
which is why the day this lands almost nothing changes: 22 of the 32 items in the built-in world that
declare a condition already say good, and the five that say average start costing something.

Two things the brief could not settle without code in front of it. The first is that the two failure
directions have to be opposite. An unmapped word reads as SOUND, for the reason above. A known damage
word reads as DAMAGED however much praise surrounds it, because somebody did write it down -- and the
WORST known word wins, which is what stops "good, if a little battered" and "worn but sound" from
answering differently for no reason a player could predict. The first draft sorted by word length,
which is a rule about spelling rather than about swords, and it survived its own sabotage check
because nothing in the test could tell the two orderings apart; the replacement is defensible and the
assertions now name the two strings that decide it. The second is that phrases need a pass of their
own against the whole string: "barely", "holding" and "together" mean nothing apart, so a word scan
walks straight past a wreck. The three the brief named by name are in that table.

A third the brief could not have known at all: §9's dial writes its own vocabulary into this same
field, so `crude` and `fine` arrive from the engine itself. A ladder that did not know them would read
a crude blade as ordinary. It knows them, and a crude craft now handles worse -- which is the dial's
bottom end finally costing something rather than merely reading as less.

What consumes it. A dismantle's DC rises by the wear, +2 at average through +6 at ruined, ADDED to the
figure the Game Master asked for rather than replacing it, so a job the model judged hard stays hard
and a wreck is harder still. That is the original request's own sentence finally meaning something.
The manifest prints the rung and the figure beside the DC, because a check four harder than the job
warrants with nothing saying why reads as the engine being unfair, and the whole point of putting this
in the engine rather than in the model's head is that the player can see it and it is the same number
every time. The dossier tells the Game Master the engine has already applied it, or the same wear gets
counted twice. And what a dismantling yields comes out one rung below the thing taken apart, which is
the rule that stops dismantle-and-rebuild being free money -- unless the model named a condition for a
yield itself, in which case it is honoured: the default fills in where the GM said nothing, never over
what it said.

conditionStep takes a signed delta rather than being called degradeCondition, because a scale built as
a one-way street to serve dismantling is one repair cannot use. That is the whole of what phase 7
needs from this.

Twelve sabotages, each break caught by a distinct assertion. Both guides updated: the Dungeon Master's
Guide gains what the box now means for authoring, and the Field Guide says plainly that a worn thing
fights you and that a round trip through a dismantling always costs a rung.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Exercised on the live login screen rather than only in the harness, with the World picker on The Salt
Cantos of Verengrad: a name whose save is in a different world stayed silent, a name with no save
stayed silent, and Claude21 - which has a save in that world - raised the warning naming the world and
saying the save cannot be recovered. The middle case is the one that would have destroyed a save an
hour earlier, when a ctrl+a meant for the name field selected the page instead and left Claude20 in it
with New Game already ticked. It was caught while typing rather than at Begin, which is the whole
argument for where the notice sits.

Promoted from fixed-unverified on that observation. The underlying design is unchanged and remains in
the leaning: a second run of the same name is still not a second save.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Verification run for BUG-059 on a fresh Scaffold Scout with all twelve room hooks locked, nine turns,
on the build carrying the partial-satisfaction wording, the field note and the detector suppression
together. Both target classes sit within five moves of the start, which is why this took nine turns
rather than the forty-three the accumulation run needed.

Four hooks were held back and three were nudged. The partial class is fixed and the regression is
closed: the toy boat worked free of the root without being shown to Mira nudged on 8 September, fell
silent on 25 September, and nudges again now. That turn also settles the confound that muddied the
earlier reading, because a Gill-Wretch ambushed in the same turn exactly as before and the nudge fired
anyway. The combat was never the reason. The wording was.

The single-act case is not fixed. The descent turn's narration says "You reach the lower chamber just
as the flood-line bottoms out, a full hand's width of wet, weed-slick stone bared", against a condition
reading "time your descent to the exact moment the chamber's water level drops lowest", and the
response carried no unlock and no near miss. That is this entry's trigger in the rule's own words for
the fourth time on that hook - 24 August, 19 September, 22 September and now - and its single success
remains the 25 September run on the build whose header stated only the literal trigger. One in five
attempts on the same hook.

One observation cuts the other way and is why the partial wording stays. The Spire's upper hook, which
paid out on the bare act for both Claude20 and Claude21, was withheld and nudged this time. The rule is
engaging where it previously never triggered, which is the designed behaviour, since a hook is supposed
to reward comprehension rather than a mechanical act.

The instrument is now trustworthy, which is the other thing this run established. The repaired detector
fired exactly once, on the one genuine miss, and stayed silent after the three correctly nudged turns
because the suppression recognised their near miss. This is the first run whose flags can be counted
rather than read by hand.

So the bar is unmet and the remaining failure is one identified shape rather than a general
inconsistency: a single-act condition the Game Master chooses to hold pending articulation. It cannot
be elicited on demand, so it should be watched for during ordinary play rather than hunted.

App suite 936/938, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The printout's header is a flex row, so the order of its children is the layout, and the portrait
came after the name-and-identity block and printed right-aligned. It now leads the header, where a
character sheet's picture sits, with the name, title, identity line and summary beside it. The CSS
needed no change.

Tests/test_character_sheet_modal.js asserts the portrait precedes the text block inside the header;
it fails against the previous markup and passes now.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Two of the four built Culture systems now carry PLAYTESTING in both halves. The three
roster-scoped sections in culture.html stay separate; §7 gains a Steps half above its notes, and
Languages gains one in its own doc. Religions and Heraldry keep the Notes-only shape,
deliberately: the system prompt carries sections for Folklore and History and for nothing else in
Culture, so neither of those two is narrated yet and a Steps half would be "press + New, look at
the card". Castes owes nothing — it has no world.castes and its controls are disabled with the
reason in the tooltip.

Folklore's §7 opened by saying the Game Master never reads a tale in play and that the authoring
box is therefore the whole of what a session can watch. That was true when it was written and has
not been for some time: §5 of the same doc already said so in as many words, and the prompt
settles it — there is a "Folklore in this room" section, rule 13f governs drawing a tale out of
its teller, and a told tale pays its XP. A section that tells a playtester there is nothing to
observe is worse than no section, so the opening is rewritten and the notes are framed as the half
about authoring rather than as the whole.

Both Steps halves were written by checking the code, and both carry a caveat that only measuring
found. Folklore: the built-in world ships with zero tales, the console can author neither a tale
nor a teller, and — the one that would have wasted somebody's evening — a tale's WORDS are written
once in the + New dialog and never again on the card, which carries a picture, an XP stepper and
the unlocked box and no editor for the name, the text or the kind. Rewriting a tale means the GM
request box or a re-import. Languages: the request box on that tab is drawn disabled with "Coming
with P4", so every step is hand-authoring; and against that, none of the sixteen steps needs an
API key at all, because the whole reading path is deterministic.

The Languages spine is the four states of one sentence, read four times, and writing it corrected
my own first reading of the system. A passage is authored in ENGLISH, not in the invented tongue:
the engine substitutes per word in one direction, english to lexicon to script, so a reader who
knows nothing sees the words they have not earned drawn as shapes among English that stays English
— a page with holes burnt in it rather than a wall of cipher. Learn the alphabet and the shapes
become letters you can pronounce and not understand. Learn one word and that word alone turns
back. Fluency turns the rest. A probe with a malformed script record showed no glyphs at all and
nearly put a false step in the doc; the record wants { kind: 'svg', glyphs }, and with it the same
sentence renders 6744 characters one way and 287 the other.

Neither doc had nested to h4, so both gain the rule the pattern docs added, and §7's five note
sub-heads and §10's sixteen are demoted under the new Notes heading. Designs/README.md's two rows
record what each section now holds and why Religions and Heraldry were left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The People entries carried a name, a description, where the person was and how they feel about the
player, and nothing about the person themselves. An age is the first fact anybody would have noticed
about somebody they met, and the card is the player's own record of having met them.

It is read off the LIVE being rather than the discovery snapshot, which is the point of deriving an age
at all: a ferryman met in the first week and looked up again ten years later is ten years older, not
frozen at the number he happened to be when the card was written. The card already resolves the live
entity for the reputation badge, so the age rides a lookup that was there.

Through entityAgeLabel, the one reader allowed to choose between the number and the prose, so a being
whose age was only ever written as "centuries old" still reads that here rather than blank, and one
nobody has aged gets no line at all instead of an empty labelled row. The birthday is the row's TOOLTIP
rather than a second line: this is a browsing view that already carries five rows, the exact day is
detail a reader wants occasionally and a list of people wants never, and the DM's own card spells it
out.

One of the new assertions was wrong rather than the code. "A person nobody has aged gets no Age line"
failed because it sliced the rendered panel from that person's name to the end and read the NEXT card's
Age line — the panel does not draw entries in the order they are handed to it. Rendering the two cases
one card at a time is the fix, and it is the same lesson as the tooltip assertion in the commit before
this one: an assertion that searches a region wider than the thing it is about will eventually be
answered by something else in that region.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The Field Guide and the Player's Handbook now describe the character-sheet dialog and its Print
button, and the DM's Guide was the one book still silent on it. The note sits in Testing your world,
right after the one on staging scars and torn gear, because that is where a DM wants it: once a
situation is staged or a playtest has run, the printed sheet is a one-page record of where the
character stood. It also says what makes the printout worth a DM's while: it shows more than the
player's pictures do, listing every mark (unticked ones as "not painted") and every damaged piece
with what the damage looks like. The Last Update stamp moves with it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

The Field Guide gained this note in the previous change, and the Handbook, whose Chapter Five is
the player's account of the character sheet, still said nothing about the dialog or its Print
button. Chapter Five now ends with the same material in the book's own shape: the sidebar portrait
opening the sheet over the story, its seven tabs, and Print laying the character out as one page to
print or save as a PDF, including that unticked marks are printed as "not painted" and what to do
when a pop-up blocker swallows the window.

The Handbook's PDF is deliberately left alone. It is struck by hand for a print run and is expected
to lag the page.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

The card carried an Age and nothing to say where the number came from, which for a derived age is the
more useful half: a guard is 58 because they were born on the 1st of Greentide in the Year 379, and a
reader looking at the first without the second has no way to tell an authored age from one the clock
has moved. The Profile block now carries an Age row and a Born row under it — the same pair, in the
same order, as the character sheet.

The date is NOT repeated beside the editor's Age box, where a first pass put it. Two copies of one date
on one card is the same noise as two copies of it in the data, and the labelled row four lines below is
one glance away; the box's own tooltip still names it. What made the inline copy look necessary was a
defect rather than a need, and the defect is the other half of this change.

Typing an age did not redraw the card. The gender and race setters beside it do not need to, and the
difference is the point: those write to a select whose displayed value IS the control, so there is
nothing derived to go stale. An age has a derived neighbour computed at render time, so setting a being
dated to the Year 379 to 30 left the card showing the old date with nothing to say the two disagreed —
on the one surface where both are visible at once. setEntityAge now redraws the tab. The whole tab
rather than patching the one span: the card is rebuilt from the entity and its collapsed state is
passed in, so nothing is lost, and threading ids through kvRows to reach two cells would be more
machinery than an edit that happens on the blur of a number box can justify.

Two assertions in the new section were answered by markup they were not about, and both are worth
recording because the sabotage pass is what found them. "The card reads the date" passed with the Born
row deleted, because the date is also inside the age box's tooltip — it now reads the row itself rather
than searching the card. And the row-order check had to be written against the rendered card rather
than the source, since the source order of a kvRows literal is not evidence about what is drawn.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The Print button at the foot of the character-sheet dialog lays the whole character out as one
page and opens the print dialog, but nothing in the Field Guide said it was there. The guide never
described the dialog either, apart from a parenthetical "click for the full sheet" in the sidebar
table. A note under Your character now covers both: the sidebar portrait opens the sheet over the
story, its seven tabs, and the Print button, including that the printed sheet lists unticked marks
("not painted") and what to do when a pop-up blocker swallows the window. The Last Update stamp
moves with it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Two questions closed and a third that turned out to be underneath both.

The first: what stops the Game Master naming two different results the same. The engine RENAMES rather
than refusing -- the newcomer takes the next free ordinal off its own base name, so a second Fine Short
Sword becomes a Fine Short Sword (2) and a player can tell them apart in a list, which is the half
naming discipline could never guarantee. Three details carry the weight. The base name is a field on
the item rather than a parse of the displayed one, because a partial's ordinal can be recovered by
regex only since "(partial)" is a shape the engine wrote itself: a finished craft is named by the model
and can end in anything, and a Blade of the Third House would parse as a Blade of the Third numbered
House, the disambiguator eating the name it exists to preserve. The increment fires on DIFFERENCE and
not on collision, or the rule breaks the case it was never meant to touch -- two fine short swords off
one recipe are one item and must go on stacking, or somebody making twenty arrows gets twenty entries.
And a made thing does not merge with a bought one of the same name either, since the forged sword has
its own description and its own picture and a merge would throw one of the two away. Completion needs
the test in two places, because a finished craft is a rename in place that never passes through
acquireItem at all, and the recipe has to be written onto the item before the test or it compares
against a thing that does not yet know what it is.

The second: a player may name a thing they made. A blade somebody spent a week on wants to be called
Widowmaker, and its popup carries a field for it -- on finished crafts only, since a partial is not a
thing yet and a bought item is catalogued and shared by name, so a pet name there would spread to every
one of its kind. Two things may deliberately end up sharing a name, and that is allowed rather than
tolerated: identity had already stopped being the label, so a made thing is identified by its recipe
and a named one never stacks with anything. The engine also never renames one back to keep them apart,
which would be taking back the very choice the ordinal exists to serve.

Which ends the assumption the whole pack rested on. Every item instance is now minted with a uid,
exactly as an entity is, and backfilled on load for every save written before it existed -- each
getting its own rather than a shared fallback, since a constant would make every item in that save
answer to one lookup.

The equipped slot is where this was already broken, and silently. equippedItemById looks an id up in
the catalogue and falls back to a name, and a crafted item is deliberately uncatalogued, so what the
slot held for it was its name: a rename left it pointing at nothing, the sword still drawn in the pack,
still apparently worn, quietly paying out no armour and no abilities, with nothing on any screen saying
why. The gesture always knew which object was picked up -- a drag is about one instance and there is no
ambiguity at the drop -- and that knowledge was thrown away one line later by narrowing it to a name.
The drag carries the uid now, the slot stores it, and the name lookup stays last for the GM's own
equipItem directive, which speaks names because it speaks fiction. A made thing resolves to its
instance even when a catalogue entry shares its name, or a shop's sword goes into the slot while the
player's own sits unworn and everything on screen looks right. That last one was found only because an
earlier test section had catalogued a bought sword of the same name -- a collision a tidier test would
never have produced.

Three neighbouring assertions moved rather than being worked around. Two pinned the drag and the slot
by their old shapes. The third counts writers to player.equippedItems and asserts there are exactly
two, on the stated reasoning that a third would be the thing to worry about -- it was right to fire,
and the rename's repoint is now the third with its reason recorded: it puts nothing on the body, it
rewrites the pointer for a piece already worn, and asking whether a thing the character is wearing may
be worn is not a question. A fourth is still the thing to worry about.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The printed sheet named a torn tunic only by its damaged name in the Inventory list, which carries
the short label and nothing else. It now has a Damaged gear heading under Marks, one line per
damaged piece: its name, whether it is worn (and in which slot) or in the pack, and what the damage
looks like. Nothing is printed when nothing is damaged, and a clean namesake is not listed.

The rows come from damagedGearRows, lifted out of the dialog's Damaged gear group so the dialog and
the sheet read one list and cannot disagree about what is damaged or where it is.
Tests/test_worn_damage.js asserts the heading, its absence, the clean namesake left out and the
description printed, each checked against its sabotage.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

The dialog's Inventory tab already showed a torn tunic by its damaged name, but the name carries
only the short label. What the damage looks like, and whether the piece is on the character or in
the pack, lived only in the item's popup, one click per item. The Profile tab now draws a Damaged
gear group under Marks, since together they are how the character looks right now, which is what
that tab is a glance at. Each row gives the piece's name, what the damage looks like, and "worn ·
Clothing" or "in the pack", with a closing line saying it is cosmetic and can be mended.

The name opens the item's popup through openInventoryCardItem, the opener the item cards use, so
the popup lands in the dialog's own host rather than behind the overlay (charsheetPopupHost). The
group is drawn only when something is damaged. Tests/test_worn_damage.js asserts the group, that a
clean namesake is not counted, its absence with nothing damaged, the worn/pack placement, and the
clickable name, each checked against its sabotage.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Two systems shipped recently (Designs/battle-scars.html, Designs/crafting.html) and had
already reached the Field Guide and the Dungeon Master's Guide, but the Player's Handbook
was never part of that pass -- it said nothing about Marks, worn damage or Crafting at all,
not even a stale placeholder. A player reading it would not know their Character sheet can
grow a Marks section, that a torn tunic is a real mechanic with a Damage field and a mend
command, or that Crafting exists as a skill family and a Character tab of its own.

Chapter Five gains a Marks paragraph and adds Crafting to the Character tab's subtab list
(it was missing there even before these two systems, matching guide.html's nine-subtab
rundown). Chapter Seven gains a callout on worn damage, cross-referenced from Marks since
a scar and a torn garment are explained by the same fight. Chapter Nine gains a Crafting
section covering the skill gate, the five specialty skills, sitting-based work, unfinished
items, and the Unfinished/Methods split on Character > Crafting -- wording and terminology
(Marks, worn damage, a sitting, Unfinished, Methods, the skill names and their governing
attributes) matched to what guide.html and the Dungeon Master's Guide already say, per
CLAUDE.md's rule against hand-copying a roster and to keep the three books consistent.

The Modder's Guide was checked against the same two systems and needs no change -- neither
touches the sidebar block conventions or the event bus that guide is scoped to.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JYoTHWgvg86FB7FmAawSkL

BUG-098, proved and then fixed. The probe written into the entry was run and cost no GM turns, since a
logout flushes a verified save by itself: a character created as a CantorAdept and logged out, then
created again under the same name in the same world as a Bladeward, left ONE key holding the Bladeward.
The first run was gone. The probe saves were deleted afterwards and every real save in the library
checked present.

The notice sits beneath the character name field, which is the part that matters rather than an
incidental detail of layout. That is where the collision is created and where the player is already
looking, so it arrives while the decision is still free; a confirmation at Begin interrupts somebody who
has already committed and is the kind of prompt people learn to click through. It is driven by all
three inputs that can create the collision - the name, the World picker and the New Game tick - because
a name that was innocent a moment ago stops being innocent when the world changes under it.

Two grades from one element, so they cannot contradict each other on screen. With New Game ticked it
warns that beginning replaces the save and that it cannot be recovered, and names the two ways out.
Without it, the same collision is informational: Continue will open it. It alerts and never refuses,
because replacing a run you are finished with is a legitimate thing to want and the defect was only
ever that it happened without being said.

Sixteen assertions and six sabotages, each caught: the warning downgraded to a note, the world dropped
from the match, either picker unwired, the unrecoverability dropped from the wording, and name matching
made exact so a typed space defeats it. Placement is asserted too, after the name and before Begin.

One sibling test needed repairing and was pinning the wrong thing. test_login_world_select asserted
onchange="onNewGameWorldChange()" as the WHOLE attribute, so appending a second call broke it on code
that still does exactly what it asserts. It now asks membership. That is the same failure this repo has
hit several times: an assertion that pins a literal rather than the property it cares about eventually
fails on a true statement.

Left fixed-unverified: proven by test, not yet seen on screen by a person. The underlying design is
unchanged - a second run of the same name is still not a second save, which is the larger change the
leaning describes.

App suite 936/938, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The Marks block with its include checkboxes was drawn on Character > Profile only, so the dialog,
which is where a player glances at the whole character, showed their Ailments and said nothing of a
face with three claw scars across it. Its Profile tab now draws the same block, from the same
parts, under Ailments, with nothing drawn for a character who has no marks.

That put the checkbox in two places, and a box ticked in one would have gone on showing the old
state in the other. togglePlayerMark now redraws the panel, and the dialog when it is open. Both are
redrawn rather than only "the other one", since the renderers are cheap and tracking which surface
was clicked would be one more thing to get wrong. Tests/test_battle_scars.js asserts the dialog's
block, its absence with no marks, and the redraw, each checked against its sabotage.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Phase 5: the recipe a successful craft leaves behind, and a place for a player to see both it and the
work they have not finished.

The notebook lives on the PLAYER, keyed by target and grade. On the character rather than the world
because a discovered method is knowledge somebody earned, not a fact about the realm -- put it on the
world and a smith's hard-won method walks into another character's hands because they happen to share
a map, and a published world ships whoever's notebook was on the bench at export. So the three-place
serializeWorld rule deliberately does not apply here, which is worth saying because a reader who knows
that rule will go hunting for the allowlist line. The rule that does apply is its player-side twin, an
explicit backfill in restoreGame beside reagentStock, because the restore rehydrates with reInstance
and never runs the constructor.

Keyed by grade as well as target so aiming higher stores a second method beside the first rather than
overwriting it: a rough way and a fine way for the same blade, which is what a real craftsman's
notebook looks like. The record carries the inputs with their counts, the skill, the DC, the hours,
the stages, and enough of the finished item to rebuild it -- the composed name and the taxonomy with
the partial label already off -- because a record storing only "iron + wood makes a sword" is a note
about something that happened rather than a recipe, and the difference does not show until somebody
tries to re-run one.

A re-run is still a sitting per turn. The design said the engine runs a stored craft the way
brewConcoction runs a concoction, which is atomic, and taken literally that would make the second
forty-hour sword a single turn because it is the second -- quietly undoing the sitting model that the
previous phase exists to establish. The hours are the design. What re-use saves is the model call, and
that was always the stated point: the player who made this blade makes the same blade again rather
than whatever the model invents this evening. So a stored method starts an ordinary project through
the same directive path a typed request takes, and is worked exactly like the first one.

Character > Crafting holds both halves, in the Inventory tab's own shape because they are the two
halves of the one question the tab is asked: what am I in the middle of, and what do I know how to
make again. Unfinished lists the projects in the pack with a stage bar and a Work on it button;
Methods lists the notebook with Make it. Both address their subject by name rather than by index, for
the reason every list in this file does -- the pack changes under a panel that is already drawn, and
an index into yesterday's list resumes somebody else's sword. A method that cannot be worked says on
its own card what is short and disables its button, because a control that exists to be refused is the
defect this codebase keeps rediscovering. The bar reports stages attempted rather than cleared, since
half-credit advancing it would report luck as progress.

Adding the backfill broke a neighbouring assertion, and the fix is the more interesting half. Two
tests slice the restore to a fixed byte budget, and one more line above the fields they check pushed
those fields out of the window -- so the assertion failed over a backfill that was still perfectly
well there. Both now slice to an end anchor instead, with a guard that fails by name if the anchor
itself ever moves, so the next person to add a player field does not have to know this happened.

The Field Guide's crafting note is rewritten from "designed, not built" to what a player can now
actually do, and the Dungeon Master's Guide from "nothing of crafting is built yet" to the five phases
that are. Both stamps refreshed.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Worn damage put the label into the item's name ("Brown Tunic, torn at the front") and kept the
fuller description for the painter, so the player could see that something was wrong but never
what it looked like, or that it cost nothing. The item popup now carries a Damage field beside
Condition: each label with its description, and a closing line saying the damage is cosmetic,
shows in portraits, and can be mended by a tailor or smith.

It appears only on a damaged instance. A clean namesake and the catalogue entry carry no wear
field at all, so their popups are unchanged, and Tests/test_worn_damage.js asserts both halves.
Each was checked against its sabotage (the field removed, and the field drawn on every item).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

The retrospective flag hunts turns that were judged sufficient, paid nothing AND said nothing. It was
checking only the first two, so a turn whose nearMiss had fired seconds earlier was still reported as
"paid nothing and told nothing" - twice in the 25 September run, once on the Gasping Spire and once on
the Warding Charm, both of them rule 13e working exactly as intended. A diagnostic that accuses the fix
of the bug it just prevented is one nobody reads by the third run.

It now suppresses when a nearMiss fired for the SAME subject in the turns it scans, matched on a
normalised name because the Game Master names subjects as it pleases - that same run recorded "The
Chancel of Forgotten Names" for a room the world calls "Chancel of Forgotten Names". A nudge for a
different subject does not excuse the flag, or an unrelated hook being nudged in the same stretch of
turns would hide a genuine silent withholding.

This also answers the harder over-report for free, which is the part worth keeping. A condition made of
several parts spreads its credit across turns legitimately, and the flag cannot read the condition to
know that - it fired on "climb out of the cathedral", a required step of the Flooded Transept's
four-part condition rather than an ignored one. But under 13e as it now reads, each finished part owes
a nudge, so a legitimately-spread condition has nudged turns behind it and falls silent here. What
survives is precisely the case that matters: credit split across a turn nobody was told about.

Three sabotages, three distinct catches: the suppression removed, the suppression widened to any nudge
at all, and the leading-"The" normalisation dropped.

App suite 932/934, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The // console gained five commands with battle scars and worn damage (scar, unscar, tear, mend),
and the only place that listed them was the in-game help. A DM reading either guide for how to stage
a scarred character or a torn tunic found nothing, and would have had to wait for the GM to narrate
one, which is rare by design.

The Field Guide's // table gets a row and a note covering the grammar: the closed region list and
the synonyms it accepts, the one-worn-piece rule for tearing, and that both are cosmetic only. Its
character-sheet list also describes the new Marks section, since a player who sees a checkbox
appear under Appearance deserves a sentence saying what unticking it does and does not do. The
DM's Guide adds both commands to its debug console block with a short staging note, and lists
them in its pointer to the full command family. Both "Last Update" stamps move.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Phase 4 of the crafting design: assembly. Dismantling shipped first because its subject was an item
and therefore had a key to hang a rule on; assembly's subject was a sentence the player typed, and
everything here follows from giving it a key of its own.

A `craft` directive starts a project or resumes one. The engine owns everything after: it checks the
materials are really in the pack and refuses with a list naming what is short, spends them at the
start because the leather really is cut, puts a half-made item in the pack in their place, works one
sitting of about eight hours per turn, rolls each stage against the graded DC, and finishes the piece
when its stages are done -- naming it from the grade actually reached rather than the grade asked for.
Crafting remains the only gate; a family craft rolls at zero proficiency when untrained and is worse,
never refused, which is the rule the whole system turns on and the one most likely to be helpfully
undone by someone reading the original brief.

The partial is an ordinary item and that is the whole of the bookkeeping. It carries the `partial`
subtype additively, so it is a weapon, a sword and a partial at once; it is `minor`, so it never
reaches the catalogue, the Compendium, or the ingredient roster the model is shown; it cannot be
equipped, refused in a sentence a player can read; and it carries a project block complete enough that
an authored one, with no conversation behind it, still knows what it is becoming. Completion takes the
label off the same object rather than replacing it, so everything the thing accreted survives. Two
projects never merge: the allocator numbers a new one, and acquireItem refuses to stack a partial at
all, which is what catches the ones the allocator cannot see.

Each sitting rewrites the description and clears `image` and `prompt` with it. That is not tidiness.
The portrait path returns early when an image is set and authors a prompt only when there is none, so
keeping either means the blade-without-a-hilt picture outlives the hilt -- and a kept prompt repaints
the old state faithfully, having been written against the old description. The description is also
what the picture is painted from, so the model is handed a true statement of how far along the work is
and writes the rest. A made thing no longer shares its look with its namesakes either: five sites
pushed a painted image out to every live copy by name, which is right for a torch and wrong for an
object whose appearance is a fact about itself.

Two things the building found, both recorded rather than smoothed over. The "+8 maximum" on the rush
penalty is unreachable by construction: it needs four twenty-five percent steps, four steps needs
skipping every hour of the job, and a job given no hours is not a job. The true ceiling is +6, which
is already past the point where any modifier matters -- the exact objection the design raised against
a steeper penalty. The bound stays written as a bound so the next reader can check it instead of
re-deriving it. And the value-producing roll is not rollDie(), which is the on-screen announcement and
returns undefined; that line had been copied from the concoction brew, where it was live and is fixed
separately.

The test builds a world for each claim and then tries to break the implementation twenty ways, each
break caught by a distinct assertion naming the failure. Four of those sabotages found real gaps while
it was being written -- the half-stage credit, the rush penalty reaching the roll, the picture
clearing, and a captured ITEM_CATALOG reference that went stale when a world was installed and made
one assertion pass against an empty husk.

Designs/crafting.html reaches Rev. 15, with the playtesting section grown the half it could not have:
steps for staging a craft, watching a sitting, and turning the dial, written against the code rather
than the doc -- including where the console cannot help, since there is no local verb that grants an
item and the one that looks like it falls through to the model.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

brewConcoction took its d20 from `rollDie(20)`. That function looks like a die and is not one: it is
the player-facing announcement, printing the dice line, flashing the result overlay and offering the
value to a fight that happens to be waiting on one. It returns undefined.

So `total` was NaN, `margin` was NaN, and concoctionGradeFor returns null for a non-finite margin --
whose branch is "the working fails, and the reagents with it". Every brew a player performed spoiled,
every time, and took the reagents down with it. The whole concoction system was unusable in play: not
degraded, not unlucky, but incapable of succeeding.

What makes this worth a long comment rather than a short fix is why the suite was green through all
of it. Every assertion in test_concoction_brewing.js and test_concoction_brew_action.js hands
brewConcoction an explicit `roll`, which is the right way to test the arithmetic and the grading, and
it walks straight past the line that was broken. playerBrewConcoction -- the Brew button, and the only
production caller there is -- passes `{ scale }` and no roll at all. The one path nobody covered was
the only path anybody uses, so the tests proved the parts of the working that were never in doubt.

The regression assertion therefore goes through playerBrewConcoction rather than through
brewConcoction with the roll withheld. The point is not that the arithmetic works when handed a
number; it is that the button a person presses gets one. A test that reaches past the production
caller is the test that already passed. It brews forty times and asserts that at least one succeeded,
which fails flat against the old code and cannot pass by luck against the new.

Found while building crafting's assembly phase, which had copied this exact line -- so the same defect
was one commit away from shipping twice.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Merges claude/focused-heisenberg-h3blh6: the design (Designs/battle-scars.html), phase 1 (a GM-given
scar kept on the character, painted into the portrait and body render, with an include checkbox) and
phase 2 (damage to the one worn piece, split from its namesakes and renamed, with mending). Both are
cosmetic only, by the owner's decision.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Phase 2 of Designs/battle-scars.html, on the owner's rule: "If the player has another brown tunic
in their backpack, that tunic is not torn - regardless of it having the same name. It is a
different instance of it - not the catalog copy." The engine had no instance to mark. A slot stores
a catalogue id, equippedItemById answers with the catalogue entry first, and two identical tunics
are one pack entry with quantity 2, so writing damage anywhere reached either every tunic in the
pack or every tunic in the world.

So damage splits one copy off the stack, gives it a wear list, derives its name from that list
("Brown Tunic, torn at the front") and re-points the slot at the name. The rename is what gives the
worn piece an identity, and it costs nothing downstream: a slot holding a name with no catalogue
entry falls through to findItemByName, which searches the pack first, and acquireItem can no
longer fold a clean tunic into the torn one. The name is re-derived on every change, never
appended, and past two labels it says "badly damaged". A true instance id was considered and
deferred, since it would teach three dozen name lookups to choose between two entries of one name.

The GM sets "wearItem" with the piece's name exactly as its WEARING list shows it, a short label
that goes into the name, and a fuller description for the painter. Rev. 1 of the doc addressed it by
slot key, but the dossier only ever shows the model slot labels, so the build takes the name (and
still accepts a slot). Only a worn piece can be damaged; the pack and storage slots are refused.
"mendItem" mends one label or all of it, worn or carried, and a fully mended piece takes back its
plain name, rejoins the clean stack and has its slot pointed at the catalogue id again. Two pieces
torn the same way merge, as Decision F leaned. Everything is cosmetic only, by the owner's
decision: no condition, no Armor Class, no stat.

The pictures get the damage as an amendment rather than a replacement. The torn copy inherits the
clean one's image, and the body render tells the painter to use each item's picture as its true
appearance, so both the piece's line and its reference caption now say it is pictured undamaged
and must be painted with the damage. A sixth portrait augmenter carries damage to the head,
clothing and armour slots into the head portrait. The GM's live equipment line shows the damage
beside the new name, and reItemObj keeps the wear through a restore.

Building it found a real bug in the first draft. A piece's onEquipped effects are tagged by its
name, and a stack of one is renamed in place, so a second tear looked for the old effects under
the new name, found none and stranded them for good. The re-point now takes a snapshot of the
identity from before the rename. Tests/test_worn_damage.js pins that and every other property,
checked against eighteen separate sabotages, each caught by the assertion naming it. The phase 1
test's chain regexes now accept the added augmenter. The design doc records the build, settles
Decisions D, F, G and J, and adds worn-damage playtesting steps and notes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Confirming run for the partial-satisfaction wording. The Warding Charm's condition is "wear it into the
Hush-Choir Gallery and speak your own name aloud there", so walking in wearing it finishes one part of
two. The hook stayed locked, correctly, and the player was told: "You have done the thing itself. What
it means is still sitting there, unsaid." Speaking the name a turn later unlocked it, and the
retrospective flag then credited turn 46 at 38 per cent - the Game Master counting the earlier turn
exactly as it had done silently the day before on the toy boat and the Ys trade. Same judgement, now
with the nudge attached.

The regression really was self-inflicted, which is worth keeping in the entry rather than quietly
fixing. The header line added to make the single-act case work stated only the literal trigger, and for
a condition with two parts that test reads false after one of them, so stating it where the model
decides made the strict reading win.

What this does not establish is also recorded. One partial case rather than two: the boat cannot be
re-tested because Claude21 has already recovered it and the Ys hook is already unlocked. And the
single-act class was not re-confirmed after this change, because the spire is unlocked on this
character and a single-act condition cannot be made to withhold on demand - doing it simply pays out.
So the claim is that the regressed shape works again, not that all three do. A fresh character settles
both at once.

The detector's known over-report appeared on cue: turn 47's flag says "paid nothing and told nothing"
of a turn that had just been nudged, because the nearMiss-suppression is still outstanding.

App suite 932/934, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The accumulation run gained the case rule 13e was failing and lost the case it was passing, and the
likeliest cause is the line added to make it gain. The Lore Hooks header stated the literal trigger -
"if your narration says the player did what a LOCKED condition describes" - right where the model
decides. For a condition with two parts that test reads FALSE after one of them, so stating it at the
point of decision plausibly made the strict reading win, taking the single-act spire case and
suppressing the partial ones that used to fire.

The evidence for the regression is one directly comparable pair. Recovering the child's toy boat from
the submerged root without showing it to Mira produced a nudge on 8 September and this ledger recorded
it as correct play; the same hook, the same half-action, produced nothing on 25 September. The Ys case
is NOT the matching pair it first looked like - 27 August's positive was a quest beat, An Accounting
for the Deep, and yesterday's was the Tide-Cult Shrine room hook, so that is a new failure of the
shape rather than a lost win. Base rate before the fix was two of six, not two of three; by class it
is partial hooks 2/2 then 0/2, and single-act articulation hooks 0/4 then 1/1.

So both places now say parts count, and say it with the boat as the worked example because that is
the case with evidence on both sides. 13e also names the reasoning it is overruling, since it is a
reasonable reading rather than a careless one: half a condition genuinely is not the condition, which
is correct about the UNLOCK and wrong about the NUDGE. Withholding the payout is right; withholding
the hint is the silent toll arriving one part early, and the player who prises the boat out of the
root has no way to learn the other half exists.

The test pins both wordings and pins them together, because a restatement that says more than the
rule it restates is how the two begin to disagree while the model reads both.

Unproven, and the confirming run is cheap this time because the shapes to hit are known: Claude21
still carries a Cantor's Hook and a Warding Charm whose conditions are two-part, so partial
satisfaction is testable without a new character.

App suite 932/934, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Phase 1 of Designs/battle-scars.html. When the GM's narration leaves a wound that would heal into
something visible, it sets a new "bodyMark" field, and the engine keeps the mark on player.marks: a
list beside the appearance rather than a sentence inside it, because the appearance is the player's
own writing and the appearance action replaces that field wholesale, which would erase every scar in
one click. The GM decides that a wound left a mark; the engine refuses any region outside a closed
list (plain synonyms such as "cheek" are mapped, nothing is guessed), refuses a restated duplicate,
and stamps the record. Marks are cosmetic only, by the owner's decision, and the directive says so.

The region decides the picture. A fifth portrait augmenter adds the ticked head-and-shoulders marks
to the head portrait and to Gallery variations; the full-body render lists every ticked mark, with
the rule that one under gear stays under it. Both pictures carry at most the newest three, since
small details drop out of a long prompt and a patchwork face is what a generous GM would produce.
Left and right are stated as the character's own with the viewer's side beside them, because a
portrait faces its viewer.

The body render needed one more change for any of this to show: it attaches the current portrait
captioned "reproduce this face exactly" and closes with "keep the face the same as the reference",
and that portrait was painted before the scar. Given an exact face and a sentence, the picture wins,
so the caption and the closing line both name the exception whenever a mark is on the head.

Each mark has the include checkbox the owner asked for, under Appearance on Character > Profile.
An unticked mark leaves both pictures but stays in the GM's live dossier, again by the owner's
decision: the checkbox is about the picture, and the scar still happened. The dossier line is in
live because the list can differ between two consecutive turns. The printable sheet lists every
mark, and "// scar" / "// unscar" let a DM stage or correct one without waiting for a bear.

Tests/test_battle_scars.js asserts each property through the real code paths, including a save
written before the field restoring through restoreGameState, and was run against fifteen separate
sabotages of the implementation; each failed the assertion that names it. The design doc now
records the settled decisions and carries a Playtesting section with steps and notes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Rev. 14 takes up what the ordinal does not reach. It keeps two projects apart while they are
unfinished and does nothing afterwards: when the partial label falls off, both land on the target's
name, and two finished short swords -- one finely worked and engraved, one plainly good -- are both
called Short Sword.

The picture breaks first, and it needs no merge to do it. eachItemCopyNamed sweeps the catalogue,
every room's floor items and the pack, matching on the lowercased name, so the two blades share one
portrait from the moment both exist and whichever was painted last wins everywhere. The merge arrives
later: completion is an in-place mutation and stacks nothing, but the first time either sword
re-enters the pack -- dropped and picked up, stored in a chest, traded -- acquireItem collapses them
into one entry with one description and one picture, the other sword simply gone.

The house rule answers the merge and is not open to negotiation, being the one the concoction system
was built around: what varies per instance goes in the NAME, or the merge eats it, which is why a
brewed thing is a "Potent Knitbone Salve" rather than a salve carrying a potency field. Crafting is
well placed to obey it because the two biggest variables are engine outputs rather than the model's
whim -- the grade is computed from stages cleared, and an engraving is a stage bought or not bought
-- so the output name is composed rather than invented. It is worth saying plainly that most crafts
SHOULD merge: two fine short swords off one recipe are the same item, and the instinct to suppress
stacking on meeting a merge bug would be wrong here. The defect is never the stack, it is a stack of
two things that differ.

What sharpened the rest was a case the composed name cannot catch: two swords of identical grade and
identical stages, one hilted with strips of black leather and the other, months later, with red. Both
compose to Fine Short Sword and they look nothing alike. The merge half needs nothing new, because
the inputs are stored with the recipe -- a recipe worth re-running has to know what it consumed -- so
a stacking key of recipe and grade separates them automatically, without anything having to notice
that leather is a visible material.

The picture is a separate failure with a separate fix, and naming discipline is a poor defence for
it, since two entries that never stack still share a portrait. Nor is it one call to guard: five
sites push a freshly painted image or its prompt out through applyItemTypeField, each commented as
sharing with the type and live copies. For a torch that is right and is why it is painted once. For a
made object it is simply wrong, because an appearance is a fact about that object rather than about
its type. So the fix belongs at the share and not at the name: one predicate, answering false for
anything crafted or partial, consulted at those five sites, after which the red-hilted sword keeps its
red hilt whatever it happens to be called.

That demotes the material term in a name to what it should always have been -- a courtesy to the
player so they can tell two swords apart in a list, rather than a load-bearing part of correctness. A
rule that rests on a judgement is far better placed where a miss costs a duller name than where it
costs a sword. One question is reopened and recorded with its leaning: what stops the Game Master
naming two different results identically, with the general "never stack two things that differ"
rejected, because acquireItem is a hot path far older than this design and changing how the whole game
stacks for one system's sake is the shape this doc already warns against.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

BUG-059's accumulation run. Claude21, a fresh level-1 Cantor-Adept on Opus 5.5 with the near-miss
field note and the Lore-Hooks header line both live, 43 turns, twelve room hooks attempted, ten
unlocked. The Gasping Spire's lower chamber was held back and the player was told - "You have done the
thing itself. What it means is still sitting there, unsaid." That hook had failed three times across
two models and this is the first time it has ever produced the line, followed a turn later by the
articulation paying it out. Judged, held, hinted, acted on, paid.

What the rest of the run is worth saying plainly: eight of the twelve hooks paid out on the bare act,
so rule 13e was never engaged on them. 5.5 rarely creates the situation the rule governs, which means
withholdings are scarce and a clean sheet proves much less than it appears to. The entry's bar of
several hooks held back with a nudge on every one cannot be reached by simply playing harder.

Two hooks were withheld without a nudge, and both are half of a two-part condition - the toy boat
recovered without being shown to Mira, and a fair trade offered to Ys without the question that
completes it. At the time each looked merely ambiguous. Completing the Ys hook settled it in the same
proof form as the original reproductions: the unlock's reason credited the trade turn at 31 per cent,
so that turn did count toward the hook, was credited at payout, and had been paid nothing and told
nothing at the time. By the 8 September precedent, where recovering that same boat without showing
Mira produced a nudge this ledger recorded as correct, one was owed. By rule 13e's literal wording,
"satisfied the letter of a locked hook's condition", half a condition did not satisfy it. The rule
does not say which, and that is the most useful thing the run found: some of what looks like a model
failing a clear rule may be a model reading an unclear one.

A nudge also fired where the rule forbids one. Turn 16 unlocked the Chancel of Forgotten Names and
turn 19, the bare command "go up", fired a near miss naming it. Rule 13e says not for a hook already
unlocked. So of two firings, one is the fix working on the case that never worked and one is spurious.

The repaired detector earned its place and showed its limits together. It caught the split-credit
shape three times that the old one would have missed, and one of those is what converted the Ys case
from a guess into evidence. But it fires on any multi-part condition where credit is legitimately
spread, and it does not check whether a near miss already fired for that subject, so it can report
"paid nothing and told nothing" of a turn that had just been nudged. Both are over-reports and the
flag needs reading rather than counting until the suppression is added.

App suite 934/936, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Rev. 13 settles the last open question in the crafting design: what distinguishes two half-made
swords. It is an ordinal in the name -- "Short Sword (partial)", then "Short Sword (partial 2)" --
assigned once when a project begins and never changed afterwards. The common case, one project,
stays clean, and a number appears only when there is something to tell apart. It is a little meta,
and that is the right trade: the player has to be able to tell which half-made sword is which, and
every alternative to putting it in the name either hides the distinction somewhere the pack list does
not show or invents machinery to carry it. Never changing is the property Rev. 12 asked for, since a
name that churned each sitting would churn the picture with it.

The part worth writing down is that it takes two enforcement points, doing different jobs. An
allocator picking the lowest free ordinal at the start of a craft keeps two of the player's own
projects apart, and -- because applyItemTypeField shares an image with every live copy of the same
name -- that is the whole of what gives each project its own picture. But an allocator can only
number what it can see, and the previous revision made a whole class of partials it cannot: an
authored one, whose name a DM or the model chose. A player already carrying a project picks up a
smith's abandoned "Short Sword (partial)" and the two merge into one entry with a quantity of two and
one progress, the other project simply gone, with nothing anywhere reporting it.

So the second point is acquireItem, which refuses to stack when either side carries the partial
subtype and takes the next free ordinal instead. That guard is cheap because the chokepoint is real
and the file already states it two lines below the merge: there is one way in and five ways out. It
is also the only site in the file that merges by name at all -- the two other inventory pushes are
unconditional (a generated spellbook, and the put-back when a container refuses a move), so neither
can merge anything and neither needs touching.

Two consequences are accepted rather than engineered around. The guard renames an incoming item after
the Game Master has narrated it, so a sentence about taking up the unfinished sword can be followed
by a pack entry reading "(partial 2)" -- a cosmetic mismatch against silent data loss, which is not a
close call. And ordinals recycle rather than counting monotonically, so finishing project 2 frees the
2: a per-save counter would need a new player field and therefore its own restoreGame backfill line,
and would eventually hand somebody a "(partial 47)" to justify the trouble.

Nothing in this design is open now. What is left is building phase 4.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

A proposal for marks that last: a scar the Game Master gives the character, and damage to the one
garment being worn, both carried on the record and painted into the portrait and the full-body
render. Nothing is built. Two decisions came from the owner and are recorded as settled: every scar
has an include checkbox on the sheet, and a tear belongs to the specific tunic being worn, never to
every item sharing its name or to the catalogue entry.

Scars are a player.marks list beside the appearance rather than a sentence appended to it, because
the appearance is the player's own writing and the GM's appearance action replaces it wholesale, so
one click would erase every scar ever given. The GM decides whether a wound leaves a mark, on the
inflictAilment pattern; the engine owns a closed region list, which is what routes a mark to the
head portrait or only to the body render.

The garment half needed a probe, because the engine has no notion of the tunic being worn: a slot
stores a catalogue id, equippedItemById prefers ITEM_CATALOG, and identical items are one counted
entry. Splitting one copy off the stack and deriving its name from a wear list turns out to give it
an identity for free: run against the real engine, every existing lookup resolved the worn slot to
that instance, the catalogue did not grow, and a later pickup merged into the clean stack. A true
instance id was considered and deferred, since it would teach roughly three dozen name lookups to
choose between two entries of one name.

The doc also names the failure both halves share: the old portrait and the item's own picture are
attached to the body render as exact references, and they will overrule the new text unless the
captions say otherwise.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VMURnCdid38DWFwWwL2mqk

Rev. 12 of the crafting design settles what the world knows about a project and what the player sees
of it. A partial must not appear in the Compendium: that collection records what the WORLD contains,
and a half-made sword is one save's project rather than a fact about the realm, so every one of them
in there stands between the player and the things the collection is for.

The flag for exactly that has been in the engine all along under a neighbouring justification.
`minor` is documented as "a real, interactable item ... deliberately NOT catalogued or added to the
Compendium -- utensils, plates, props ... too unimportant to the world to warrant a shared type". A
project fits it inversely, being too PARTICULAR to be a shared type rather than too trivial, and the
flag does not care which way round the reason runs. One field then settles three separate problems:
the Compendium entry; Rev. 11's finding that an inline item is catalogued under a slug of its name,
so progress in the name would mint a permanent entry per stage of every project anybody starts; and
the sharpest of the outward reconciliations, since allIngredients filters ITEM_CATALOG and feeds
ingredientRosterLines, so an item that never joins the catalogue cannot reach the model as an
ingredient. It costs nothing in persistence -- reItemObj names the uncatalogued case explicitly --
and the two known costs of minor, instance-fallback lore pricing and skipped re-cataloguing on
identification, both apply to properties a project does not have. Had either bitten, the answer was
to accept the clutter and let partials in; neither does, so the cheap shape and the clean one are the
same shape.

The visible half is a marker in the name, a field in the popup, and a picture painted from the Game
Master's own description of the last sitting. The marker is stable across a project's life rather
than a counter that churns every sitting, because with the catalogue cost gone the counter's only
remaining job -- saying how far along the work is -- belongs to the popup field, which does it in
prose and has room for a sentence. The picture needs nothing built: itemImagePromptDirective already
composes its context from name, type, condition and description, and ensureItemPortraitForPopup takes
the item OBJECT rather than a catalogue id, so an uncatalogued partial paints exactly as anything
else does. A blade finished with no hilt yet looks like one because that is what the narration said.

The trap in that chain is silent and is written down before anyone meets it. Both entry points bail
when a result already exists -- the portrait path opens by returning if an image is set, and a prompt
is authored only when absent -- so a sitting that advances the work must clear image AND prompt with
the description it rewrites. Clearing one is not enough: a kept prompt was written against the old
description and would repaint the previous state faithfully. That same corner sharpens the one open
decision rather than closing it. applyItemTypeField writes through eachItemCopyNamed, sharing image
and prompt with every live copy of the same name, so two projects called "Short Sword (partial)"
would share one picture even if nothing ever merged them -- which defeats the picture-follows-the-work
rule outright. So the name must carry a per-project discriminator, and it must be stable per project
rather than per sitting; what that discriminator should be is what remains open.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Rev. 11 of the crafting design writes down the property every part of the partial-item shape has
been resting on without ever stating it. A subtype is additive rather than exclusive: the half-made
blade is a weapon, a sword and a partial simultaneously, three claims that are all true at once and
all separately readable. That is what lets a system arriving this late stack a label onto the
taxonomy and operate on it without renegotiating with anything already reading "sword". It was
checked rather than assumed, because it is precisely the sort of thing that could quietly not be
true: every consumer in the file is a membership test, normalizeClassList preserves order while
privileging no position, and nothing anywhere reads subtypes[0] as "the" subtype. One reader is
order-sensitive and is named so the next person does not have to find it -- consumeVerbFor takes the
first subtype matching a consume verb, which decides Eat against Drink among those labels only, and
"partial" is not one it can reach.

The other half is completion, and it settles as removal rather than replacement. The finished sword
is the same object with one label retracted, not a new item granted beside a consumed one. That is
cheaper and also truer: the item keeps its identity straight through the work, so a DM's authored
lore, the origin and the description the sittings have been accreting all survive, where a
replace-on-completion would have to carry each forward by hand and would silently lose whatever it
forgot. The mutation is safe on the held instance because Item's constructor runs normalizeClassList
over whatever it is handed, so every instance owns its own array and cannot write through to the
catalogue entry it came from.

Checking that turned up a finding that argues against the open decision's own leaning, and it is
recorded next to the leaning rather than buried. An inline item is registered into ITEM_CATALOG under
a slug of its NAME, additively, and the Compendium reads that catalogue -- so putting progress in the
name, which is the obvious answer to two projects merging under acquireItem's name-stacking, would
mint one permanent catalogue entry per stage of every project anybody ever starts. It does not
overturn the item shape, which wins on four counts against this one, but whatever finally answers that
decision has to answer this too.

The section closes on the limit of the property, which is the part easiest to over-read. Additivity
is a guarantee about the STORAGE and promises nothing about the RULES. A system adding a label owes
the reconciliation in both directions, and the outward direction has a list: the paper doll must
refuse to equip a partial, consumeVerbFor would offer Drink on a half-made potion through a button
that spends a turn, and allIngredients filters the catalogue by subtype and feeds both the recipe
picker and ingredientRosterLines -- so a half-prepared thing would not merely clutter a dropdown, it
would reach the model as a real ingredient in the prompt. A system whose subtypes nothing else reads
owes nothing to anybody, so the rule is that the set is enumerated rather than assumed empty; the
failure when it is not is silent, everything storing correctly while one rule quietly answers about
the wrong object. And "the system is responsible" is deliberately not "the engine is responsible":
which half carries a given reconciliation is its own design question, answered both ways in this doc
already, and reaching for the engine by reflex is how a system ends up doing more work than the
design asked of it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Two changes toward BUG-059, and neither is proven by them - they are what makes the next run worth
running.

The retrospective flag was blind to the shape it exists for. It was written for a reason that credits
an earlier turn INSTEAD of this one and demanded here < 0.2 to prove it, which assumes the Game Master
forgets to mention the turn that finally paid the hook out. It does not: the articulation is what
triggers the unlock, so the reason names both. Measured on the 22 September reproduction rather than
reasoned about, that reason scored 0.273 against the descent turn and 0.273 against the articulation
turn - identical - so all three clauses failed and the instrument reported a clean turn on the exact
case it was built to catch. Two clean unlocks from the same session scored 0.000 against every earlier
turn, because a reason genuinely about this turn shares no content words with what came before. That
gap, 0.273 against 0.000, is where the new split threshold sits; it is a margin rather than a tuned
number, and the test asserts it with those exact strings because a threshold justified by invented
examples is justified by nothing.

The second change follows the owner's suggestion that the rule and the data it governs are too far
apart, which turned out to be structurally true and worse than impressionistic. Rule 13e sits in the
cached stable rulebook at the front; the locked hooks arrive in the per-turn dossier appended AFTER up
to forty messages of transcript, so they are the last thing read before the model answers. Every other
dossier section points back to its own rule - Item Lore to 13b, Lore Hooks to 13d, Folklore to 13f,
History to 13g, Factions to 13c - and nothing anywhere pointed to 13e, the rule for what is owed when
one of those listed hooks is declined. The header now states the trigger where the hooks are. It goes
in live rather than by moving 13e, because moving per-turn-invariant text out of the cached half is
what costs 2x on every call.

They are deliberately bundled. Both are the same intervention - make 13e visible where the decision
happens - so isolating them would be a fiction; if the combination works it does not matter which half
did it, and if it fails both are excluded.

One assertion had to be rewritten after a sabotage disproved it. SOLE is mathematically subsumed by
SPLIT, so removing it broke nothing and the assertion claiming it caught cases passed against a build
with it disabled. SOLE earns its place by choosing the wording, not by detecting anything, and the
test now pins that instead.

App suite 932/934, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Every revision of the crafting design up to here settled the arithmetic of the dial and left the clock
as a phrase: "the hours are real, the world moves". That is not an implementation, and checked against
the engine it is not even true — timeSkipHours does gameClockEpochGameMs += hours and fires nothing, so
under an atomic reading a forty-hour craft would change a number and nothing would happen. Worse, the
atomic reading contradicted the design's own fatigue argument, which speaks of fatigue biting "within a
sitting" and resetting "across nights" — sittings and nights that a single-turn craft does not have. The
sentence was describing a structure the design had never specified.

So a craft is worked a SITTING at a time, one per turn, a sitting being a work period of roughly eight
hours that buys however many stages fit in it. Nobody works forty hours; a design that resolves a long
craft in one message is not modelling a craftsman. The Game Master narrates what the period produced and
the work stops there unfinished, and the player may press on into another period or sleep and resume in
the morning. Pressing on is allowed and punished by machinery already wired: a second period is past
tired's -1 DEX and -1 INT, which is Crafting itself and two of its three DEX families, and a third
reaches fatigued at -2 across the board. Some late stages simply fail, narrated as hands that will not
steady rather than a die that came up short, and the environment is the Game Master's to weigh — the
same second period is a different proposition at a forge and in a cave in the rain.

The half-done thing lives in the pack as an item carrying a `partial` subtype, rather than in a hidden
craftInProgress field on the character, and that is the better answer for four reasons rather than
because it is cheaper. It is visible, so a project is something the player can see and go back to
instead of something they have to remember starting. It needs no new save machinery, riding reItemObj
into reInstance exactly as dismantleTryDay already does, where a new player field would need its own
backfill line in restoreGame and that trap has been sprung here more than once. It cannot be equipped or
used, refused through the { ok: false, refusal } path equipItemIntoSlot already has for class-restricted
gear — built on the principle that a refusal nobody can read is the same defect as no refusal. And the
inputs are consumed at the START, because the leather really is cut, so a project cannot be sold off for
its components halfway through.

Best of all it fixes the asymmetry §1 is built on. Dismantling was built first because its subject was
an object and therefore had something to hang a rule on, where assembly's subject was a sentence the
player typed. The partial item turns assembly's subject into an object too, so resuming, interrupting
and abandoning all become questions about a thing rather than about a conversation.

Three engine facts were checked before any of this was written down rather than after. resolveItemKinds
normalises subtypes through normalizeClassList, which trims and drops empties and has no allowlist, so a
`partial` subtype survives the migration that rebuilds every item's taxonomy — the normalizer that would
otherwise have eaten it silently. equipItemIntoSlot already returns a readable refusal and applies it
before anything moves. And item-taxonomy.html is generated from a measurement of authored worlds rather
than a fixed list of legal subtypes, so nothing needs registering for a new one to exist.

One decision is left open and it is this codebase's oldest trap in a new hat: acquireItem stacks pack
entries by name alone, so two unfinished shortswords would merge into one entry with one progress. The
leaning is to put the progress in the NAME, which is the only thing that survives a merge and is also
the completion status the design already wants shown — an "Unfinished Shortsword (3 of 7)" cannot
collide with a "(5 of 7)". What that leaves is two projects at the same stage, and whether that wants a
further guard or is rare enough to accept is not yet decided.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Re-ran Tools/gen-progress-report.js against the current git log: 4280 commits
across 88 active days, up from 4258 across 87. September's page and the index
both move to reflect the 22 commits and one new active day since the last
refresh.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WqPrXHTm7x3QDMkh4LdrTA

Phase 3 of the crafting design, and the first act of crafting a player can actually perform. A
"dismantle" directive names the subject, the craft the job wants and what the thing was made of;
everything from there is the engine's. It checks the item is really in the pack, allows one attempt per
item per in-world day and spends it on any outcome, rolls the check and prints the manifest, and on a
pass removes the item and grants the materials while a failure leaves it alone.

It is the half built first because it is the half with a KEY. The subject is an item that already
exists, so a once-a-day rule has something to hang on; assembly is a sentence the player typed and gets
charged in hours instead. dismantleTryDay is the same mechanic identifyTryDay and diagnoseTryDay already
use, on the same day index, and it rides on the item, which comes back through reInstance — checked
rather than assumed.

Three rules the design spent its longest arguments on are enforced here rather than asked for. The pack
is checked, which is the grounding principle in the one place it is a lookup rather than a judgement,
and the check lives on the craft path rather than on consumeItem, whose call sites predate crafting and
would then also have to be right about eating a pie. Magical yields are stripped rather than obeyed,
because magic is not a material a hammer can work. And Crafting is the only gate: a character with
Crafting and no Metalwork takes the sword apart at no proficiency rather than being refused, which is
the rule the whole system turns on, proved through the engine instead of stated at it. Reintroducing
"you need Metalwork to touch iron" is the likeliest future regression, since it is what the original
brief said, and the test asserts against it by name.

Nothing degrades. The design says a dismantled thing yields materials a rung below what it was, and that
rung does not exist — the condition ladder is parked, item.condition is still free text nothing branches
on, and half a ladder built to serve one caller is how a scale ends up walkable in only one direction,
which repair could then never use. The omission is written into the code so it reads as a decision.

Two findings are worth the commit message because neither announces itself. applyItemSpec returns
{ id, name, kind, warnings } and NOT the item, so the first draft's res.item was always undefined and
every yield silently granted nothing: a sword vanishing into an empty pair of hands with no error
anywhere. It was caught by checking the function's return rather than assuming it, and the test now
names it in its failure message. And because acquireItem stacks pack entries by name, two identical
swords share one entry and therefore one cooldown — measured, not reasoned about, and left alone,
because per-unit tracking would need the item identity acquireItem exists to prevent.

The test's own first draft was worse than the bug. It forced outcomes with DC 1 and DC 30, and
checkOutcome answers on the ROLL before the total: a natural 1 fails at DC 1 and a natural 20 is a
critical at DC 30, so each assertion was 5% flaky. It passed six times standalone and failed inside the
suite, which is the worst shape a test can take, because the next person re-runs it and moves on. It now
forces the die instead of the difficulty, and the suite was run three times end to end to confirm.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Phase 1 of the crafting design: crafting at tier 1 on INT, and metalwork (STR), leatherworking,
woodworking, tailoring and engraving (DEX) at tier 2 behind it. Data only — nothing in the engine reads
them — and shipping them first is the point, because phase 2 already handed the Game Master the whole
skill catalogue. From today it can tell a player the iron wants a hand they have not trained and name it
correctly, where before it would have had to invent the name and send them after a skill their world
never had.

The rule that changed is the one the original request opened with. That brief said iron REQUIRES
Ironworking and leather REQUIRES Leatherworking; it does not. Crafting alone lets a character attempt
anything, and the five crafts are investment rather than permission — the Game Master may set the bar
high, or too high for them today, but never refuses for want of a craft. Those two are not in tension:
a DC beyond the modifier is still a DC, a critical still clears two stages, and the door is never
actually shut. What that buys is a tier-2 layer that is a BUILD rather than a checklist — an armourer
takes Metalwork and Engraving and makes gear worth wearing and worth looking at, a thief takes
Leatherworking and Tailoring for grips, straps and a cloak that hangs right — and it turns what the doc
recorded as a gap into the mechanic, since applySkillChecks already rolls an untrained check at zero
proficiency rather than refusing it. The only thing that would break it is a hardGate on one of these
rows, and the test asserts against that by name.

The roster grew and changed shape twice. Four of the five are FAMILIES that each absorb several
materials — metal and glass to the forge, hide and fur and sinew, wood with bone and horn and stone,
cloth with thread and cord — because a skill per material is a tree nobody can afford to buy into and a
point-buy nobody will spend on. Engraving is the fifth and is deliberately not a material: it is a kind
of work, the fine decorative pass over a piece already made, applied on a finished thing whatever it is
made of, so in the stage model it ADDS a stage rather than replacing one. The earlier revision had that
slot as a catch-all bin for leftover materials, which is a worse skill than a craft; the leftovers went
to the families that actually work them. And cloth left Leatherworking for a Tailoring of its own,
because a needle through linen and an awl through hide are different trades with different tools.

The concoction roster's briefing line was re-read in the same change, as the design said it would have
to be. It called concoction "the crafting skill", which was unambiguous only while no skill was named
crafting; it now says recipes roll against the concoction skill and that this is NOT the mundane
crafting skill, which is a different trade. That broke an assertion in test_concoction_editor_tab, and
the assertion deserved to break: it sliced from the phrase "crafting skill" and tested the 200
characters after it, pinning a sentence rather than the thing the sentence is about, so a necessary
rewording sent indexOf to -1 and failed a check whose behaviour was untouched. It now anchors on
recipeSkill(null) — the very resolver the directive interpolates from — and asserts the id, the display
name and the governing attribute all reach the briefing, plus that the line disclaims the mundane craft
by name.

Tests/test_crafting_skills.js pins the tree, the gate rule proved through the engine rather than read
off the records, that no craft names a class so any build can take any of them, and that each reaches
the GM with a description distinct enough to be recommended from — two crafts that read alike are two
the GM will confuse. All seven sabotages against it are caught by a distinct named assertion.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Rather than wait for a sighting, the original pairing was reassembled by hand: two tabs, two worlds,
no reload anywhere in it. Tab one live as Claude20 in The Salt Cantos of Verengrad standing in the
Chancel; tab two switched to Malina the Mage in The Lost Realms, which is the same character in the
same other world as the run this entry was filed about. Tab one was pinned before and compared after,
twice - once when tab two loaded Malina, and again when tab two saved explicitly, a logout being a
verified flush that fires the cross-window ping.

Both times the world held, the player held, the room still belonged to its own world, no tripwire
fired and the audit did not move. The part worth recording is that the ping was received and simply
not obeyed: tab one set _sessionSuperseded and declined to save over the slot another window had
taken. A window that had quietly ignored the message would look the same from outside and would be a
different and worse thing, so the latch engaging is the positive evidence rather than the silence
alone. Two ordinary character switches through the login screen, also without reload, came back clean
on both instruments.

It does not close, and the reason is a single stale save. This entry closes on both instruments being
silent and the login audit is not: Test2 stands in northern_road, a room its snapshot's world does not
contain. That is the durable artefact this entry already says the guard does not explain rather than a
new sighting, Test2 is a test character, the save is not loadable as it stands, and saves carry no
timestamp so it cannot be dated. So the remaining question is a decision and not an investigation -
delete that save and let the audit fall silent honestly, or keep it as a sample of the artefact. It is
written into the entry rather than acted on, because clearing the last obstacle to closing a bug is
not something to do as a side effect of tidying up.

App suite 930/932, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

BUG-098, filed. Found by nearly doing it: while verifying BUG-097 the login screen had to be switched
off Claude20, and a ctrl+a meant for the name field selected the whole page instead, leaving the field
reading Claude20 with New Game already ticked and the button one click away. A screenshot caught it.
Nobody making the same slip in ordinary play has a screenshot to check, which is the finding.

The evidence is four links and none of them is inference. savedGameKey builds the key from character
and world and nothing else, with no slot or counter. mirrorSaveToLibrary's own comment says replaying
the same character in the same world updates that one entry rather than piling up duplicates. The
write is objectStore.put with an explicit key, which replaces by contract. And startGame carries no
collision guard in four hundred lines. The library demonstrates the key shape unaided: it holds two
Test2 saves whose only difference is the world.

The sharp end is the message. At the moment of the decision the login screen says the saved game is
untouched, which is true while it is displayed and false shortly afterwards, because the first
autosave - or simply logging out, which flushes unconditionally - lands on the same key. A
reassurance standing in front of a data-loss path is worse than no reassurance, since it answers the
question the careful player was about to ask.

Not reproduced by experiment on purpose: the only honest test destroys a save, and spending one of
the owner's to demonstrate what the code already states is the wrong trade. The probe is written into
the entry for whoever takes the fix, and it costs no GM turns because logout flushes a save by
itself.

The leaning records the owner's reading, that a second run of the same name should be a second save,
along with what that costs - the composite key is load-bearing and carries its own paragraph on why
the separator is a NUL, and both the load menu and the disk button would have to show rows differing
in nothing a player can see but a date. The cheap half comes first and is not a stopgap: warn before
beginning. The owner has specified where that warning goes, and the placement is the part worth
keeping - an alert beneath the character name field, fired when the typed name collides with an
existing save for the selected world, reacting to both inputs rather than to what the screen was
populated with. That is where the collision is created and where the player is looking, so the notice
arrives while the decision is still cheap; a confirmation at Begin interrupts someone who has already
committed and is the kind of prompt people learn to click through. An alert rather than a refusal,
because replacing a finished run is legitimate - the point is that nobody does it unknowingly.

App suite 930/932, the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

BUG-097, verified in play. The unit test pins the contract; this is the path a person actually takes.
Claude20 was loaded, carrying a 181-turn capture baselined on Claude19. Logged out through the button
on the screen, New Game ticked, Claude21 created, one turn played. The navigation type stayed
"navigate" throughout, which is the whole point: no reload happened, so this exercised the in-page
path the defect lives on instead of a page load quietly masking it.

At logout the capture went from 181 turns to null, with shownConversationNpcs, crawlEpisodeSeq and
factionJournal cleared beside it, and the compendium came back SHAPED with all nine arrays rather than
as a bare object. That last one is worth the second look: it is the trap flagged when the reset was
written, and an empty object there would have left every reader of compendium.people throwing on the
first turn of every new game. Claude21 then recorded one turn baselined on itself, in memory and on
disk, while Claude20's save stayed untouched at 181 turns baselined on a Bladeward - deliberately not
repaired, since it is both the "before" evidence and the live example for the separate decision about
contaminated captures.

BUG-072 gets its census recorded in the same pass, since character switching is the operation every
sighting of it correlates with and this run did a lot of it. Four tripwire firings exist, all on 1-2
September, none since. Two of them fall about three hours AFTER the fix commit, which by this entry's
own rule keeps it open and resets any quiet window - but they are confounded and the entry now says so
plainly: the fix is a change to text_adventure.html, a tab open since before it landed would have gone
on running the old code until reloaded, and this app deliberately has no reload on logout. Nothing in
the record settles which it was and it should not be argued either way. Against that sit twenty-two
days of silence, including deliberate no-reload character switching on 22 and 24 September. The single
durable fault is Test2, a test character, and saves carry no timestamp so it cannot be dated; this
entry already says the guard stops new mixtures rather than explaining old ones.

Left at fixed-unverified rather than moved, because dating the window from the last firing and dating
it from the fix give opposite answers, and that is a judgement about evidence rather than a reading of
the instruments.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

BUG-097. Three functions decided the life of a session and each held a private, partial answer:
_restoreGameStateInner rebuilds one from a snapshot, startGame builds a fresh one, logout tears one
down. Nothing held them in agreement, and state fell through the seam between them.

The diagnosis in the entry needed correcting first, and the correction is the useful part. The
restore is not the culprit: it sets playthroughCapture from the snapshot and defaults it to null, so
loading a clean save was always safe. The hole is the NEW GAME path. Claude20 was created straight
after a Claude19 session and inherited his capture at birth, which is why the turn count came out at
166 rather than the 194 a same-session leak would have produced. The arithmetic settled it.

Measured rather than guessed, and the answer is smaller than the panic suggested. Of the sixteen
globals the restore reads out of the snapshot, logout already cleared six and startGame eight;
exactly three fell through both - shownConversationNpcs, playthroughCapture and crawlEpisodeSeq. That
is why a blanket location.reload() on logout was rejected rather than merely disliked. It would work,
since logout does not reload today and is an in-page teardown, but it costs a 5.8 MB re-parse on
every logout, would be the first location.reload() anywhere in this app, cuts off the onPlayerLogout
mod event mid-action, and does nothing at all for BUG-072, where another window adopts this one's
state through the save ping. Reloading this window cannot help that one.

resetSessionState() now holds the set and both doors call it: startGame before it builds the new
world and player, logout at the tail where six hand-picked assignments used to sit. The rule for
adding to it is what keeps it from decaying into a fourth private list - the snapshot IS the session,
so a global the restore reads out of snap belongs to a session and must be reset here. That is close
to a definition rather than a judgement call, which is what lets a test enforce it with no exclusion
list for anyone to quietly grow. Values are the declared initialisers; compendium is the trap, since
it declares nine arrays and a plausible empty object would leave every reader of compendium.people
throwing.

The test reads the restore, collects every global assigned from snap, and fails naming any the reset
does not clear, so a global added tomorrow is covered without anybody remembering this. Seven
sabotages, each caught by a distinguishing assertion, including the call MOVED below the world build
- which erases the new game instead of the old one while every presence check still passes. That
assertion had to be repaired before it was worth anything: its first version matched the comment
above the call site rather than the call, so the move-sabotage passed. Found by running the sabotage
rather than by reading the assertion.

Existing saves are not repaired by this and that is left as a separate decision. App suite 929/931,
the two failures being the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Two more landing-page files arrived with the room banners and left main red on
test_asset_provenance. Neither turned out to be what its filename suggests, which is the argument for
opening a file rather than reasoning about its name.

dungeon-sprites.png is not a sheet of sprites. It is a 1782x1171 SCREENSHOT of this game's own
sprite-sheet dialog: the title reads "Sprite sheet — Barrow Tallowling", and in frame are the sheet and
corridor panels, the eight cut cells with their handles, the engine's own measurement prose, the Even
cuts / Trim to the creature / Full height buttons, the frame strip and the Cancel / Save sheet row. So
it is filed as a mixed case in the shape the heraldry and language-book entries set: the capture, the
world, the creature and the framing are the owner's, and the artwork inside the panels is generated.

It also does something almost nothing else in this ledger does — it names its own generator. A PAINTED
BY control sits in the dialog reading "OpenAI", so the picture states in frame what drew the creature on
it. The entry records that as what it is: the app's own UI reporting the provider it used at the moment
of capture, which is evidence about the artwork rather than a signed assertion in the bytes, and a good
deal better than a reading of the style. The terms behind that provider are not read into the record,
for the same reason the Nano Banana entries give.

room-inn.gif joins the entry that already covers Images/Inn.png and the still, and its basis is
deliberately marked as weaker than the still's. Looked at, it is the same painted tavern in motion —
the hearth, the map on the table, the barkeep, the hooded figure — illustration throughout with no
chrome, so a generated picture and not a capture. What is not available is the proof the still had: a
GIF's frames are palette-quantised and this one is downscaled, so there is no pixel-identical hash to
run and it rests on looking. Its ezgif marker names an optimiser that touched the bytes, exactly as the
dungeon-catacombs.gif entry records, and its sibling room-inn.mp4 does carry a generated-media assertion
under signature — corroborating, not proving. The three files are one banner in three formats.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

main went red on test_asset_provenance when the animated room banners landed: room-inn.png had no
ledger line and its own C2PA manifest is a handling credential, so the tool correctly declined to reach
a verdict from the bytes.

It needed no judgement in the end. The file is byte-for-byte the same ARTWORK as Images/Inn.png, which
this ledger already covers as the owner's generated work: both decode to 3172x1344 and their
decompressed IDAT pixel streams hash identically. The container files differ by about 5.8 KB and
therefore have different whole-file hashes, and that difference is the added C2PA metadata and nothing
else. So the web copy joins the existing entry rather than getting one of its own, on the same footing
and for the same stated reason as Images/VillageSquareNight.png a few entries above it — which is the
precedent this ledger set for exactly this situation, one artwork living at two paths.

That is a stronger basis than most rows here have. It is not a reading of the style or an inference from
the commit it arrived in; it is a proof that two files contain the same picture, one of which the owner
has already accounted for. The entry says which, so a later reader can re-run the comparison rather than
take it on trust.

Its sibling room-inn.mp4 is deliberately not listed, and the entry says why, because the omission looks
like an oversight and is the opposite. That file carries a generated-media assertion in its own bytes,
so the tool reaches "AI — declared (C2PA)" without anybody's help — which is also why only the still was
reported. The check fails on the absence of a verdict and never on one it reached, and a hand-written
ledger line asserting what a file already says under signature would be a weaker claim wearing a
stronger one's clothes.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The Field Guide is not the DM's Guide and the difference decided the shape of this. Its sections are
what the in-game "/" help SEARCHES: extractGuideSections splits the page on h2/h3 and
selectRelevantGuideSections hands the best match back to the player in a popup. So anything written here
is an answer the game gives, and a full how-to for a system that does not exist would be served to a
player who then types it and gets nothing. The guide's own convention agrees: it documents what works,
and mentions an unbuilt edge in a clause where one would otherwise form a wrong expectation — the way it
notes that a Game-Master-invented language is not yet built. There is no "what it will be" section here
of the kind Castes has in the DM's Guide, and this change does not start one.

So crafting gets a short note in Skills that leads with the only sentence that matters to a player —
there is nothing to type yet — says asking will not work however it is phrased, and says plainly that it
is written down only so the answer to "can I?" is a straight no rather than a silence. What follows is
four lines of what it will be, in the second person and with no verbs to try: a Crafting skill and
material families behind it, saying what you want and roughly how long to spend, the time deciding how
fine the result is and how likely you are to ruin it reaching too far, and a thing made once being
makeable again. Verified against the real selector rather than assumed: three of four plainly-phrased
questions — "can I craft a sword", "crafting", "what skill would I need" — now reach that note; "how do
I make things" does not, being vague enough that the selector prefers another section, and nothing
anywhere returns crafting instructions.

The other two additions are behaviour that shipped. In Skills, beside the 5% floor note that already
explains what happens when an action maps to no skill you have learned, the guide now says the Game
Master is given the world's whole catalogue and can therefore tell you WHICH skill you would need — and
that every skill it names is one you can genuinely go and find a book or a mentor for. That last clause
is the player-facing half of why the catalogue was worth sending: before it, a named skill might have
been invented, and a player would go looking for something their world never had. And the dossier list
in the Game Master chapter gains the catalogue as an entry, since that list is a factual inventory of
the briefing and was missing one. It is described as what the world can teach, explicitly a different
list from the skills the player has, because the two being confused is exactly the error the prompt
section itself is written to prevent.

The Last Update stamp is moved, per the rule that a stale one claims a currency the page does not have.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Two additions to Player — Skills and one correction that was sitting in it.

The correction first, because it contradicted itself in its own sentence. The section said the built-in
catalogue "now runs three tiers, not two — Venomcraft and Apothecary sit at tier 2, built on Concoction,
itself tier 2, and a handful of skills reach tier 3", and then stated the rule that makes that
impossible: a tier is a rung a skill's prerequisites climb to, so a skill built atop a tier-2 skill
cannot itself be tier 2. Read off SKILL_CATALOG, Venomcraft and Apothecary are tier 3 and are the ONLY
two skills at that tier, both built on Concoction, which is tier 2 behind Herbalism. The sentence now
says that, and says it in a form a reader can check against the tab.

The first addition is behaviour that shipped and changes what an authored skill is worth. Until
recently only the skills a character had LEARNED reached the Game Master; the world's catalogue was
never sent, so the GM could not name a skill the player had not got and would either refuse in general
terms or invent a plausible name — and an invented name is a dead end the author did not write, which
the player goes looking for in their Skills panel and does not find. The whole catalogue now travels in
the cached half of the prompt with each skill's stat, DC, tier and, for a gated skill, what it wants
first by name. Two things follow for a DM and both are worth stating in a guide rather than a design
doc: anything authored in that tab is immediately nameable by the GM, so a vague description will be
recommended vaguely; and the catalogue is cached rather than per-turn, so it costs one write and not a
charge on every turn. The note beside it covers the one hard gate, because a Game Master telling a
Warrior they could earn magic the hard way has promised something the point-buy will never sell.

The second addition is crafting, and it takes the shape the guide already uses for a system that does
not exist yet — the Castes panel, which is drawn, states its intent and stores nothing. Crafting says
plainly that none of it is built, then covers what it will do: three acts rather than two now that
repair is in scope, GM-adjudicated rather than table-driven and why that is the opposite of Concoctions
on purpose, the grounding principle that a craft combines what already exists and never creates it, the
four rules the hours run under, stages carrying partial credit, and the recipe a successful craft leaves
behind. It ends where a DM can actually act today: author the skills. Crafting is tier 1 on INT with
tier-2 families behind it, that is an ordinary set of rows in this very tab, and since the GM now reads
the whole catalogue it can already tell a player the iron wants a hand they have not trained — and name
it correctly — before a line of engine code exists.

The four links added were checked against the document rather than guessed: the first three anchors
written were all wrong, and the real ids are run-usage, cul-tbd and ed-magic. Rendered in Chromium to
confirm both headings land inside ed-skills and that every internal anchor resolves; the two the page
reports are bare href="#" placeholders that predate this change. The Last Update stamp is moved, per
the rule that a stale one claims a currency the page does not have.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Thirty-six of the sixty-two documents under Designs/ define a dark `:root`, a light palette inside a
prefers-color-scheme block, and `:root[data-theme="dark"|"light"]` rules that outrank both on
specificity. That last pair is an override hook and nothing ever set it. A reader whose machine is in
light mode had no way to ask for the dark palette short of opening devtools and setting the attribute by
hand, and the hook had sat unused in every one of those files since the style block was first copied.

Tools/theme-toggle.js writes the control, on the same shape as Tools/content-notice.js: no arguments
lists what is missing, --fix writes it, --check exits 1 and is what the test runs. It is a tool rather
than a one-off migration for the reason this repository keeps relearning — the thirty-seventh document
would not have one, and nobody would notice until they went looking for a button that was never there.

The subject is the pages with a second palette to switch TO. The other twenty-six carry no
prefers-color-scheme rule at all and are hard-coded dark, so a button there would draw a control that
does nothing, and the test asserts they stay clean rather than merely that the others are done.
encyclopedia-prototype.html is skipped by name: it already has a toggle wired into its nav under its own
storage key, two toggles on one page is worse than one, and re-keying its storage would silently discard
a reader's saved preference. That leaves thirty-five.

Two placement decisions are load-bearing and both were found by working out how the tools interact
rather than by anything failing. The block must contain no `</div>`, because content-notice.js anchors
its insertion on the file's LAST `</div>` — its own header explains that `</body>` is not an anchor,
nine of these pages having none — and a `</div>` here would move that anchor and relocate the licence
notice in thirty-five files. And the control anchors immediately BEFORE the notice rather than on that
same last `</div>`: sharing the anchor makes the two tools ping-pong, content-notice putting its notice
after this block and this tool then re-inserting itself after the notice, so every alternating --fix
rewrites thirty-five files to swap two regions that were both already correct. Anchoring before the
notice makes each tool a no-op for the other, which was checked by running both twice over and
confirming the diff did not move.

The early script is separate from the control and sits before the page's own `<style>` so a saved choice
is applied before the first paint; read it late and a reader who chose dark on a light machine watches
the page flash white and correct itself on every navigation. Every localStorage access is wrapped,
because it throws rather than returning null in a private window, under blocked site data, and in a
file:// context on some browsers — and opening one of these straight off disk is the normal way they are
read. The styles ride in the generated block rather than being merged into each page's stylesheet: these
are thirty-five hand-written sheets that share a palette and nothing else, and every token used was
checked to be defined in all thirty-five before it was used.

One behaviour differs from the prototype's toggle deliberately. With no attribute set the label asks the
machine which palette is in force, and asks it the way this CSS is actually written — light applies only
under prefers-color-scheme: light, so anything else is dark. A routine that assumed dark whenever the
attribute is absent reads correctly on a dark machine and mislabels itself on every light one, which is
precisely the reader this was added for.

Verified in real Chromium over the DevTools protocol rather than by asserting markup, since the whole
risk is a script that does not run or runs and paints the wrong label: the button reaches the rendered
page, the script repaints the label away from its hard-coded default, pressing it sets the attribute AND
repaints the palette, the label flips, the choice reaches localStorage, and a reload restores both the
attribute and the painted background. Headless defaults to light, so that run exercised the
follow-the-machine path too. Tests/test_theme_toggle.js pins what is decidable in Node, and all ten
sabotages against it are caught by a distinct named assertion.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The last three open figures in the crafting design are settled, and they were derived rather than
chosen: the engine's checkOutcome ladder, skillProficiencyForLevel at level + 1 so +2 at Novice and +6
at Master, and skillAbilityMod across the stat range the shipped classes actually carry, run against a
set of statements about how the thing should feel to play. Rough is 2 stages needing 1 cleared at
baseDC - 5; good is 3 needing 2 at baseDC - 2; fine is 5 needing 4 at baseDC + 1; pristine is 7 needing
6 at baseDC + 4, with a critical clearing two stages. Every grade's stage count exceeds what it needs by
one, so the work carries a stage of slack before the player buys any, and since aiming at a grade
attempts only that grade's stages, nobody can exceed what they aimed at — the structure is the cap and
there is no cap rule to write.

Rev. 5 left the clock as two separate ideas, a rush penalty and a stage ceiling. They are one rule run
in both directions: short by 25% of the hours costs +2 DC on every stage to a maximum of +8, over by
25% buys +1 stage to a maximum of +2. The maximum IS the ceiling Rev. 5 asked for, and stating it beside
its opposite makes the whole clock a single sentence.

What it plays like is in the doc as a table, because a figure nobody can picture is a figure nobody can
argue with. A Novice makes a crude thing 91% of the time. An Adept reaching for fine is a coin-flip at
49% and gets to 79% by booking half as long again. A Master reaches pristine 52% unhurried, 80% given
the extra time. And a Novice reaching for a masterwork gets one twice in a hundred while coming away
with something in 85 — usually a good blade, rarely nothing — which is the entire case for partial
credit in one row, and the reason over-reaching is a gamble somebody will actually take.

The case that prompted all of this now resolves the way it was described rather than the way a rule
would casually produce. "A pristine short sword in 4 hours" against a forty-hour job is a 90% shortfall,
so +6 DC on all seven stages: a master gets the masterwork one time in twenty and usually produces a
decent blade instead. Allowed, attempted, most likely to fail at what was asked for.

Two formulations were tried and rejected, and both are recorded with their reasons because both are the
kind that look better on paper than they play. A flat DC across all grades is tidy and puts a Novice at
a 55% chance of botching the crudest item the system can make, which makes the bottom of the ladder —
where most crafting will happen — unusable. And a steeper rush penalty of +1 DC per 10% of time skipped
reads more precisely while breaking the mechanic: at a 90% shortfall the DC passes the point where any
modifier below a Master's matters at all, so Novice and Adept come out with identical odds, both
clearing stages only on natural 20s. A rush should be a gamble that skill improves, not a lottery skill
cannot touch; the +2-per-25% version keeps the spread at 70%, 32% and 5% failure across the three.

Nothing in this design is open now. Two things remain parked, both halves of the condition ladder, and
they are parked deliberately rather than unanswered.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Rev. 4 answered "does booking more hours than the job needs buy anything" with "yes, and it needs no
mechanism, because the cap is the top grade". That caps nothing. Against a grade wanting a fixed COUNT
of cleared stages, more stages at a lower DC each is strictly better — four-of-six beats four-of-four
and goes on beating it — so booking the longest useful time became the dominant play. That is the
single-setting dial Rev. 3's rising DC existed to prevent, put back by the revision meant to refine it,
and it was found by the owner's own earlier instinct being re-examined rather than by anything failing.

The squeeze behind it is kept visible in the doc because anyone revising this will meet it. A grade read
as a FRACTION of stages makes extra time worthless, since four checks at 55% and eight at 75% are the
same clean sweep. A grade read as a COUNT makes extra time priceless. Neither alone bends the curve the
way the design wants it bent, which is helps, then stops helping, then hurts — and only something that
makes LATER stages worse produces that shape. Which is exactly the endurance argument that prompted the
review: it is not merely compatible with the model, it is the only thing that gets the curve right.

So the count stays and two things bound it. An explicit ceiling on stages, the job's own count plus a
margin, which is one more number in the table the hours already come from. And fatigue, which costs
nothing to have because it is already wired: a craft advances the clock, FATIGUE_TIERS runs off the
clock at 18, 30 and 42 hours awake, and each tier's stat deltas reach a crafting roll through a chain
that exists end to end — an entry in player.status, summed by recomputeStatusMods into player.statusMod,
added by effectiveStat, read by skillAbilityMod, applied to every stage. It lands on the crafting stats
by luck rather than design: tired is -1 DEX and -1 INT, which is Crafting itself and the hide and wood
families, and fatigued reaches the metal craft too. It disciplines cramming rather than lingering —
twenty unbroken hours tells and three days with sleep between them does not — which is true to life and
is documented as correct rather than as a gap. Lingering is disciplined by the ceiling and by the days
that pass.

The result is four rules, and the section now opens with them because a player should be able to guess
every one: aim higher and it is harder and longer; rush it and you will probably botch it; take somewhat
longer and it goes somewhat better, up to a ceiling; work through the night and you get worse at it. The
complexity sits in an engine table rather than in anybody's head, which is the test a mechanic like this
has to pass.

Two further findings from the same review are recorded rather than built. The earlier framing that "more
time means more risk" was right about the OUTCOME and only wrong about the mechanism — ambition does
raise risk in the stage model, through the count of successes a grade demands rather than through the
per-check DC — and the doc no longer implies otherwise. And a less-skilled craftsman does NOT take longer
for the same result: it is a true observation about real craft whose payoff here would be perverse, since
under a count model the novice's extra hours would buy extra stages and help them. The intuition behind it
is already served by the outcome rather than the clock, because a novice attempting pristine faces the
same stages, clears fewer, and comes away with a good sword.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The report is regenerated from `git log`, and this container's checkout was shallow, so the
generator's history walk stopped short and the page silently understated the project's activity.
Unshallowing the checkout and re-running `Tools/gen-progress-report.js` brings September's page and
the index back in line with the full commit history.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QmaK9sJJthQtpxD9eGDa26

An operator unticked Public on the Worlds tab, went to their registry, and the realm was still there,
still pending review. The request had been made; the answer had been thrown away. Unticking writes the
decision on the vault first and then asks the registry to unlist the realm, and every way that second
half can fail — a keyed world waiting on its author's signature, a publisher token the registry no
longer recognises, a registry that is simply down — landed in a 22-character-wide note under a checkbox
that had already unticked itself. The vault then read "private", the listing stood, and nothing anywhere
would ever retry it: the heartbeat only touches worlds still marked public, and the ↗ button only
publishes.

So the withdrawal now asks before it sends and reports what came back. It asks because a withdrawal
destroys a listing and, on a registry that queues arrivals, the realm's place in the queue with it: a
realm re-published afterwards arrives pending again, behind everything that was already waiting. That is
worth one question, and it is asked in applyPublic rather than in the two handlers so that both controls
ask it and the signing press does not — an author who has already agreed and gone to find their key file
must not be asked a second time on the press that completes the very withdrawal they agreed to.

The report is a dialog rather than a note because the note is the thing that failed. Four outcomes, four
sentences, and the three that leave the listing standing say so in words: withdrawn, nothing-was-sent
from a vault with no registry configured, a keyed world whose author has not signed yet, and a flat
refusal. Only the first says the realm is no longer listed; a registry that never held it says the same,
because both are true of the listing now, which is the only thing being asked about. The note reddens on
a refusal too — it could not before, because redness was read off `problems`, which this path never
fills: a withdrawal deletes a listing, it does not validate a descriptor, so every refusal rendered in
the same grey as a success.

And a refused withdrawal now leaves a way to try again. The "Withdraw & try again" button that a DENIED
realm grows is the right control and was already there; what it could not see is this case, because
`pubState` reads the record the vault stored and the vault stored "not public" and answered honestly.
So the box unticks, the label goes back to Public, and nothing in the record says the listing is still
standing — the button disappeared on exactly the press that made it necessary, and the only retry left
was to tick Public, which re-publishes the realm, so that the box could be unticked again. It is drawn
from the registry's own answer as well as from the record now, and the flag is set before the redraw
that reads it rather than after, which is right once and then one press behind for ever.

The vault's own seam was correct and stays as it was: Server/test/test_registry_withdrawal.js drives a
real registry over a socket and shows a pending realm, an approved realm and a refused withdrawal each
behaving as they should, alongside the page's own applyPublic and reportWithdrawal run against fakes.
Fourteen sabotages each fail on a distinct assertion. test_admin_page.js's "a publish that reports
nothing-was-sent does not untick the box" now slices from the request rather than from the top of the
function, because the function no longer begins with one — the branch that puts the tick back when the
operator answers no is not the success path, and the old slice failed on a revert that is correct.

Server/README.md and the Vault Administrator's Guide describe the withdrawal, and the guide's
troubleshooting table gains the row this report would have been answered by.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Rev. 4 closes the last six open decisions in the crafting design, and one of them dissolved on contact
in a way that found a defect in Rev. 3.

Whether booking more hours than a job needs should buy anything was agreed as a small capped bonus.
Worked against the stage model it needs no mechanism at all: extra hours already buy extra stages, and
extra stages are already more chances to accumulate the successes a grade asks for. The cap turns out
to be the top grade rather than a number anybody writes down, since once enough stages are cleared for
pristine there is nothing above pristine to reach. That is the whole answer, and reaching it exposed
something Rev. 3 had wrong. Quality has to be a COUNT of stages cleared, not a fraction of them. If the
top grade meant clearing every stage, splitting the difficulty across more stages would buy nothing at
all — four checks at 55% each is a 9% clean sweep and eight at 75% is 10%, the familiar trap where more
rolls means more chances to fail. Counting successes inverts it, because four of six is far easier to
reach than four of four, and the whole argument for spending longer rests on that inversion.

The other five settled as led. The hours figure comes off an engine table with the model naming the
KIND of job rather than the number, which is the division applySkillChecks already draws by re-deriving
every modifier the model sends, and which exists because models are poor at wall-clock estimates — the
same weakness that sank a model-chosen duration as a flat cost two revisions ago. A total failure
wastes the week and, once the condition ladder can express it, leaves the materials a rung worse; the
interim is that the materials come back untouched, because an interim that is too gentle is recoverable
where one that is too harsh teaches players not to use the mechanic at all.

The recipe lives on the player rather than the world, and that decides which save trap applies in a way
worth stating explicitly: it is not a world-level map, so the three-place rule and serializeWorld's
allowlist have nothing to do with it and a reader who knows that rule will go looking for a line that
should not exist. What it needs is the player-side twin, a backfill line in restoreGame beside
reagentStock, because the restore rehydrates with reInstance and never runs the constructor. The engine
re-runs a stored craft with no model call, and that requirement is what fixes the record's shape — a
recipe the engine must run alone has to carry the inputs and counts, the skill each stage rolls, the
per-stage DCs, the hours, the grade reached and enough output spec to rebuild the item including the
description its picture came from. A record storing only "iron + wood + leather → sword" is a note
about something that happened, and the difference does not show until somebody re-runs one. Aiming
above the stored grade is a new craft rather than a re-run, so it goes back to the model and stores a
second recipe on success, which leaves a player with a rough method and a fine one for the same blade.

And the input check sits on the craft path rather than on consumeItem. That field is the engine's
general spend-this-object directive with call sites older than this design, and a refusal welded onto
it for crafting's sake would also have to be right about eating a pie. Crafting needs an apply path of
its own anyway, to roll the stages and assemble the output, and a system with its own path can enforce
its own rules without reaching into everybody else's.

One decision is left open and it is a table rather than an argument: how many cleared stages each grade
wants, and whether under-booking compresses the work into fewer harder checks or simply puts the grade
out of reach. Compression is the leaning, because "most likely to fail" is what was asked for and
impossible is not.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Claude Opus 5.5 landed in the per-turn model picker (MODEL_CHOICES) on 22 Sep, and the DM's Guide was
updated in the same commit — but the Field Guide and Player's Handbook each list that picker's models by
hand in prose, and neither is read by Tests/test_model_roster.js, so both kept naming only Sonnet 5,
Opus 5 and Opus 4.8. Both now name Opus 5.5 too, in the picker's actual display order.

The Character Creator also gained a Born date picker beside its Age box on 22 Sep (previously Age was
the only birthdate control available before play started; Born was sheet-only, DM-gated, reachable only
after the story began). Both guides described the older, Age-only Creator. Updated to say the Creator
now carries the same Age-and-Born pair the sheet does, including that typing an age in the picker moves
the calendar to the year it implies.

Field Guide's Last Update stamp moved to reflect these changes; the Player's Handbook carries no such
stamp and the Dungeon Master's Guide was already current.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LyAyZaNP226yr97GZTfGnw

node Tools/gen-progress-report.js re-read git history against a full, unshallowed
checkout and refreshed the index and the September month page with the commits that
had landed since the last regeneration. No other month changed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P8YpSBxCjS11LwChkZzN9u

Rev. 3 answers the nine open questions that were holding the crafting design at the sketch stage, and
three of the answers changed the shape of it rather than filling in a blank.

The economy brake is a rule instead of a number. Rev. 2 proposed a value ceiling on what a craft could
produce, which is a figure somebody has to tune forever and re-tune the first time a world ships with
different wealth. The principle replacing it is that a craft COMBINES what already exists and never
creates it: no conjuring a material to make the thing you want, no conjuring a thing by describing it.
The converse is what makes it generous rather than mean — if the materials are in the world and the
Game Master grants the attempt and sets the checks, the result is by definition a thing that can exist
here and only wanted the craftsmanship. Bounding the inputs needs no tuning, because the world's own
material stock is the budget, and it is the half the engine can actually enforce: "was this in the
pack?" is a lookup where "is this sword worth too much?" is a judgement a model can be talked out of.
Magic leaves scope by that same logic rather than by a special case, magic not being a material a
hammer can work; imbuing a finished object is a different act and wants its own design.

Time turned out to be the mechanic rather than a fee. Rev. 2 leaned toward the engine charging a flat
figure by kind of work, which would have made hours a cost; making them a choice makes them the most
interesting decision in the system. Ambition is the input and the hours are what it costs — stating it
the other way round inverts the mechanic and licenses the silly reading, that a craftsman who takes
their time is likelier to botch the work. The Game Master owns the estimate because it knows a sword is
not an hour's work; the player owns the ambition and may argue with the clock. Naming a target and a
time that does not fit it is allowed and likely to fail, and that gap is the whole point: a player out
of time may still chance it knowing what they are chancing. Naming only the target has the Game Master
allocate the hours, which is not the lazy branch but the other way to play — one is a player choosing,
the other is a player letting the game play out. Both are gameplay, so a craft with no time named is a
choice and not an omission, and the directive must not stop to ask.

The hardest part was connecting the checks, the DC and the hours, and the answer is stages. A long
craft is not one hard roll; it is several ordinary ones. The hours buy how many stages there are, the
ambition sets the total difficulty, and that difficulty spread across the stages is each check's DC —
one knob rather than two, and the rush stops being an arbitrary penalty and becomes the same work
compressed into fewer stages. It asks nothing new of the engine, skillChecks being an array the Game
Master already fills. Two things fall out of it. Quality becomes how far up the stages you got rather
than whether you passed, which answers what a failed twenty-hour attempt costs: it costs quality, so
the gamble is worth taking and the dial is worth turning. And the stages can be different skills —
blade, grip, haft — which is better than averaging them into one roll, because a smith strong at metal
and weak at hide comes away with a good blade in a poor grip, and that is a detail the description and
the generated picture can carry.

Two smaller decisions with long reaches. A DC the character cannot clear is a correct answer, stated as
a permission because scaling everything down to what the player can roll is what a model does by
default and is the likeliest way this system goes soft; nothing is lost by refusing that way, because
the gate opens as the character levels, which is a better retry rule than any cooldown. And a craft
that succeeds leaves its recipe behind in the save, re-runnable by the engine with no model call — which
quietly dissolves the opposition this doc's §2 is built on, since a stored craft has inputs, a skill, a
DC, a duration and an output, which is RECIPE_CATALOG's shape with reagents swapped for items. The
closed catalogue and the open system are not rivals; they are one pipeline, and the open half is how
the closed half gets its entries.

Repair comes into scope, which costs nothing today and constrains one thing that would be expensive to
undo later: the condition scale must be designed walkable in both directions, not as a one-way street
to serve dismantling. The ladder itself stays parked, and Rev. 3 sharpens what that means — only the
READING is parked, so the dial's quality ships as a write to a field that is free text and already
displayed in six places, and a pristine sword is for a while a better-looking sword rather than a
better-handling one.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Measured after adding it rather than assumed, and the measurement came back inconclusive, which is
worth recording precisely because the next session will otherwise repeat it. Four hooks were played
on Opus 5.5 after the note landed and none of them engaged rule 13e at all: the Game Master paid out
on the bare letter of the condition every time. The Chancel of Forgotten Names is the case to read,
being the same shape as the Gasping Spire - read every statue's base and realize none was ever carved.
The command was the reading alone with the realization deliberately withheld, and the Game Master
supplied the realization itself and paid the hook in the same breath. Nothing was held back, so there
was nothing to nudge.

That is the awkward shape of this defect: the fix cannot be demonstrated until the failure recurs, and
the failure is rare rather than absent - one withholding in five hooks on this model. The entry's
existing bar, a run that holds several hooks back and nudges on every one, is still the bar.

Two findings about the instrument came out of the same run and both bear on any future measurement.
The retrospective detector did not fire on the reproduction it exists for: the unlock's reason read
"timed her descent to the lowest draw on the previous turn, and now named aloud that the chamber
breathes on the bells", which names both turns, so the word-overlap test scores the current turn
highly and the earlier-turn signal is drowned out. A silent withholding followed by a two-clause
reason is the common case, and it is the case that slips through. And the capture those flags are
written into is not reliably the current character's, which is BUG-097.

Claude20 is left at level 2 in the Chancel with eight room hooks still locked, which is the instrument
for the next attempt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

BUG-059, reproduced a third time and on a second model. Opus 5.5 shipped on 22 September and the
obvious hypothesis was that a better model simply follows the rule; it does not. Tested with nothing
else changed, on a fresh level-1 character with all twelve room hooks locked, in the same room as the
other two reproductions and against the same condition. The narration said the player dropped into
the shaft while the flood-line was at its lowest, the response carried no loreUnlock and no nearMiss,
and the hook paid out a turn later with a why that credits the descent turn by name. That is rule
13e's trigger in the rule's own words, with the rule's own worked example live in the prompt.

Claude19 could not be used and that is worth recording, because the obvious next session will try.
All twelve of his room hooks are taken, and nine of his twelve remaining item hooks are unplaced, so
their hooks never enter the Item Lore dossier and a silent turn on one proves nothing. That is case
one of this entry, withdrawn on 24 August, waiting to be re-filed by anyone who does not check.

What 5.5 does differently is the opposite of what was expected and makes the finding sharper. Three
other hooks in the same session paid out on the bare letter of the condition with no articulation at
all, one of them saying "as the condition states" in its own why. So this is not a model reluctant to
pay out. It paid three hooks on the act and withheld the fourth in silence, which is what the
articulation pattern predicts: where the remaining work is the player saying what a thing means, the
Game Master does not experience itself as withholding, so a rule triggered by noticing that never
fires.

The remedy here is not more rulebook prose, which is now measurably spent. It is that nearMiss was
the only field of the forty-odd in the response contract with NO field note. Every other field is
explained where the model writes it; this one shipped pre-filled as null in a column of nineteen
nulls with its entire contract thousands of tokens away in the cached stable half. It now carries a
note in the same voice as its neighbours, stating the mandatory trigger, the two cases that leave it
null, and the fact that the cost of setting it wrongly is one quiet line while the cost of omitting
it is the whole hook.

BUG-097 is filed alongside, found while verifying this one: a new character inherits the previous
character's playthrough capture and saves it as its own. Six nearMiss flags appeared in a
seven-turn-old character's capture and would have read as the new model nudging six times had they
not been checked. Claude20's save on disk carries 173 turns baselined on Claude19, a different class.
The cause is one guard asking whether a capture object exists rather than whether it belongs to the
player in front of it, with nothing resetting the global on logout or New Game.

App suite 927/929; the two failures are the pre-existing Encyclopedias and static-denylist ones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Recorded yesterday as a defect to be scheduled; the owner has decided to leave them, and the reason
corrects the entry rather than merely closing it. Brave You Worlds <info@braveyouworlds.com> is the
owning company's identity, not the owner's personal one, which is Darren Govoni
<darren@visualagents.ai>. Those commits therefore credit the company that owns the repository rather
than asserting that a person wrote something a session wrote — which is what the previous wording
here claimed, and it was wrong in the direction that makes a problem sound worse than it is.

It is also very nearly the rule this repo deliberately adopted in 70fcf97e, "Sessions commit as the
company", before 204300a7 replaced it with the CLA allowlist. So the twenty-nine are not a falsehood
in the log; they are a superseded convention reappearing by accident. Against that, rewriting them
costs 971 commits rebuilt across twenty-odd branches and a force-push of a protected main that
concurrent sessions are working from, which is out of all proportion to the harm.

The rule itself is unchanged and the mechanism stays: pass the identity on the command. An accurate
author field is what 204300a7 chose and what cla.yml's own comment assumes when it says those commits
are authored Claude. Drifting back into the company identity by accident is still drift, and it costs
nothing to prevent at the point of commit — which is the whole point of naming the mechanism rather
than only the outcome.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

CLAUDE.md has said since 6 September that a session's commits are authored Claude
<noreply@anthropic.com>, and it turns out to have been describing an outcome without naming the
mechanism that produces it. The owner's ~/.gitconfig names Brave You Worlds
<info@braveyouworlds.com>, so a plain `git commit` in this checkout quietly authors as the owner.
Twenty-nine commits between 7 and 19 September went in that way, from several different sessions,
and nothing anywhere reported it: the commit succeeds, the push succeeds, CI is green, and the log
simply says a person wrote something a session wrote. That is the precise harm 204300a7 chose the
CLA allowlist to avoid, reintroduced one layer down.

The fix is a per-command override rather than repo-local config, and the reason is worth stating
where the rule is, because setting `git config user.name` in this repo is the obvious move and is
wrong: the owner commits from this same checkout, so it would misattribute their work in the
opposite direction — the same defect with a more sympathetic victim.

The twenty-nine are recorded rather than rewritten. They remain identifiable, which is what keeps
this bounded: every one carries a Co-Authored-By trailer and a session link, and filtering the
owner's authored commits by that trailer is how they were found in the first place. Rewriting them
would mean rebuilding 971 commits reachable across twenty-odd branches and force-pushing a protected
main that concurrent sessions are working from, which is a scheduled operation and somebody's
decision, not a tidy-up.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Added to the admin page's catalogue and the settings selector, as asked — which turned out to be nine
lists across two programs, because a model id is not a version that upgrades: GM_MODELS and
pickGmModel's preference walk in the vault, both pricing tables, MODEL_CHOICES, MODEL_LABELS,
WORLD_GEN_MODEL_IDS, the World Builder's static <select>, and MID_TURN_SYSTEM_MODELS.
Tests/test_model_roster.js already existed to catch exactly this and caught four of them, including two
in the DM's Guide, which it reads as part of the roster.

claude-opus-5-5 is the id, $4/$20 per MTok against Opus 5's $5/$25, same 1M context and tokenizer.

THE PRICING ROW IS THE ONE THAT WOULD HAVE HURT. 'claude-opus-5' is a PREFIX of 'claude-opus-5-5' and
rateFor resolves by longest prefix, so without its own row the newer, cheaper model bills at the older
one's rate. Measured rather than reasoned: with the row, $4/$20; with it deleted, $5/$25 — a silent 25%
over-report in a usage ledger, reading exactly like a real number. That is the trap the Fables carry a
note about, arriving for the second time and in the direction that over-charges.

It is on MID_TURN_SYSTEM_MODELS explicitly although the prefix arm of acceptsMidTurnSystem would have
admitted it anyway — "claude-opus-5-5".startsWith("claude-opus-5-") is true. So the entry changes no
behaviour; what it changes is that it is a decision. The model's migration guide says the
mid-conversation system message carries over from Opus 5, and that sentence is the reason, where the
prefix match would only have been a coincidence of naming. Worth recording: the quick-reference roster of
models accepting one does not list Opus 5.5 at all — the per-model section does, and the shorter list is
the stale one. Checked rather than inferred, which is what the comment on that list asks for.

Four things about Opus 5.5 would break a caller and none of them touches this engine: thinking cannot be
disabled, forced tool_choice any/tool returns a 400, thinking blocks are tied to the model, and computer
use moved to a toolset. This app sends no `thinking`, no `tool_choice` and no `output_config` at all, so
the request shape is already compatible. One behavioural difference does follow from that last absence
and is worth knowing: with no effort set, Opus 5.5 defaults to `medium` where Opus 5 defaults to `high`,
so the GM deliberates less per turn on it. Left alone rather than papered over with an effort parameter
nothing else in this file sets.

In pickGmModel's walk it sits SECOND rather than first. By that comment's own reasoning — the current
balanced Opus, and cheaper — it has the better claim to lead, but the walk is what a vault falls back to
when a client names nothing, and moving that onto a just-launched model is a change nobody asked for in
the request that added it. Second already fixes the failure the list exists to prevent: an admin
permitting only Opus 5.5 and a Fable now gets Opus 5.5 for gameplay rather than the slow
world-generation model.

Two sabotages then walked through the roster guard untouched — dropping the model from MODEL_CHOICES,
and from WORLD_GEN_MODEL_IDS — because the file asserts only that every client model is sanctioned, and
a shrinking menu makes that inequality more true, not less. Its own header names that failure first
("Missing from the client's menus → nobody can pick it") and nothing bound it. Now two rules do, written
as the split the two menus exist for rather than as a list of ids: every sanctioned model is a world-gen
choice, and every sanctioned non-Fable is also playable per turn.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Regenerated from git history right after merging in the commits that landed on main while this
branch's per-month split was being built, so the report doesn't ship a day stale relative to what
it is committed alongside.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017oJRXN9vSS4Gg7asRHxA7C

Ticking Public is a vault offering a realm; whether anybody can find it is the registry's answer to that
offer, and the two were drawn as one word. A world sat in an approval queue for as long as the queue
took while the box beside it read "Public" — a plain statement, to the one person in a position to act
on it, that players could already find a realm nobody could see. The box now reads Public, Pending or
Denied, and a refused realm has its controls dead with a Withdraw button in their place.

The registry had to start saying which. The publish response and every heartbeat now carry `listing` by
name. That reverses a deliberate silence, and the reversal is the interesting half: the word was
`pending` whatever the answer had been, on the reasoning that a registry telling a stranger it has
refused them invites the argument, and that nothing downstream acted on the difference. Both clauses
turned out to be wrong in the same place. Something downstream acts on it now, and the party being kept
in the dark was never a stranger — it is the publisher of that very record, standing at a control that
would otherwise read Pending for ever at a queue that answered weeks ago. Waiting on a decision already
made is a worse outcome than an argument about it. What is still withheld is the half that mattered:
nothing about a decision reaches a reader, because a realm the registry has not approved is refused at
the read route and absent from every browse, exactly as before.

Writing the assertion for that turned up the opposite leak and fixed it. `publicRecord` stripped
`publisher` by name and passed the rest of the record through whole, so every realm that had been
through the approval queue carried the queue's own paperwork to any browser that asked — which way it
went, when, the note the administrator typed, and since R15 the verified email address of the person who
decided it. None of that is a fact about a realm and the last of it is a fact about somebody who never
published anything. All six decision fields are stripped now; the admin queue builds its own object and
is unaffected.

The heartbeat is the carrier rather than the publish, and that follows from what a publish is: a realm
is answered while it is still pending, because being published is what puts it in the queue. A decision
made afterwards would reach a vault only on the next publish, which for a finished world is never — the
same argument R16 already makes for the minted clientId, in the same place. The daily round writes down
only what it is told, because a heartbeat to a registry too old to carry the field answers 200 with no
listing, and overwriting a good stored answer with silence would make the tab forget an approval once a
day, for ever. Silence is a fourth state and draws as Public: almost every vault has no registry
configured, sends nothing and is told nothing, and drawing Pending over a realm nobody has been asked
about would invent a queue that does not exist.

A refusal also has to be escapable, and disabling the box removed the only way out. Unticking Public is
what withdraws a realm, and withdrawing is what makes a second attempt possible at all — the registry's
DELETE removes the record, so a realm offered again afterwards is a request it has not seen rather than
the one it refused, where re-offering without withdrawing keeps the answer it was given. So the cell
grows a Withdraw button when the answer is denied, making the same request the checkbox makes, which
means a keyed world lands in the same signing flow it always did.

Two bugs were found by their own assertions while this was written. The handlers disable the box for the
length of a request and re-enabled it in a `finally` that wrote false, which would have undone the state
its own answer had just set — a refused realm coming back live at the one moment it must not. And the
whole state was drawn only when it changed, so a page opened on a world that was already refused showed
a dead checkbox and no way out of it until some unrelated press happened to redraw the row.

Server/test/test_world_registry_listing.js pins it and twenty-five sabotages were run against it, each
caught by a distinct named assertion. Designs/realm-registry.html R17 is the write-up.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

At 4,200+ commits the single generated page had reached 6.7MB and could only grow: every
commit ever made stayed on the page a browser had to load, forever. Tools/gen-progress-report.js
now writes Web/Reports/progress-report.html as a lightweight index (the same overall stats, plus
a card per month linking out) and one Web/Reports/progress-report-YYYY-MM.html per calendar month
that has commits, each with the day-by-day listing the old single page used to carry for its slice
of history, plus prev/next-month navigation and a link back to the index. The heaviest file today
(September) is under 2.5MB instead of 6.7MB, and next month starts a fresh page rather than adding
to this one.

Tools/content-notice.js's PAGES/GENERATED now discover every Web/Reports/*.html file by walking the
directory instead of naming progress-report.html once, since the report is no longer a single named
file — a fixed filename would have covered only the index and left every month page without its
Game Content notice enforced.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017oJRXN9vSS4Gg7asRHxA7C

The convention that arrived on 22 Sep asks a doc whose system is built to end with a PLAYTESTING
section in two halves — Steps, then the Notes that section always was. World History had the Notes
only, and I had just built in it twice, so it is owed one. Twenty-four steps across four groups,
following the shape Containers §10 and Abilities §14 set.

History is the HARD staging case, closer to Abilities than to Containers, and the callout says so
with two things that were measured rather than assumed. The built-in world contains zero
historical events and zero folklore, so until a playtester authors one every surface in the
section is correctly empty and a step that assumed otherwise would be unrunnable. And the `//`
console cannot author either half of the setup: its instant local roster has nothing for history,
and its free-form path classifies a line into room, being, plant, item or help and no further — so
with no key it is refused outright and with one it will build you a person rather than a war.
Pairing somebody with an event is editor-only for the same reason. What the console IS good for
here is `// list <name>`, which dumps a being's whole record including the new `history` array, so
it is the ground truth an expectation can be checked against.

A and B need no API key at all, which is worth leading with: the authoring tab, the dates at
partial precision, the pairing, the publication switch and both of the player's empty states are
all reachable without one. C and D are the table and do need one.

D is the group worth running first even though it is last, because it is the only thing here a
single turn can prove: one sentence — ask the gatekeeper what the siege cost him — is both an
account of a public event and the condition on a private secret, and both halves must land, with
the hook's XP paid. Either alone is the defect the `historyTold` split ended.

Writing it against the code rather than against the doc's own prose caught one error that would
have shipped. A first pass sent the playtester to Editor > Beings for an NPC's lore hook and a
probe said the card had no such control — which was the probe's fault, not the card's: it searched
a window around the first occurrence of "Lore" and landed on an ability called Local Lore, two
hundred characters above the real section. The card does carry it. Everything else in the section
was measured the same way: that the publish checkbox is disabled until the event has text, that a
yearless record is refused with the dialog still holding what was typed and the reason underneath,
that month index 5 is Suncrest in this world, that Reveal all disappears with DM mode, and the
exact wording of the two player-facing empty states. The doc had never nested to h4, so it gains
the same rule the two pattern docs added, and its computed style now matches Containers byte for
byte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The Character Creator had the Age box and not the Born row, so a character could be given an age before
the story started but not a date — the calendar was reachable only from the Profile, afterwards. It now
carries the same pair the sheet does, in the same order, and the picker itself gained the third control
the pair implies: an Age box inside the dialog.

That third copy earns its place rather than duplicating the first two. Somebody opening the birthdate
dialog arrives with either a date or a number in mind, and the dialog previously only answered the
first: a Dungeon Master who knows "she is seventy" had to count back seventy presses of the year arrow
to reach the page they wanted. Typing an age there now moves the view to the year it implies, keeping
the month and day, so the calendar lands where they were going instead of merely recording the answer
somewhere off screen.

Three controls showing one fact is exactly the arrangement that can drift, so every write goes through
one funnel. The character sheet is rebuilt wholesale and that covers its pair; the CREATOR is not, and
deliberately so — its fields are built once by openOriginDialog, and re-running that to pick up a
changed birthday would rebuild every control in the dialog, discarding a name or a background the
player is part-way through typing. So its two controls are updated in place. A caller that updated half
of them would leave the creator reading 25 beside a birthdate that says 41, while a player is looking
at both and deciding, which is the two-copies-disagreeing failure this design exists to avoid arriving
in the one screen where it would be most confusing.

Two of the new assertions were weak on the first pass and are worth recording. The one for the
picker's age box searched the whole rendered grid for the implied year, which every day cell's tooltip
also carries — so a view left sitting on the old year passed, because the number was somewhere in the
markup either way. It now reads the view's own caption. And the creator's sync assertion sets both
controls to known-stale values first, since an element that already happens to hold the right answer
proves nothing about whether anything wrote to it.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The fix in the previous commit was mounted one level too high. paintImageFromPrompt capped whatever came
in through styleRefImage at 1024px JPEG, which is right for the room banner and wrong for the only other
caller of that slot: makeMeshIconForItem sends an item's own portrait, already inside the cap, as the
design and colour a 3D mesher then bakes into a texture. Nothing there had a size problem, so all a
blanket rule bought that path was a JPEG re-encode it never asked for, and a quality change to a feature
whose output is a mesh is not a thing to make as a side effect of fixing a 413 somewhere else.

So the cap moves to the character-portrait call site, behind the "Include Room in Portraits" setting that
already decides whether a banner travels at all. That is where the size is knowable: the caller can see
it is handing over a full-resolution painting, and paintImageFromPrompt cannot see anything about what it
has been given. A portrait with the setting off now does no canvas work at all, where the chokepoint
version decoded on every redraw that carried any reference. Measured again in Chromium on a 3840x2160
banner: the call site's request body is 0.214 MB against the vault's 12 MB ceiling, and the same banner
handed straight to paintImageFromPrompt still travels at 25.577 MB - which is the mesh icon path proving
it is untouched.

The painter now carries a comment saying it deliberately shrinks nothing, and the test asserts that as an
ABSENCE - no compressImageForInit anywhere in that function. An absence is exactly what a later reader
re-adds while thinking they are fixing an oversight, which is how this one got written the first time;
sabotaging the file by putting the chokepoint cap back is caught by name rather than passing quietly.
Three more assertions pin the call site: that the cap is there, that it sits INSIDE the setting's ternary
rather than in front of it, and that compressImageForInit still resolves an empty source to empty - a room
with no banner has to yield '' or the prompt claims an attachment nothing sent.

One test had to be rebounded rather than satisfied. test_image_provider.js matched the portrait branch
with a 2400-character window from `action === 'portrait'`, and the comment added above the call pushed
paintImageFromPrompt past it: two assertions about ROUTING failed over a paragraph of prose. Bumping the
number would have left the same trap one edit further away, so the slice now runs to where the branch
actually ends - its `} else if` - which is the fix test_portrait_style_ref.js already applies to three
slices of its own, with the reason written beside each.

The vault's 413 handler from the previous commit is unchanged and still earns its place: it answers for
every oversized body on every parser, not only this one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The entry for the three landing-page age portraits was explicit that its AI-generated split was
INFERRED — from the painterly manner matching the declared corpus and from the commit they arrived in —
and its doesNotClose said the only way past that was to ask, because the files name no generator. Asked
on 22 September, the owner answered that they generated all three with Nano Banana Pro. So the entry
moves onto the same footing as every other generated row in this ledger bar the Suno track: the owner's
statement, recorded where it will outlive the session it was given in, which is the whole reason this
file exists.

Two exactnesses are kept rather than smoothed away. The tool named is Nano Banana PRO, which is not the
string the square-* carousel entry carries, and the two are deliberately not collapsed into one on the
assumption they are the same grant — whether Pro sits under the same terms as the plain tool is part of
the outstanding terms question and is not assumed here. And nothing in the bytes corroborates the name:
all three files were searched for a SynthID note and for any Google or DeepMind marker and carry none,
exactly as the square-* and heraldry-* files do not, so the basis says plainly that this rests on the
owner's word. The terms behind the tool are still not read into the record, for the reason the square-*
entry sets out — a session's recollection of a third party's licence, written down as though it were a
finding, is precisely what this ledger exists to stop.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

A seam left by the previous commit. Replacing the old "only two docs have one" sentence swallowed the
paragraph break after it, so the argument about writing Steps against the code ran straight into the
unrelated note about Reagents being the readable case for a system not yet reachable in play. Two
thoughts in one paragraph, neither of which is about the other.

The count went with it: "do not backfill fifty-one docs" was arithmetic from a state that no longer
holds. Sixty docs, eleven with a Notes half, so forty-nine have none — and the sentence says that rather
than a bare number, since the next person to change the ratio should not have to work out which figure
the sentence meant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Character age (birthdates, the Age/Born pair on the Profile sheet and the Character
Creator, the // set age and clock console commands) shipped with no guide coverage
anywhere — none of the three books mentioned it. The Field Guide and Player's Handbook
now say so, and the Field Guide's OOC command table gets the row it was missing. District
map-pin navigation was already documented for DMs and in the Field Guide, but the
Player's Handbook's Maps chapter had never heard of a district at all; it now has the
same passage in player-facing terms.

The Dungeon Master's Guide's World tab section listed five inner subtabs and was missing
a sixth: Settings, which currently holds only Identity — the "Mint a key for this world…"
button that signs a world for the Realm Registry (Designs/realm-registry.html §05). That
control existed with no documentation reachable from either guide.

Checked the code before writing the dialects-and-languages "chapters" addition a first
draft of this pass would have made: the DM-only View button that previews a chaptered
book page-by-page lives solely on the item editor's card (openBookViewDialog, drawn only
in the DM's Items editor) and is not reachable from a player's in-play book popup at all —
reading one in play simply prints every chapter's title and text joined into one passage,
same as it always did. Documented it that way instead, in the Field Guide only, rather
than inventing a player-facing "View" feature that doesn't exist.

Everything else audited from the Designs/ changes since the last guide pass (abilities,
containers, dungeon-builder, encyclopedia-prototype, music-ai, prompt-economics,
region-files, world-history, gm-rulebook, world-packs, native-app-login, server-vault,
website-login, and crafting's still-proposed system) was either already accurately
covered or correctly out of scope for these three books.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NQG37cXwiHLgk7RetF3JK3

Two sessions looked at Web/LandingPage/images/age-*.png within minutes of each other and each added a
ledger entry, and the merge kept both. Paths in this file are exact and a path belongs to one entry, so
the duplicate is the failure test_asset_provenance catches by name — it left main red on exactly the
check the ledger exists to satisfy.

The later entry is removed rather than the earlier, and the two facts it had that the earlier one did
not are folded into the earlier as a marked addendum: the measured sizes and hashes, and two readings
of the C2PA worth having beside the handling conclusion both sessions reached independently — each
manifest carries an ingredient assertion with relationship parentOf, so something came in that the
manifest does not name, and in neither session was the signature validated against a trust list, only
read. The addendum says which session added it, because the whole value of a line here is that a person
looked, and two people looking separately at the same pictures and seeing generated illustration rather
than a capture is a little more evidence than one.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The character-age carousel's three images arrived with no ledger line, so main was red on
test_asset_provenance and would have been for the next session too. They were looked at: one woman in a
brown hood and a green jerkin, painted three times at three ages, with the same scar across her throat
in all three — pale and low in the young one, livid in the middle one, drawn and white in the old. No
application chrome anywhere in frame, so they are generated pictures rather than captures, and not the
mixed case the heraldry and language-book screenshots are.

The entry is deliberately weaker than its neighbours and says so where the file records it rather than
only here. The square-* carousel rests on the owner's statement naming the tool; this rests on the
pictures and on the merge they came in with, because nobody has been asked. The ai-generated split is
therefore recorded as a session's reading and not as something the owner said, so that it cannot be
cited later as though it were, and doesNotClose asks for it to be confirmed or corrected rather than
left standing because a build went green.

The C2PA manifest is handling and not origin, as it is on every other file in this repository that
carries one: claim generator "Anthropic Files", origin-confidence "unknown", and a description saying
Claude provided the file and may have created or modified it — which is equally true of a photograph.
Each also carries an ingredient assertion with relationship parentOf, so something came in and the
manifest does not name it. There is no trainedAlgorithmicMedia assertion and no SynthID note in any of
the three, which is exactly why the inventory reported them unknown. The signature was read, not
verified against a trust list, and the entry says that too.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Three portraits arrived in the owner's own ageing commit and the inventory named them UNKNOWN, which
turned the suite red on main. That is the check working: UNKNOWN means nobody has looked yet, and it
stays true only while somebody keeps it true.

Looked at, and the entry separates what was seen from what was inferred, because the two are
different weights of evidence and this file exists to record which. SEEN: one character — a hooded
ranger, dark cloak over green, a scar across the throat that carries through all three — painted at
young, middle and old, in the same painterly oil manner as the portraits and key art already declared
here. INFERRED: that they are the owner's own generated work, from that style match and from the
commit they arrived in.

The distinction matters because these are NOT the Suno case. Each file carries a C2PA record, but it
is a handling credential — who moved the file — and not a generator assertion, so unlike the music
these files do not state what made them. The basis says so in as many words rather than letting
"C2PA present" read as provenance it is not. What only the owner can answer is which generator: if it
was one whose terms are not already among those they have stated, this entry cannot see that.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The skill catalogue rendered every class gate the same way — "a Rogue art (anyone else learns it at
reduced proficiency)" — and that sentence is false for exactly one skill. Spellcasting is hard-gated:
skillHardGated names it, skillClassLocked makes it the model's single permanent refusal, and learnSkill
turns it down outright for a class outside the list. Telling a Warrior they could earn magic the hard
way is a promise the point-buy will never honour, which is the same defect the catalogue shipped to
prevent — a refusal that sends the player after something they can never have — arriving from inside
the fix rather than from a model's invention. Hard gates now read "Mage/Sorcerer/... ONLY — closed to
every other class, permanently", soft gates keep the off-class wording, and the distinction is stated
as a property of the SKILL and never of the character, because skillClassLocked reads player.class and
this half of the prompt is cached.

The test grows four assertions around it, and they are written as a pair in both directions: a hard
gate must carry the closed wording, a soft gate must NOT carry it AND must say the off-class route is
open in as many words. Asserting only the first passes a catalogue that marks everything closed, which
is the opposite lie and just as easy to write.

Designs/crafting.html gains §11, in the Steps-then-Notes shape that landed in CLAUDE.md today, covering
the one piece of this doc that has code behind it and nothing else. The Steps were written by checking
the engine rather than from the doc's own prose, and two of them exist because of what the check found.
The manifest above the narration is the ground truth for step A: if narration claims a roll and no row
appears, the model emitted an id applySkillChecks discarded, and that is the failure settled outright
by a single turn rather than suggested by several. And step C carries the console caveat the new rule
asks for — "// learn skill spellcasting" passes force: true and bypasses the very gate the step is
checking, so it proves the console can do what the player cannot, which is the opposite of the
question. The Notes half keeps the claims a desk cannot settle, the first being whether the Game Master
reaches for the catalogue at all rather than going on refusing in general terms, and the sharpest being
whether "an untrained check still rolls" overshoots into rolling everything and quietly makes the
character's own skill list decorative.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Character portrait generation with Settings > Imagery > "Include Room in Portraits" switched on began
returning `PayloadTooLargeError: request entity too large`, on a feature nothing had touched. The setting
sends the room's currently-shown banner along as a colour and style example, and paintImageFromPrompt read
it straight to base64 with imageToDataUri and posted it. Measured in Chromium: a 1376x768 PNG banner is a
3.32 MB data URI, a 2048x1152 one 7.17 MB, and a 3840x2160 one 25.58 MB. The vault parses request bodies
with express.json at a 12 MB limit, which the last of those breaks twice over with no room left for the
prompt. No code change caused the failure; the banners got bigger, which is why it arrived looking like a
mystery rather than a regression.

This was the only image path in the app reaching the vault without passing through compressImageForInit.
The weathered-banner edit and all three video paths already shrink their source, and the weathered one
says why in its own comment - the output is a fresh render, so a small quality hit on the SOURCE is
invisible. That argument is stronger here, not weaker: a style reference contributes colour and brushwork
and never a pixel of the picture painted from it, which is what STYLE_REF_PREFIX tells the model it is for.
Shrunk at maxDim 1024 and JPEG 0.82, all three banners above land under 0.35 MB; driven end to end in
Chromium against a stubbed vault, the 25.58 MB body is now 0.214 MB. The shrink wraps inside the read
rather than the other way round, because reading first still builds the 25 MB string; and
compressImageForInit falls back to the original source when the canvas is tainted, so a cross-origin
banner still reaches imageToDataUri's fetch-then-canvas path.

The other half is that the vault said this badly. body-parser's 413 fell through to Express's default
error handler, which answers with an HTML page whose first line is the raw error text - so the client,
which reads its errors with resp.json(), parsed nothing and showed either a bare status or that sentence,
which names the transport and no remedy. The vault now carries an error handler for it, beside the one for
an unreachable Auth0 and written the same way: a predicate in vault-core recognises the three shapes a
too-large error arrives in, and payloadTooLargeMessage answers in JSON with the ceiling the parser actually
reported plus the one thing the raw error never says, that a body only reaches this size by carrying a
picture. It is mounted after every route rather than beside the JSON parser on purpose. Express scans
forward from the layer that failed, so a handler sitting next to that parser would cover it and miss every
per-route parser mounted later - /vault/media's raw upload and admin's world publish. The new
Server/test/test_payload_too_large.js drives both over HTTP and asserts each names its own ceiling, 12 MB
and 24 MB, rather than a hard-coded figure.

One comment is corrected rather than obeyed. uploadBodyRender's cap claimed that Update and Extract
Portrait pass the render through compressImageForInit on the way out. They do not - both hand o.body() to
paintImageFromPrompt as a raw initImage, and that helper compresses only the style reference. The 1024 cap
on the upload is therefore the only thing keeping a pasted 4K render out of the same 12 MB ceiling, which
is worth knowing before somebody lifts it. Subject references are left uncompressed here deliberately:
Extract Portrait is a crop-and-magnify, so re-encoding its source would magnify the artefacts too, and
that trade is a separate decision from this failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

A build sold without authoring tools that still carries a world forge is the same hole one room along,
and the launcher had a Build button opening it. Both surfaces now come out under TLR_NO_DM: the
in-game DM Editor at 219,704 bytes and the World Builder overlay at 31,881, 251 KB together.

THEY ARE SIBLINGS, NOT PARTS, so each is cut separately and each leaves its OWN marker. A shared
phrase would make a half-done strip — one surface cut, the other missed — read in the file as a
complete job, and the file is the only place anybody would look.

THE REFUSAL IS AT THE CHOKEPOINT rather than at what is drawn. Three routes reach the Builder: New
World on the login screen, the desktop launcher's Build button, and ?builder=1 typed at the address.
Only the first two have something to hide, and the third is the one that matters — it is the same
class of bypass the parameter-only version was, so openWorldEditor itself returns early when the
overlay is not in the page. One guard covers all three.

THE LAUNCHER DRAWS NO BUILD BUTTON for such a build, hidden rather than disabled: disabled reads as
"not yet" — a vault still starting, a key not entered — and this is "not in this product". Set once
where the config is read, and deliberately NOT guarded at the five places that release the buttons,
because `hidden` and `disabled` are independent properties and five guards that must agree is the
arrangement where one of them quietly stops agreeing. The flag's declaration moved up beside the
config handler that now reads it; it worked from fifty kilobytes below, since the handler is a
closure, but a setting nobody can find is a setting that gets declared twice.

TWO ENTRY POINTS WERE ALREADY LEADING NOWHERE after the previous commit and are closed here. Edit
World on the login screen and the pencils beside a save both open a DETACHED DM Editor — ?detach=
editor on this same page — so with the Editor's markup stripped they opened blank windows. An
affordance that leads nowhere is worse than one that is absent, because the blank window is what gets
reported.

Verified in Chromium across five cases rather than reasoned about: the original page offers both; the
original at ?builder=1 opens the Builder; the STRIPPED page at a bare address has neither in the DOM,
draws neither button, and still paints its login screen with no console error; the stripped page at
?builder=1 — the launcher's own address — leaves the login screen exactly where it was; and ?nodm=0
changes none of it.

Two tests in the app suite went red and were right to, in a way worth recording because it will
happen again. test_world_builder_title and test_artstyle_presets both asserted with a CHARACTER
BUDGET — `function openWorldEditor()[\s\S]{0,320}…` — so a guard and its comment at the top of that
function moved the call they were about further down than the window reached, while altering nothing
either assertion claims. Both slice the function by brace now. Rewriting them turned up two further
holes that the originals shared: the regex matched a COMMENTED-OUT call, which is how such a call
would most plausibly disappear, and one of them sliced from a newline-flattened copy of the file, so
the comment stripping had no lines to work on. Both were found by making those exact edits and
watching nothing fail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Lore hooks unlocked through a history account were not paying, and the reason was that they were
not firing at all. Filing an event rode `loreUnlock`, which carries at most ONE thing per turn and
in which everything else is a reward. Asking the gatekeeper what the siege cost him is one
conversation that does two things — it recounts an event and it satisfies that man's own lore hook
— and the two had to share a slot. Rule 13g told the model to report the account, so the half that
pays XP was the half that silently did not happen: a hook the player had genuinely earned stayed
locked, with nothing anywhere reporting it.

The principle is one line, and it is the whole change: a field that costs nothing must never
compete for the slot that pays. History moved to a `historyTold` field of its own, applied
independently of every unlock, and the rule, the response contract and the dossier now each say in
as many words that it is set BESIDE whatever the turn earned rather than instead of it. That
sentence is what the split exists to make true, so it is asserted in all three places: a model
that reads the field as an alternative re-creates the bug it was made to end.

Nothing about the account itself changed. It still pays nothing, is never withheld, has no
condition, and resolves only from somebody in this room paired with the event. What changed is
that the hook beside it now unlocks and pays its own XP, which it always should have.

Two things follow from the same move rather than being added beside it. The field takes one event
or an ARRAY of them, because the one-per-turn rationing had only ever been a consequence of
sharing that slot, and two events genuinely can be recounted in one breath — the war, and the
famine that came of it. And `nearMiss` is deliberately NOT suppressed by it: that guard exists
because a hint beside a REWARD is noise, and filing an event is not one, so a turn that recounted
the war and also brushed a hook it did not pay out still owes the player the nudge. Both are
pinned, the second because a reader adding the field to that guard would be making an edit that
looks like tidying.

The old shape still opens. A model reaching for `loreUnlock: { kind: "event" }` out of habit has
its account filed rather than dropped, with a DM log line naming the door it came through —
because arriving that way still costs the turn its hook, which is the one thing worth knowing
about it. The kind is gone from the enum and the field points at what replaced it, so a model
reading the contract finds one way to do this rather than two.

Twenty sabotages were each caught by a distinct named assertion. One of my own assertions was
rewritten after surviving the break it was written for: "rule 13g names the field" passed against
a rule that had been put back to the old `loreUnlock` shape, because the paragraph goes on
mentioning `historyTold` two sentences later — it now checks that the field is named as the thing
to SET.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The per-turn dossier built its skills section from knownSkills() and carried nothing else. That is
enough for every system built so far, because a check is only ever rolled against a skill somebody has
— and it stops being enough the moment the right answer is about a skill they LACK. "You would need
Ironworking for that, and you have never trained it" could only be said by inventing a name, and both
halves of that fail silently. The refusal sends the player after a skill their world does not contain,
which is a dead end the Game Master authored and nothing reports. And if the model then rolls a check
against the id it made up, applySkillChecks resolves it through skillById and returns on the miss: the
narration says a roll happened, there is no manifest row, no xp is awarded, and no error appears
anywhere. The guard that drops the check is correct — fabricating one would be worse — and it is
exactly what makes the failure quiet.

So "Skills — everything this world can teach" is a GM-eyes-only section in the cached half, built from
allSkills() so it reads the running world's own map and falls back to the built-in catalogue. Each line
carries name, id, governing stat, DC hint, tier, and for a gated skill what it wants first BY NAME, so
a refusal can say "that wants Apothecary, and you would need Concoction before it" rather than naming
an identifier at the player. It goes in `stable` because the one rule that decides that answers
cleanly: the world's skill catalogue cannot differ between two consecutive turns. What the character
has learned still lives in `live`, and the two are deliberately separate sections rather than one
annotated list — for the same reason the ailment catalogue is separate from what the player is
carrying. Annotating the roster with what is known is the natural way to write this, it reads
perfectly, and it would put a per-turn value inside a 230k-character cached prefix and re-bill the lot
on the turn a skill is learnt. The test's load-bearing assertion is therefore not about content at all:
learning a skill must leave the cached half byte-identical, and it reports the first byte that moved.

The prose is mostly one use and one prohibition. The use is naming what the character lacks. The
prohibition is inventing a skill, stated with its consequence rather than as a rule, because the
consequence is the part a model can act on. It also says the thing that is easy to get backwards: a
check on a LISTED skill the character has not learned still rolls, at no proficiency, because their own
list says what they are trained in and not what they are permitted to try. The worked example in that
prose is interpolated from the roster rather than typed in — a hand-written "you would need
Ironworking" names a skill no world is obliged to have, and sitting inside an instruction that says
"use a name from this list" it is the sentence a model is likeliest to read as licence to use that
name. The three skillChecks rules changed too: they said a check's id came "from Character Skills",
which is precisely the restriction this lifts, and they now name both lists.

The crafting design doc moves to Rev. 2 on the back of it. §4 is rewritten as what shipped, kept in the
past tense it was written in because the defect is worth reading before the fix. The retry gate is
settled as the asymmetry the doc argued for rather than one an implementation would have discovered:
dismantleTryDay on the item for dismantling, which has a subject with an id, and hours charged on the
clock for assembly, which has only a sentence the player typed. The three rejected keys are kept with
the reason each fails — a per-character flag is the shape the identify gate already avoided, a hash of
the inputs is a derived key that changes when one more scrap of leather is picked up, and a field the
model sets and reads is not a key but a gate a model can forget. Item condition is parked with a brief
rather than dropped, and the brief carries the thing worth knowing: the penalty may be the engine's
rather than the Game Master's, since clampAbilityBonus already clamps symmetrically and takes
negatives and an equipped item already contributes its abilities, so a worn item carrying a standing
−1 is a short walk down a path already paved — and a number the engine applies is one the model cannot
forget and the player can see.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The previous commit pointed a spell portrait at the tab's own popup and left the NAME still opening
the editor card, on the reasoning that the card was then one click away and nothing had been taken
from the DM. What that shipped was a tile whose two halves answered different questions, and the
half carrying the spell's name — the half that reads like the label of the thing, and therefore the
one a player clicks when they mean "what is this" — gave them the near-full-window DM editor. It was
reported as the change not having worked at all, and from the player's side it had not.

So the per-surface override is no longer about the picture. A surface may name one act for the WHOLE
tile, as `opens(rec, name)` returning {onclick, title}, and both halves go there; a surface that
names none keeps the two-halves default, which is right on an editor tab for the reasons already in
the comment above it — the gallery is a way to reach a record's card, so the picture is free to be a
picture. The two defaults are now module-level functions rather than one of them sitting in
PORTRAIT_VIEW_DEFAULTS, because they are a pair and a reader who finds one should find the other.

The title travels with the handler in the same object deliberately. A title promising an enlargement
over a handler that opens a popup is the kind of wrongness nobody reports — and it is how this very
defect was diagnosed from a screenshot, the tooltip reading "Open Cat's Grace's card" over the
dialog that had just opened one.

Tests/test_editor_view_modes.js §10 asserts the two halves separately, because they are separately
wireable and were separately wrong, and eleven sabotages each fail on a distinct assertion that
names the cause: the picture-only shape that shipped, the name-only mirror of it, titles left behind
while handlers move, the row naming no act at all, the act promoted to a default for every surface,
the popup host moved inside the view it must survive, the subview losing position:relative, the id
dropped from the shared popup rule and from the de-duplication roster, showSpellPopup ignoring the
host it is handed, and its default host changed under every story link.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The answer to "is this stored somewhere else" was no. Nothing in the repository had a Playthrough Testing
section; what eleven of the sixty Designs docs carry is "Playtesting notes", which CLAUDE.md defines as
explicitly NOT this — "not a test plan and not a list of features to click through". Those hold open
questions about model behaviour. A step list for exercising shipped features had never been written.

So the notes become a half rather than a section. Abilities §14 and Containers §10 now end with a
PLAYTESTING section holding Steps and Notes, and the two were chosen because they are the two shapes of
the staging problem: containers is the easy case and abilities the hard one.

Containers stages almost entirely from the // console — its free-form path places a container with
contents, a lock and a trap in one line, and the directive's own worked example is the first step. The
steps run through movement and the out-of-band GM note, the four lock methods (with the assertion that
the numeric pickDC and a button's GM-only hint never reach the player, which is the step most likely to
catch a regression because a leaked DC looks like helpful UI), traps on ALL THREE open paths since a trap
that fires only on the story path is the commonest shape of that bug and the story path is the one a
hand-tester uses first, and the capacity and nesting refusals. One step exists to be recognised rather
than to pass: loading a world older than Perception, whose failure before the ENGINE_REQUIRED_SKILLS
backfill was silent end to end — the DM authored the trap, the GM rolled it, applySkillChecks binned the
roll because the world had no such skill, and nothing was said, on every trap in the world.

Abilities leads with why it is hard, and both caveats were MEASURED rather than read off the design.
The // console cannot grant an ability at all: its fallback emits stats, hp, coin, xp, statuses, spells,
skills, items and the palette, and abilityChanges is applied in applyTurnResult, the story-turn path. And
`// give me <item>` loses an ability authored onto that item — the console's addItems shape carries a
name, and makeItem merges the catalogue entry only when given a ref, so the ring arrives with no
abilities and nothing says so. A probe confirmed both readings before either was written down. The
staging route is the item card's own Drop button, which places makeItem({ ref }).

Writing that turned up a gap, now Notes 6 rather than a step: §3 constrains racial abilities to
kind:"passive" through the race-edit DIRECTIVE, which binds the Game Master and nothing else. The ability
editor is shared across its four hosts and does not constrain Kind, so a DM can hand-author the Checked
racial ability the directive forbids and no engine path refuses it. The first draft of that step told a
playtester to expect a refusal; the check showed there is none. What happens to such an ability is a
table question either way, and the worse answer — silently never firing — is the one worth knowing before
somebody spends an evening on a racial trait that does nothing.

CLAUDE.md gains the convention, including that the Steps must be written by checking the code rather than
from the doc's own prose. A step that confidently tells a playtester to expect something the engine never
does is worse than no step, for the reason a test that passes against a sabotaged implementation is worse
than no test. Its stale claim that only two docs have a notes section is corrected too: eleven do.

Both docs needed an h4 rule adding to their style block, neither having nested that deep before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Four changes that are one change: a being's age now works exactly as the player's does, both painting
prompts are told what they are painting, and the birthdate the whole thing rests on is visible and
settable instead of being a number's shadow.

BEINGS AGE. This reverses decision F, which shipped two days ago leaning the other way. The original
entry argued that nobody will type a birthday for each of a world's hundreds of beings and that the GM
authors ages as prose. Both are true, and neither is an argument for STORING the number — they are an
argument against asking for a birthday, which is answered by deriving one. An age set anywhere is
converted on the way in, so the number somebody typed is preserved exactly on the day they typed it and
moves with the clock afterwards, and a world wound on five years is a world where the blacksmith's
apprentice is five years older. The conversion is four lines; the cost the old entry weighed was not
the cost of doing it. The number is NOT kept beside the birthday, because a stored age next to a
derived one disagrees the first time the clock turns a year, which is the failure this design exists to
avoid.

The conversion has to be written twice, and the second one was very nearly missed. A freshly built
world goes through makeEntity; a SAVED one does not, because reInstance copies the snapshot's own keys
onto the prototype — the same rule CLAUDE.md already records for player fields, with a second door
nothing had written down. Left out of reEntityObj, every world saved while `age` was the stored field
would have come back with the number sitting there unread and every being in it ageless: the card falls
through to the prose, and a being that had an age yesterday has none today with nothing to say where it
went. Found by asking where a save actually re-enters the engine rather than by anything failing, which
is why CLAUDE.md now carries the entity twin of that rule beside the player one.

THE TWO PAINTING PROMPTS. A face and a build are the two things a model invents when it is not told,
and it invents the same one every time: an athletic adult in their late twenties. A character of
fifteen or of seventy comes back looking like neither, which is the most visible way an age can be in
the data and not in the game. So portraitPromptWithAge joins gender, race and appearance on the portrait
chain, and the full-body render states it through the equipment adapter — the one seam the player and
every being both pass through, so NPC renders are not left as the only ageless ones. Both phrase it as
a DIRECTION rather than a fact: "Age: 63" in an image prompt is read as a caption and painted as a
word, while "a face and build of a person of 63" is read as an instruction. The render asks for the
NUMBER and never the label, because "over four centuries dead" is not a build a painter can act on.

THE BIRTHDATE, VISIBLE. Character > Profile gains a Born row under Age that shows the date and opens a
month view of this world's own calendar — its months, its weekday names, its year label, its month
lengths — whose days are pressable. It is a separate function from the status bar's calendar on
purpose: that one is browse-only with a test behind it, because the CLOCK is wired into every timed
thing in the game, and giving the browser a mode where its cells sometimes do set something is how that
guarantee would eventually be lost. A birthdate is not the clock; it is one field on one character.

Editing either control moves the other, which is not a convenience but the only arrangement that does
not reintroduce the original failure in the one place a person can see it: two boxes that can disagree,
on the same screen, would be worse than the stored number ever was. Typing an age moves the birth YEAR
and keeps the day — the year is the only part an age can decide — and pressing a day sets the whole
date and the age follows. The picker opens ON the birthday rather than on the present, because a DM
editing a forty-year-old should not page back forty years to reach the day they are editing, and each
day cell's tooltip says what choosing it would make them, since "which day makes them the age I mean"
is the question somebody opening this dialog is actually asking.

Two tests were pinning the portrait chain as a literal nesting — paintImageFromPrompt(withRace(
withGender(withAppearance(...)))) written out in full, in two files — so a fourth helper failed both
while appearance, gender and race sat exactly where they had always been. They were measuring the
spelling of the call rather than the property it stands for. They now assert that each helper wraps the
prompt, which is the property, and both were sabotage-checked to confirm they still catch a dropped
one; the portrait test now names all four, so the age is pinned there too.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

A design document for crafting: assembling an item out of materials and taking one back apart, with a
tier-1 Crafting skill to attempt anything and material skills at tier 2 behind it, adjudicated by the
Game Master rather than by a recipe table.

The first thing the doc has to answer is why a second crafting system should exist when the concoction
recipes already work. They are opposites in every respect — closed catalogue against open, engine
adjudication against GM, an authored DC against an invented one, an existing item id in `yields`
against an item authored on the spot — and read as a table that looks like an inconsistency waiting to
be resolved. It is not one. Concoction is magic and magic is specific: Knitbone Salve is a named
working with a right way to do it, and a world where a player can talk a model into inventing a potion
every evening has no magic system at all. Mundane craft is general: there is no canonical way to make a
knife, every smith who ever lived made one up as they went, and a table of authored knife recipes would
be endless and beside the point. The built-in world already ships an iron ingot whose whole description
is "Raw crafting material" with nothing in the game that can work it.

Three findings came out of reading the engine rather than out of the request, and each changes what the
work costs. The per-turn dossier builds its skills section from knownSkills() — what the character has
learned — and never carries the world's catalogue, so a Game Master asked to decide whether somebody
has the skills for a job cannot name a skill they lack. Invent one and two things fail quietly at once:
the refusal points at a skill the world does not have, and applySkillChecks resolves the id through
skillById and returns on a miss, so the narration claims a roll that produced no manifest row, no XP and
no error. That makes a skill catalogue in `stable` a prerequisite for the system rather than a
refinement of it, and it is useful to anything else that ever has to refuse by name.

The once-a-day retry gate has no key on the assembly half. Both shipped day-gates hang off an id that
already exists — identifyTryDay on an item, diagnoseTryDay on an ailment — and neither is a
per-character flag, deliberately, because one failed identification blocking every identification in the
world is the failure that shape produces. Dismantling inherits the pattern for free, since its subject is
an item. An assembly attempt is a sentence the player typed. The doc lays out four keys and leans
toward charging hours on the clock instead, which lands in the same place and admits that the two halves
are not one system with a direction flag.

And item.condition is free text that nothing reads: declared as an empty string on Item, written by
applyItemSpec, and consumed only by two inventory spans, an editor tag and row, two dossier lines and the
item popup. The request's load-bearing condition mechanic therefore builds a ladder that does not exist.
The shipped vocabulary is pristine, good, average and worn over 32 uses and does order itself, by an
author having taste rather than by anything enforcing it — and the request's "Fair" is spelled "average"
in the only world there is. The lean is a normalizer over a declared scale rather than an enum, because
an unmapped word reading as the default rung is a missing penalty where a validator rejecting an
authored string is a world that will not load. Worth knowing before anyone greps: `condition` is four
unrelated vocabularies under one field name — an item's repair, an ability's when-clause, the weather,
and a world's own status ids — so this change is scoped by what carries the field, not by its name.

Two smaller notes recorded rather than acted on. The concoction authoring roster briefs the model with
"The crafting skill is…", interpolated from recipeSkill(null), which resolves to concoction today; a
skill whose id is literally `crafting` turns that sentence into a plausible misreading for a model and a
trap for the next reader. And an open crafting system is an unmetered item source that the evaluation
pass cannot see at all, since a crafted item exists in no world data — so the recommendation regardless
of which other brakes are chosen is an engine-set mark on anything this system makes, because a system
that cannot be audited cannot be tuned.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

On an editor tab the gallery exists to reach a record's CARD, so the picture is free to be a picture
and clicking it enlarges. Character › Spells is read by a player deciding whether to cast the thing,
and the answer to that is the spell's own popup — school, level, MP cost, whether it is carried, the
Cast button. So this one surface sends its picture somewhere else, and the registry is where it says
so: a `pictureAct` accessor with the lightbox as its default, overridden on the one row that wants
something else. The name still opens the card, so nothing was taken away — which is what makes
giving up the lightbox on this tab cost nothing.

The popup opens in the tab's own upper-right corner, the way the pack's item popup does, from a host
declared beside the view rather than inside it: renderSpellbook rewrites that view wholesale, and a
popup parented to it would be torn down by every redraw. showSpellPopup takes the host as an
argument now, exactly as showSkillPopup already did and for the same reason, defaulting to the
sidebar so a spell named in the story still lands where it always has.

Four things had to be right for the popup to appear where it should, and three of them fail
silently. The id needs a line in the shared CSS rule or the box has no position, width or z-index at
all; it needs a .room-popup-body, because showEntityPopup finds none and returns without a word; it
needs a place in the de-duplication roster, or one spell can stand open in two popups at once. The
fourth was missing: the subview had no position:relative, so top/right in the teens would have been
measured against an ancestor the tab is not in. #character-sub-inventory carried that rule for the
pack's popup and nothing carried it here.

Adding the spellbook to that rule broke an assertion in test_inventory_tab.js, which read
`#character-sub-inventory { position: relative; }` byte for byte and failed the moment a second
subview needed the same treatment — a change that left the property it guards exactly as it was. It
asks whether the id appears in the selector of a rule that sets position:relative now, which is the
question it was always about.

Three findings in my own test work are worth recording. The section's host slice ran from the
element to the first closing tag after the phrase it searched for, so a host that had LOST its body
still passed — the search ran on past the element and found the next popup's body further down the
file. It walks div depth now. The DOM mock returned a FRESH element from every querySelector call,
which cannot express the one shape this section drives, a write into .room-popup-body and a read
back out; it memoizes per selector. And the regex doing that depth walk contained a literal
backspace character rather than a word boundary, so it matched nothing and reported every host as
empty — invisible in the file and in grep, and found only by running the slice outside the test and
watching it work.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The obvious build is a field on the player holding 30, and it is wrong here for one reason: this
game's clock jumps, and it jumps from a dozen places. A rest, a wait, a sleep, brewing a concoction,
crafting, a GM time-skip and now the DM console's own "// advance" each move the in-world clock by
hours or days. A stored age has to be found and bumped at every one of those sites, and the failure of
a missed one is silent — the sheet reads 30 while the world has turned twice, the Game Master is
briefed with a number that has quietly become fiction, and the only way anybody notices is by
wondering why a character who has lived through two winters is the age they started. It is the same
shape as the roster pasted into a prompt and the count written down in prose: a second copy of a fact
is free to disagree with the first.

So what is stored is the birthday — player.birth, a { year, month, day } in the world's own calendar —
and the age is worked out from it and the clock every time anything asks. There is no second copy to
keep in step, and a character ages because the clock moved, which is the only reason anybody ages.
setPlayerAge and ageFromBirth are exact inverses, including the ordinary rule that a character is
still the younger age the day before their birthday, so an age typed in and read back is the same
number and a birthday already set is never moved by a later correction to the age.

The birth YEAR is kept against the clock's substrate rather than the year the world displays, which
looks wrong in a save file and is not. realmDisplayYear paints calendar.year + (utcYear - 437) over
the raw clock, so a DM re-basing their era on Editor > World > Calendar — an ordinary edit — moves
every displayed year at once. Stored as a displayed year, a birthday would sit still while the present
moved and the character would age 763 years over a field edit. Stored against the substrate the
difference is invariant: the era moves, the birthday moves with it, the age does not, and a character
exported into another world is the same age in both while being born in whatever that world calls the
year. The test moves the era off 437 before asserting it, because the default calendar's year IS the
epoch year and the assertion is worthless without that — measured, a conversion removed entirely
passed every check until that line was added.

Three states, not two. No birthday reads "—" and not 0, because an unanswered question and a newborn
are different answers; a birthday in the future reads "not yet born", a state only a DM winding the
clock back can reach and one the sheet should say out loud rather than round away. Existing saves are
not backfilled with an invented age: a character already in play has an age their player has been
imagining, and a number made up by the engine would overwrite it while looking authoritative. The
Character Creator opens on DEFAULT_START_AGE instead, which is a default the player is looking at and
can change before they begin.

Beings get the plainer version. ent.age is a whole number somebody wrote down, an instance fact like
Race and Gender rather than a trait of the kind, and it does not advance with the clock — nobody is
going to type a birthday for each of a world's hundreds of NPCs, and the Game Master authors ages as
prose. It sits BESIDE profile.age rather than replacing it, because some authored ages could never be
numbers: the built-in world ships "unknown — centuries, perhaps", "over four centuries dead" and
"varies". Two fields naming one idea is exactly the muddle this codebase keeps paying for, so there is
one reader, entityAgeLabel, and every display goes through it; a profile.age that is purely a number
is adopted as the number on the way through makeEntity, so the seven dated NPCs in the built-in world
get a real field without anybody re-typing a roster.

The age reaches the GM on the Player line of the LIVE dossier and nowhere else. The test for a new
prompt line is not its topic but whether its value can differ between two consecutive turns, and an
age crosses a birthday mid-session. In the cached half it would break the prefix on the turn the
character had a birthday and bill every later call at full price, with the prompt still correct and
the game still playing.

The clock commands are the other half. The calendar widget browses and will not set, and its own
header says why — the clock moves one way during play and every timed thing is keyed to an absolute
in-world millisecond, so a day cell that set the date would be a time machine wired into all of it.
That reasoning holds for a widget; the DM console is where that surgery belongs. // date reports,
// advance and // rewind move by a span, and // set date/year/month/day/time set one part or all of
it, reading the world's OWN month names out of world.calendar rather than a list written into the
parser — a DM plays in Hollowtide, not in December, and a name the calendar does not know moves
nothing rather than quietly landing on January under the wrong weather pattern.

The two directions behave differently on purpose. Forward is a time skip and needs nothing: it is byte
for byte what a long rest does, and the poison wearing off is the point. Backward carries every
absolute stamp with it, or they are stranded in a future the clock will not reach again — an expiry
that never fires, a creature stamped dead an hour ago that is dead an hour from now and whose respawn
cooldown never starts, and an awakeSinceGameMs that reads as centuries. That last one is not
hypothetical: it is the failure initGameClock already carries a paragraph about, a character
permanently Exhausted at -3 to four attributes with nothing on screen to say why. So a rewind
preserves every relative duration and reverses nothing else, and says so in its own notice, because a
DM who is not told will read the unchanged world as a bug in the command.

Two assertions in test_character_race.js were proximity regexes — 600 and 400 characters between two
labels — and the new Age row failed them while Race and Class sat exactly where they had always been.
They now compare positions, scoped to the block that draws them, which is the property they were
reaching for; both were sabotage-checked to confirm they still catch a real reordering.

Designs/character-age.html is the write-up, with decision F left open: whether beings should age too.
The leaning is to give them a birthdate the day somebody wants it, reusing ageFromBirth rather than
inventing a second mechanism.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The prior session that generated Web/Reports/progress-report.html was working
from a shallow clone whose local main had drifted 296 commits behind
origin/main, so the report understated the project's activity by nearly a
week and a half of work. This run fetched full history (git fetch
--unshallow), reset main to origin/main, and re-ran
Tools/gen-progress-report.js from the complete log: 4,202 commits across 85
days, June 30 through September 22, busiest day September 7th with 166
commits.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017oJRXN9vSS4Gg7asRHxA7C

One row in PORTRAIT_VIEW_SURFACES, two buttons in the toolbar, and three lines in the renderer. It
joins the registry rather than growing a toggle of its own for the reason the registry exists: every
surface on it already agrees about what By Portrait means, what it persists under and how its dialog
behaves, and one more written by hand would agree until the first time any of them changed.

It is the first surface on that registry that is not an editor tab, which is worth naming because
the machinery is called editor-this and editor-that throughout. Nothing about it is editor-specific
— it is a view id, a card builder, a finder and a renderer — and the dialog it opens sits at the top
of the document rather than inside the editor screen, so it is reachable from the character sheet
exactly as it is from the Editor.

The row is `charspells` and not `spellbook`. That would sit one letter from the `spellbooks` surface
above it, which is the Editor's spellbook ITEMS tab and a different roster entirely, and this tab's
view element is already called spellbook-view — the pair would read as the same thing in every line
that mentioned either. The finder is allSpells() rather than the tab's own listed set, deliberately:
the list narrows to what the character knows in the Known scope, and a dialog opened over a spell
should not close itself because a control the reader never touched moved underneath it.

Two things here are not true of the twenty-one editor surfaces. The tab has a LOADOUT STRIP above
its list, which is the memorization state rather than one of the cards, so it is composed outside
the card-or-gallery choice and stands in both modes — losing it to a view toggle would make By
Portrait a worse tab rather than a different one. And it has two ways to be empty, no character and
a filter that matched nothing, so syncEditorViewButtons is called above both: four surfaces shipped
with that call on the card-drawing path only, and the symptom was a toggle that stopped saying which
mode it was in the moment a tab had nothing to draw.

The registry test picked the new row up by the act of adding it, which is what walking a registry
buys — thirty-nine assertions with nothing written for them. Its generic loop was still skipping the
interesting half, though: Character › Spells opens on the spells the character KNOWS and a freshly
built Kestrel knows none, so the swap check and the finder round-trip saw an empty tab and moved on
in silence. That is fixed in the fixture rather than worked around beside it — the scope is widened
to the whole grimoire when the world is built, and the one surface belonging to the player is now
exercised by the same loops as the ones belonging to the DM.

A new section covers what those loops cannot. Its first two assertions were worthless as written:
they set the mode, rendered an empty tab and checked the buttons, which were already correct from
the render before — so a renderer that never synced at all passed both, and the sabotage that moves
the call below the early returns sailed through. They knock the buttons into the wrong state first
now, and that sabotage fails.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The padlock never appeared. The world was signed, the vault had the key in the file it was serving, and
the Worlds tab still drew nothing — and nothing the operator could press changed it. Ticking Public
rewrites one key on the record; signing a registry challenge rewrites nothing at all; a restart re-reads
the same index. The one path that rebuilds a record is a world's FILE changing, and adding a column to
an admin table does not touch anybody's world.

So `keyed` reached only the worlds published after it existed. Every record written before kept no such
field, the table read the absence as unsigned, and the repair was to re-publish from the World Editor —
which is not a thing anybody thinks to try in order to fix a missing icon. The bug is not really about
`keyed`: it is that a field derived from the world file has no way of arriving late, and the next such
field would have shipped exactly the same way.

Hence DERIVED, one table of the fields a record computes from the file, which _reconcile can now ask a
record for by name. A record missing any of them is re-read for those alone — once, since the repair is
written down, after which its fileMtime matches again and the load costs a stat. Deliberately not the
full rebuild that sits below it: that path marks a record `adopted` and can only report nobody as its
publisher, so taking it would trade the operator's own name for "from disk" in order to deliver a
padlock. The same table now feeds both the adopt path and the publish path, which had a copy of the
`keyed` expression each; the second copy is always the one that goes stale.

The test reproduces the vault as an older build left it — the field deleted from a real index over an
untouched world — and asserts through the store rather than against the file, because a backfill written
somewhere list() does not read would satisfy a file check and fail every reader. It also pins what must
NOT move: the publisher, the adopted flag, and `public`, which no file can say and a rebuild that
recomputed would silently unlist every world in the vault.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf
Co-Authored-By: Claude <noreply@anthropic.com>

The keyed mark added with R14 said one thing — this world carries a key — and an operator wanting the
fact they actually care about had to read it together with the Public checkbox four columns away. The
pair is the interesting state: a key proves nothing until there is a listing for it to prove, and a
listing proves nothing without a key. So the mark now carries both, in the registry's own signed green,
which means the padlock an operator reads on this page and the padlock a player reads in browse.html
are the same padlock rather than two vocabularies that happen to draw the same picture.

Gold is kept for a signed world held back rather than dropped. Removing the mark until a world went
public would have read as "your key did not work" at exactly the moment somebody has just minted one,
and that is the reading that costs an author the reason to mint a key at all. Each page names its own
--green: browse.html and the admin panel sit on different backgrounds, and a colour copied across by
value would be the wrong green on one of them.

What green deliberately does not claim is that the registry ACCEPTED the listing. Under R16 a registry
approves each world by hand and never sends the answer back, so `public` is this vault's decision to
offer a world and nothing more; both tooltips say offered rather than listed, because a padlock reading
"listed" would be false for every world sitting in an approval queue, which is every world until
somebody works that queue.

The mark follows the Public tick live, from the server's answer rather than from the click — the same
rule the tick itself follows, and for the same reason: a world the vault stored but could not list
comes back public:false, and a mark coloured from the press would show a listing that does not exist.
It is rebuilt from lockMark rather than having its class flipped, since the title and the label differ
between the two states too and a class toggle leaves a green padlock whose tooltip still says private.
An unsigned world earns no padlock by being published, at render or at the tick: publishing is not
proof.

The test was matching the source of the old expression, which for a two-input decision proves only that
somebody typed both words. lockMark depends on nothing but the SVG string, so test_admin_page.js now
lifts it out of the page and calls it, and asserts the four combinations as answers; the case that
matters is the fourth, where a condition written `w.public` alone hands the page's one claim about
proof to a world with no key, and a source match for the class passes on exactly that. The colours are
compared as the `color` declaration rather than the whole rule, so a green rule quietly pointed back at
the gold is caught. test_vault_world_editor.js, which really runs applyPublic, now records which answer
the mark is handed at each of the moments the tick is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf
Co-Authored-By: Claude <noreply@anthropic.com>

It was plain text, and that was an oversight rather than a refusal — asked about, on the reasonable
assumption it might have been deliberate. Deciding whether to carry an operator is exactly the moment
somebody wants to look at their server, and an address that has to be selected and pasted into a bar
is an address nobody looks at.

It carries the same two guards the listing's Play control already uses, rather than new ones. https
only: a registry that turned a plain-http address into a click would be inviting a request it has just
said is not safe to trust, and an http vault still shows its address as text. And
rel="noopener noreferrer" with target="_blank", which matters more here than on the public listing —
this is the page an administrator is signed in to, so window.opener on a stranger's tab is a handle on
a session rather than on a directory.

The refusal that IS real is stated in the link's own title instead of being used as a reason to
withhold it: this opens a vault the registry has not approved, so the click tells that operator
somebody looked. That is the administrator's judgement, and §08's rule is that this service hands over
facts it observed and gets out of the way.

The test section that guarded this was called "The one attribute built from a stranger's string" and
was scoped to hostCell, so the new link would have inherited nothing. It now covers both, and asserts
the COUNT of links built from somebody else's address — a third one trips it and has to be brought
under the same guards, rather than arriving beside a section header that quietly stopped being true.
That count is the part worth having: the second link was added as plain text in the first place
precisely because nobody could tell whether the first had been left unlinked on purpose.

Driven in Chromium against a queue holding one https vault and one http vault: the first is a link
with both attributes set, the second is text.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

index.html is a template Claude Design regenerates, and four things in it are hand-added and survive
nothing: the two sign-in script tags, the #auth-btn button, the three footer notice links, and the
closing tag on the lightbox's screenshot div. An export drops them without a trace — the page still
renders and still says the right year — and it has now happened twice, costing a hand-diff against git
both times. Tools/landing-parts.js --check names what is missing and --fix puts it back.

It does not replace the tests and could not: test_landing_login.js watches the sign-in half and
test_site_terms.js watches the links and the tag balance, and between them they reported nine failures
from the last overwritten file. A fixer is a convenience; a test is the thing that says something is
wrong. This turns a five-minute merge into one command and that is the whole of its job.

The property worth having is that it REFUSES. Every part names an anchor in generated markup and a
design tool is free to move it, so a part that cannot be placed — or whose anchor now matches twice —
stops the run with the part named and NOTHING written, not even the parts it could place. A fixer that
skipped what it could not find and reported success would leave the page in exactly the state it
exists to repair, with a green line saying it was done, which is strictly worse than not having it.
Ambiguity refuses for the same reason: two matches means the anchor is no longer the thing it was
chosen to identify.

The parts are copied out of the page itself rather than retyped, and the test asserts a restored file
is byte-identical to the shipped one — so a copy that drifted from what it claims to reproduce fails
rather than quietly putting back something slightly different. The comments travel with their parts,
because a part restored WITHOUT the comment saying "an export drops this" is a part the next person
drops again having had no way to know.

Six sabotages, each caught by a distinct assertion. One survived the first pass and was the sabotage's
fault rather than the code's: it reordered the single write instead of moving it inside the loop, so
it did not produce the half-applied file the assertion guards against.

Verified against the real broken export from 21 Sep 2026, recovered out of git: --check names the two
missing parts, --fix restores them, and the result matches the hand merge exactly.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The commit that restored the footer links said the unclosed lightbox div was "worse and nothing caught
it directly". That is false. Tests/test_site_terms.js caught it in the same run as the missing links —
nine failures from one overwritten file, including "index.html closes every <div> it opens" and "the
footer sits outside every <sc-if>".

What actually happened is worth more than the correction: the test output was skimmed through `head`,
the structural failures sat below the fold, and the unclosed div was then rediscovered by hand-diffing
against the last good version — arriving at a finding the suite had already printed. A safety net read
through a truncating pipe is a safety net with a hole in the reader rather than in the net.

Recorded in the test's own comment rather than left to a commit message nobody will search, because
the false claim would otherwise read as a coverage gap and invite somebody to add a second structural
check on top of the one that already works.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The routine's doc-maintenance edits are small, self-contained, and low-risk
each run, unlike the feature-branch case the Branches section already
carves out for reviewable-as-a-unit work. Spinning up a claude/<topic>
branch for it just leaves an unmerged branch to clean up after every run
with nothing gained.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UJNQZHKSnW5cFPfEGYqJdf

An export from the design tool overwrote index.html and dropped two hand-added things. Both had been
added before, and both comments explaining why were dropped with them, which is how the same page lost
the same two things twice.

The three footer links — Privacy, Terms of Service and Licence — are what Tests/test_site_terms.js
watches for, and it caught them. The site was published with none of the three, which matters beyond
tidiness: terms.html is the URL Google's OAuth consent screen asks for by name, and a verification
reviewer following a footer that offers nothing reads exactly that.

The second loss was worse and nothing caught it directly. The lightbox's screenshot div came back
WITHOUT its closing tag, which is the identical bug 533b31e8 fixed and wrote a comment against: the
overlay above it never closes either, so everything after that block — the whole footer, the logo, the
Progress Report link and the copyright line — parses as a child of the lightbox and renders only while
the lightbox is open. On a page nobody has clicked a screenshot on, that is never. The page looks
complete because the section above it ends with a call to action.

Verified structurally rather than by eye, because there is nothing to see: an HTML parse of the file
as committed left `sc-if` unclosed at EOF and put the copyright line inside an `<a>`, and the merged
file closes every tag and gives the privacy link the same ancestry it has in the last known-good
version. Both restored comments now say the loss has happened twice and that the closing tag is the
first thing to check if the footer ever disappears again.

Nothing else was lost: every href, comment and tag in the last good version is accounted for, and the
only difference that remains is the vault-administrators guide link, which is a deliberate addition.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Approving a vault used to list every realm it served. It is now the first of two answers: approving a
VAULT says this registry carries this operator and mints them their one application, listing a REALM
says this particular world is served, and a realm reaches a reader only when both say yes.

The argument is §09's own. "Not a moderator. It can delist, which is the only lever it has and the
only one it should grow" — and at vault granularity that lever was unusable, because refusing one
realm meant turning off the operator serving it and every other realm they host. Per-realm listing is
the same lever at the size somebody would actually reach for.

It deliberately does not re-ask on every edit. Re-publishing is how a vault fixes a typo or refreshes
a version, and requeueing an approved realm each time would make the queue useless and the approval
meaningless; the registry holds a name, a paragraph and an address, so there is nothing in an edit a
second look could catch. A new realm arrives pending, an edited one keeps its answer, and existing
realms are grandfathered exactly as their vaults were, and marked.

Three smaller decisions fell out. A realm has no forget — that is how a VAULT gets a fresh hearing,
while withdrawing a realm is the publisher's own act and §06 keeps the record either way. The decision
route refuses a body naming both a realm and a vault rather than guessing, because a caller that meant
one and sent two has a bug and choosing for them hides it. And an absent `listing` is not served:
every record gets one from the migration or the publish path, so a missing field means something went
wrong, and `listing || 'approved'` would turn every such accident into a published realm.

The dialog now quotes the author's brief before the decision, which is what makes this lever usable at
all — but it also states the limit, and that is the part worth keeping. A name and a paragraph is the
whole of what this service holds; §07 keeps world data out on purpose and §09 says reviewing content
it does not hold is not available to it. A dialog that showed the summary and said nothing else would
imply the summary IS the realm, and an administrator who read one and approved would reasonably
believe they had reviewed something.

The padlock answers the other half: R14 made a keyed world able to PROVE a listing is its author's,
and the two were being told apart by reading two words that begin alike and sit in the same place. It
is now visible before the word is read — in the registry's badge and brief, in the approval queue, and
in the vault's own admin table where an author sees which worlds carry a key at all. Inside the badge
rather than instead of it, because the words are the exact statement and a picture is not; inline SVG
in currentColor rather than an emoji, which is a different picture on every platform and coloured by
the font. The vault's copy is display only — the publish path still reads the key from the world every
time, so a stored copy can never let a vault assert an identity the world does not carry.

Ten sabotages against the new gate, each caught by a distinct assertion. Six survived the first pass
and five were gaps in the tests rather than the code, all of the same shape: every assertion reached
the new behaviour through a PENDING vault, so the properties that only exist on an approved one —
re-publish keeping its answer, resolve-by-uid checking the realm's own gate, a record with no listing
field at all — were never exercised. The sixth, that a realm decision is credited to the session
rather than the body, could only be tested where a session exists, and was not.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Reported as "clicking Approve does nothing", and that is exactly what it looked like. A failed
decision closed the dialog and wrote its reason into the page's message box — which lives with the
realms list, above the queue. An administrator scrolled down to press Approve never saw a word of it:
the dialog vanished, the row did not change, and the tenant's actual complaint was rendered off-screen
behind them.

The report has to appear where the control was. So a failure now keeps the dialog open, prints the
server's own sentence inside it, and restores the button to its verb so the decision can be retried
once the cause is fixed. Only a decision that succeeded closes anything.

The server logs it too. The answer goes to one browser and is gone; the journal is where somebody
looks when a button did nothing, and a failure that existed only in a dismissed dialog is one nobody
can diagnose afterwards. Both the mint and revoke paths now name what went wrong before they answer.

Driven in Chromium against a tenant that refuses to create clients — the shape of a first real mint
going wrong: the dialog stays, the error reads "Auth0 answered 403: insufficient_scope. Nothing was
changed", the button says Approve again, and the vault is still pending.

Also stops sending `Authorization: Bearer ` with nothing after it when the session is a cookie. It
changed no behaviour — the cookie is checked first — but it is a header that means nothing and reads
like a bug in a capture, which costs somebody an hour exactly once.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Two things a reverse proxy hides, each of which cost a round trip in the same afternoon.

The first was the prefix, fixed in the commit before this one. The second is the one that made an
already-fixed bug look unfixed: the service runs from its install directory and never from the
checkout, so git pull followed by systemctl restart changes nothing and is indistinguishable from a
fix that did not work. deploy/setup-registry.sh now stamps the commit it installed into APP_DIR/BUILD
and server.js prints it first at boot, ahead of everything whose meaning depends on it. Running
straight from a checkout says that instead, which is its own answer. "Am I running what I think I am
running" is now a line in the log rather than an afternoon.

The remaining hazard is a REGISTRY_PUBLIC_URL that does not match where the service is actually
mounted, and nothing could catch it alone: the page knows the address it was really fetched from, the
service knows what it was configured with, and neither can see the other's. So the session answer now
carries the configured URL and the page compares it against its own mount, saying plainly what to
change when they disagree. Without that, the symptom is a 404 on a URL nobody recognises, which reads
as a broken feature rather than a wrong setting — exactly how the prefix bug presented.

It discloses nothing: a reader holding that answer is, by construction, already looking at the address
it names. A sabotage pins that the field is populated, because a check that silently comparesan empty
string to a real one passes for ever.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The sign-in shipped broken behind a reverse proxy, which is the only way anybody runs this. A proxy
mounting the service under a prefix STRIPS that prefix before the request arrives — nginx's
proxy_pass http://127.0.0.1:8790/ turns a browser's /registry/admin/callback into this service's
/admin/callback — so url.pathname describes the route inside the service and says nothing whatever
about the address a browser used. Deriving the mount from it produced /admin/login?retry=1, which is a
404 on the site root. Reported from a real deployment, where the silent attempt came back
login_required and the retry went nowhere.

REGISTRY_PUBLIC_URL is the only thing that knows where this service lives from outside, and it is
already required for the callback to be registrable at all, so it is always present on this path.
Every redirect the sign-in issues is now built from it.

This is the same class of bug as the browse page's root-absolute fetch earlier in this work, which was
fixed by deriving a mount in the page from location.pathname. That fix was right because the PAGE does
know its own address. The server does not, and reusing the shape without noticing the difference is
how the same mistake arrived twice.

The tests were the real failure, not the code. Every assertion about a redirect used a loose regex
that matched a root-relative path as happily as an absolute one, and every request in them was made
without a prefix — so the suite exercised precisely the arrangement where the bug is invisible, and
passed. They now assert the exact absolute URL for all four redirects the sign-in can issue, and the
comment above them says why the path in the request deliberately carries no prefix.

Tightening them turned up a second instance, in the return address handed back from the state store.
It is set only by this service, so it could not be an attacker's today — but a redirect target trusted
because of where it came from is one refactor away from being an open redirect, and the check costs a
comparison. Anything outside this registry's own public URL now goes to the queue, which is where the
person was trying to get to anyway.

Verified against a proxy that actually strips the prefix rather than reasoned about: sign in, silent
attempt refused, retry carrying /registry, code exchanged, session cookie set, queue read and a vault
approved — all through the mount.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Trim to the creature sets both crop edges in one press. By the time anybody reaches for it the
background has already been made transparent — keying it out is what the whole Background section
upstream is for — so the alpha channel knows exactly which rows hold the figure, and dragging two
lines by eye is doing worse, by hand, what can simply be measured.

Three details keep it from being a button that looks like it worked. It must be handed the KEYED
sheet: the raw one still carries its opaque field, every row of it counts as content, and the answer
would always be "the whole thing" — success reported, nothing changed, which is worse than a
failure. A row counts only if it holds a short run of solid-enough pixels rather than a single one,
because a provider's flat field is never quite flat and the keyer's own de-spill leaves the odd
pixel just above zero; anchoring the crop to a speck puts the edge back where it started. And the
alpha threshold is low rather than absent for the same reason pointing the other way — the rim of
the figure ramps, so demanding full opacity shaves off its outline — with a row of slack each way on
top of that, a crop one row INSIDE the figure being the fault nobody would think to look for.

It refuses rather than guessing. A sheet with nothing transparent on it is reported and the author
is sent to the Background controls; one the provider will not let us read back is reported and they
are sent to the handles; a sheet with no size says so instead of blaming the background. A failed
scan leaves the crop exactly where it was, half-applying one being worse than not running it. And it
is offered whenever there is a sheet rather than only once the crop has been moved, because it is
the first thing to reach for rather than a way back from something.

The scan is driven over real RGBA buffers rather than against a mock that answers questions about
itself: it is a loop over rows, and a loop over rows is exactly the kind of thing whose off-by-one
shows up only against actual pixels. Eight sheets are painted for it, including the two that decide
the thresholds — one stray pixel near the top, which must not drag the edge back, and a figure whose
first and last rows are half-transparent, which must still count.

One assertion in it could not tell the guard it was about from the absence of that guard. A sheet of
no size returns an error either way; without the guard the error is the one about nothing being
transparent, which sends the author to the Background controls over a sheet that has no pixels at
all. It checks the reason now, not merely that there is one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

R15's administrator half. The approval queue shipped behind a shared token because that is what the
service had; this is the answer that replaces it, and it is one login rather than two: the registry and
the website sit behind one Auth0 tenant, so an administrator already signed in there has a session with
that tenant, and prompt=none turns it into a registry session with nothing to type. There is no second
account, no second password, and no session shared between two services — only a tenant that has
already met this browser. Anybody not already signed in gets Auth0's own form, once, after the silent
attempt comes back login_required.

The exchange happens in the service rather than the page, and the reason is a line of the browse page's
own CSP. connect-src 'self' is §07's refusal made structural, so a browser-side PKCE exchange would
have meant widening it for every reader of a public page in order to serve one administrator. So the
code comes back here, is exchanged here, and what the browser ends up holding is an opaque session id
in an HttpOnly SameSite=Lax cookie. The token never reaches script at all, which is a better answer
than the one the policy ruled out — and the cookie reintroduces a CSRF surface a bearer header did not
have, which is what SameSite=Lax is there for.

The allowlist fails closed, because the alternative is the worst mistake available here. A tenant is a
directory of everybody who has ever signed in to the website, so accepting "any user this tenant
authenticates" would make every player an administrator of the registry. With REGISTRY_ADMIN_EMAILS
empty, sign-in is OFF rather than open. The address must also be one the tenant has verified: an
unverified address is a claim by whoever registered it, and matching on one would let somebody
administer this registry by signing up elsewhere with the right address.

The token verification is the one piece of cryptography this service cannot avoid, and it is done with
Node's own crypto so that Registry/ stays dependency-free. alg is pinned to RS256 rather than read from
the header, which is the oldest JWT attack there is; the signature is checked against the tenant's own
JWKS; iss and aud are compared as exact strings, because Auth0 issues iss with a trailing slash and a
comparison that trimmed one would accept a tenant this is not; and expiry is checked on every request
rather than trusted from an exchange that happened once.

A decision is now credited to the signed-in address rather than to whatever the request body claimed. A
ledger line naming whoever the caller said they were is an audit trail that cannot be relied on for the
one thing an audit trail is for. The shared token survives as the fallback — Registry/ is Apache-2.0 so
that other people can run one, and a registry whose operator has no tenant must still be administrable
— and it reports no person rather than inventing one.

One change that is about the console rather than the protocol: the session route answers 200 with
admin:false instead of 401 for a caller who is nobody. It answers "who is this", and "nobody" is a real
answer, while a 401 made every anonymous visitor's browser log a red network error on a page working
perfectly, which is how a console stops being somewhere real faults get noticed. It still discloses
only whether a sign-in exists, which a sabotage pins.

Seventeen sabotages, each caught by a distinct assertion, covering every check above. One survived the
first pass and was a gap in the test rather than the code: the clock never advanced past a session's
lifetime, so the expiry branch was never exercised at all. The whole flow was then driven in Chromium
against a fake tenant over TLS — signed out, one click, silent auth, approved, credited to the address
— with nothing in sessionStorage and a clean console.

What this does NOT do is give the publisher an identity. A publish is still authenticated by a shared
token, so the queue says "published by alice" rather than naming somebody with a mailbox, and R16's
note that the dialog cannot show the operator's email stands exactly as written.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

setup-registry.sh only wrote /etc/registry.env when the file did not exist, on the sound reasoning
that re-running it must never regenerate the publisher tokens and lock out every vault already
publishing. What that missed is the upgrade: an install predating a new setting said "left untouched"
and moved on, so REGISTRY_ADMIN_TOKEN was never generated, never appended, and never printed. The
operator re-ran the script, saw nothing, and had an approval API that was off with no error anywhere
to say why — which is exactly how it was found.

The hazard the old rule guarded against is REPLACING a value, not adding one. So an absent key is now
appended: the file keeps its own 0600 root:root and every value already in it, the generated token is
printed once, and a second run changes nothing because the check is for the key's presence. The
commented AUTH0_* block is added the same way, so an existing install also learns the five names that
let approval mint.

Verified on all three paths rather than reasoned about: a fresh install generates and prints it, an
upgrade from a pre-admin-token file appends without disturbing the lines above, a re-run leaves the
file byte-identical, and the mode stays 0600 throughout.

Also corrects "shown once" in the summary, which was true of a fresh install and false of an upgrade —
it is shown when generated, and read from the file after that.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

R16 stage 2, which was always the intended way this works — the CLI was a stopgap built because
shipping a queue with no way to answer it would have been shipping a hole that swallows publishes.

The browse page grows a sign-in below the realms, and an administrator sees the queue: each vault with
the realms it serves, who published them, whether each was signed by the key minted with it or is
merely first to claim the name, and when its address was last confirmed. Approve, Deny and Forget each
open a dialog that says what pressing it will DO, because approving is not a label change — it creates
a real application in a real tenant with a named callback, and revoking deletes one. A confirmation
that only repeated the question would be a click-through.

What the dialog may honestly say is the part worth the care. Every fact in the queue is something this
service observed: the address the server itself confirmed before the listing existed, the signature
that verified or did not, the day the address last answered, the account that wrote the record. So the
dialog states plainly that the address was confirmed by the server and that who runs that server is not
something this registry has checked. That sentence is the whole honest content of an approval, which is
a low bar on purpose — admitting an operator to a directory rather than vouching for them.

A publisher token is not an administrator token and the two sets never overlap, which is why isAdmin
sits directly beside publisherOf. A publisher writes their own listing; an administrator decides whose
listings exist at all, and a design where the first becomes the second by a check in the wrong place is
one where every operator can approve themselves. For the same reason the admin token's ABSENCE turns
the API off rather than open, which is the opposite of how the publisher map defaults: an open
publisher registry is a reasonable thing on a LAN, and an open approval API is never anything but a
mistake.

The queue is not a public read. It goes out without the Access-Control-Allow-Origin the read API
carries — a game resolving an exit runs on somebody else's origin, an approval queue does not — and
with no-store, because a shared proxy holding a queue is a queue somebody else can read. In the browser
the token lives in sessionStorage and travels as an Authorization header, never a cookie: a header is
not sent automatically so there is no CSRF surface, sessionStorage dies with the tab, and the page's own
CSP leaves injected script nowhere to send it.

Deciding in-process also retires the two-writer race rather than mitigating it, which is the real
argument for this being the intended path: there is no second copy of registry.json to lose a decision
to. The mitigation stays for the CLI, which stays for a box whose operator would rather not put an
admin credential in a browser.

Nine sabotages against the new surface, each caught by a distinct assertion, including the two that
would be quietest: a publisher token being accepted as an administrator's, and an absent admin token
reading as open. The page itself was driven in Chromium against a live registry — sign in, queue,
dialog, approve, realms listed — with no console errors.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The CLI edits registry.json while the service is running, which made a second writer real for the first
time, and the instruction that shipped with it — restart the registry after deciding — named the
visible half of the problem while concealing the serious one.

Visible: the service went on serving its own copy, so an approval appeared to do nothing until a
restart. Concealed: the service serializes its WHOLE state on every publish and every heartbeat, so the
next one wrote its stale copy back over the file and silently undid the decision. An operator who
approved a vault and then received a single heartbeat before restarting lost the approval, with nothing
anywhere to say so. That is a data-loss bug dressed as a documentation note, and the note is what kept
it from being noticed.

The store now records the file's size and mtime whenever it reads or writes, and re-reads when they
have moved. Before every write it checks unconditionally, because that is the path that loses a
decision rather than delaying one; on reads it checks at most every couple of seconds, because this
store's own header promises that a resolve is a map lookup with no I/O at all and a human approving a
vault can wait. The check happens BEFORE the mutation rather than inside _save(), which the tests pin
directly: refreshing around the write would reload the file over the very change being written, so the
publish would vanish and the save would persist its own undoing.

RegistryStore takes an injected clock for this, like lifecycle.js and like search()'s nowMs, because
the branch worth testing is the moment the throttle lapses and a store reading its own clock cannot be
asked about it.

Two of the first five sabotages against this survived, and both were gaps in the test rather than in
the code. The clobbering assertions happened to follow a read that had already refreshed the service's
copy, so they said nothing about whether a write checks for itself; and nothing exercised decideVault
from two processes at once, which is exactly what the stage 2 web surface will do while the CLI still
exists. Both cases are now written the way the failure would actually arrive — a write landing with no
read in between.

It is a mitigation rather than a transaction, and the document says so: two processes writing one file
still race, and the window is now milliseconds rather than the service's whole uptime. Stage 2 removes
the second writer, which is the real fix.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

R16 stage 4, the registry half. Approval mints an application; the operator has to end up holding its
client id, and the alternative to this is an email. So an approved vault is told its id on the two
answers it already receives — the publish it made, and the heartbeat it sends once a day.

The heartbeat is the one that matters, and it was nearly left out. A vault approved AFTER it published
would otherwise not learn its id until it published again, which for a finished world could be never;
the heartbeat is the only call a vault makes on its own schedule without anybody asking it to, which
makes it the only channel that reaches an operator who has gone back to writing their world.

That channel is unauthenticated, so the reasoning for putting a client id on it is written down beside
it. A client id is an identifier rather than a credential — it travels in every /authorize URL and
every address bar. What would make publishing one dangerous is a client several parties can name, and
refusing exactly that is the whole of R16's decision: an operator's callbacks are registered on their
own client and nowhere else, so an authorization request naming this id can only redirect to this
operator's own vault, which is where the code was going anyway. The shared-client design is the one
where knowing an id is worth something.

The id is handed out on STATUS and never on the field being present, which looks redundant because the
CLI clears the field whenever it deletes the application. It is not redundant: a half-written denial,
or the stage 2 surface forgetting, leaves a record naming an application that no longer exists, and a
registry reading the field would go on publishing the id of a credential it had destroyed. The test
now covers that case directly — a vault denied WITHOUT clearing the field — because the version that
only tested the CLI's own path proved nothing about the guard, the field having already been gone.

The other sabotage that survived the first pass was mine rather than the code's: it replaced a
conditional spread with one that produced an empty string, which the spread's own truthiness guard
then omitted anyway. An absent field and an empty one are different answers, and the assertion that
they are was only being exercised by accident.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

R16 stage 3. Approval now creates an Auth0 application belonging to one operator, whose only public
callback is that vault's address, grants it the player API, and hands back a client id. The operator
opens no dashboard and types no URL, which was the whole promise of the section.

Everything the design argued for is a field in one request, so the request is where the reasoning
lives. The mode is NAMED rather than inherited, because until 23 October the default is permissive on
an eligible tenant and an inherited default would hand back a client with OIDC, no forced client grant
and no tpc_ prefix — all of it invisible. The grant types are authorization_code and nothing else,
which is the entire mitigation for the one real power this shape gives an operator: without the
refresh grant they hold a session while the player is present and no credential after the player
leaves. The client is public, because strict mode makes PKCE mandatory and a confidential one would
mean delivering a secret to a stranger over a channel this project does not have. And the API grant
names one client_id explicitly and never default_for, which applies to every third-party client in the
tenant, present and future, and is the single field that would quietly hand each approved operator
whatever audience it named.

Two things are checked on the ANSWER rather than assumed from the request, because asking for a
property and trusting it was honoured is the mistake this area has already produced twice. A client id
without the tpc_ prefix is a permissive client whatever was sent, and a response carrying a secret
means the client is confidential after all, making this registry custodian of a credential it never
meant to hold. Both are deleted rather than recorded, and the secret never reaches the error string,
which outlives the rotation.

The two orders are the safety and neither is arbitrary. A mint that fails its grant deletes the client
it just made, because a third-party client with no grant can reach no API at all — an application that
exists, belongs to somebody, and cannot do the one thing it was made for, whose id the next approval
would read from the ledger and never retry. And a revoke deletes the application BEFORE dropping the
record, because failing the other way round leaves a live credential belonging to somebody who has just
been refused, with nothing left on disk that remembers it exists. When the tenant cannot be reached,
the command changes nothing and says so; a half-revoke reads as done, which is worse than a failure.

None of it is required. Registry/ is Apache-2.0 so that other people can run one, and a registry with
no Auth0 credentials approves vaults and mints nothing — a legitimate way to run one, distinguished in
the code from a half-set environment, which is somebody's mistake and names every missing variable.

Nineteen sabotages were run against the tests and each is caught by a distinct assertion naming the
failure. Two did not survive that and were the tests' fault rather than the code's: a revoke asserted
with a bare await escaped to the file's own catch and reported "the test itself threw", which names no
property and passes for a failure; and the assertion about dropping a client id tested only the case
where the field was already absent, so it passed against a store that had lost the preserve branch
entirely. The load-bearing half — that re-approving a vault which already has an application keeps it,
since the CLI passes no id in that case — was not tested at all until now.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

An Auth0 API identifier is an opaque string that nothing resolves or fetches. It was chosen here under
the impression that it needed a certificate on the host it names, which is not so — it needs no
certificate, no DNS record and no route behind it, and is written in URL form only because a name built
from a domain somebody owns is easier to keep globally unique. The identifier cannot be changed after
the API is created, so it is recorded here as a name chosen once and pinned by exact string wherever it
is checked, under the same rule Website Login states for the issuer: an aud comparison is an equality
test, and a tidied trailing slash is a refused login.

The consequence worth writing down is the one a later session would break innocently. The string
occupies a path on a host that serves real routes, beside the registry's own /registry mount, so that
path is now spoken for. Nothing breaks if a real page appears there, because nothing in this design
ever requests the URL — but the confusion runs in the dangerous direction, where somebody notices that
the audience appears to 404 and goes looking for a service that was never meant to exist.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Auth0 changes the default for third_party_security_mode on POST /api/v2/clients from permissive to
strict on 23 October 2026, and only for tenants that were using third-party applications before 23
April 2026. Until then, a mint that omits the field gets a permissive client on such a tenant: OIDC
available, API access following the API's own policy rather than requiring an explicit grant, and no
tpc_ prefix. Every property the design depends on, absent, with nothing failing to say so.

The property is set at creation and cannot be changed, so the repair for a window of wrongly-minted
clients is not a patch but recreating each one, which invalidates the user grants and refresh tokens it
held and has to be coordinated with the operator. That is expensive enough to be worth a line of code
now: approval sends the mode explicitly on every create, and asserts the tpc_ prefix on the response
before recording the client id. Checking the answer rather than trusting the request is the whole
point — this is the same shape as checking a capability and not its prerequisite, which has cost this
project twice already in this area.

Two things found alongside it. Legacy Rules are not supported for strict third-party applications and
error out, so a tenant with an active Rule cannot sign a player in to an operator's vault until those
Rules are Actions; that fails loudly, which is the good kind, but it should be established before the
first approval rather than at the first crossing. And Auth0's migration guide instructs setting up
default API permissions before adopting strict mode — advice aimed at Dynamic Client Registration,
where clients appear with nobody present to grant them anything. This registry mints each client itself
and writes that client's grant in the same breath, so following the guide literally would create the
one client grant that hands every approved operator whatever audience it names. The API's Default
Permissions for Third Party Apps stays Unauthorized, and now the document says why somebody reading the
guide should not change it.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Two questions were outstanding before stage 3 could be written: whether an approved operator can be
denied a refresh token, and whether they can be stopped from requesting a token for the registry's
audience. Reading Auth0's own documentation answers both, and turns up a third thing neither document
had accounted for, which changes the mechanism rather than the configuration.

A third-party application created through the Management API is created in enhanced security mode,
with the mode set at creation and immutable, and enhanced security mode does not support OIDC. No
openid, no profile, no email, no ID token. So the operator's vault cannot be handed an identity
document and must instead request an audience and verify an access token against this tenant's JWKS.

That is Website Login Decision 7's mechanism exactly, which means that decision is absorbed rather
than parked — its verification half is what the vault now builds, and only its no-registration half is
dropped. The registration it brings back is also what repairs that decision's one serious flaw. It had
to collapse every vault into a single shared audience precisely because it refused to register
anything, and it named the cost itself: a token minted for a player is accepted by every vault, so an
operator who receives one can replay it elsewhere as that player, undetectably. With a client and a
client grant per operator, aud goes back to doing the job it exists for, and the hole DPoP was named
to patch does not arise.

The refresh-token question closes at mint rather than in the tenant. grant_types is settable on
POST /api/v2/clients, so a client minted with authorization_code and without refresh_token cannot use
the refresh grant. Two routes that look like the answer are recorded as not being it. The API-level
Allow Offline Access toggle is global, so using it to restrain operators would also restrain us. And a
Post-Login Action calling api.accessToken.setCustomClaim('scope', ...) to strip offline_access does not
work at all — it writes a custom claim that happens to be named scope, which is not the grant, and the
refresh token is issued anyway. That one is worth the words because its failure is invisible in the
obvious test: the scope claim reads correctly while the credential it was meant to withhold sits in
somebody else's hands. It is an assertion that passes against a sabotaged implementation, and it is
worse than no mitigation because it looks like evidence.

The audience question needed no answer. A third-party application always requires an explicit client
grant to reach any API, even one whose policy is Allow All, and cannot be granted a system API at all.
So the closed state is the default and R15's invariant holds from this end without being configured to.
There is exactly one way to break it — a client grant written with default_for: third_party_clients,
which applies to every third-party client present and future — so approval writes per-client grants
with an explicit client_id, always. That is the one mistake in this design that would be quiet and
total, which is why it is written down beside the thing it would undo.

One consequence is an improvement rather than a cost. With no OIDC scopes there is no email claim to
leak by accident, so sub crosses and the address does not, by construction rather than by discipline.
An operator who genuinely gates by email has to add it as a custom claim, which makes that a
deliberate and visible act — and it is exactly the case Decision 7 had already identified as the one
where asking the player is natural.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

R16 and Website Login Decision 7 have been two candidate routes to the same thing: a player signed in
at thelostrealms.ai able to play on somebody else's vault without that operator running an Auth0
tenant. R16 approves the operator and mints them an application; Decision 7 makes the vault a resource
server and registers nothing. Both documents said Decision 7 was the destination and R16 the
scaffolding, on the reasoning that fewer registered objects is better.

Reading Auth0's own documentation on third-party applications reverses the ranking, on a finding
neither section had weighed. An operator's minted application is a THIRD-PARTY application, and Auth0
requires a user consent screen for those — always, and it cannot be skipped — naming the application
and the scopes it asks for. That is precisely the per-destination consent prompt Decision 7 spends four
paragraphs constructing by hand, after concluding in its own words that "Auth0's consent screen names a
registered client and there is none, so the consent has to be ours". Under R16 there is one. So the
shape carrying more registered objects is the shape where the identity provider draws the consent
rather than the relying party, which is the party with the least standing to draw it — and it is worth
most in exactly the case that matters, an operator we approved and should not have.

The argument on the other side did not survive being checked, and the retraction is recorded rather
than quietly dropped. Tenant scale was asserted as a reason to prefer Decision 7: no documented cap on
applications per tenant could be found, and Auth0 ships custom rate-limit policies aimed specifically
at "applications you do not control, such as partner integrations", which is evidence the pattern is
expected at scale rather than tolerated. An argument that was made and found empty is worth more to the
next reader than one that was never made.

One real delta survives and it is mitigable rather than structural. Under R16 the operator exchanges an
authorization code, so they hold tokens for every player who signs in there — including a refresh token
if their client may ask for offline_access. That closes with tenant configuration: deny offline_access
to operator clients, and restrict the audiences they may request. Both are now in the stage 3
checklist, and neither is optional, because without them a low-bar approval carries a standing
credential and this choice is simply wrong.

Decision 7 is parked rather than abandoned, with the three triggers that would revive it written down
so that parking is a decision and not a drift. Everything in it from "the player may decline" onward is
marked as surviving regardless: the refusal rules, what a prompt may honestly show, and the rule that
the registry publishes what it observed and never what it inferred about somebody else. Those are about
the crossing rather than the token, and R16 inherits them unchanged.

Two corrections in passing. PAR is closed to us twice over, not once — third-party applications may not
send request_uri or request at all, on top of PAR being confidential-clients-only. But the same
parameter list permits authorization_details and dpop_jkt, so "RAR is not available to us" is probably
too strong; the sentence is left standing with a note, because an allowed parameter is not a
demonstrated feature and nobody has tried it in the tenant. And a blast radius worth knowing before
stage 3: a third-party application can only authenticate through domain-level connections, and a
promoted connection is reachable by every third-party application in the tenant. There is no per-client
connection mapping to fall back on, which is an argument for the approval bar being higher than
"they published something".

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The Culture tab's Heraldry and NPC-History pickers shipped weeks ago and are already
documented in the Dungeon Master's Guide book, but the in-game Field Guide's Culture
section stopped after Religions and its Editing Beings section never grew a History
picker to match the Folklore one beside it — so a DM reading the Field Guide alone
would not know either existed. The dialect mechanism (a language's `parent` field,
built as of 10 Sep 2026) was linked to its design doc but never actually explained in
guide.html, unlike the Handbook book which already spells it out in the Languages field
table. Also documented the Tools menu's Download Media Pack and Download Vault Pack,
which move a world's already-hosted art out as a zip and had no mention in either guide
despite being built and shipped.

The Player's Handbook's equipment chapter has said "thirteen places" in its own body
text since the Belt and Leggings slots were added, while its table of contents and
chapter heading still say "eleven slots" from before that change — a player counting
along the list in front of them would find two more than the chapter's own title
promised. Also gave its Languages paragraph a sentence on dialects, since a player
who runs into a second card for what reads like the same tongue had nothing in the
book explaining why.

No changes needed in the Dungeon Master's Guide or the Modder's Guide: both were
checked against every Designs/ doc touched since 16 Sep 2026 and already reflect
their shipped state, including the sprite sheet editor, Districts, Culture's built
and disabled tabs, Hidden Beings, and the event bus roster.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UJNQZHKSnW5cFPfEGYqJdf

Two omissions from the commit before this, both of which would have surfaced as silence rather than as
an error. The installer names the files it copies one by one — deliberately, so a file list that
changes is caught rather than guessed at — so vaults.js would simply not have reached the server, and
an operator with a vault waiting on review would have had no way to answer it. A CLI that has to be
scp'd to be used is a CLI an operator turns the gate off instead of using.

And the setup script now ends by saying the gate is on, because the failure mode of not knowing is
that a publish succeeds and the browse page stays empty, which reads as a bug and not as a queue. It
prints the three commands, including the restart — the service holds its own copy of registry.json in
memory and its next save writes that copy back over a decision made underneath it — and it says that
worlds listed before this arrived were grandfathered and need nothing.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

This is stage 1 of R16 in Designs/realm-registry.html, and it is the half that survives the rest of
it being retired. A world published from a vault address the registry has never seen now lands
pending: stored, owned, heartbeating and swept, and not served to readers. An administrator approves
the vault and every world it serves appears at once.

Per vault rather than per world, which was the clarification that made the idea worth building. What
approval is ultimately for is an operator-shaped thing — stage 3 mints an Auth0 application whose one
callback URL is that vault's login address — so approving per world would ask one human the same
question every time an operator published a second realm, and would leave N answers to a question that
can only have one. The key is therefore the origin, scheme host and port, because that is the
granularity a callback registration actually has. Two paths on one host are one vault; a different port
is a different server; the case of a hostname and an elided default port are not differences at all. A
vault that MOVES is a new origin and is pending again, which is correct rather than a rough edge — an
operator on an ephemeral tunnel hostname meets it every time the tunnel restarts, and nobody approved
the new address.

A publish is never refused for this, and that is the part it would be easiest to get wrong. Refusing
would leave nothing for an administrator to look at, which is the whole of what the state exists for,
and it would surrender the uid claim to the next publisher who asked — the squatting case R14 exists to
close, reintroduced by the review queue. For the same reason the filter sits in the read API rather
than in the store: the sweep, the heartbeat, origin proof and a withdrawal all still see a pending
record, so a listing waiting on review does not quietly lapse while it waits. The gate is on both
doors, browse and resolve-by-uid, because a uid is seven characters and its author knows it; hiding a
world from a listing while answering for it by name would be a speed bump with a comment above it. The
refusal is 403 rather than 404 so the author is not sent looking for a bug that is a queue, and it does
not name the vault address, which is the thing being withheld.

The gate follows the publisher tokens unless an operator says otherwise. A registry with no accounts is
a private one with nobody to do the approving and nobody to protect from, and switching this on there
would break the two-terminal development recipe in Registry/README.md with a queue nothing can service.

Upgrading into it loses nothing: a registry.json written before this holds worlds and no vault records,
and reading it under the new rule would make every listing that already exists vanish behind a review
nobody was there to perform. Those vaults are grandfathered in and marked as such, so the ledger never
claims a human looked at them. The migration runs once and only backwards — the publish path writes the
vault record before the world, so a world with no vault record can only have come from an older build.
The test pins the other half of that too: a DENIED vault whose world is still on disk must not be
re-approved by the same pass, since nothing is ever deleted here.

Registry/vaults.js answers the queue from the machine the service runs on, because the page with the
Approve button needs an administrator sign-in that does not exist yet (it is R15), and shipping the
state with no way to answer it would be shipping a hole that swallows publishes. Authentication by
being on the box is the strongest this directory has today.

Server/test/test_registry_vaults.js carries it, and fourteen sabotages were run against it — each
caught by a distinct assertion naming the failure. One assertion did not survive that: it claimed to
pin the load-time status filter and was in fact passing on a downstream equality check, so deleting the
line it named left the suite green. It now asserts absence rather than non-approval.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Reported as monsters rendering smaller than they should, and the diagnosis in the report was right:
the providers return a frame with a great deal of empty air above and below the figure, and how much
varies by creature — a spider leaves most of its cell empty, a standing skeleton very little.

What makes that a size bug rather than a framing one is monFit. The quad is w by h squares, h is
what the author typed, and w is derived from one frame's aspect — and then the engine draws the
WHOLE FRAME onto that quad. So a creature occupying 59% of its frame is drawn at 59% of the height
that was asked for: 0.9 squares typed, 0.53 standing. Nothing anywhere is wrong and no number on
screen disagrees with any other, which is why this had to be reported by somebody looking at a
corridor rather than caught by anything.

So the fix is a crop and not a multiplier: trimming the sheet changes the frame the aspect is
measured from. Two horizontal edges over the sheet, the cut lines' idiom turned ninety degrees, with
the discarded bands shaded — a line near the top edge of a sheet reads as a border, while a darkened
band above it reads as "this goes". It is one band off every frame rather than a per-frame decision,
because the empty air is a property of the cell the model painted in and that is the same cell in
all of them. The band is rounded to whole pixels, a canvas sized 170.4 being silently floored so
that the last row of every frame then comes from half a source row.

It joins the cuts in every other respect, and that was most of the work. The rebuild now asks
whether EITHER axis has moved: gated on the cuts alone, a crop with even cuts does nothing at all
while the report cheerfully agrees with the author, which is the version the test refuses. It rides
in the authoring record and is restored under the same "already in the picture" flag as the cuts,
since a sheet saved cropped IS the band and taking the same fractions off it again eats into a
figure that is now filling its frame — and the author need only press Save for that to be the stored
one. It has its own reset, offered only when it has been moved, because "even cuts" says nothing
about a crop and one button for both would undo an adjustment nobody asked about.

The headline claim is checked against the engine's own arithmetic rather than described. Every other
assertion here says the sheet was rebuilt correctly; none of them says the rebuild fixes anything.
So the test lifts monFit and drives it: a creature filling 59% of a 256x512 cell stands 0.53 squares
against a height of 0.9, cropping to the figure puts it at 0.9 exactly, and its width-per-height is
unchanged to four decimal places — a crop that altered the creature's proportions would be a new bug
wearing the old one's clothes. A crop wide enough to overflow the one-square corridor is still
clamped and still says so, because the dialog passes that sentence to the author.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

R16. A vault whose operator has no Auth0 tenant cannot sign players in, because its callback URL is in
nobody's allowed list but its own operator's — and a stranger cannot add an address to somebody else's
tenant. The answer is to make a publish a request: a world from a vault this registry has not seen
lands pending, an administrator sees it with the world and the address, and approving it calls the
Management API to register the callback. No dashboard, no typing, and the error that mechanism exists
to prevent is a mistyped URL nobody notices until a login fails.

What makes it better than the same click done by hand is that the fact being approved has already been
proven. Origin proof called that address and had it confirm it serves that world before the listing
existed, so the callback being registered is one the registry watched the operator demonstrate control
of. The commonest way a callback allowlist goes wrong is an address nobody checked.

The decision is that approval mints an application PER OPERATOR rather than appending a URL to one
shared client, and the reason is a specific failure rather than tidiness. A client_id is public — it is
in every browser — so with one shared client anybody can construct an authorize request naming any
approved operator's callback, send it to a signed-in player, and have the code land at that operator's
vault, which holds the verifier because it built the request. Every approved operator would be able to
take tokens for any player they could get to follow a link, and approval is deliberately a low bar. An
allowlist of callbacks on a shared public client is a list of parties who may impersonate the login.

Per-operator applications also make revocation a delete rather than an edit to an array that concurrent
approvals are racing to write, and they sit inside the identity model already settled rather than beside
it: Native App Login §13 chose one tenant and several applications, so one account, one sub and one
player identity are untouched. The cost is one field the vault already reads from its environment.

It is written down as a bridge and should be built to be retired. Website Login Decision 7 removes the
need for any of it by making a vault a resource server rather than an Auth0 client, at which point
nothing is registered and nothing is approved. So the approval record is the durable part and the Auth0
application is the disposable one, and nothing outside the approval step should learn applications exist.

Two gaps are recorded rather than glossed. The dialog cannot show the operator's email, because a
publish is authenticated by a publisher token and the registry learns an id rather than a person — R15
is what changes that, and until it does an email is a self-declared claim that must be labelled as one.
And the Management API credential is the most powerful secret this service will hold: create:clients can
modify any application in the tenant, the website's included, so it belongs in the registry's
EnvironmentFile at 0600 beside its publisher tokens, scoped to the minimum, with approval carrying an
audit line naming who approved what.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The dialog scrolls, so its title scrolled away with everything else — and the title is the only
thing naming the monster being edited, which on a page of pictures with no name on it is a real
question. It is pinned now, and a × sits at its right-hand end, because the way out of a scrolled
dialog should not be somewhere you have to scroll to. It runs the same close Cancel runs and says
"close without saving" rather than "close": this dialog keeps no draft, so a close is a discard, and
calling it anything else would be a promise it does not make.

Pinning it has one trap that looks correct until you scroll. `position: sticky` pins to the top of
the SCROLLPORT, which is the scrolling element's padding box — so a dialog keeping its 20px of top
padding parks the header 20px down and lets the content scroll visibly through the strip above it.
The padding moves onto the header instead, which is the thing that has to cover that strip. The
header also needs a background of its own and a stacking order: without the first the sheet slides
under the words, and without the second the cut handles and the pager, which both paint over their
neighbours, are not guaranteed to lose to it.

One assertion in this change was measuring the right thing by luck and was caught by its own
sabotage. It sliced the header from its opening tag to `<div class="sheet-ed">`, which is where the
next section starts rather than where the header ends — so a close button moved OUT of the pinned
header and left loose in the gap between the two still read as being inside it, which is the single
question that slice exists to answer. It cuts at the header's own closing tag now, and the sabotage
fails on both assertions about where the button is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The author's half of the public-doors consent, and the half that makes the other half usable: the vault
could read these marks before this and nothing could set one. Editor › Rooms gains a "Public door"
toggle per room, a chip in the card header when it is on, and the field behind both.

IT LIVES ON THE ROOM, and that is the decision rather than a detail. serializeWorld is an allowlist
whose own comment says "Named here or it does not exist", and a world-level map must be named in three
places or it vanishes on reload — the failure that cost this codebase its ailments map once. A room
field needs none of that, because rooms are written whole as `rooms: s.rooms` and come back through
reInstance, which copies the snapshot's own keys rather than rebuilding from named ones. That is safety
resting on how two other functions happen to behave, so Tests/test_public_door_mark.js asserts the
round trip rather than trusting the comment: mark a room, serialize, rebuild, and it is still open —
while every room nobody marked is still closed, which is the direction that would be worse to get wrong.

Being in the world data is also what makes the mark portable, and portability is the point. Download
Vault Pack exists so a realm can be handed to somebody else, so a door marked on the HOST would mean
importing a world opened every door its author had marked, on a machine that author has never heard of.
Marked here, the consent travels inside every copy and belongs to the person who wrote the place.

Strictly `true`, in three places that must agree: the constructor defaults false, reRoomObj backfills
`=== true` for every room authored before the field existed, and the toggle stores `!!checked`. A room
holding 1 or 'yes' would be a door this screen draws as open and Server/world-store.js refuses to
publish, which is worse than either answer alone. The chip is in the header rather than only inside the
card because a setting you have to open a card to see is one nobody audits, and the failure worth
preventing is a door left ajar in a realm its author believes is closed.

The toggle went in between Weather and Visited and test_weather_imagery.js failed, because it pins that
adjacency in the source as a deliberate layout decision. It now sits to their left, and the reason is
written where the next person to add a toggle to that row will read it.

Five sabotages fail named assertions: a room defaulting to open, restore reading truthy as consent, the
toggle storing what it was handed, the header chip never rendering, and the mark being dropped on the
way into a save.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The knowledge needed to stand a vault up was spread across Server/README.md, SECURITY.md, PRIVACY.md,
the Designs pages for the vault and the media store, and — for the parts nobody had written down — the
source. Server/README.md is the reference and stays it, but a reference is organised by subsystem, and
somebody installing for the first time needs the order things want doing in: keys, then HTTPS, then a
login, then worlds. Handbook/vault-administrators-guide.html is that order, in the Handbook's house
chrome (the Field Guide's sidebar, search box and back-to-top, shared with the DM's and Modder's
guides), across nineteen sections and three appendices.

It carries a test, which is unusual for a book and is here for one reason: two of its lists are
ROSTERS, and a roster pasted into a document is the failure this repository has hit most often. A
missing environment variable does not read as an omission — an operator follows a complete-looking
appendix, never sets the one it forgot, and concludes the feature behind it does not exist. So
Tests/test_vault_guide.js reads both rosters out of the server instead of keeping its own copy:
every `env.NAME` the vault actually reads, scanned out of Server/*.js, and every id in
core.MANAGED_KEYS. It checks the reverse direction too, because a guide naming a variable nothing
reads sends somebody to set a value that will be ignored, and they will believe it took effect.

Appendix A is therefore more complete than Server/README.md, which omits eleven variables the code
reads — VAULT_CALL_LOG, VAULT_CALL_LOG_QUIET, VAULT_DEBUG, VAULT_ENV_FILE, VAULT_GENERATIONS_DIR,
VAULT_GENERATIONS_KEEP, VAULT_MEDIA_PROVENANCE, VAULT_PROVIDERS_FILE, VAULT_SETTINGS_FILE,
VAULT_USAGE_FILE and VAULT_USAGE_HISTORY_FILE. None of those was hidden on purpose; they simply
arrived after the paragraph that would have mentioned them.

Three Auth0 facts are pinned against Server/identity.js rather than against a memory of it: the
callback path, the logout returnTo, and which of the two secrets the vault uses. The logout row earned
its assertion this week — an Allowed Logout URL of `…/admin` looks like the obvious answer, Auth0
matches the value exactly, and the result is that every sign-out fails while sign-in keeps working, so
nothing points at the setting. The guide names the wrong value as well as the right one.

The claims about what a vault never does are checked against PRIVACY.md, so the book cannot drift into
promising more than the project is prepared to defend. The new book is registered in
test_content_notice.js's BOOKS list, which is what holds it to the Game Content licence, and has a
provenance entry recording that it was drafted here from this repository's own material.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

Which image provider made a sheet is the thing an author changes when a sheet comes back wrong —
some are simply better than others at a flat-lit row of equal frames, and which one is better varies
by creature. That choice was two pages and a settings dialog away. It is now under the sheet, on the
page where the judgement is made, with Regenerate beside it, and it replaces a sentence saying the
cut lines could be dragged: an instruction, which is the kind of thing that now lives in the Guide,
and the space is worth more as the control.

The Builder names no provider of its own. It asks the game window, which answers from
slotProviderIds('image') — the same call the game's own Settings dropdown is built from, so the two
cannot disagree, and a vault's custom providers arrive with it. A list written into the Builder
would go stale the day a provider was added, and go stale invisibly: the dialog would offer four
names while the game had five, and the fifth would simply never be tried. A provider with no key is
offered and labelled as having none rather than dropped, because it still works — the game falls
back to its keyless one for the call and logs the substitution — and dropping it would make the
dialog disagree with Settings about what exists.

The host end is a per-call override, and three things about it carry weight. It is VALIDATED against
the slot's own roster, because what arrives from another window is a request, and an unchecked id
reaches IMAGE_PROVIDERS[undefined].generate. It is still subject to the key-missing fallback, so a
provider picked here with no key behind it drops to the keyless one and says so exactly as one
picked in Settings does — otherwise the dialog reports "the provider returned nothing" for a missing
key. And it WRITES NOTHING: pressing Regenerate must not re-point every portrait the game paints
afterwards, from a control that says nothing about portraits. Which provider painted a monster is
kept in that monster's authoring record instead, so reopening its sheet comes back to that one.

Regenerate runs the generate path itself rather than a second copy of it, on the rule this dialog's
own header states: a Regenerate that built its own request would be a second place for the provider,
the name and the prompt to be read from. The options are built as elements rather than interpolated
into innerHTML, which is the one place in this file where that distinction matters — every id and
label crossed a postMessage from another window, and the Builder has no escaping helper because
nothing in it has ever needed one.

Two assertions elsewhere broke on this and were pinning spelling rather than properties.
test_portrait_style_ref.js matched `const extra = …` byte for byte, and a second per-call option
merged in after it turned that into a `let` — a change that left the property it is about exactly
intact. It matches without the keyword now, and the same file gained the matching assertion for the
provider option, which stays out of that ternary for the same reason the abort signal does: a caller
can want a particular provider for a plain prompt, for one with a style reference, or for one with
an init image.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The first piece of a crossing, and it is the far side: a world learning to declare its doors. Region
Files §13 designs the whole of it and the status line on that page still reads six phases with four
outstanding, so nothing here is the crossing itself — no exit points across yet, and `beyond` is still
fifty-six occurrences of ordinary prose. What this adds is the declaration a crossing would arrive
through, which is the half that can be verified today against a live registry.

TWO CONSENTS, FROM TWO PEOPLE, AND NEITHER SUFFICIENT. The author marks rooms — publicEntry, in the
world data — so the marks travel inside a Vault Pack and are the author's statement about their own
realm. The host sets accepts, on the vault, about this machine, because they are the one who will serve
the traffic. buildWorldDescriptor joins them, and publishes doors only when both agree. The direction
that matters is the permissive one: Download Vault Pack makes worlds portable on purpose, so without
the host's half, importing somebody's realm would open every door its author had marked, on a machine
that author has never heard of. The vault's half defaults to off and is carried across a re-publish for
the same reason `public` is — an author saving their world is not their host deciding to take visitors.

DOORS, NOT MAPS. An entry carries a room id, a name and a region. Nothing else. A registry enumerating
rooms would hand any reader a walkthrough of somebody's realm, which §07 refuses, so a room's prose
stays where it belongs — served by the vault at the moment of arrival, for a room whose author opened
it. The list is capped and truncated rather than refused, because a world with three hundred marks is a
bulk tick rather than an attack and refusing the descriptor would take a realm off the map for a
mistake its author cannot see.

A room field rather than a world-level map, and the reason is the rule this file warns loudest about.
serializeWorld is an allowlist and a new map there must be named in three places; a room field needs
none of that, because rooms serialize whole (`rooms: s.rooms`) and come back through reInstance, which
copies the snapshot's own keys. That is safety resting on how two other functions happen to work, so
the test says so rather than the comment alone. Room ids are the right address for the same reason the
engine already uses them for exits: nothing renames one, so an entry is exactly as durable as an exit.

worldDescriptorProblems gained the shape checks, and they run at both ends because that function does —
the vault before sending so an author hears it at the button, the registry on arrival because a
publisher's validation is a publisher's claim. The rules are about shape, never truth: whether a named
room exists is a question only the hosting vault can answer, and it answers it when somebody arrives.

Five sabotages were confirmed to fail named assertions: reading consent as truthy rather than === true,
publishing the author's doors without the host, defaulting accepts to on, keeping a stale door list
instead of re-deriving it, and letting a room's description into an entry.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Regenerated from full git history (the checkout was unshallowed first, since
gen-progress-report.js reads `git log` directly and a shallow clone would
silently under-report commits, days active, and the first day of the span).
Now covers 4,164 commits across 84 days, June 30 through September 21.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K2tD17mwichLxf97FcGHpU

Decision 7 named Rich Authorization Requests as the primary route yesterday, on the strength of two
properties that are real: Auth0 renders authorization_details in a customized consent prompt, and binds
the granted detail into the issued token. That would have named the destination vault on screen and made
a token useless at any other vault, in one mechanism. The plan was to check tenant availability.

Availability is not the question. For the authorization code flow RAR requires PAR, and PAR is
documented as supporting confidential clients only — Client Secret, Private Key JWT or mTLS. The website
is an SPA authenticating with None, which is the whole argument of §03, and the vault is a Native public
client for the reason the desktop bundle carries no secret. No tier changes that. Buying RAR means
making the website confidential, which is §11's BFF variant and puts back the client secret §03 spent
its length removing — not a trade worth making for a consent screen.

DPoP is available and is the half that mattered. Auth0's own comparison assigns mTLS to confidential
clients and DPoP to public ones, naming SPAs and mobile apps; the access token carries a cnf.jkt
thumbprint of a key the browser holds, so a vault cannot present it elsewhere and can verify the binding
itself; and a resource server may require sender-constraining for public applications specifically,
which is exactly the vault's position. So the replay hole closes with the standard mechanism on the
client type already in use, and what falls back to us is the consent prompt — which was the plan before
RAR looked possible, and which has to be ours anyway because it must disclose the operator and address
as well as the data.

The correction is recorded rather than quietly rewritten because the mistake has a shape worth keeping:
the capability was checked and the prerequisite was not. It is the second time in one session that
reading one more line of documentation changed an answer arrived at by reasoning.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The previous commit left showing a resolved geographic location beside a listing as parked — "nothing,
for now", and "an improvement to the information". That is the wrong record, and the difference matters
here more than usual: a parked idea gets picked up later by somebody who reads it as a good one waiting
for a spare afternoon, while a declined one with a principle attached does not. It is declined, and the
principle generalises well beyond geography.

Every signal this design would show a player is a record of something the service actually did. We asked
the vault whether it hosts the world and it answered. The signature verified against the key bound to the
uid, or it did not. Nothing has confirmed this listing for six days. This is the address the publisher
gave us. A player can check all of those, and if one is wrong we are wrong about our own conduct rather
than about a stranger's.

A country from a geolocation database is not of that kind, and neither is a risk rating, a trust score or
a verified-operator badge. Each is an assessment we authored about a third party's server or their
country — approximate, stale, wrong for anything behind a CDN, and ours to defend the first time it is
disputed. Worse, it is an opinion presented as a safety signal, which is the form in which an opinion
does the most damage, because the reader takes it for a fact somebody checked. The judgement is the
player's in whole: they may refuse for a reason about geography, about an operator's name, or about
nothing they could put into words, and none of that requires us to hold a view.

The precedent was already in the code and is cited rather than invented. registryProofAnswer reports the
address a vault says it serves "for diagnostics and deliberately NOT a gate", and declines to act on a
mismatch rather than editorialise about one — the same instinct, arrived at for the same reason, two
years of design documents earlier.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Decision 7 had the mechanics right and the emphasis wrong. It said declining must be safe, then spent
most of its length on what a prompt should show — the operator, the address, whether the listing is
proved or merely first to claim the name — which reads as though the quality of those signals is what
makes the choice legitimate. It is the other way round. The requirement is that somebody may decline to
send their identity to a server for any reason at all, including one nobody anticipated and one they
could not articulate, and the signals exist to make that choice better informed rather than to justify
it. A design that only lets somebody refuse for reasons it recognises has not given them the choice.

Stated first now, with everything about signals explicitly subordinate to it. This also settles what to
do about showing a resolved geographic location beside a listing, which the address alone invites a
player to guess at and frequently to guess wrong: nothing, for now. It would be a correction to an
inference people make from a hostname whether or not anything is shown, and it would need a local
database rather than an outbound lookup so that PRIVACY.md's list of calls stays short — but it is an
improvement to the information, and the decision does not rest on it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Decision 7 said per-destination binding was "more machinery than a first cut needs" and left the consent
to be built by hand. Both were understated, and reading Auth0's documentation rather than reasoning from
the protocol is what corrected them.

Rich Authorization Requests carry an authorization_details array describing the specific thing being
authorised. Auth0 renders it in a customized consent prompt and binds the granted detail into the issued
access token. So the consent can name the destination — the realm, its operator, its address — which a
generic scope never could, and Auth0 publishes a schema shaped for exactly this ask,
urn:auth0:schemas:authorization-details:v1:user-profile, whose properties carry per-field display flags
so that "this server is asking for your email" is the sentence on screen rather than a scope name. And
because the detail travels inside the token, a token naming one vault is visibly not for another: that
is per-destination binding with the registration done once per type, not once per realm, which is the
constraint that ruled out a per-vault audience in the first place.

Two conditions have to be confirmed before relying on it. RAR requires the request to go through PAR,
and while the documentation states no plan restriction, PAR and RAR sit near Auth0's regulated-identity
features, so the tenant is what settles it. If either fails, nothing is lost that was not already
planned: DPoP still closes the replay hole — dpop_jkt is a documented /authorize parameter — and the
consent falls back to an interstitial the game shows itself.

The same commit records what that interstitial has to do if it is built, because the requirements do not
change with the mechanism. It names the operator and the address, says that connecting reveals the
player's IP — which Region Files §13 already lists as a cost of the direct hop — and is remembered per
vault. Declining is an outcome rather than an error: nothing is sent and the player stays where they
were, because a consent screen whose refusal breaks the session is one people learn to click through.
What a player can actually judge is stated too, since the tempting answer is wrong: a certificate proves
the server is the one the address names and says nothing about who runs it, so the signals worth showing
are the registry's own — proved against the world's key, or unproven and merely first to claim the name.

What crosses should be the sub and not the email, and there is a code fact in the way rather than a
policy one: isPlayerUser begins `if (!email) return false` and applies that even when anyoneCanJoin is
on, so a pseudonymous visitor is refused today by construction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Website Login Decision 7. A vault's session is a cookie it sets from its own callback on its own origin,
and a third-party vault is a different origin every time whose callback URL can never be in this
tenant's allowed list — a stranger cannot add their address to somebody else's tenant, and wildcards do
not reach arbitrary domains. Native App Login §01 pinned the constraint that made this tractable until
now, that the only origin any sign-in returns to is localhost, and said to go to §11 rather than widen
the callback list if it ever stopped holding. A published realm with a visitor is the day it stopped.

So the vault stops being an Auth0 client for players and becomes a resource server, which is the
distinction §09 already draws applied one layer out. Auth0 mints an access token for a vault audience,
the page carries it, and the vault verifies it against the tenant's JWKS and mints its own short-lived
bearer token from that. Nothing is registered per vault; an issuer and an audience are configuration.
The vault's own login URL stays exactly what it is, the administrator's door. It must be the access
token and never the id_token, for the reason §09 gives: an id_token is a statement issued to the page,
and a backend accepting one is accepting something never scoped to it.

This is not the broker §09 refuses, and the difference is the whole of why it is safe: the credential is
Auth0's. The site begins a login and carries a token; it issues nothing anybody can sign in with, holds
no client secret for another application, and receives no authorization code on a vault's behalf. It is
the same machine Realm Registry R15 uses for publishers, which is the strongest argument for it — a
player proving identity to a vault and a publisher proving identity to the registry become one thing to
get right rather than two.

It supersedes Region Files §13 on the mechanism and keeps everything else that section decided. §13's
popup logs in at the remote vault and returns a token that vault issued, which is replay-proof because
each vault is its own issuer — and which assumes the remote vault can run an Auth0 login, the assumption
that has just failed. What survives unchanged is the part that was never about the login: a bearer token
rather than a session cookie, because a cookie sent to another origin is a third-party cookie with a
published end date, and because a credentialed cross-origin request may not be answered with
Access-Control-Allow-Origin: *.

The cost is named rather than left to be found. One audience across every vault means a token minted for
a player is accepted by all of them, so an operator who receives one can present it at another vault as
that player. Short TTLs and keeping the token a pure identity assertion are the cheap mitigations;
per-destination binding needs a vault-issued nonce or DPoP. Two consequences are weighed in the decision
itself: play on every vault then depends on one tenant being reachable, where a vault that gates play
today fails alone; and Registry/ is Apache-2.0 so that other people can run one, which a player identity
only we can issue makes nominal — kept honest only by the vault reading its issuer from the environment,
so an operator may point at their own.

None of it replaces the simpler path. A realm published with public doors needs no login at all, because
accepts and entries[] are the author's act of consent, and building this before that path would be
solving the rarer problem first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The guard that turns a TLS failure into a sentence an operator can act on was a substring test,
/CERT|SSL|self.signed/i, against the code Node hides on `cause`. It missed the commonest code there is:
UNABLE_TO_VERIFY_LEAF_SIGNATURE contains none of those three words, so a publish refused for exactly
the reason this guard exists to explain arrived as "that vault could not be reached — fetch failed —
UNABLE_TO_VERIFY_LEAF_SIGNATURE" and nothing else. That is what the guard's own comment describes as
the failure it was written to prevent, happening to somebody.

The miss was not bad luck. make-cert.sh used to mint a lone self-signed leaf, which fails as
DEPTH_ZERO_SELF_SIGNED_CERT and matches "CERT". It now mints a local root authority and signs a leaf
with it, which fails as UNABLE_TO_VERIFY_LEAF_SIGNATURE and matches nothing. The guard and the thing it
guards drifted apart, and the drift is invisible: both halves are correct, and only the pair is wrong.
A pattern that catches the examples somebody had in mind is a pattern that stops catching them when the
examples change, so this is a list of the codes OpenSSL actually produces, which a test can enumerate.

The chain message names BOTH causes of that one code, because they need different fixes and only one is
obvious. A certificate signed by an authority nothing outside that machine trusts and a real
certificate served without its intermediates produce the same code, so naming only the first sends
somebody who did buy a certificate hunting a problem they do not have — which is the fullchain.pem
mistake, and it is the one people make second. The REGISTRY_ALLOW_LOCAL pointer stays, because a
developer running both halves on one desk has no other way past this, but it is scoped now: on a public
registry it stops verifying certificates for every listing rather than the one being debugged, and the
sentence says so.

The assertions enumerate codes rather than patterns, and each was confirmed against a sabotage:
restoring the original substring test fails three, dropping UNABLE_TO_VERIFY_LEAF_SIGNATURE from the
list fails three, removing the fullchain half of the message fails the one that asks for both, and a
hint that fires on every failure fails the two that keep a refused connection from being called a
certificate problem. The end-to-end pair goes through proveOrigin with a fetch that throws the way
Node's does, so what is tested is the catch block rather than the helper alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

They were one value, VAULT_PUBLIC_URL, doing both jobs, and the vault that needs them different is the
ordinary case rather than an exotic one: a Server Vault on somebody's own machine, published to the
internet through a tunnel. Its operator signs in at http://localhost:8787, because that is the callback
the shared tenant registers for every install (native-app-login.html §13) and no stranger can add their
own address to somebody else's Auth0 tenant. The realm it hosts has to be listed where players can
actually reach it. Fused, the registry got whichever answer Auth0 needed, and a listing naming
localhost is refused by both ends — correctly, and with no way to say what was meant.

The sharper case is the one with no Auth0 at all. The listing address was read off cfg.auth0.baseURL,
so a vault with the game open and admin loopback-only — which is what the README describes, and what
most third-party installs will be — had no listing address and was refused by its own configuration
with "this vault has no public URL". That vault is reachable and serves players; the message named a
variable its operator may well have set, and nothing anywhere said the value was being taken from
somewhere else. So this is a bug fix as much as a feature: the most natural way for somebody else to
run a vault was the one configuration locked out of the registry.

VAULT_PUBLIC_URL now keeps its plain meaning and is what gets published, read verbatim. VAULT_LOGIN_URL
overrides the Auth0 origin and defaults to VAULT_PUBLIC_URL, so every install that has only ever set one
variable behaves exactly as it did. The scheme raise reaches Auth0's copy alone: publicUrlWithServingScheme
exists because a redirect_uri must carry the scheme this process serves, which is a fact about this
socket, while a listing's scheme is a fact about the far end of a tunnel that this process cannot see —
raising it would be guessing about somebody else's proxy, and an http listing is still refused by
publicUrlProblem, which is the right place and says why.

Two banner lines moved with it. The scheme-raise note compared publicUrlRaw against the Auth0 value and
said the raised one was used "for Auth0 callbacks and registry listings" — now false, and it would have
printed on every boot of any vault that set VAULT_LOGIN_URL, about a scheme nothing had changed. It
compares the login value now and names the variable that supplied it, because after the split there are
two it could be and an operator grepping for the wrong one finds nothing.

The new warning is for the combination that lists fine and turns every player away: published at a
public address, play gated behind Auth0, login origin loopback. The listing is valid, origin proof
passes, and an arriving player is redirected to a callback on their own machine. Nothing fails on the
vault, so nothing would ever have reported it. Signing in on the website does not help and cannot — a
vault's session is a cookie it sets from its own callback, which website-login.html §09 states
precisely because the opposite is the natural guess.

Tests/test_listing_url_split.js pins the default, the split, the no-Auth0 vault publishing, the raise
reaching only Auth0, both consumers reading cfg.listingUrl, and the warning's three conditions. Each was
confirmed against a sabotaged implementation: raising the listing scheme, dropping the default,
re-coupling the listing to Auth0, reverting either consumer, and loosening the warning all fail named
assertions. Its source check had to be fixed first — stripping block comments before line comments let
a line comment reading "every /vault/* proxy call" open a block comment that swallowed the line being
asserted, so the test reported a change that had been made correctly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

R15 in the registry's §05. The proposal is that a vault already knows who is signed in to it, so that
identity should be what the registry recognises, and nobody should have to copy a publisher token out
of tokens.json into a .env. The instinct is right and it is pointed at the wrong half of the pair: yes
as the identity, no as the key. A sub is not a secret. It is already written into worlds-index.json as
publishedBy, named as such in PRIVACY.md, and printed in logs at both ends, so a registry accepting it
as the credential would be accepting a username as a password — and what the publisher field guards is
first-come ownership of an unkeyed uid, which makes forging one the whole attack rather than a step
toward it.

What the vault holds today decides the shape. The login is real — openid-client verifies the id_token
against the tenant's JWKS — but identity.js then keeps the claims, signs them into its own cookie with
its own secret, and discards Auth0's token; the scope is openid profile email, so no access token for
any audience is requested at all. The vault can prove who you are to itself and holds nothing it can
pass on that a registry could check. The leaning is therefore an access token minted for a registry
audience, verified against the tenant's JWKS, with sub read out of the verified token — the same
answer the proposal wanted, one step further along, and the seam publisherOf's own comment already
anticipates.

Three findings made it into the decision because they are cheaper than they look, and each was checked
rather than assumed. Only PUT and DELETE call publisherOf, so the expiry of a user-bound token never
has to cover an unattended job — which also answers half of R13, whose leaning still says the
heartbeat wants a long-lived token, and a line there now says the code settled it. Registry/ can stay
dependency-free: Node's own crypto verifies RS256 against a JWKS entry through createPublicKey with
format 'jwk', which was run here against a good signature and a tampered one. And it is the only shape
that can ship in the desktop bundle, which is what the no-client-secret rewrite of identity.js bought.

The costs are written down beside it rather than discovered later. A vault with no Auth0 could not
publish, which is a policy change and not a technical one. Publishing would depend on the tenant being
reachable where a token map is local. Registry/ is Apache-2.0 so that other people can run one, so the
issuer and audience have to be configuration and the token map probably has to survive as the fallback
— a tenant baked in would make the service unrunnable for anyone but us, which is the same failure
Tests/test_registry_license.js guards one layer down. The dependency is refresh tokens: SESSION_TTL_MS
is seven days absolute against a token that typically lasts one, and the comment above that constant
already names phase 4 of the login design as the answer. The access token must not go in the session
cookie, which today carries identity claims rather than credentials and goes to the browser.

And it strains an invariant, deliberately. "A registry token is never a vault token" survives at the
token level only if the registry verifies aud — miss that and every player in the tenant becomes a
publisher. It does not survive at the account level, because one tenant behind both means publishing
and playing are one login, which is the convenience being asked for. §07's refusal is untouched: the
read half still takes no login and wants no cookie.

The open-decision count moves to twelve. It counts tags rather than classes, which is why it read
eleven against twelve elements — R14 carries a Settled tag on a block still classed open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The absence of REGISTRY_URL used to mean a vault had no registry at all, and the comment above the
resolver said so deliberately: the honest answer for such a vault was the stub's sentence — nothing was
sent, the decision is recorded here. That reasoning was sound and has been overtaken. It was written
when there was no registry to point at, so "most vaults name none" described the world accurately, and
a public directory nobody is listed in is not a directory. The default is now
https://thelostrealms.ai/registry.

The path is part of the default, not decoration. The registry is mounted under a prefix behind the same
web server that serves the site, and a base is joined to /api/worlds/... verbatim, so a bare host would
send every publish to the website — which answers 404, and a 404 from somewhere else reads as a
registry that refused rather than as an address that was never the registry. That is the same mistake
the browse page made last week, from the other side.

Opting out is now a setting rather than the absence of one: REGISTRY_URL empty, or none, or off,
restores the old behaviour exactly. The resolver therefore reads the variable for UNDEFINED rather than
for falsy, because an operator who has written the line has expressed a preference and one who has not,
has not. The same distinction applies to a caller's opts.registryUrl, and that one is load-bearing:
heartbeatPublicWorlds is called with an empty string to mean "send nothing", and the old `||` chain let
that fall through to the environment, which under a default would have turned it into a live request to
the project registry.

Two things this exposed, both of which would have been silent. The heartbeat gate in server.js read
process.env.REGISTRY_URL directly, so it would have answered differently from the thing it gates for
the commonest vault there is — one that has never written the variable — and a world published to the
default would never have been confirmed, lapsing a week later with nothing logged and nothing failing.
It asks the module now, and the module also answers whether the default is in use, so the variable's
name stays in one place; a second reader of it is precisely how the two came to disagree. And the
admin page's note on when the Public box must not revert was written for a vault with no REGISTRY_URL,
a case that now includes any refusal from a registry that is really there.

Because the project registry runs with publisher tokens, the first publish from an unconfigured vault
is refused, and "the registry refused this world — a publisher token is required" tells an operator who
has never heard of REGISTRY_TOKEN nothing they can act on. That refusal now names the next step. The
vault also says at boot which registry it publishes to and whether that is the default: the registry
itself announces open versus token-gated for the stated reason that the failure mode of a quiet default
is nobody remembering which one they are running, and a vault publishing somewhere it was never told
about has the same problem from the other end.

PRIVACY.md is part of this rather than a follow-up, because the change moves data. A vault left at its
defaults now sends a listing to Brave You Worlds when a world is ticked Public, and heartbeats daily
after that, so the blanket claim that nothing here reports to us no longer stands unqualified. What
remains true is stated precisely instead: nothing is sent until the box is ticked, per world, and a
vault with no public world makes no registry request at all.

The three tests that asserted the old default failed, which is them working; each now pins the new
contract, and the resolver's nine answers are asserted directly. Five sabotages were confirmed to fail
named assertions: a default without its path, a default with a trailing slash, unset collapsed with
empty, opts.registryUrl:'' falling through, and the heartbeat gate reverting to the environment
variable. One assertion of mine had to be narrowed first — it forbade the gate from naming
REGISTRY_URL and so matched the comment explaining why the gate does not read it, which is the
prose-instead-of-code trap this repository has now hit three times.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Behind a reverse-proxy prefix the page loaded perfectly and then reported "Could not reach the
registry — the registry answered 404". The 404 was real and it came from somewhere else entirely: the
page fetched '/api/worlds', a root-absolute path, so under nginx location /registry/ it asked the
surrounding website for a route that website has never had. The registry was never contacted and
nothing was wrong with it, which is exactly what makes the sentence expensive — it names the registry,
so it sends whoever reads it to the registry's logs, where everything is fine.

The page now works out where it is mounted from the URL it was served at. The service answers on
exactly two page paths, <mount>/ and <mount>/browse, so stripping those off location.pathname recovers
the mount, and a bare /registry with no trailing slash recovers it too — a mount is somebody else's
configuration, and a page that only works when the proxy was written correctly fails in the one case
nobody tested. A <base> tag is the tidier spelling and is unavailable on purpose: the CSP sets
base-uri 'none', because a base tag re-points every relative URL on the page at once. The favicon link
becomes relative for the same reason, where a leading slash fetches the host site's icon rather than
the registry's.

The test evaluates the MOUNT expression rather than matching it. What this guards against is a regex
that is subtly wrong — one replace in the wrong order, a missing anchor — and a check that the line
looks right cannot tell a correct one from a broken one. Nine paths, plus separate assertions that the
one fetch is built from MOUNT and that no root-absolute fetch survives anywhere in the script, so a
second call site added later is caught on its own terms. Each was confirmed against a sabotaged page:
restoring the root-absolute fetch fails two, dropping an anchor from the regex fails the nine cases,
re-adding the leading slash to the icon fails the favicon assertion, and renaming MOUNT away fails the
fixture check first so the rest cannot pass vacuously.

Adding MOUNT also broke the block that runs the whole page script in a DOM mock, which is the test
doing its job — the page reads location now, so the mock has to supply one. It is given a prefixed
path rather than '/', since nothing in that block is about the mount and running it under the awkward
case costs nothing.

Verified end to end in Chromium behind a proxy that strips the prefix the way the nginx snippet does:
before the change all three of /registry/, /registry and /registry/browse request /api/worlds and
render the 404; after it, all three request /registry/api/worlds and render the empty-registry note.
The snippet the script prints gains the trailing-slash redirect, a body limit matching the one
registry-app.js enforces, and a note about the five-second origin-proof callback a publish waits on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Two failures, one run apart, both of which the script could only hit on a real host.

The ecosystem file pointed pm2's out_file and error_file at /dev/stdout and /dev/stderr. That is the
recipe everyone uses in Docker and it works there, because fd 1 in a container is a pipe and a pipe can
be reopened through /proc/self/fd/1. systemd hands a journal-logging service a unix socket on fd 1, and
open() on a socket inode returns ENXIO — measured here rather than reasoned, with a child whose fd 1 is
a connected unix socket. pm2 opens its log files before forking the app, so the service died at that
point and the line that reached the health check was "0 application started (no apps to run on
ecosystem.config.js)", which reads as a broken config file. The ENXIO trace was three screens up.
Pointing both at /dev/null loses nothing: pm2-runtime forwards the app's stdout and stderr to its own
stdout whatever out_file says — that is what makes pm2 work in a container at all — and systemd is
reading that. Verified by running pm2-runtime with these exact values and watching the registry's
startup lines arrive on pm2's stdout with no log files written under PM2_HOME.

Behind that sat a worse one. Four of the registry's files require ../Server/registry.js and
../Server/registry-keys.js, the two vault modules carved out to Apache-2.0 precisely so the registry is
runnable by anyone. The script flattened Registry/ into /opt/registry, where ../Server resolves to
/opt/Server and nothing had put anything. Every file landed, every permission was right, and Node said
MODULE_NOT_FOUND — five times over, because pm2 retries, ending again at "0 application started". The
install now mirrors the repository: Registry/ and Server/ as siblings under /opt/registry, which is
also why they are nested rather than a directory called Server appearing at the top of /opt. The
preflight checks for both modules and says what a checkout missing them means, stale copies from the
flat layout are removed by name, and favicon.ico is installed because registry-app.js looks for it one
level up and quietly serves nothing when it is absent.

Re-running the script after a failed install used to look like the failure repeating. The StartLimit
breaker does its job and leaves the unit in failed, and a failed unit refuses systemctl restart with
"start request repeated too quickly" — so the run carrying the fix appeared not to work. A
reset-failed before the restart costs nothing on a healthy unit.

Rehearsed end to end against the real sources: the rendered ecosystem file parses, pm2-runtime starts
server.js from the installed tree, /health answers, and the browse page and favicon both serve.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The unit restricted the service to AF_INET and AF_INET6, which is the reflex set and which describes
the registry's own listener perfectly. It does not describe what the process tree underneath it does,
and on the first real host the service never came up: pm2 talks to its own supervisor over unix
sockets it creates under PM2_HOME, in pm2-runtime's no-daemon mode as much as in any other, so with
AF_UNIX refused it could not reach them and never got as far as running server.js. The health check
timed out with nothing about the registry anywhere in the journal, because the registry had not
started. Traced here, pm2-runtime creates pub.sock and rpc.sock before it launches anything.

AF_NETLINK goes in for a second reason that is easy to miss until origin proof stops working. glibc's
resolver enumerates the machine's interfaces over a netlink socket before choosing a source address:
one dns.lookup() from Node, under strace, opens AF_NETLINK, AF_UNIX, AF_INET and AF_INET6. glibc does
have a fallback for a netlink socket it cannot open, but verifying a vault's origin is the one thing
this service exists to do, and the fix is one word.

Two things made this expensive to read, and both are now written into the unit beside the line. A
blocked address family does not come back as EPERM the way a blocked syscall does; it is EAFNOSUPPORT,
which reads as a kernel built without the feature and sends you to the wrong place entirely. And the
first error in the journal named interactor.sock, so it pointed at pm2's monitoring agent rather than
at the confinement line — the agent is telemetry for an account nobody has linked, so it is now off
via PM2_NO_INTERACTION, which is not the fix but does stop an unused process being the loudest thing
anybody reads.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Everything you type is on one page and everything you look at is on the other, with a pager under
them naming both. Generating or choosing a sheet turns to the second page by itself, that being the
point of pressing the button; reopening a monster does not, because the prompt is what you came back
for.

The three-column layout it replaces rested on a real argument — the sheet, the grid the engine cuts
it on and how the result reads in a corridor have to be judged against each other, and a sheet whose
frame count is wrong looks perfectly fine examined one at a time — so that argument is what page 2
honours. The sheet and the corridor are side by side with the frame strip under the sheet, and each
has half a dialog instead of a third. What the three columns cost was exactly that: five things
sharing the width, and the two that most need it are the one whose cut lines are dragged against
gaps a few pixels wide and the one that exists to show detail. The prompt is the thing that never
had to be seen beside them, so the prompt is the thing that moved.

Both pages stay in the DOM and are hidden rather than unmounted — every field on page 1 holds
something somebody typed, and a page rebuilt on each turn would hand back an empty prompt for the
crime of looking at the corridor. The hidden one needs an explicit [hidden] { display: none },
because any display rule of ours outranks the user-agent rule behind the attribute and both pages
would otherwise render at once, which reads as the carousel never having been wired up.

Two things follow from a page being off screen. The corridor does not paint while its page is away,
sixty frames a second of a canvas nobody can see being a cost that stays invisible until it is on a
battery; the CLOCK keeps running, so a creature left mid-stride is still mid-stride however long you
spend on its prompt. And the sheet's cell numbers, dropped when a cell is too narrow for one, are
measured every time that page is turned to rather than once when the dialog opens — a hidden element
measures zero, so the question has no answer until the page is up, and the old measuring point now
measures the wrong page.

Reported alongside it: reopening a monster's sheet showed an empty description and an empty prompt.
The diagnosis in the report was exactly right, nothing anywhere held them. The renderer wants pixels
and a frame count and has both, and nobody had asked what an AUTHOR wants on a second visit — which
is the sentence and the prompt, "change one word and regenerate" being the common second visit and
impossible without writing the whole prompt again from a picture. A per-monster record now carries
description, prompt, build, key colour, tolerance and cut positions. It rides in the dungeon payload
beside mons, which round-trips whole, so no engine file learns that an image prompt exists; it is
filtered to the monsters that still exist, goes when the monster goes, and is replaced rather than
merged on import. Every field falls back to the default it had before the record existed, so a
monster from an older build opens exactly as it always did.

Restoring the cut positions was asked for with its consequence stated, and the consequence needed a
guard the request did not mention. What is on disk is the REBUILT sheet — already even, already cut
at those positions — so re-running the cut over it would slice an even sheet at positions meant for
the crooked original and shift every frame, and the author need only press Save for the shifted
version to be the one stored. A flag says this picture already is the result of these cuts; the cut
stage hands it through untouched, the first drag clears it, and the report under the sheet says
which of the two states it is in.

Three assertions in test_custom_monsters.js broke on this and were brittle rather than right: one
listed every field of the payload so adding one failed it, one required two calls to be adjacent
lines when what it is about is their order, and one spelled out createCustomMonster's whole
parameter list so a new option read as the function having vanished. All three now pin the property.
A fourth, in the sheet editor's own file, asked the animation loop not to MENTION sheetPage — a rule
about vocabulary rather than behaviour, and one whose fixture could not run the gated version at
all: it threw, the file died mid-run without printing a FAIL line, and a check looking for one read
that as a pass. It drives the clock with the page away now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The install script writes /etc/systemd/system/registry.service from an unquoted heredoc, because the
unit has to interpolate ${RUN_USER}, ${APP_DIR}, ${NODE_BIN} and half a dozen other values the script
computes. Unquoted also means bash performs command substitution inside it, and it does not care that
the text it is expanding is a prose comment rather than a directive. The circuit-breaker explanation
added to the [Unit] section mentioned `failed` and `systemctl status` in backticks, the way the rest
of this file's prose does, and bash ran both: the script printed "line 227: failed: command not
found" and wrote a unit in which the second one's multi-line output had been spliced into [Unit],
where systemd reads every line of it as an unknown directive and ignores it. The one pre-existing
backtick pair in that heredoc was escaped correctly, which is what made the new ones look safe.

Escaping the two backticks is the fix. Two things guard against writing them again. A comment at the
heredoc's opening says the quoting rule and names this failure, so the next person adding prose there
does not have to infer it from one escaped line further down. And the script now reads the unit back
through systemd-analyze verify, which is what catches the damaging half: an empty substitution only
costs a word out of a comment, but output spliced into [Unit] becomes unknown directives, and that is
exactly what the verifier reports. It is deliberately non-fatal — refusing an otherwise good install
over a warning is worse than not checking — and it catches a mistyped directive name for free, which
systemd would otherwise accept in silence and simply not obey.

The verification that missed this originally checked that StartLimitIntervalSec and StartLimitBurst
had landed in [Unit] rather than [Service], by rendering the heredoc through the same unquoted path
and reading the section headings. It never grepped the rendered unit for the prose it was supposed to
contain, so the substitution reproduced itself silently in the check. The rendered unit is now
compared against the literal text expected in it, line count included.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Create monster and Cancel were sitting directly on the row of transport and zoom buttons under the
corridor. The row had never been given a gap of its own: in the plain dialog the paragraph above it
carries an 18px bottom margin and supplies one, and this dialog has no paragraph. Nothing showed
that while the corridor ended in a hint whose line height happened to leave some air, and moving
that prose out to the Dungeon Master's Guide put the two buttons that END the dialog directly under
the ones that do not.

The distance is the same one the dialog already puts between its three columns, and it is the same
declaration rather than the same number typed twice. That means a custom property on the dialog
element and not on the grid: the acts row is the grid's sibling, so a variable declared there would
reach the columns and not the row beneath them, and the margin would resolve to nothing at all with
no warning — which is the version of this the test now refuses.

One assertion in that test was measuring the right thing by luck. It read the grid's gap with a bare
/gap:/, which also matches inside --sheet-gap:, so the sabotage that declares the variable in the
wrong place failed on a mismatch between `16px` and `var(--sheet-gap)` rather than on where the
variable lives. It asks for the gap property now, and the sabotage fails on the assertion that is
actually about it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

A paragraph and a half under a control is read once and then scrolled past forever, and the corridor
preview had grown one: what the view is, why zoom is a lens rather than a walk forward, what pause
holds and what the arrows beside it do. It is now a section of the Dungeon Master's Guide, under
Editor · Dungeons, beside the sprite sheet editor it belongs to — four subsections covering the cut
lines and what dragging one actually does, the corridor and its lens, the cell readout with its
printed numbers and its lit cell, and pause with the steppers.

The dialog keeps the part that has to be within reach of a finger and loses the part that has to be
findable. Every control in that row carries a title, and the ones whose face is a symbol carry an
aria-label — which the two zoom buttons did not, and that is a real gap this change surfaced rather
than a tidy-up: while the paragraph was there a screen reader had something to read, and taking it
away left a minus sign and a plus sign announcing themselves as punctuation. The gap under the
corridor carries a comment saying where the prose went, because an empty space under a row of
unexplained buttons reads as an oversight and the next person fills it back in.

The failure mode of a move like this is that it looks exactly like a deletion. Nothing in this
repository compares a document against the interface it documents, so the test does it from the side
that did the deleting: eleven claims, each naming a mechanism that is no longer explained anywhere
the author can see it while working, matched against the Guide's Dungeons section. They match on the
subject rather than on a sentence, so the Guide can be rewritten freely and only a rewrite that
drops the thing fails.

One of those rows started out weak in exactly the way this file's notes warn about. It looked for
"lens", which appears twice in the section, so a rewrite replacing the sentence that carries the
reasoning with "zoom makes it bigger" left the other occurrence standing and the check passed on
vocabulary while the argument was gone. It is two rows now, and the second asks for the contrast
with a camera move, which is the half that is actually load-bearing — without it the next person
"fixes" the zoom into a walk forward because nothing says why it is not one.

Not covered, and worth saying rather than implying: nothing checks that the Guide's Last Update
stamp is CURRENT. The test pins its shape and refuses one dated in the future, but whether it was
moved when the content moved is not decidable from the file, and the rule in CLAUDE.md remains the
only thing enforcing it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Correcting 4e7abf1, whose message and whose comments carried a worked example that is simply false
and a count that was invented. Both said the fault shows at 3 frames a second, cell 1: that
333.3333333333333 / 1000 * 3 comes out as 0.9999999999999999 and floors to the cell before. It does
not. It comes out as exactly 1, and 3 frames a second round-trips every cell of every count in the
test's grid. The commit also claimed eleven wrong landings where the number is 271.

The real case, checked in node rather than argued from the shape of the arithmetic: at 7 frames a
second, cell 61 begins at 8714.285714285714ms, which converts back to 60.999999999999992895 and
floors to 60. The middle of that cell is 8785.714285714286 and floors to 61, which is what the guard
is for and is unchanged — only the description of why was wrong.

What makes this worth a commit of its own rather than a quiet edit is the second thing measuring
showed, which is the argument for the test being written the way it is. The fault follows no rule
anybody would guess. It is not "the rates whose cell length is inexact in binary": 3, 6 and 24
frames a second are all inexact and all round-trip perfectly, while 9, 11 and 30 fail dozens of
cells each. And it does not appear at low cell indices at all, the error not having accumulated far
enough to cross an integer, so a two- or three-frame sheet passes at every rate tried. Of the 271
wrong landings, not one is at 1, 2, 3, 6 or 24 frames a second — which are exactly the rates
somebody picking a single case by hand would reach for, the default being 2.

So the loop over nine frame counts at ten rates is not thoroughness for its own sake; it is the only
form of this test that can fail. A worked example chosen by reasoning about binary would have picked
3 frames a second and passed against the broken implementation, which is the thing this repository's
notes say is worse than no test at all. The test's comment and the design doc now carry the measured
case and say why no spot check stands in for the loop.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Arrows either side of Play walk one cell forward or back, wrapping both ways — a walk cycle is a
loop, and the seam between its last frame and its first is exactly what somebody stepping through
one is usually checking. Both go dead on a single-frame sheet, on the same rule as the zoom buttons:
a press that cannot do anything and stays live reads as broken.

A step pauses rather than being refused while playing. Stepping only means anything while paused,
since the next animation frame overwrites the clock otherwise, and the two ways to honour that are
to grey the arrows out until Pause has been pressed or to have the step do the pausing itself. The
second is one press instead of two, and it is the gesture people actually make: you are watching the
loop, something goes past wrong, and you reach for the back arrow. Greyed-out arrows would make you
stop first and then discover you had paused on a different cell than the one you meant to look at.

A step sets the CLOCK, because the clock is what the corridor draws from and what the readout reads.
There is no separate current-frame to set, and introducing one would be a second answer to the
question the single frame function exists to keep single — the same reasoning that folded the
corridor's own modulo into it.

It sets the clock to the middle of the cell, and the half is not cosmetic. The frame is floor(ms /
1000 * fps), so a clock landed on a cell's own boundary asks floating point which side of it the
answer falls: at three frames a second cell 1 begins at 333.33ms, and 333.3333333333333 / 1000 * 3
is 0.9999999999999999, which floors to the cell BEFORE the one the button just said it was moving
to. Half a cell in is the furthest possible point from that. Nothing about the fault is visible in
the source, and a test reading the expression would have agreed with it, so the test steps every
cell of nine frame counts at ten rates and asks the frame function where it actually landed. Written
first without the half, it named eleven landings on the wrong cell.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Three displays of one fact. The corridor says Cell 3 of 8, the sheet prints that number in each of
its cells, and the cell playing is lit. The question an author actually has when a frame looks wrong
is which frame, and without these the only way to answer it is to count along a row whose count is
the very thing in dispute.

The arithmetic is one function, asked by the corridor that draws the cell and by the readout that
names it. It was two lines in each to begin with, which is two chances for the label to name a frame
the picture is not on — and the whole value of the label is that it can be trusted while looking at
the sheet rather than at the corridor, so a label that can drift off the picture is worse than none.

The numbers live in cell-shaped regions rather than as labels floating at a percentage, so a cell
too narrow clips its own number instead of overrunning its neighbour's, and the same box is what the
highlight is painted on. Below fourteen pixels a cell the numbers are dropped altogether: sixty-four
frames across three hundred pixels is under five pixels each, and a clipped 8 reads as a 3. That
width is measured on a refresh and never in the animation loop, a getBoundingClientRect being a
forced layout read and the loop running sixty times a second, and it is measured once more after the
veil is shown because everything before that runs against a hidden element whose width is zero.

Pause puts the animation on a clock of its own, advanced by the real elapsed time only while
playing. Freezing the timestamp handed to the draw would have stopped the redraw as well, and a
paused corridor still has to answer a zoom press, a re-cut or a height change, which is most of what
anybody pauses in order to do. So the clock stops and the drawing does not.

Two details there are silent when wrong. A requestAnimationFrame timestamp is milliseconds since the
page loaded, so the first tick must contribute nothing — taken as an elapsed time it jumps the
animation by however long the Builder had been open, which on a sheet made late in a session is
minutes. And stopping the loop forgets the last timestamp, or the next open resumes against a stamp
from the previous one and jumps by the gap between them. The button is labelled with the act it will
perform rather than the state it is in, and carries an aria-label, its face being a triangle and two
bars.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The contract asks for frames of equal width and the providers routinely deliver the right number of
figures spaced by eye. That is not a fault the frame count can repair, because the count is not what
is wrong: there really are eight figures, and the even cuts fall through two of them. The lines over
the sheet reported this exactly and could do nothing about it, which left an author with a correct
diagnosis and only a wrong lever to pull.

Each line can now be dragged, and what a drag does is the part worth recording: it does not teach
the engine uneven cells, and was not allowed to. spriteFrameU slices a texture into N equal columns
across its full width, and that is true of every sprite in every dungeon already drawn. A per-frame
cut table would mean a new field on the texture carried through the map file, the three
serialisation places and the restore, read in the draw loop, and kept consistent with the frame
count by something — all for a fault that belongs to one picture and is repairable in the editor
that received it. So the repair happens once, here, and what leaves the dialog is an ordinary even
sheet: the slices copied into cells of their own, every cell the width of the widest slice.

Centred in its cell and never stretched to it. Scaling each slice to a common width would make the
creature pulse in size across its own walk cycle — the slices differ in width because the model
spaced the figures unevenly, not because the creature changes size between frames — and centring is
lossless besides, every source pixel landing on exactly one destination pixel with a transparent
margin, which is what the frame contract asks for anyway.

The sheet therefore exists in three forms at once and a reader has to be told which one is meant.
Raw is exactly what arrived and every re-key starts from it; keyed is raw with the background made
transparent, and is what the top preview shows and what the handles are dragged over; img is keyed
and re-cut, and is what the strip, the corridor, the measurement and the commit read, because it is
what the engine gets. Lining a handle up against a sheet already rebuilt to match it is chasing your
own tail. A cut may not pass or land on a neighbour, because a zero-width slice has no pixels to
copy and divides by a width of zero on the way out. Nothing is rebuilt until the pointer is
released: a 2048-wide canvas re-encoded to a data URL sixty times a second is what dragging would
otherwise cost. Cuts survive a tolerance nudge, since that dial moves no figure, and are dropped by
a new sheet or a new frame count, since positions placed against one picture are worse than none
against another — they look deliberate.

The corridor gains minus, plus and Fit, multiplicative from half size to six times because the
useful range spans an order of magnitude and a fixed step would be twenty presses at the top while
being far too coarse at the bottom. It zooms the lens rather than the camera, on the same reasoning
as the original framing: focal length scales the walls, the floor, the ceiling and the creature by
the same factor, so how the thing sits against a one-square corridor and under a 1.15 ceiling is
unchanged at every setting.

One trap here was already in the code. The focal solve carried a clamp of 120 to 2200, written as a
guard against a degenerate height solving to an absurd lens, and left as fixed figures it silently
caps the zoom for anything small — a rat at 0.2 squares reaches 1.4x of the 6x the buttons go on
counting to, with nothing on screen saying so. It scales with the zoom now, which factors out to
guarding the unzoomed solve exactly as intended. The test lifts the two expressions and drives them
at four creature heights across the whole range rather than reading them, because a cap that bites
only for small creatures passes every assertion anyone would write about a person-sized one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The sprite sheet editor's description and prompt boxes scrolled in the operating system's own bar: a
fat light-grey slab in a window otherwise drawn in gold on near-black, and the most conspicuous
thing on the page. The Builder is a separate document with its own stylesheet, so it has to restate
the theme, and its restatement named two ids — #edit-panel and #edit-canvas-wrap. Everything else
got whatever the platform draws. Nothing could report that, because the styling was absent rather
than wrong: the surface reads as one nobody thought about, which is exactly what it was, and the two
textareas in this dialog were never going to appear in a list of ids written before the dialog
existed.

The rule is now scoped to #db-root and matches anything inside it. scrollbar-width and
scrollbar-color are inherited properties, so one declaration on the root carries them to every
descendant; the ::-webkit-scrollbar pseudo-elements do not inherit and have to be matched on the
element itself, which is what the universal selector is for, and it costs nothing on an element that
never scrolls since a scrollbar pseudo-element with no scrollbar draws nothing. One surface
overrides it on purpose and still out-specifies it: the tile properties pane asks for a visible
track because it clips silently on a short window, and a blanket rule that won would take that back
without a word — the pane would keep a themed bar and go back to hiding its own overflow. The corner
where two bars meet is claimed too, since a pane that scrolls both ways shows a grey square between
them otherwise.

The dialog itself now scrolls, which is the third scroller and the one that prompted looking. Three
columns of controls, a sheet, a frame strip and a corridor come to some 600px inside a veil that is
a centring flexbox, and a flexbox clips an oversized child rather than scrolling it — so on a laptop
the acts row went off the bottom and Create monster could not be reached at all. It is bounded by
the viewport rather than by a pixel figure, because a pixel figure is a guess about somebody else's
display.

Tests/test_builder_scrollbars.js checks coverage by matching the selectors against named elements
rather than by counting rules, so a rule that goes back to naming ids fails on the textareas while
still passing on the two panels it names — the shape the defect actually had. It reads the app's own
figures out of #narrative and holds the Builder's base rule to them, so "matching the game's panels"
is a sentence something checks rather than a comment; it refuses a selector shape it cannot parse
instead of reporting it as a miss, since "no rule covers this" and "the matcher could not read the
rule" are opposite findings; and it walks the markup to confirm nothing scrollable has escaped
#db-root, which two orphan closing tags managed once already.

One assertion in test_sprite_sheet_editor.js broke on this and was wrong rather than right: it
matched the dialog's width off a single line of source, and splitting the declarations to make room
for the max-height failed it without changing how wide the dialog is. It reads the rule now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Both editions still read as though the bus were unbuilt: a "Part III · Coming"
badge and its own TOC entry, "the proposal that would change that... it warns
you not to write against it yet", a meta description promising the reader
"what is only proposed", a living-document note saying the bus "describes
something that does not exist yet", and two workarounds (the DM-role check,
the game-ready observer) presented as the thing a mod has to do until the bus
that would replace them arrives — when onDMLogin and onGameReady already do
exactly that and are named three sections later in the same document. The
event roster table right beside most of this correctly marked every row
Live, so a reader crossing the page watched the guide contradict itself.

Two smaller drifts sat in the envelope-field table: "one of the six live
names" from when the roster had six entries rather than thirteen, and a
worldUid description promising cross-window delivery "once the... half
lands" for a transport that has been dispatching unconditionally since it
shipped. Both editions carried the same wording, so both needed the same
fixes.

Tests/test_extension_docs.js is what caught the meta-description edit: it
required both books to contain a "not built"/"proposed" phrase near
"cross-window", a check written for the same not-yet-shipped state and never
revisited once the transport landed, so it had been passing only because the
old meta description's "what is only proposed" happened to satisfy a regex
that had nothing to do with it. Replaced it with a check derived from
MOD_EVENT_ROSTER's own cross:true rows, so a book now has to state the
actual cross-window count (currently eleven of thirteen) rather than any
particular claim about whether the feature exists.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fu1GA45LKFtv7fjt7uJSZt

Three things shipped since the guides were last touched and none of them had
reached either the Field Guide or the Dungeon Master's Guide: the Dungeon
Builder's Create Monster dialog was replaced by a full sprite sheet editor
(Invent, Generate sheet, the key-colour background, the corridor preview, the
2fps default), a book item's Actions row grew a View button that previews a
chapter the way the reader's own language would show it, and the detached
World Editor header grew its own Remote Embedded Media button for a draft or
vault world, which has no loaded save for the existing Tools-menu action to
walk.

The DM Guide's old paragraph on "create monsters" described the four-field
upload dialog the new editor replaced, so it read as documentation for a
control that no longer exists. The Field Guide had never mentioned the View
button, and its Remote Embedded Media section assumed a loaded save was
always available to move art from, which stopped being true the moment a DM
could reach the same action while editing a bare draft.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fu1GA45LKFtv7fjt7uJSZt

The sprite sheet editor could do every step of making a monster and could start none of them. An
author arriving at it faced an empty name, an empty description and a prompt box, and the two
generating buttons both wanted something typed first. Invent, at the left of the acts row, runs the
three steps that were already there: it asks the Game Master for a creature from this world, writes
the image prompt from what came back, and paints the sheet. The host half is one new bridge message
and one directive; the Builder half is a chain over the functions the two buttons above it already
call.

It chains those functions verbatim rather than repeating them with an extra argument, which is the
rule the dialog's own header comment states about itself: two paths onto one act is how they drift,
and a prompt built by Invent that differed by a clause from the prompt built by pressing the sparkle
is a difference nobody would see until a sheet came back wrong. The cost is a second GM call —
Invent asks what creature, and the clause pass then writes that creature into the sheet contract.
Folding them into one call was the obvious saving and was rejected, because the clause pass is what
interpolates the frame count, the cell size and the key colour from the controls the author has
actually set, and a single call returning a finished prompt would be a model writing those numbers.
Wrong numbers in a prompt are precisely what the frame control exists to repair afterwards, and a
sheet is a minute of generating; a second text call is cheap against painting one twice.

Each step stops on its own failure and leaves what the earlier ones filled in, so an author whose
image provider is down still has the creature and the prompt and Generate sheet is one press away.
The reason left standing is the one that actually failed: a chain that ran on regardless would have
the next step fail too, on the empty prompt the last one left behind, and overwrite "the GM
declined" with "write a prompt first" — which is the sabotage the first version of the test did not
catch, and the assertion added for it is the one that does.

The default frame rate goes from 14 to 2. It was 14 because that is the torch flame's rate, and
putting fire and sprites on one clock looked tidy; it is the wrong clock for a creature. A flame
flickers, so fourteen reads as fire, while a four- or eight-frame walk cycle played fourteen times a
second is over in half a second and reads as a vibration rather than a step — which is how every
sheet generated in this editor came out. Two is roughly one step a second, which is what the sheets
are drawn for, and anything that should dart has a field to say so in.

That change is not free and the cost is recorded rather than fixed. tidyMon deletes an fps equal to
the default rather than writing it out, so "the author chose fourteen" and "the author chose
nothing" are the same bytes on disk and cannot be told apart: every monster in every saved map left
at the old default now animates at two. A monster carrying any other rate is untouched, and so is
the flame. Two tests asserted the old coupling in as many words, and both now pin the opposite claim
— that the two clocks are separate and that nothing says otherwise — because the comment claiming
they matched had already survived one constant moving under it. The dialog's frame-rate field reads
its default, its minimum and its maximum from the engine instead of the literal 8 it used to carry,
which agreed with neither.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Two things reported from using the editor. The providers do not return transparency — checked
repeatedly against real generations, every sheet comes back opaque — and the corridor preview was too
small and too far away to see any detail.

THE BACKGROUND STOPS BEING A REQUEST AND BECOMES A COLOUR. The contract asked for a fully transparent
field in two separate paragraphs and arguing with that in prose was not working, so the prompt now names
a flat solid colour, which a model can actually paint, and the colour is keyed out in the Builder the
moment the sheet arrives. An image model is much better at "put this on a solid magenta field" than at
emitting an alpha channel, because the first is a thing it can paint and the second is a file format.
Magenta by default, and not arbitrarily: a key colour has to be one the subject never contains, and on a
fantasy monster roster green eats goblins, slimes, moss and every scaled thing while magenta is a colour
almost nothing alive or forged is. Green is offered for the case magenta fails — a fleshy or rose-toned
creature — because which colour is safe is a fact about the monster rather than about the technique, and
"already transparent" keys nothing, for a provider that does deliver alpha and for a PNG an author drew
themselves. Prompts/monster-sprites.txt says all of this too, since it is the document a person reads.

THE EDGE IS THE WHOLE DIFFICULTY OF KEYING, and two attempts at it are worth recording. A plain
threshold gives every pixel alpha 0 or 255 and leaves the anti-aliased rim as a ring of half-key pixels,
which on a dark wall reads as a coloured halo — so there are two bands, cleared inside `near`, kept
beyond `far`, ramped between, with the key's own channel pulled back toward the other two on the way.
Getting `far` wrong is easy and invisible: it was `near * 1.9`, which put the outer edge two thirds of
the way across the colour space, and a test over real pixels found an ordinary bone-coloured body pixel
coming back 79% opaque with its red and blue shifted. It is a narrow band just outside the key now. Then
the same test found the second fault: a cleared pixel is invisible, so its COLOUR looks as though it
cannot matter, and it does — the GPU filters the texture bilinearly and averages a texel with its
neighbours, transparent ones included, so a rim of alpha-nought pure-magenta pixels smears magenta into
the sprite's outline wherever it is drawn at anything but 1:1. Invisible in the editor, obvious in the
dungeon. Every cleared pixel that touches a kept one now takes that pixel's colour; one step is enough,
because bilinear filtering only ever reaches one texel.

THE PROMPT AND THE CONTROLS ARE NOT ALLOWED TO DISAGREE SILENTLY, which the colour made urgent: a prompt
asking for green while the keyer looks for magenta produces a sheet whose background is untouched, and
the author sees a full magenta rectangle and no reason for it. The prompt is not rewritten — it is a box
the author is invited to edit and losing a hand edit quietly is worse than the disagreement — so the
disagreement is reported instead, under the prompt, for the key colour and for the frame count alike.
Absence is not disagreement: a prompt written from scratch that names none of these things is left alone.

THE PREVIEW IS FRAMED ON THE CREATURE NOW rather than on the corridor. It stands at one square, which is
not an arbitrary "closer" — orthogonal adjacency is the distance at which the party actually meets a
monster, so it is the view that matters — and the focal length is solved so a creature of any height
fills most of the frame, where a fixed one left anything short a smudge near the horizon. Zooming the
lens rather than walking the camera in is what keeps it honest: focal length scales the walls, the floor,
the ceiling and the creature by the same factor, so how it sits against a one-square corridor and under a
1.15 ceiling is unchanged. The canvas is 460x360, because a 236px box cannot hold a whole monster at a
size where its face is legible.

Four new sections in Tests/test_sprite_sheet_editor.js, and the keyer's is run over real pixels rather
than read — a keyer subtly too greedy eats the figure and one too shy leaves a halo, and neither is
visible in the source. Both faults above are its findings. It also pins that re-keying reads the RAW
sheet every time, since keying is destructive and re-keying a keyed canvas eats a further ring of the
figure on every nudge of the tolerance. Six sabotages, and a seventh that survived first time: the
tolerance assertion used `>=`, which three equal counts satisfy, so a tolerance pinned to a constant
passed it — strict now. test_custom_monsters.js has one assertion re-pointed after the shape moved to
the top of the draw, its intent unchanged and re-sabotaged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Reported as a vertical scrollbar on the whole dungeon editor. The sprite sheet dialog replaced the old
Create monster one and left two of its closing </div> behind, which closed #db-root twenty-odd lines
early. Everything after that point fell outside it — including the two file inputs for tile art and map
import, which are hidden by `#db-root input[type=file] { display: none }` and which, escaping it,
rendered as visible Choose-file widgets below the fold. Measured: the document ran 921px against a 900px
viewport, and the 21px was a file picker. The sidebar is the only thing on this page meant to scroll and
it has its own overflow; the page itself now measures exactly the viewport at 700, 900 and 1200px tall,
with and without the dialog open.

The two lines are gone. What is more interesting is that nothing caught it, and something nearly did:
test_builder_sidebar_notes.js walks <details> depth down the file and says in as many words that an
unbalanced tag "would swallow the rest of the panel into one fold". That sentence is exactly as true of
<div>, and nobody had written it — so a dialog edit could close an ancestor early and the only symptom
was a scrollbar nobody would think to attribute to a modal.

Tests/test_sprite_sheet_editor.js §12 writes it: every <div> in the Builder closes exactly once, and
every file input is inside #db-root where the rule that hides it reaches. It lives in this file rather
than beside the <details> walk because editing a DIALOG is how it happens, and this is the file a dialog
edit brings you to. Verified by putting the two orphan tags back — both assertions fire, and the browser
agrees the page starts scrolling again.

Its own first version was wrong in a way worth recording: it walked #db-root's extent from the index of
the `id="db-root"` ATTRIBUTE, so the first <div> it met was a child and the walk reported the element
ending at that child's close — four file inputs "escaped" a container they were comfortably inside. It
starts from the opening tag now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Making one meant writing a prompt by hand from a text file kept beside the code, carrying it to an
image provider, and bringing the PNG back to a four-field box that asked for a name, a file, a frame
count and a height. The Dungeon Builder now has the whole act in one place: what the creature is, the
prompt, the sheet, the grid the engine will cut it on, the rate it moves at, and the thing standing two
squares down a corridor. It replaces the Create monster dialog rather than sitting beside it — that
dialog is this one's left column with the generating and the checking taken out, and two dialogs onto
one act is how they drift.

It is wide because the three things that can disagree have to be on screen together: the sheet, the
grid, and how the result reads moving. A sheet whose frame count is wrong looks perfectly fine examined
one at a time, which is exactly what a 400px column shows you. The sheet sits on a chequerboard for the
same kind of reason — a fully transparent background and a black one painted into every frame are
indistinguishable on a dark panel, and that is the most common thing wrong with a generated sheet.

THE GM IS ASKED FOR THE CREATURE CLAUSE AND NOTHING ELSE. The ✨ gets one sentence saying what the thing
looks like; the geometry is interpolated here from the frame count and cell size the author has actually
set, and the directive tells the model in as many words not to write frames, layout or lighting. A model
asked for the whole prompt writes plausible numbers, and wrong numbers are precisely the failure the
frame control exists to repair afterwards — asking for them would be building the fault the rest of the
dialog is there to correct. The clause leads and the contract follows it, which is the shape of the
example this was drawn from. Prompts/monster-sprites.txt stays as the document a person reads; the
contract in the code is what a provider is sent, and neither writes the frame count down.

Both generating acts cross to the game window, because the provider keys live in the vault and the
Builder is a separate window one window.open away from anything. The host answers by window IDENTITY —
event.source compared against the windows this tab opened — and never by origin, because the app is
file://-openable and a file:// document's origin is the literal "null": an allowlist would either refuse
the Builder there or have to admit every sandboxed frame with it. The sheet comes back as a data URL at
its ORIGINAL size, since its pixel dimensions are its contract and the app's usual 512px cap would leave
eight 64x128 frames and a smear at arm's length; as data rather than a link because the Builder measures
every sheet on a canvas and a cross-origin image taints it. A provider that forbids the read still hands
over its link rather than losing a picture it actually painted.

THE WORLD ART STYLE IS OFF FOR A SHEET, and that is the line most likely to be tidied away by someone
making this consistent with every other picture in the game. Those want it. A sheet wants the opposite:
its prompt spends most of its length demanding flat ambient light, no cast shadow, no rim light and a
hard cut-out on a transparent field, a style line saying "moody oil painting with visible brushwork"
argues with all of it, and the argument is won by whichever the model likes better.

Two things were got wrong first and are worth the next reader's attention. The corridor preview
interpolated between a near and a far rectangle instead of projecting, which put the monster's square at
nearly the full width of the canvas and drew a creature the size of a door — a preview whose one job is
to say how big something reads, answering a third of a corridor's length too close. It is a pinhole
projection at the engine's own figures now: walls one square apart, ceiling at 1.15, eye at 0.58. And
the frame guess estimated from the cell aspect alone, which reported five frames on a sheet that plainly
held eight: a provider commonly honours the count and rounds the cell, so the count asked for now wins
whenever the width divides evenly by it and the aspect is consulted only when it does not.

Two existing tests moved with it. test_custom_monsters.js is re-pointed at the new dialog with every
assertion's intent kept, and one of its regexes had been matching an English sentence — the alternation's
second branch is the bare word `sheet:`, and the new prose says "a monster in this engine IS its sheet:
a horizontal strip…", so it now strips comments first, the same trap test_item_card_dialog.js already
carries a note about. test_builder_sidebar_notes.js is untouched and stays as strict as it was: the
dialog's explanatory text moved off .note onto a class of its own, because that rule is about a sidebar
an author scrolls past on every pass of a map and a dialog is opened deliberately, read once and acted
in. Narrowing the rule to fit would have been the easier half of the same change and the wrong one.

Tests/test_sprite_sheet_editor.js is new — 79 assertions, nine sabotages each caught by the assertion
written for it, over the prompt's interpolated geometry, the derived width, the absence of any key or
provider call in the Builder, the identity guard, the art-style and downscale rules, the frame guess,
and that re-sheeting keeps a monster's id so the squares already standing one still have a monster.
Designs/dungeon-builder.html §18 is the write-up, with its open decisions — cells are frame-count-only
by choice, since full slice control would change how every saved dungeon is read — and §18a the
playtesting notes, which are all about how a provider behaves under the contract.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Two gaps in how the unit supervised the service, both of which only show up on a day nobody is watching.

Restart was on-failure, which does not cover a clean exit — and for a long-running server exiting 0 is
not a job well done, it is a bug that happens to look tidy. systemd would have read it as completion and
left the registry stopped with nothing in `systemctl status` suggesting anything was wrong. The only
intentional stop here is systemctl's own, so Restart=always is the honest setting.

The second is worse, and it is created by a design decision elsewhere that is right. server.js hard-stops
on a tokens file it cannot read, deliberately, so that a typo in a path can never quietly downgrade an
authenticated registry into one anybody may write to. That is an uncaught throw, so an exit 1, so a
failure, so a restart five seconds later, and then the same throw — forever. systemd's own default rate
limit cannot catch it: five starts in ten seconds is unreachable when RestartSec is 5s, so the breaker
never trips. The journal fills at twelve entries a minute and the one line naming the cause scrolls out
of sight. Now five failures inside a minute put the unit in `failed` and leave it there, which is a state
somebody will actually see.

StartLimitIntervalSec and StartLimitBurst are in [Unit] rather than [Service], and that is not
cosmetic. They moved sections in systemd v229; a current systemd logs "Unknown lvalue" and IGNORES them
under [Service], which is the quiet way to believe you have a circuit breaker and not have one. The
generated unit was rendered and parsed section by section to check it, because this is exactly the kind
of thing that looks right in a diff.

The script's existing preflight refuses to install when the named tokens file is missing, which catches
the common case at install time. It cannot help somebody editing /etc/registry.env afterwards, or a
tokens file whose permissions change, and those are the paths this is for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The note beside instances:1 warned about RegistryStore and stopped there, which is a third of the
reason. Two more pieces of state live in one process's memory and each breaks differently, so somebody
who finds the first, fixes it and raises the number still has a broken registry — and one of the two
they would not have found is the hardest to diagnose of the three.

ChallengeStore.live is a Map of origin-proof nonces, so a challenge issued by one worker cannot be
verified by another and roughly (N-1)/N of publishes fail under round-robin routing. That presents as
flaky origin proof rather than as anything architectural, and it is intermittent by construction, which
is worse to chase than the store's failure even though the store's loses data: the store at least fails
consistently and silently in one direction. The sweep is the third — setInterval in every worker means
N times the outbound origin-proof traffic to other operators' vaults, racing to write, and lifecycle.js
notes a re-read guard that is single-process and does nothing across them.

The note now also says what to do instead, because a warning with no path is one people route around.
The read side is what grows — reads are open, unauthenticated and happen on every crossing, while writes
are one heartbeat per vault — and /api/worlds is a pure GET varying only by query string with no auth
and no per-caller state, so caching it at the reverse proxy takes nearly all read load off Node with no
code change and this process still the single writer. Only past that does the store need shared backing,
and SQLite in WAL mode is the shape that fits: many readers, one writer, no network dependency. That
last part is not a preference. Registry/ is carved out to Apache-2.0 precisely so anyone can run one and
COMMERCIAL-LICENSE.md promises it publicly, so a required Redis or Postgres raises the floor for every
third-party operator and quietly works against what the carve-out is for.

Nothing here changes behaviour. It is written down because the finding otherwise lived only in a
conversation, next to a number somebody will eventually be tempted to change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

A shallow checkout had been quietly truncating the git log this report is built
from, so a regeneration from that state would have understated commits, days
active and lines of code. Unshallowed the repo before regenerating so the
report's stats span the project's actual history: 4,131 commits across 82 days
(2026-06-30 to 2026-09-19).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VPrrzgX9PKDDV5SkGrw2uG

The registry was a thing you started by hand with `node Registry/server.js`, which is fine on a laptop
and not a way to run something a federation resolves crossings against. This installs it the way the
login relay is installed — a dedicated unprivileged account, a confined unit, secrets in a 0600
environment file rather than in a world-readable unit — with pm2 in between, which is the part that
differs and the part worth explaining.

Web/LoginApi/deploy/loginapi.service argues against pm2 in its own header: a Node process supervising a
Node process, for a service with no dependencies, is installing a dependency to run the thing that has
none. That reasoning still holds for the relay, and this is deliberately the opposite call rather than
an oversight — for the registry, pm2 buys a uniform operational story across the estate and somewhere to
grow into, at the cost of one global package. The script says so where somebody comparing the two units
will find it.

It runs pm2-runtime rather than the `pm2 start` + `pm2 save` + `pm2 startup` recipe, so pm2 stays in the
foreground and systemd is the real supervisor: Restart=, boot ordering and journald all behave the way
every other unit on the box behaves, and there is no resurrect file to drift out of step. With the daemon
form systemd supervises a launcher that exits, and what actually restarts the service is a saved JSON
dump nobody reviews.

The ecosystem file pins instances to 1 in fork mode, and that is a correctness requirement rather than a
starting value. Cluster mode is the obvious reason to reach for pm2 and is the one thing this service
cannot have: RegistryStore reads registry.json into memory once, in its constructor, and every save
writes that whole map back. Two workers each hold their own copy and neither re-reads, so a descriptor
published to one is invisible to the other, and the other's next publish writes its stale map over the
file. The write is atomic, which makes the loss clean and total rather than corrupt — nothing logs, and
there is nothing afterwards to notice. The comment saying so is in the generated file, where the person
about to raise the number is looking.

Two differences from the relay's confinement, both forced by what this service actually does. It WRITES,
so ProtectSystem=strict needs StateDirectory=registry to survive — one writable path, created and owned
by systemd, with the registry's data and pm2's own scratch inside it and nowhere else writable at all.
And it makes OUTBOUND requests, because origin proof fetches a well-known path on a claimed vault before
listing it.

The script is re-runnable and that is how a change is deployed, because /opt/registry is a copy and a
`git pull` alone changes nothing there — the exact trap that cost an afternoon on the relay, where a
renamed secret went in, the service restarted, and the old code kept running from its own copy while
every symptom pointed at configuration. A re-run refreshes the files and the unit and leaves the
environment file and the data alone.

It also refuses to start a registry whose named tokens file is missing, ahead of systemd rather than
after it. server.js treats that as a hard stop by design, so that a typo in a path can never quietly
downgrade an authenticated registry to one anybody may write to — correct, and it produces a baffling
first run where the service starts, dies, and the health check reports a timeout while the cause is one
line deep in the journal. The script says it in a sentence instead. It finishes by asking /health rather
than by trusting `systemctl is-active`, which for a service that exits a second later is not the same
question.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

BUG-093. Every item objective a plan emits is titled "Acquire X" and every one of them asserted
inventoryHas, which answers a different question: is X in the pack right now. The two agree only for
a run that picks things up and never does anything with them, and they come apart the moment one
plays the world as written. Handing three Tide-Cult Tokens to Ys is the authored solution to that
quest, took two sessions to reach, and permanently un-earned Acquire Tide-Cult Token. A consumable
that consumeItem correctly destroys on use could never satisfy its own objective at all. The grade
rewarded hoarding and punished playing, and it did so silently, because the number simply came back
lower and read as content the run had missed.

State cannot answer a question about history, so the history is recorded. player.itemsEverAcquired
is a list of lowercased names written in acquireItem, which BUG-046's consolidation had already made
the single chokepoint where possession begins, so one line covers every route in. It goes above the
treasure early-return on purpose: the evaluator counts the trove as carried, so filing it below
would leave a gemstone gradeable while held and ungradeable once spent, which is this same bug with
a smaller blast radius. The class loadout is seeded by hand at both of its sites, being the one way
into the pack that is construction rather than acquisition.

The concern that held this back was that it moves every historical grade, and it turned out not to,
for a reason worth keeping rather than a lucky one. everAcquired falls back to the pack when a save
carries no acquisition record, which is exactly the old behaviour, and every save in existence
predates the field. Claude19's 19 September save grades 68/106 both ways; that is measured, not
assumed. The corollary is that the fix is forward-looking only, and his tokens stay un-earned for
good. Seeding the record from the compendium was considered and rejected: discovering a thing is not
acquiring it, and the reconstruction would hand out credit the save cannot support.

The committed plan was swapped surgically, thirty objectives and their thirty route twins, rather
than regenerated. Regenerating yields 112 objectives instead of 106, and the six extra are world
content rather than this change; worse, the committed plan was built from verengrad-authored-world.json,
a file that was never tracked and no longer exists, so nothing can confirm the world a regeneration
reads is that same artefact further authored. Absorbing that would have moved the denominator every
historical figure is quoted against, silently, inside a change about a predicate.

Ten sabotages, each caught by an assertion that distinguishes it, including one that MOVES the call
below the treasure branch rather than deleting it. The restore and loadout assertions slice the file
structurally rather than by a character window, which is the failure this repo's own notes predict.
test_acquire_item.js gained a stub for the new collaborator; it tests where a thing goes, not what is
remembered of it. The manifest records that its measured figures predate the predicate, and its
$carryNote is marked resolved: a Tide Cantrix could not hold 20 of 35 item objectives at once, so
they were never jointly satisfiable by that class, and now they are.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

BUG-096. gmFetch is the single transport chokepoint for all ninety-four GM calls, so one AbortController
there covers every one of them, and on abort it raises a flagged error whose message is written for the
person who will read it in the story: the Game Master did not answer within 120s, the turn was not taken,
try it again. AbortError signal is aborted without reason tells a player nothing.

Nothing else had to change to recover. The turn already wraps its work in a try/catch that hides the
spinner, logs, writes a line into the story and releases isProcessing - the machinery was never missing,
and all a hang needed was to become a throw. That is why the fix is small: this was not a broken recovery
path, it was a failure that never reached one.

Two client limits rather than one, because the calls are not alike. A single tight deadline was the
tempting version and would have been a worse bug than this: world generation runs on Fable with budgets
up to sixteen thousand tokens and legitimately takes minutes, so two minutes would kill it. The
interactive turn takes the tight number because a frozen prompt is the whole complaint, and everything
else keeps five. The vault's own deadline is longest of the three on purpose, so in the ordinary case the
browser gives up first and the player gets the better message; it is not redundant with the client's,
because it covers what the client cannot - a browser that has already gone away while the vault holds a
socket to a provider that stopped answering. It answers 504 with a timeout flag rather than throwing, so
the client gets a reply it can report instead of a dropped connection it has to guess about.

Both halves are driven rather than asserted at. Each test stands up a transport that accepts the request
and never answers, and the stub honours the abort signal because a real fetch does - a plain promise that
never settles hangs whether the signal was wired or not, which is a test that cannot tell the two builds
apart, and the first draft made exactly that mistake. Every assertion races a short clock so the broken
build fails in seconds instead of dying by suite timeout and reporting nothing. Six sabotages fail six
distinct named assertions, and the leak check had to be rewritten once because _getActiveHandles does not
report timers on this runtime and passed whether the timer was cleared or not.

Two unrelated tests moved with this and neither property changed. Both pinned gmFetch by character
window, and the comment block and the options argument pushed them past their patterns on code that still
does exactly what they assert. They ask membership now. This is the failure the repository's own note
predicts, that a window measures distance rather than membership and every one of them here eventually
fails on a true statement about code that simply moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The run resumed after a clean logout cleared the stall and went on to unlock the last five room hooks, so
the world now has none left: the spire's upper and lower chambers, the narthex, the chancel and the
transept, taking the character from 124 experience to 464 and completion from 72 to 75 per cent. Two of
those answers are worth reading rather than counting. The chancel replies to the statues with not
forgotten, never named, the chancel was built to hold one name once and yours arrives late and will not
stay, which is the unnamed condition woven into a payoff nobody asked it to reference. The transept turns
out to be the inverse of what it looks like, the marks cut into its silt holding perfectly while the slab
beside them moves.

BUG-059 reproduced twice, and both are now proven the way the original entry proved it. On the spire's
own original case the descent was timed to the trough, recognised by the Game Master in its own XP reason
and paid for, and held back with no nudge; the later unlock credits that descent. Then the transept did
it again and more cleanly - the whole three-part condition performed across four turns, narrated as
achieved, held back in silence, and the unlock's reason names only the pre-articulation turns and does
not mention the articulation at all. One pattern falls out of the three known instances: the nudge fired
on the single occasion the held-back hook needed a second actor, the boat shown to Mira, and did not fire
on the two that needed only the player to say what a thing meant.

BUG-096 cleared by itself and stays open, which is the point of it. Fourteen turns then ran normally and
nothing showed in the vault console, so the stall was transient and session-scoped; what made a transient
stall into an unrecoverable session was the missing deadline, and that has not changed.

BUG-065 is probably unreachable on this character and the entry now says so. Its case needs the Game
Master to narrate a corridor shut, which it did after the Anchor Saint was told her name, and she has
been named since 27 August: the southward route out of the chancel was walked deliberately and met no
refusal at all. It wants a fresh character who has not yet named her.

No new disposition evidence. The chorister in the lower chamber was approached for BUG-068 and BUG-074
and was already bound and passive from session 7, which the Game Master recognised and correctly declined
to redo. Those two want a creature that is currently hostile.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

BUG-096 recorded that a stalled GM request leaves the turn hanging with no timeout on either side. It
also takes the exit. logout() opens with an unconditional save flush, so pressing Log Out while a call is
in flight does nothing whatsoever - the click lands, the handler runs, and it waits behind the same
stall. Three attempts over several minutes left the logged-in flag true, the overlay hidden and the
player still mounted, with no new entry in the save diagnostic, while the living-world clock carried on.

That turns a bad turn into a session that cannot be finished, only abandoned, and it is the shape this
ledger keeps meeting: a state the player cannot see, in a UI that offers no way out of it. Worth saying
plainly that nothing was lost in this instance, because the per-turn autosave had already written the
experience and the room - but the player has no way to know that, which is most of the problem.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The ledger run went looking for the entries waiting on play and found the one nobody wanted. BUG-059's
own original case is the Gasping Spire's lower chamber, where the condition asks the player to time a
descent to the moment the water drops lowest. Claude19 did exactly that and deliberately did not say what
it meant, because saying what it means is how the hook was eventually earned in August and the point was
to see whether the nudge fires on the action alone. It does not. The roll was a critical, the narration
described the low water in words that paraphrase the original case almost exactly, and the response
carried neither loreUnlock nor nearMiss while the room lore stayed locked.

This time the judgement did not have to be inferred from a later unlock's why field, because the Game
Master named the authored condition in its own XP reason and paid twenty experience for it - timed the
descent to the trough of the spire's breathing rather than forcing it. So the action was recognised,
rewarded and described as done, the hook was held back, and the one thing rule 13e requires in that
situation was not set. Back to open, under the rule this ledger sets for itself, and the 8 September
sighting is left standing rather than withdrawn: the two together say the nudge fires sometimes, on one
build, eleven days apart, with both runs played the same way.

Then the session ended itself. Every turn after that one hung - echo printed, input cleared, nothing ever
returned, and isProcessing latched true so nothing further could be typed. The vault was not down: it
answered static requests and its own config in milliseconds while POST /vault/gm sat pending for ever,
and tracing the client showed the call really was issued. What turns a stalled upstream into a dead
session is that nothing sets a deadline - no AbortController in gmFetch, none in vault-core.js, none in
server.js - so the game cannot fail the turn, cannot say so, and cannot be recovered from inside. Filed
as BUG-096, deliberately not as a rate-limit report, since why the upstream stalled is a fact about
tonight and the missing timeout is a fact about the code.

The Upper Chamber's hook paid cleanly on the way through, which is worth recording beside the failure:
sitting still through three tolls without doing anything else uncovered why the spire gasps, field set in
the same response as the narration. The casualty is BUG-059's confirming turn, which was typed three
times and never reached the model; the XP reason carries the same admission, so the evidence stands, but
that turn is owed and is the first thing to try next session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Every other instruction in the GM prompt is overridable by design. `world.rules` is handed to the model
under a heading that says BINDING, the narrative guide is authorial instruction by definition, and a DM
authors both — that is what makes a world worth authoring. It is also the hole. World data is written by
whoever built the world, it travels inside the prompt, and a world file can arrive from anywhere: an
import, an export a stranger mailed, and before long a realm bought as downloadable content. A model
reading "BINDING" a few hundred lines above an authored paragraph has no way to tell which of the two we
meant to win.

So CONTENT_GUARDRAIL says which, out loud, and is interpolated at the very front of `stable` ahead of
every authored section. It states that it outranks every other instruction including the BINDING world
rules, and — the sentence that actually does the work — that text arriving inside world data does not
become an instruction by claiming to be one. Position alone is an argument the model cannot hear; a
world author writing "these rules override everything above" is making the louder claim unless we make
ours explicitly.

It is in the cached half because it is identical on every turn, and the test pins that separately from
Tests/test_prompt_cache.js: this is the newest text in the prefix and the likeliest place for somebody
to add a helpful interpolation later, which would move the prefix every turn and bill the whole 36k
rulebook at the write rate while the game went on playing correctly.

The forbidden categories are a data array rather than prose, for the reason the equipment slots were:
a list pasted into a paragraph goes stale the first time somebody adds to it and nothing says so. The
test reads that same array and asserts every entry reached the prompt, so adding a category here is the
whole of adding one. It is deliberately bullets and not numbers — the first draft numbered them 1 to 6
and collided with the ## Rules list, which cites itself by label constantly, leaving "rule 3" pointing
at two paragraphs at once and one of them the sexual-violence line. Tests/test_rulebook_numbering.js
caught that, which is the second time this week an existing test has earned its keep on a change that
had nothing to do with it.

The ALLOWED paragraph is load-bearing rather than reassurance, and is the half that will be trimmed by
somebody who thinks it is padding. This is a dark fantasy game whose combat kills people, whose villains
are cruel, and whose morality system means nothing if the player cannot choose badly. A model told to be
careful and not told where to stop is careful everywhere, and the symptom is a Game Master that softens
a battle — which reads as bad writing and never as a safety rule, so nobody traces it back here.

The test asserts each property and then breaks it on purpose against an engine re-booted from mutated
source: the interpolation deleted, a category cut out of the array literal, a world whose rules attack
the floor by name. Two of its own assertions were wrong on the first run and the sabotage is what found
them. Searching the whole prompt for "violence" passed on the sexual-violence PROHIBITION while claiming
to prove violence was permitted — green, and asserting the opposite of what the text said — so the
permission assertions are now scoped to the ALLOWED paragraph. And the roster sabotage spliced the live
array, which changes nothing: CONTENT_GUARDRAIL is built once at load like COMBAT_CONTRACT, so the
prompt was already frozen and the test would have reported the code broken when it was the test.

What this does not do is show that a model obeys any of it. That is a playtesting claim and belongs in a
PLAYTESTING NOTES section when this system gets a design doc. What is decidable at a desk is that the
text reaches the model, in the cached half, ahead of the content that would contradict it, with every
category intact — and that is what a store-page guardrail attestation would be describing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Running the suite from a `git worktree` reported 918/919 with test_asset_provenance.js failing and
nothing in the output naming the cause. The ignored-file half of the criterion writes a pattern into
`.git/info/exclude`, and it located that file as ROOT/.git — which in a worktree is a FILE holding
`gitdir: …/.git/worktrees/<name>`, not a directory. The guard asked `existsSync`, the file answered
yes, and the `mkdirSync` a few lines later threw ENOTDIR. That throw was uncaught, so the process
died where it stood and the three assertions after the block never ran at all; the suite's summary
was the only symptom, and it pointed at the file rather than at the checkout.

The narrow fix would have been to ask whether ROOT/.git is a directory and take the tarball-export
SKIP path when it is not. That is correct and it means the check quietly does not run in a worktree,
which is the same shape as the defect it is testing for: a filter nobody can see. So instead the
block now asks git where the common git directory is — `git rev-parse --git-common-dir`, which is
where `info/exclude` lives and which answers correctly for a clone, a worktree and a submodule
alike. The test already spawns processes, so this costs nothing new. Only the genuine absence of git
now skips, which is what the SKIP message always claimed.

Resolving a path is a claim, and a wrong one here is silent in a particular way: the exclude lands
somewhere git does not read, the probe is then merely an untracked file, and the two assertions
below fail as though the ignore rule had regressed. So the block now asks `git check-ignore` whether
the rule actually took, before drawing any conclusion from the tool's output, and reports the git
directory it used. Sabotaged by pointing the resolution at a real but unrelated directory, that
assertion is the one that names the cause while the other two blame the wrong thing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

BUG-094's fix was settled by test on 12 September; this is the same thing observed in play, and the save
it damaged is repaired. Twenty-six rooms back to twelve, no village_square, and then a full reload -
which is the exact operation that used to re-merge - leaving it at twelve. The load that had been
vandalising this save every time no longer does.

The confirming number is not twelve but seventy-two. World completion read 32% before and reads 72%
after, which is precisely where session 10 closed: the figure had never measured lost progress, only
foreign content sitting in the denominator. Getting the old number back without replaying anything is
what says the surgery removed the right records and nothing else.

Subtractive rather than a replacement, because the save legitimately diverges from the library copy - it
holds a Child's Toy Boat recovered in play that the vault's world.json has never had. So a record went
only if it was in the save AND in the built-in world AND not authored in Verengrad, and the third
condition did the work: four regions, ten spells, ten skills, nine alignments and every weather table
that both worlds share were kept, where a cruder rule reading anything absent from the library copy would
have torn Verengrad's own content out. A hundred and seventeen records across thirteen collections, and
items landing on 45 against the authored 44 is the toy boat surviving, which is how the rule proves it
discriminated rather than guessed.

Safety was established before anything was touched rather than hoped for afterwards. All fifteen carried
items resolve to Verengrad refs, and a scan of the whole player object for the doomed ids returned three
hits of which two were vocabulary: dagger is a subtype on the Bone Needle, spellbook is the Drowned
Psalter's type. The third, player.factionSeen.guards, was a real marker for the built-in faction and went
with it. world.imported is set true again to match Claude18 and Claude20 on the same world, though with
the identity check in place that is belt-and-braces rather than the guard. The pre-repair export is kept
as the rollback point.

The notes record the consequence that matters for planning: this save can never gain the new systems. A
save carries its own world and the only merge that exists pulls from the built-in one, so factions,
reagents, concoctions and ailments authored into the Verengrad library will reach new games only.
Claude19 is for the ledger entries; the feature notes need a fresh character on the enriched world.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Regenerated from the full git history (node Tools/gen-progress-report.js):
4121 commits across 82 days, busiest day September 7th with 166 commits.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S6zhcnaxdvCZxNukZNFWYU

The relay page carried `form-action https://<tenant>` and Chrome blocked the submission it exists to
make: "Sending form data to 'https://auth.thelostrealms.ai/continue?state=…' violates the following
Content Security Policy directive: form-action https://auth.thelostrealms.ai". The directive names the
exact origin being posted to and the browser refuses anyway, which is why this took three wrong guesses
to reach — a site-wide CSP intersecting with ours, a blocked script, an expired token. Each was
plausible and none was it.

Chrome enforces form-action ACROSS REDIRECTS rather than only against the URL the form names. /continue
completes the login and redirects to whichever application started it, and that origin is one this
service is never told: the website, a hosted game, or a vault on http://localhost:8787 all reach this
endpoint identically, which is the entire point of one tenant serving every surface. So the allowlist
was missing the destination by construction, and the block is reported against the URL that WAS
allowed — which reads as the value being wrong rather than as the list being incomplete. It cannot be
completed. A wildcard would permit everything and assert nothing.

So it is removed, and the test asserts its absence with the reason, because re-adding it looks like an
obvious hardening improvement and breaks every login that reaches this page.

What is lost is worth stating rather than waving away. form-action would have stopped this page posting
somewhere other than the tenant — over an action that is server-generated from configuration, on a page
with one form, with no user input anywhere near that URL, and with script-src locked to a per-response
nonce. The directives that remain are the ones doing the work here: default-src 'none' permits no
fetches at all, base-uri 'none' stops a injected <base> from rewriting the action, and
frame-ancestors 'none' keeps the page out of anybody else's frame.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Designs/native-app-login.html §14 puts the outbound token at sixty seconds, reasoning that it is minted
and posted in the same redirect. That is true of the automatic path, which takes milliseconds, and
false of the one a person uses. When the relay page's script cannot run the page waits for a click, and
sixty seconds is less time than somebody takes to read a screen that says "Returning you to sign-in…",
conclude it has stalled, and press the button underneath it.

What they get then is "Oops!, something went wrong" from Auth0: validateToken finds an expired token,
the Action denies rather than admitting anybody whose answer it cannot verify, and the login fails.
Nothing in that message says "too slow" and nothing on the page said it was on a clock. The failure
also arrives well after the part that looked wrong, so the natural reading is that the relay is broken
rather than that the answer went stale while it sat on screen.

Five minutes. The expiry here is defence in depth rather than the control that matters: `state` is what
binds an answer to one live Auth0 transaction, and Auth0 refuses a /continue whose transaction has
finished, so replaying a token requires that same login still to be open. Five minutes is a third of
Auth0's own default for this and still far shorter than the window `state` leaves.

This does not explain why the script fails to run, which is a separate and still-open question. It
explains why the fallback did not work either, which made one fault look like two.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The previous commit put the Continue button inside <noscript> to stop it being clicked while the page
was already submitting. That fixes the double submission and breaks the case that is actually
happening: <noscript> renders when SCRIPTING IS DISABLED, and the script here is not disabled, it is
BLOCKED. A Content-Security-Policy added by the site's own web server intersects with the one this
response sends — browsers enforce every policy present, not the last one — so a site policy that does
not know this response's nonce stops the inline script while the styles, permitted by both, still
load. The page therefore arrives looking correct and does nothing, which is what was observed.

Behind <noscript> the button would not render in that case either, since scripting is enabled. The
page would offer no automatic submission and nothing to click, at the last step of a login, with no
way forward at all. Trading a double submission for a dead end is a bad trade.

So the button is rendered always and the script disables it before submitting. A blocked script leaves
a working button; a running script leaves nothing to click. The order matters and is asserted: code
after form.submit() may never run, because the navigation is already under way, and the window that
needed closing is exactly the one the submission opens.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The page that carries the signed answer back to /continue submits itself by script and also rendered a
Continue button for anyone without script. Unconditionally — so with script enabled it did both: the
automatic submission went out, the page stayed on screen saying "Returning you to sign-in…", and a
button sat there inviting a click on a screen that appears to have stalled. Clicking it POSTs to
/continue a second time with the same `state`, and Auth0 consumed that transaction on the first call.

The shape of the failure is why this is worth more than a one-line fix. The FIRST call succeeded
completely: onContinuePostLogin ran, the acceptance was written to app_metadata, the login finished.
The SECOND produced "Unable to process redirect callback … invalid state parameter", and that is the
screen the user was left looking at. So the visible evidence pointed at a broken relay while the
record sat in the user's profile proving it had worked — and retrying appeared to fix it, because by
then the stored version matched and no consent was required at all. Three separate signals, each
misleading in a different direction.

The button is inside <noscript> now, so with script available there is nothing to click while the
submission is in flight. The script also marks the form as sent before calling submit() rather than
from a submit listener, because form.submit() does not fire that event — a flag set by the listener
would never be set, which is the sort of guard that reads as protection and is not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Auth0 appends session_token and state to TERMS_PAGE_URL, and nginx's `return 301` does not re-append
arguments the way `rewrite` does. So a redirect sitting between Auth0 and the consent page drops the
transaction, and the shape of that failure is the reason it is worth a section: the page loads
perfectly, shows its "this page is part of signing in" notice, and the login dead-ends with nothing
looking broken anywhere.

The common case is a site that hides file extensions. The rule found in front of this one —
`if ($request_uri ~ ^/(.*)\.html$) { return 301 /$1; }` — is safe, and safe by accident:
$request_uri INCLUDES the query string, so once Auth0 has appended one the value no longer ends in
.html and the rule does not fire. The same rule written with $uri, which is the more idiomatic
variable and excludes arguments, fires and drops the parameters. That is a login flow depending on
which of two nearly identical variables somebody reached for, and the dependency is invisible from
either file.

So the README says to point TERMS_PAGE_URL at a URL that answers 200 with no redirect, and gives the
curl that settles it — with the query string attached, because that is the whole test. Opening the
bare page in a browser proves the file is reachable and nothing else: with no query string there is
nothing to lose, and the page renders the same either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Two decisions settled, and only one of them needed code. Declining the terms denies the login, which
is what the Action already did: api.access.deny fails the sign-in on every surface, so no session
exists for somebody who agreed to nothing. That is also what dissolves the ordering problem a desktop
vault otherwise has, since it claims its owner in middleware on the first authenticated request —
long before any dialog a client could draw.

The other was storage, and separate app_metadata keys won over one combined id. The combined version
is simpler in every file it touches and has one behaviour nobody wants: changing any document asks
everybody about all of them, which is the prompt people click through without reading. So the Action
takes a TERMS_KEY naming the key it owns — `terms` today, `eula` when that document exists — and
adding the second document becomes a second copy of the Action with its own secrets rather than an
edit to this one.

The cost lands on the relay, which is why this is worth doing before an Action is pasted rather than
after. With one key per document, more than one version id is current at a time, so TERMS_VERSION now
accepts a comma-separated list and the check is membership rather than equality. Three properties had
to survive that: a draft in the list is still refused, because the draft rule is a constant and must
not become reachable by listing one; an id in neither list is still refused, because a list is two
exact matches rather than a licence; and an EMPTY list accepts NOTHING. That last is the opposite of
how a missing filter usually behaves and is the point — falling through to "allow" when unset would
sign an acceptance of whatever version a browser claimed, which is the exact thing the check exists
to stop, arrived at by omission.

The key is validated rather than trusted. It names a field we own, and a typo would write an
acceptance under a name nothing reads: the record lands, the next login prompts again, and the answer
sits in the profile under a key that never matches. On the way in an invalid key means the Action does
not prompt; on the way back it denies, because by then a person has answered and misfiling that
silently is worse than refusing it. A test asserts the read and the write use the same variable, since
the failure of that is invisible from either half alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The install puts server.js and terms-core.js in /opt/loginapi and the unit runs them from there. That
is deliberate — the alternative couples a running daemon to a working checkout — but it means the
repository and the running code are two things, and the README described how to create them without
ever saying how to keep them in step.

The failure it produces found itself within an hour of the first deployment, and it is the kind where
both halves look correct in isolation. A variable was renamed in the repository; /etc/loginapi.env was
updated to match; the copy was not refreshed. The running code read the old name, the environment
supplied the new one, and /healthz answered configured:false while the file on disk plainly contained
the value. Neither the env file nor the service log points at the gap, because neither knows the other
half moved.

A symlink from /opt/loginapi into the checkout would close it and is explicitly not recommended. The
service runs unprivileged with ProtectHome=yes, so a checkout under a home directory is unreachable to
it; relocating the checkout to suit the service then means a git pull can change running code with no
restart and no record of when that happened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The relay read AUTH0_REDIRECT_SECRET and the Action read TERMS_REDIRECT_SECRET, and they are the same
value. That is the worst possible naming for this particular variable: the entire requirement on it is
that the two copies match byte for byte, and giving them different names invites somebody to generate
two — which fails at the last step of a login, as a signature mismatch, with the two halves looking
like separate settings that were each configured correctly.

TERMS_REDIRECT_SECRET wins for two reasons beyond agreement. It sits beside TERMS_VERSION in the same
file rather than in a different alphabetical neighbourhood, and AUTH0_REDIRECT_SECRET was misleading
on its face: Auth0 issues nothing here. The value is generated by whoever deploys this and told to
both sides, which is what makes it a shared secret rather than a credential.

.env.example names the old spelling in prose so an instance already running against it is
recognisable rather than mysterious — the symptom of missing it is /healthz reporting
configured:false and every relay request answering 503, which is loud, but only points at the right
line if the reader knows what changed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Amazon Linux 2023's nodejs24 package installs /usr/bin/node-24 and no unversioned binary, which the
unit did not anticipate: it said to adjust the path "if it is not /usr/bin/node" and left the reader
to discover that there may be no such file at all. `ls -l /usr/bin/node*` is the check that answers
it, and `alternatives --list | grep node` is worth trying first, because an unversioned symlink
registered there survives a major-version bump without touching this file.

Pointing ExecStart at the versioned binary is correct and needs nothing else relaxed — it is a system
path, so ProtectHome is not involved. What is worth stating is where that puts the version number:
in this unit. A later migration to nodejs26 that removes 24 breaks the service at its next restart
rather than at the moment of the change, which is the same failure shape as the nvm path below it,
milder only because removing a system package is a deliberate act and pruning an nvm version is not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Server/package.json declares engines >=20.15.0, and anybody reading it while putting the relay on a
web server would reasonably conclude they need that. The floor is real and it belongs to the VAULT:
zip-read.js verifies upload checksums with zlib.crc32, which arrived in v20.15.0 on the 20 line. The
relay does nothing of the sort. The newest API it touches is Buffer.from(…, 'base64url') at Node 15.7,
and createHmac, timingSafeEqual, randomBytes, http.createServer and URLSearchParams all predate that
by years.

The practical consequence is what makes it worth writing down. Following the repository's floor on a
server whose distribution packages something older leads to adding a third-party Node repository to a
web host for a service that needs none of it — more moving parts, and an apt or dnf source to keep
trusted, in service of a version requirement that was never this service's. Whatever the distribution
ships is ample, and the README now says so with the one-line install for both package managers.

fetch() is worth a note for the next person who greps: it appears in server.js only inside the comment
explaining why the consent page submits a form instead of calling one, so the relay has no Node 18
requirement hiding in it either. That is the fourth time in this directory's short life that prose
about a thing has read as the thing — after "not fetch()" in the consent page, the Liquid tags written
out in the page template's own header, and width:100% in the footer's comment.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The unit said to adjust the path to node if it is not /usr/bin/node, which is true and is not enough
advice for the common case. `which node` on a machine using nvm answers with something like
~/.nvm/versions/node/v24.20.0/bin/node, and that path fails here for two unrelated reasons.

The first is immediate and at least announces itself: ProtectHome=yes makes /home invisible to the
service, so systemd cannot execute ExecStart and the unit dies with 203/EXEC. That reads as a
permissions problem on the binary and is not one — the file is fine, the directory is not there as far
as this process is concerned. A symlink into /usr/local/bin does not help, since the target is still
under /home.

The second is the one worth writing down, because nothing reports it for weeks. The path carries a
VERSION NUMBER, and it stops existing the next time nvm installs a newer Node and the old one is
cleaned up. A running service keeps running; it fails at its next restart, long after the change that
caused it, with no connection to anything anybody remembers doing. nvm is per-user and
version-switchable by design and a system service is neither, so pointing one at the other couples a
daemon to one operator's shell configuration.

So the unit now names the durable answer — a system-wide Node a package manager owns — and gives the
one-line way to run against nvm's copy anyway, which is a reasonable thing to want while getting
something up: BindReadOnlyPaths on that one directory, applied after ProtectHome so the rest of /home
stays hidden. It also says explicitly not to reach for ProtectHome=read-only, which does work and
trades every home directory on the box being readable by this service for a path fix that one line
does precisely. The README's symptom table gains the 203/EXEC row for the same reason the others are
there: the message does not point at its cause.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Decision 6 says the deployable parts of this belong in the repository rather than in somebody's
console history, and until now that applied to the Action and the page template while the thing that
actually runs on a server had nothing. deploy/ now holds a systemd unit and worked reverse-proxy
blocks for nginx and Apache, and the README carries the six steps end to end.

systemd rather than pm2, which the design document mentioned first. pm2 is a Node process supervising
a Node process, so for a service with no dependencies it means installing a dependency in order to run
the thing that has none. systemd is already running, already starts on boot and already takes stdout
into journald — and it can drop privileges and remove filesystem access, which is worth having on the
one process in this system that holds an HMAC secret.

The confinement is unusually tight and the relay can afford it because it writes nothing: no database,
no cache, no log files of its own. ProtectSystem=strict with no ReadWritePaths leaves the whole
filesystem read-only to it. That is worth stating in the unit rather than only achieving, because the
first change that needs a writable path is also the change that makes the privacy notice's "we run no
user database" claim false, and a unit that has to be loosened to allow it is a place that question
gets asked.

The secret is deliberately not in the unit. Unit files are world-readable — systemctl cat works for
any account on the box — so an Environment= line carrying AUTH0_REDIRECT_SECRET publishes it locally.
EnvironmentFile is read by systemd as root before privileges are dropped, so the file can be 0600
root:root and the service still gets its values.

Two omissions are named rather than left out. MemoryDenyWriteExecute is the reflex next hardening line
and it breaks Node, because V8's JIT maps pages writable and then executable; the process dies at
startup with a SIGSYS that reads as a crash rather than as a policy refusal. And the trailing slash on
nginx's proxy_pass is what strips the /loginapi prefix — without it the relay is asked for a path it
does not serve, answers 404, and the consent page fails at the last step of a login with nothing to
say why. Both are one character or one line, and both fail in a way that does not point at itself, so
the README has a table matching each symptom to its cause.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Merges the Auth0 work. The headline is that the vault holds no AUTH0_CLIENT_SECRET and never did need
one: express-openid-connect refuses public code-flow clients outright, which was the sole reason a
secret was ever held, and replacing it with openid-client and Authorization Code + PKCE against a
Native application removed the credential rather than protecting it. That mattered more than it
sounds, because auth0Configured() is all-or-nothing and a vault that decided Auth0 was not configured
served the game to anyone who could reach the port — the state every distributed copy would have
shipped in.

One tenant now covers the website, the hosted game and a vault running on somebody's own machine, so
a person is one account rather than three. The cost of that is paid in the play gate: an empty
VAULT_PLAYER_EMAILS used to mean "anyone", which was sound while each owner ran their own tenant and
became "every marketing-page signup may play on every default-configured vault" the moment the tenant
was shared. An empty list now admits the admins and the owner; VAULT_ANYONE_CAN_JOIN is the explicit
route and always was. A desktop install claims its first authenticated account as owner, because
authentication working on a clean machine while authorization refused the owner it had just admitted
was otherwise the shipped product.

The terms flow arrives half-built and says so. Web/LoginApi holds the relay that signs an acceptance
for an Auth0 Redirect Action — zero dependencies, no database, because the acceptance lives on the
Auth0 profile and that is what lets the privacy notice say we run no user database and mean it. The
consent page and the login page template are here too. Nothing is deployed: the page posts to
/loginapi/eula/continue, which does not exist yet, and reaching it means guessing a URL for a page
that explains it is part of signing in. The EULA stays eula-0.1-draft and the relay refuses a draft
version as a constant rather than a setting, so wiring this up early cannot collect agreements to a
document no lawyer has read.

Several things in here are corrections to guidance that was actively wrong rather than merely absent
— the vault's own error page told operators to point AUTH0_ISSUER_BASE_URL at an auth0.com URL, which
breaks single sign-on for a tenant on a custom domain, and each such fix carries the failure that
found it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The login screen lost its background image the moment the template was applied, and the rule that
caused it was written into this repository as an assertion. "Branding → Styles owns the page
background, so the template must not set one" sounds right and is backwards. A custom page template
replaces the WHOLE document, including the default one Auth0 was using to apply that setting. The
theme still holds the value; after a template is applied there is simply nothing left to apply it.
Auth0's own minimum template restates the background for exactly this reason, which is the thing to
have read before asserting the opposite.

So the body rule is back, in the shape Auth0 documents. The COLOUR still comes from the theme, as the
custom property auth0:head injects, because that one really would be overriding to hard-code. The
IMAGE is named by URL because no Liquid variable exposes it — branding.colors.page_background is a
colour — and that duplication is Auth0's design rather than a choice: change it in Branding → Styles
and it must change here too. The test now asserts all of that, where it previously asserted the
absence that caused the fault.

Separately, the footer was 32px wider than the viewport on every width. It was position:fixed with
width:100% and 16px of horizontal padding, and this file has no global box-sizing rule — the site's
stylesheet supplies that and is not loaded here — so the login page scrolled sideways. Measured
rather than guessed: 517px of footer against a 485px document. Both edges are anchored now, which is
correct whatever the padding becomes. The links also wrap as a flex group rather than relying on a
breakpoint to hide the separators, since a breakpoint is a guess about widths and wrapping is an
answer for all of them.

And a third occurrence of one pattern, which is enough to name it. The footer assertion failed
against correct code because width:100% appears in the comment explaining why it is not used — after
"not fetch()" in the consent page, and after the Liquid tags written out in this template's own
header, which made the template invalid. It is not coincidence: a comment that earns its place names
the thing it warns about, so prose about a mistake reads exactly like the mistake to anything
matching on text. Every check about what a file DOES now reads it with the prose stripped first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Auth0 refused the template with "The template must contain a single auth0:head tag and at least one
auth0:widget tag", and it was right. The block at the top of the file explaining why those two tags
matter spelled both of them out, so the file carried two of each. Auth0 counts the tags across the
whole template and a Liquid comment is not excluded from that count, so the prose about the tags was
indistinguishable from the tags. They are named without their delimiters now, and the comment says
why it is written that way, because the obvious edit is to spell them out again.

The template was the symptom. The fault was in the validator, which asked whether each tag was
PRESENT — and a duplicate is invisible to a presence check. It passed a file that the tenant refused,
which is the worst answer a pre-flight check can give: it converts "this will not work" into "this is
fine", and the person running it has no reason to doubt the tool until the API contradicts it. The
rule implemented now is Auth0's own, per tag rather than shared: exactly one head, one or more widget.
The two tags do not have the same rule and a symmetric check would have been wrong about one of them.

Where a count is too high the message names a comment as the likely source, because the second copy
is rarely where anyone looks — the first one is right there in the markup doing its job.

Tests cover the duplicate directly, along with the asymmetry (two widgets is valid, two heads is not)
and a sabotage case proving the counter counts rather than reporting presence, since a counter that
silently degraded to a boolean would restore exactly the hole this closes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The backup step reads the template the tenant has now, before replacing it. A tenant that has never
had one answers 404 inexistent_templates_universal_login — which is the state of every tenant the
first time this script is run, so the one command that had to work on a fresh tenant was the only
one that could not. It was written with a try/catch around that read, and the catch never ran,
because api() reported failure through die() and die() called process.exit().

The message the user got was not even the 404. Calling process.exit() from inside an async function
tears the event loop down with a fetch still in flight, and libuv on Windows aborts: "Assertion
failed: !(handle->flags & UV_HANDLE_CLOSING)". That crash prints AFTER the real error and reads like
the real error, so the first thing to understand about the failure was the thing that had nothing to
do with it.

So api() now throws an ApiError carrying the status and a body with the token redacted, and
fetchCurrent() decides what a status means: 404 is "there is no template yet" and returns an answer,
everything else propagates. A 403 in particular must still stop the run — it means the token lacks
update:branding, and carrying on would replace a template with no backup taken. die() sets
process.exitCode and throws a sentinel instead of exiting, so the process ends on its own once the
socket is closed and the message a person reads is the last thing printed.

Two things the failure exposed beyond the bug. The CLI body ran on require, so a test could not
import the validator without the script making a network call — it is behind require.main now. And
the backup message promised that `--delete` undoes an apply on a tenant that had nothing, which was
true of the Management API and not of this script; --delete exists now, and it is the only undo
there is, since Auth0 offers no Dashboard page to clear this setting from.

The new assertions drive fetchCurrent with a stubbed 404, a stubbed 403 and a stubbed success, so the
case that shipped broken is now the case with a test on it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The printed Auth0 CLI command did not work, and the reason is worth keeping because it is not
specific to this template. Windows PowerShell's legacy native-argument passing re-splits a string on
whitespace before handing it to an .exe, so a JSON payload containing `{%- auth0:head -%}` arrives
as three separate arguments and the CLI rejects `-%}` as an unknown shorthand flag. The error it
prints has been through Go's fmt twice and reads as `Unknown shorthand flag: '%!'(MISSING) in
-%!}(MISSING)`, which names neither the file nor the cause.

Writing the payload to a file was the right first move and was not enough on its own: a file only
helps the shells that can pass its contents as one argument, and that is the thing PowerShell 5.1
will not do. So the guidance now leads with the token path, which hands the template to Node and
Node to the Management API with no shell parsing anywhere in between. The CLI route stays, marked
for bash and zsh, with the PowerShell 7.3+ workaround named and the 5.1 case sent to option one.

The comment above the payload file records this as something that happened rather than something
anticipated, because the file alone looks like enough until somebody on Windows runs it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The command apply-template.js printed inlined the whole Liquid template into a bash $( ) substitution.
That is wrong twice over. It does not run in PowerShell, which is where this is actually being typed,
and the general form of it cannot be made safe: the template is several kilobytes of HTML carrying
quotes, braces and newlines, and bash, PowerShell and cmd each quote those differently. The failure
mode is not a command that errors — it is a template that applies and is subtly wrong, on the one
setting Auth0 gives no Dashboard page to inspect it from.

So the payload is written to a file and the printed commands read it back, in the two shells anybody
here will be using, with the token path offered as a third. A file is the one form that survives all
of them identically. The JSON round-trips byte-for-byte to the source with both Liquid tags intact,
which is checked before it is offered rather than after it is sent. payload.json is generated and
gitignored alongside the backups directory.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Designs/native-app-login.html §14 carries a rider that is easy to read as a detail and is not: the
privacy notice belongs BEFORE the sign-in rather than after it, because the login IS the collection —
an address is already a record in our tenant by the time any post-login dialog could describe how it
is handled. The landing page could not honour it. Its corner row is five icon-only buttons with no
room for a line of prose, and the obvious fallback, a tooltip, is not disclosure at all: there is no
hover on a touch screen, a title attribute cannot hold a link, and notice that requires hovering
before clicking is notice most people never receive.

The screen where credentials are actually entered is Auth0's, and one page template serves the whole
tenant, so the website, the hosted game and the vault inside the desktop app are covered by a single
setting. That is §13's one-tenant decision paying for itself a second time. There is no Dashboard
page for it — Auth0 states that page templates can only be updated through the Management API — which
is why the template and a script to push it live here rather than a note about where to click, and
why the backup that script writes is the only undo that exists.

apply-template.js refuses more than it does. One template covers every application and every screen,
signup and MFA and password reset included, so a template missing {%- auth0:widget -%} renders a
beautiful page with no way to sign in, everywhere at once, and it presents as a styling fault. The
script checks both required tags as literal substrings, sends nothing without --apply, saves the
current template first, and never echoes the management token even in an error body.

Two drafts of the template were wrong in the same direction and the second was caught by the person
who would have paid for it. It set a body background, which Branding → Styles owns — so it would have
silently replaced a background image chosen in that editor while appearing to be about a footer. That
is now an assertion. The footer is translucent with a backdrop blur for the same reason one step on:
a solid strip does not replace a background but permanently covers the bottom of it, which is the
same loss arriving by another route.

The consent page verifies nothing and cannot, because verification needs the shared secret and a
secret in page JavaScript is a published one. It submits a plain form rather than fetching, which
keeps CORS off the single origin holding that secret. It hard-codes the version it displays instead
of decoding it out of the session token — the token does carry it, and reading it is exactly how a
page ends up showing one agreement and recording another. Three places now have to agree: the page's
meta id, the field it posts, and the relay's own configured version.

One assertion failed on correct code before it was right: "never fetches" matched the comment
explaining that the page does not fetch. A test that fails on correct code has its assertion deleted
rather than its matcher fixed, and then it catches nothing, so it strips comments first and was
re-confirmed against a real fetch( inserted into the script.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

A user signed in on the website, opened the vault in another tab, and was shown Auth0's full login
screen. The redirect itself is expected and permanent — the vault is a separate relying party with
its own session cookie on its own origin, so it must run its own OIDC round trip, which is what §11
means by "SSO removes the password prompt, it does not remove the redirect URI registration". The
login SCREEN is not expected. identity.js sends no prompt parameter, so nothing in this code asks
for it.

What does ask for it is a tenant reachable at two addresses. A custom domain does not replace the
canonical TENANT.REGION.auth0.com, it sits beside it, and Auth0 keeps a SEPARATE LOGIN SESSION PER
DOMAIN — its own custom-domain page says so while describing a migration, noting that sessions
created at the canonical domain stop being valid once the custom one is in use. So one tenant named
by two different hosts is one tenant and two cookie jars. Everything else works: both surfaces
authenticate, both resolve the same account, both gates behave. The only symptom is the second
surface asking somebody to log in who already has, which reads as a fault in whichever surface was
opened second.

The reason this is a change to the code rather than a note somewhere is that the vault was actively
teaching it. oidcUnreachablePage told operators AUTH0_ISSUER_BASE_URL "must be the full
https://…auth0.com tenant URL", and that a firewall would be blocking *.auth0.com. Both sentences
predate the tenant having a custom domain and both became false when it got one — and the first does
not merely fail to help, it instructs the reader to create exactly this split, on the page they are
reading BECAUSE something is already wrong. .env.example and README.md carried the same example for
the same reason, so all three now lead with the custom domain and state the consequence rather than
only the form.

The test pins the absence of the retired sentence with that sentence as its sabotage case, because
it would have passed every assertion already there: the page named the issuer, offered a retry link,
escaped its input and reported an unset value, and was wrong about the one thing an operator would
act on. Designs/native-app-login.html §13 gains the rule it turns out to depend on — one tenant is
not sufficient for one login across three surfaces; they must also name the same domain.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Section 07 argued that the custom domain is load-bearing rather than branding, and then described
only the half that faces the browser: the silent-auth iframe, the third-party cookie, the registrable
domain the two have to share. The half it left out is that choosing a custom domain also changes the
return address Auth0 hands to every social connection, and each of those providers keeps its own list
of permitted redirect URIs. Auth0's custom-domain page says so in a single line that is easy to read
past, and reading past it costs a login that fails on Google's page, under Google's branding, with
wording about the app's request being invalid — which reads like a problem with verification or
publication status and is a string comparison failing.

Two registrations look right and are both wrong, so both are written down. The path is not optional:
https://auth.thelostrealms.ai does not match https://auth.thelostrealms.ai/login/callback, because
the comparison is over the whole string rather than the host. And the site's own origin does not
belong in that list at all — the leg being authorised is Auth0 to Google and back, the website is not
a party to it, and Google never redirects there. A bare origin belongs in the field directly above,
Authorized JavaScript origins, which is what such a value is usually reaching for.

The canonical tenant URI is worth registering alongside the custom one even though nothing here
initiates through it, because the Dashboard's own Try Connection button does. Without it that button
fails while production succeeds, which is the most misleading pair of signals the configuration can
produce.

Also recorded, because it removes an option people reach for first: Auth0's development keys cannot
be used with a custom domain at all. A tenant on one has no shortcut for social connections, so
supplying the provider's own client id and secret is the only configuration that runs rather than a
tidy-up for later. The "dev keys" badge belongs to the CONNECTION rather than to any application,
which is why correcting an application's client id does not move it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The commit before this one added the three pages and the test that checks them, and landed none of
the three files it modified. A `git stash pop` used to prove an unrelated failure was pre-existing
restores the working tree without restoring the index, so the modifications came back unstaged, and
a commit without -a took only what was staged. The count of changed paths looked right and was not
checked against what the commit actually contained. The result was the worst half to ship on its
own: the pages existed, nothing linked them, and test_site_terms.js was on main asserting the links
it had just been separated from.

So this completes it. The unclosed <div role="img"> in the lightbox block is closed — until now
everything after it, the WHOLE FOOTER, was parsed as a child of a block inside
<sc-if value="{{ lbOpen }}"> and drawn only while somebody had an image enlarged, which is to say
never. The footer carries Privacy, Terms of Service and Licence, each pointing at the document that
holds that name. licensing.html gains D-12, the decision that records an acceptance as
{version, acceptedAt} rather than a boolean, because eula.html links to it by name and a reader
following that link would otherwise find a document without it. And Web/Website/privacy.html stops
saying the game "collects nothing and reports nothing to us" — true when written, false from the
moment accounts were added, since signing in reaches our identity provider.

Tests/test_site_terms.js passes from this commit rather than from the last one. It was already
written to catch precisely this: its assertions about the footer are there because a page can carry
every link in its source and still render none of them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The landing page had no privacy notice and no terms, and the footer that would have linked them was
being drawn for nobody. One <div role="img"> in the lightbox block shipped without a closing tag, so
everything after it — logo, Progress Report link, copyright line — was parsed as a child of that
block, which sits inside <sc-if value="{{ lbOpen }}"> and is therefore rendered only while somebody
has an image enlarged. The page looked finished because the section above the footer ends on a call
to action, and a source-level reading cannot tell the difference. Tag balance is now asserted, along
with the footer sitting outside every conditional, because the shape of the bug outlived the typo
that caused it.

Three documents rather than two, each linked under the name it actually carries. The distinction is
not presentational: a SERVICE's terms are about what the people running it may and may not do —
accounts, acceptable use, availability, termination — and that is something those people can state.
A software licence's warranty, liability and termination clauses are not, so eula.html names six of
them as missing and keeps a -draft id that the acceptance flow is specified to refuse. Labelling
that page "Terms" was the shortcut that mattered: an identity provider asking for a terms-of-service
URL is asking for one that is in force, and a reviewer following the link read "nothing here asks
you to accept anything". terms.html is in force, carries an as-is disclaimer, and preserves both the
liability that cannot lawfully be excluded and a consumer's statutory rights — a blanket disclaimer
that ignores either is unenforceable exactly where it would be tested. One box on it names the
liability wording as the section written by the people who built the software rather than by a
solicitor, on the same reasoning as the EULA's own list: a document with invisible gaps is worse
than one with visible ones.

Each page records its version twice, in a meta tag and in a line a reader can see, and the two are
asserted against each other. licensing.html D-12 requires an acceptance to be {version, acceptedAt}
rather than a boolean, because a boolean means revised terms can never re-prompt and nobody finds
out until the day the terms change. The machine-readable half is the one nobody looks at, so it is
the one that goes stale. D-12 comes along with these pages because eula.html links to it by name.

Web/Website/privacy.html said the game "collects nothing and reports nothing to us". That was true
when written and stopped being true when accounts were added, since signing in reaches our identity
provider. A privacy notice is the one document that must not be allowed to keep a sentence like
that, so it is corrected and the retired wording is pinned as a test that fails if it returns.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The footer offered Privacy and Terms, and Terms pointed at eula.html. That page says on its face
"Draft — not in force" and "nothing here asks you to accept anything", which is exactly right for
what it is and exactly wrong for what it was labelled. The label mattered the moment Google's OAuth
consent screen asked for a terms-of-service URL by name: a verification reviewer follows the link
and reads a disclaimer that no agreement exists.

Making the EULA in force to satisfy that form would have been the wrong repair, and the reason is
the difference between the two documents rather than their readiness. A SERVICE's terms are about
what the people running it may and may not do — accounts, acceptable use, availability, termination
— and that is something those people can state. A software licence's warranty, liability and
termination clauses are not; eula.html names six of them as missing and keeps the -draft suffix
that stops Web/LoginApi from ever recording an acceptance of it. So there are three documents now,
each in the footer under the name it actually carries: Privacy, Terms of Service, Licence.

terms.html is in force and says so. It carries an as-is disclaimer, and preserves the liability
that cannot lawfully be excluded and a consumer's statutory rights, because a blanket disclaimer
that ignores both is unenforceable in the place it is most likely to be tested. One box names the
liability wording as the section written by the people who built the software rather than by a
solicitor — the same honesty the EULA's own list of gaps applies, on the reasoning that a document
with invisible gaps is worse than one with visible ones. It is not a draft: the suffix would make
the page uncollectable as well as unusable to an identity provider, and the test says so in those
words so nobody adds one later out of caution.

Two assertions were added and both were confirmed against a sabotaged tree rather than assumed: a
-draft id on the terms of service fails, and a link labelled a bare "Terms" fails. The second is
the one a link checker cannot catch, because the href resolved, the page existed, and the label
belonged to a different document.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Designs/native-app-login.html §14 settled where a EULA acceptance belongs — in the login pipeline,
where the privileged work happens inside Auth0 and nothing privileged is distributed — and left one
thing that could not be static. Auth0 treats a redirect answer as evidence only when it arrives as a
JWT signed with the same secret the Action holds, and a secret in page JavaScript is a published
secret. So there is exactly one thing in that flow a browser must not be trusted with, and
Web/LoginApi is it: verify the token coming in, sign the one going back, store nothing.

Storing nothing is a property rather than an omission. The acceptance lives on the Auth0 profile,
written by the Action, so there is no schema here and no backup of ours — which is what lets
Web/LandingPage/privacy.html say we run no user database and mean it literally. The first INSERT
written in that directory makes the sentence false and nothing else in the repository would report
it, so the file says so at the top.

Writing it corrected the sequence it was written against. The last step read "302 →
https://TENANT/continue?state=…", and a 302 produces a GET; Auth0's own guidance is that the token
must be POSTed, because on a query string it lands in browser history, in the next request's Referer
and in every proxy log on the way. The relay therefore answers with a small auto-submitting form.
That also settled how the consent page talks to it: a plain HTML form rather than fetch, which
removes CORS entirely from the endpoint holding the secret and keeps the page working with
JavaScript off. The cost is that the service returns HTML, which is most of why the transport is
longer than the core it wraps.

One claim in §14 was also stronger than it can bear, and the README says so where an implementer
will meet it rather than leaving "signed" to imply it. The signature proves the answer came through
this service for THIS transaction — closing third-party forgery, and closing replay because `state`
rides inside the token rather than beside it. It does not prove anybody read the page: a signed-in
user can POST accepted=true directly. Closing that needs a nonce minted when the page is rendered,
and the page is static on purpose.

Nearly every assertion in the suite is a refusal, because a verifier that says yes wrongly has no
symptom: the login completes, the acceptance is recorded, and the record is worthless. So the
inbound token is refused for a wrong secret, an absent signature, an alg the header chose rather
than one we did, an expiry, a lookalike issuer and a missing subject; the answer must be a real
boolean, since "false" is truthy and a consent record that says yes because a form serialised a no
would be the worst defect here; and a version ending in -draft is refused as a constant rather than
a setting. That last one is the point of licensing.html D-12 — an operator who can switch it off
will, on the afternoon somebody wants a demonstration, and eula-0.1-draft names six clauses nobody
has written.

Two things found while wiring it in. Server/.gitignore has a .env line and per-directory ignores do
not reach siblings, so cp .env.example .env followed by git add -A would have committed the HMAC
secret; the rule is now written here and test_secret_hygiene.js checks that it exists rather than
trusting somebody wrote it, which is the shape the audio exceptions are checked in. And
Tools/spdx-headers.js swept four directories, none of them under Web/ — the relay is added to SCOPE
by name rather than by sweeping Web/, which would stamp a software licence on marketing pages.
LICENSE does not enumerate Web/ and does not have to, its list being explicitly "without limiting
the foregoing" over the software; naming it there would be clearer and is a decision for a person.

Designs/README.md said website-login had six open decisions where the document's own badge says
five. The document is the authority, so the index is corrected to match it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The tightening of isPlayerUser was one line and its description was five places, none of which
changed with it. An empty VAULT_PLAYER_EMAILS used to mean "any authenticated user may play", on
the reasoning that the tenant decides who may sign in at all — sound while each vault owner ran
their own tenant, and false the moment the vault began sharing one with the public website, where
the same line would have admitted every marketing-page signup to every default-configured vault.
The code now admits the admins and the owner and nobody else. The admin page's Players card went
on saying "Leave empty to let any authenticated user play", and an admin acting on it would have
emptied the list expecting to open their vault and shut it instead. The README, .env.example and
the loadConfig comment said the same thing, and the README additionally told an operator to
register a Regular Web Application and described a login served by express-openid-connect, neither
of which survived the move to PKCE — a Regular Web App is confidential, so Auth0 issues it the
secret this branch exists to get rid of.

The new test is over the text rather than the behaviour, which needs a word about why it is shaped
the way it is. "Any authenticated user may play" is a TRUE statement about VAULT_ANYONE_CAN_JOIN
and a false one about an empty list, and both appear in the same README table row a few words
apart, so a file-wide grep for the phrase cannot tell correct documentation from wrong and would
have to be silenced to pass — which is how a check like this gets deleted rather than fixed. It
therefore reads the claim per sentence and fails only where one sentence makes both halves at once,
after reading the truth out of isPlayerUser so that a deliberate return to the old default fails
loudly here instead of passing quietly. The sabotage cases earned their place: the first retired
sentence went through the detector untouched, because an <em> sitting inside "let any authenticated
user play" broke the pattern while the rendered page read exactly as before.

Designs/server-vault.html keeps its Auth0 section as written, with a note naming the two facts in it
that stopped being true, and §12 of the native-app-login document no longer says "that is exactly
right today" about a line §13 of the same document removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Section 14 had the comparison table and the prose but nothing an implementation could be checked
against, which is the half that matters for a design nobody is building this week. The sequence is now
explicit from the sign-in to the app receiving a session, in the same flow-block form sections 05 and
11 use.

Writing it out settled a shape the prose had left vague: the consent PAGE stays static on the CDN and
only the POST goes to a service. The page verifies nothing and needs to verify nothing -- the terms are
public, so there is no secret for it to hold and no reason to give it one -- and the verification that
matters happens on the way back, where a service that does hold the secret checks the inbound token and
signs the answer. That keeps all HTML on the CDN and puts a single endpoint behind a process.

The callout names the three steps whose absence has no symptom. The version comparison rather than a
stored boolean, because a boolean cannot re-prompt and the day that matters is the day the terms
change. canRedirect(), because the Login Flow also runs for SSO, silent authentication and
refresh-token exchange, and the website's SPA does silent auth on every page load -- an unguarded
redirect renders a consent form inside a hidden iframe and hangs the login. And state INSIDE the signed
token rather than merely beside it, which is what binds the answer to this login rather than to any
login.

It also states what the service is not. It stores nothing: the acceptance lives on the Auth0 profile,
so there is no database, schema or backup of ours anywhere in the design, which is what lets the new
privacy notice say we run no user database and mean it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The links were the ask. The footer they belong in turned out never to have reached a reader, which is
why this commit is larger than a line.

One div in the lightbox block had no closing tag. It is an empty element by design -- the enlarged
screenshot is drawn entirely by lbImgStyle as a background -- so the omission looked like nothing, and
the damage was nowhere near it: the overlay div above never closed either, so everything following was
parsed as a child of that block. The block sits inside <sc-if value="{{ lbOpen }}">, which means the
LOGO, the Progress Report link, the tagline and the copyright line rendered only while somebody had an
image enlarged. On a page nobody had clicked an image on, the footer did not exist. It looked complete
because the section above it ends in a call to action, and nothing about a missing footer announces
itself.

That is worth stating precisely because licensing.html D-11 excludes Web/LandingPage from the Game
Content notice on the ground that it "carries a copyright line already". The line was in the source
and reached nobody. It does now.

Found by rendering the page in a browser to check the new links, after the source-level assertions had
already passed -- which is the lesson the test now carries. A regex over the file cannot tell a link
that reaches a reader from one parsed into a hidden subtree, so test_site_terms.js checks the property
that actually broke: tag balance across all four templates in that directory, plus that the footer
sits outside every sc-if. Both would have caught this, and neither needs a browser.

The links themselves are hand-added to a GENERATED page, like the two sign-in script tags and
#auth-btn before them, so they carry the same warning in a comment and the same assertion in the
suite: an export from the design tool drops them, the footer still renders, still carries the right
year, and quietly stops offering the privacy notice a product with accounts is supposed to link.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Two pages that every route to terms acceptance needs, built now while the reasoning is fresh, with the
wiring left for after the vault login is tested. The DOCUMENTS are route-independent: a Redirect
Action displays them, Forms for Actions links them, an installer shows them, a footer points at them.
Only the interactive consent screen depends on which route D-12 lands on, and that is not here.

The find that mattered more than the new pages: Web/Website/privacy.html ended with "The Lost Realms
-- the game and the server software behind it -- collects nothing and reports nothing to us". That was
true when it was written and false the moment accounts were added, because signing in reaches our
identity provider. A published privacy notice is precisely the document that must not be allowed to
keep a sentence like that, and the game's own site had no notice at all to contradict it. Corrected in
place, and the correction says what it used to say and why that stopped being true, rather than
quietly editing the claim away.

The new notice separates three things that collect very different amounts, because the honest answer
for two of them is nothing and letting that stand for the third would be the same failure again. The
site is static files with no server behind it. Playing reports nothing -- saves, characters and
settings stay on the machine, and the model provider that answers a turn is the player's, not ours.
Signing in is the one thing that reaches us, and it holds an address and little else. It states
plainly that we run no user database of our own AND that this does not make it somebody else's
problem: the account lives with Auth0 on our behalf, which makes them the processor and us the
controller, and "our vendor holds it" is how the arrangement works rather than an exemption from it.
It also records the two local facts the desktop install now has -- that the sign-in reaches us even
from a machine nobody else can see, and that the first address to sign in is written to that install's
own settings as its administrator.

The EULA is a draft and says so in the largest box on the page. It collects the terms that already
exist and are settled -- the two-licence split, the four clauses LICENSE-CONTENT carries because this
is a game driven by a language model, the Virginia forum, the machine-generated-artwork disclosure --
and then names the six clauses a lawyer still has to write rather than inventing operative language
for them. Its version id ends in -draft deliberately, and the acceptance flow is specified to refuse a
draft id, so wiring this up early cannot quietly gather agreements to a document nobody qualified has
read.

Both pages are hand-written HTML rather than dc-runtime templates, unlike index.html beside them. The
design tool regenerates what it owns, and legal text a re-export can silently rewrite is worse than no
legal text. Tests/test_site_terms.js pins that, along with the two ways these pages rot: a version
that disagrees between the meta tag and the visible footer, which would leave every past acceptance
looking current after a substantive edit; and a draft whose id and text stop agreeing about whether it
is one. It also holds the retired sentence out of the company notice, because the way that sentence
came back would be somebody restoring a paragraph.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

D-12 in licensing.html and a new section 14 in native-app-login.html. Neither is built and the EULA
text does not exist yet; what is recorded is the mechanism question, which has an answer, and the
implementation of it that looks obvious and is dangerous.

The EULA and the privacy policy want different moments, and pairing them gets one wrong. Post-login
is right for the EULA: it licenses use, and an acceptance bound to an identity is worth more than a
click bound to a machine. It is wrong for the privacy policy, because the login IS the collection --
by the time somebody has signed in, their address is already a record in our tenant, and a policy
shown afterwards describes handling that has happened.

The dangerous implementation is worth writing down before somebody reaches for it. Recording
acceptance on the Auth0 profile means the Management API, which means a machine-to-machine client
secret, and the obvious host is the vault: it is running when a desktop user signs in and it already
holds the session. Timing is not the objection. The objection is that the secret would ship inside
the installer -- the one thing the PKCE work removed -- and it would be strictly worse than what was
removed, because a leaked login-client secret allows impersonating the application in a flow while an
M2M secret carrying update:users allows rewriting every user record in the tenant. Auth0's own guide
for this use case asks for six such scopes. Independently fatal: the vault exists on one of three
surfaces, so a vault-hosted answer leaves the website and the hosted game unserved.

So it goes in the login pipeline, and section 14 records both documented routes with the mechanics
anyone revisiting will want: identity out as a signed session_token carrying sub rather than the
address, since Auth0's own guidelines say the token is signed but not encrypted while its own table
offers an email claim; the answer back at /continue either as a plain form field or as a signed token
whose state claim closes replay; and api.user.setAppMetadata in onContinuePostLogin, with a refusal
as api.access.deny so a declining user does not end up signed in having agreed to nothing.

The part that reorders the two routes is that "no backend" survives only one of them. A signed answer
needs the consent page to hold the same HMAC secret the Action holds, and a secret in a static page is
a published secret -- so a static page can only post the unsigned field, which a signed-in user can
post without reading the page. That is a person skipping their own consent screen rather than forging
somebody else's, and may be good enough for a EULA, but it is a choice rather than a detail. Forms for
Actions is the genuinely backend-free route because Auth0 hosts the form; the Redirect Action earns
its keep only where the screen must look like our own site, and then costs the verify-and-sign service
website-login.html section 09 describes.

Two riders recorded because they are cheap now and expensive later: store {version, acceptedAt} and
never a boolean, or a revised EULA can never re-prompt; and guard the Action on canRedirect(), because
the Login Flow also runs for SSO, silent authentication and refresh-token exchange, and the website's
SPA does silent auth on every page load.

One thing this retires rather than adds. Trust on first use claims the owner on the first
authenticated request, which is middleware and runs before any dialog a client could draw -- so a user
who declined an in-app EULA would already be recorded as that vault's admin. Acceptance inside the
login pipeline dissolves that: a refusal means the login never completes, the vault never sees an
authenticated request, and nothing is claimed.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Two halves of one thing: making an installed copy work on a clean machine with nothing exported.
Either half alone ships something broken, which is why they arrive together.

The shell now carries the tenant. DEFAULT_AUTH0_ISSUER and DEFAULT_AUTH0_CLIENT_ID sit in
Electron/main.js and are handed to a vault it starts, guarded by the same if-not-already-set rule as
every other value, so exporting your own still points an install at your own tenant. Both are public
by design -- a Native application presents no client secret, which is the whole reason the vault
could be distributed at all -- and someone who unpacks the app and edits them is pointing their own
install at their own tenant, which is supported rather than prevented. They must be present together,
because auth0Configured() is all-or-nothing and a half-filled pair yields no gate rather than a weak
one, so the launch test fails on an empty either and a build cannot ship half a tenant. The bundled
issuer also joins the shell's in-app origin list, so a NAVIGATION on the login page is not judged
against an allow-list its own origin is missing from and pushed to the system browser mid-flow.

That fixes authentication and exposes the authorization half. A fresh install has no admin list and
no player list, and an empty player list stopped meaning "anyone" a few commits ago -- so every
packaged copy would sign its owner in perfectly and then answer 403. Nobody exports anything to press
Start, so that is the shipped product rather than an edge case.

So: trust on first use, because a desktop vault genuinely has one owner -- the person who installed
it. The first account to authenticate is claimed as owner and sole admin, written to the access file,
and announced in the log, because that is the moment a machine decided who administers it and the only
record its user will ever have. Four bounds, each load-bearing rather than defensive. An explicit flag
that only the desktop shell sets, since it is the one component that knows this vault belongs to
whoever is sitting at it -- without that line the first stranger to reach an exposed vault would own
it, which is the same hazard an empty player list used to have arriving through a new door. Nothing
already configured, so a claim can never overwrite an intention a human expressed, including one
restored from the access file on a later boot. A verified email, the bar the gates already apply,
because this hands over an entire install. And once, since the claim writes the list that makes the
next attempt decline.

test_first_user_owner.js tests every bound as a REFUSAL rather than as a success, because a claim that
fires when it should not gives away a whole vault and nothing downstream reports it. The middleware is
mounted above every gate rather than inside one: inside requirePlayer it would not cover /admin, and
inside requireAdmin it would not cover the game.

Electron's config tests needed updating rather than fixing. The bundled issuer is now always in the
allowed-origin list, so assertions that counted absolute entries now measure what configuration ADDS
to it, reading the bundled value out of main.js so a copy here cannot keep passing while the shipped
tenant changes.

PRIVACY.md moves with it, because the claim writes a person's address to a file on first run: it says
what is recorded, that it stays on the machine, and that a vault someone configured themselves is
never touched by it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Third and last of the values that decide whether a vault we launch has a sign-in at all, and the one
nobody would think to look for. auth0Configured() requires issuer, client id, session secret AND
public URL, and it is all-or-nothing: miss any one and the vault does not fall back to a weaker gate,
it decides Auth0 is unconfigured and serves the game to whoever can reach the port.

VAULT_PUBLIC_URL is `env.VAULT_PUBLIC_URL || ''` in vault-core -- no default anywhere -- and the shell
never set it. So an operator who exported AUTH0_ISSUER_BASE_URL and AUTH0_CLIENT_ID for a vault the
desktop app starts got no login whatsoever, with the only notice a line in a log a packaged app's user
never sees. That is the same failure the session secret had a few commits ago, in the one remaining
field, and the shell is the right place to answer it for the same reason: the URL is a fact it already
owns, being the origin it is about to point the window at. It sits beside the VAULT_HOST and
VAULT_PORT lines, which exist on exactly that argument.

Taken from CONFIG.origin rather than written as http://localhost:8787, which is what it resolves to
for a built app anyway. A literal would be correct today and wrong for anyone using --url= or
TLR_VAULT_URL to point the shell at a vault on another machine: Auth0 compares redirect_uri exactly,
so a callback origin naming this machine when the vault is elsewhere is a Callback URL mismatch the
operator never typed. Guarded like every other value here, so an environment that already names one
keeps it, which is what leaves self-hosting against a different tenant possible.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Two things the configuration table did not say, both found by setting the vault's application up for
real rather than by reading anything.

Auth0 enables implicit, authorization_code and refresh_token on every PUBLIC application it creates,
so Implicit is a default nobody chose rather than a box somebody ticked. The table listed the two
grants we want and said nothing about the third, which leaves a reader wondering whether it belongs
there. Nothing in this codebase uses it -- identity.js registers response_types ['code'] and the
callback accepts nothing else -- so unticking it changes no behaviour at all.

It is still worth the click, and the reason is where this application's callback is. Implicit returns
tokens in the URL FRAGMENT of the redirect, and this redirect lands on
http://localhost:8787/admin/callback: plain HTTP, on loopback, which section 05 is explicit that
another process on the machine may be able to observe. The whole argument there is that an
intercepted code is worthless without the code_verifier. An implicit response carries a usable token
over that same hop with nothing binding it to the process that asked -- the one hazard PKCE exists to
close, reachable through a grant we never call. The callout says so without dramatising it: this is
not a live hole, because nothing here ever sends response_type=token and a stranger who lifted the
public client_id would have to redirect to a vault on their own machine, which is the ordinary
public-client trade of section 10. It is a capability with no caller, and Auth0's position is that
the PKCE flow replaces implicit outright for new development.

The second correction is to something this document asserted a commit ago. It said the
non-verifiable-callback confirmation prompt is turned off per application, taking precedence over the
tenant, and that this was the right granularity because only the Native application has a
non-verifiable callback. Auth0 documents exactly that. What actually happens is that the Dashboard
directs the change to Tenant Settings, and that is where it had to be made -- so the row now says so,
and the callout states the consequence the per-application version did not have: a tenant-level
opt-out reaches every application in the tenant, including ones registered later. The website's SPA
is still unaffected, because the setting only bites a callback that is non-verifiable and an https
origin is not. But a future application with a custom URI scheme or another loopback callback would
inherit this silently instead of deciding for itself, which is the moment to go looking for whether
the per-application override has become available.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Both surfaced from setting the vault's application up for real, which is the only way either would
have been found -- the docs were internally consistent and confidently wrong.

The first is harmless once you know. Both configuration tables told a reader to set Token Endpoint
Authentication Method to None, and there is no such field: registering a Native or Single Page
application MAKES it a public client, Auth0 flags token_endpoint_auth_method none on creation, and in
Auth0's own words "the Auth0 Dashboard does not include authentication method or credentials settings
for these application types". So hunting for the setting and not finding it is the setting being
correct, and the tables now say that rather than sending the next person looking. GET
/api/v2/clients/{id} shows the value for anyone who wants to see it.

The second was worse, because following it would have done something. The website table listed
Allowed Origins (CORS) with the reasoning "the page calls /oauth/token from JavaScript" -- which
sounds right, and is not how Auth0 arranges it: its own SPA quickstart configures three URL lists and
never mentions that field. The Dashboard reveals it only after switching on Allow Cross-Origin
Authentication, so the row was quietly instructing someone to enable a feature this design avoids on
purpose. Auth0's guidance is blunt in the other direction: if you do not need CORS, leave the toggle
off.

Hence a new callout disentangling three settings that sit near each other, all say origin, and are
routinely confused. Allowed Web Origins is ours and load-bearing on the website -- it is what
web_message needs, and its absence is what signs people out on reload. Allowed Origins (CORS) stays
empty. Allow Cross-Origin Authentication means EMBEDDED LOGIN -- a password typed into our own page
and posted to Auth0 -- which nothing here does, and which the name actively misleads about: it sounds
like permission for a login to cross between our origins. Both applications send the user to Auth0's
own Universal Login and take back a code, which is the whole security argument of the website doc's
section 05 and the reason a frameless desktop window was acceptable at all.

The callout also answers the question the toggle gets enabled for. Signing in on the website cannot
log anyone into a vault, with it or without it: a vault's session is a cookie it sets from its own
callback, and what a shared tenant buys is one account plus, inside a single browser, an /authorize
that can be answered without a password. Turning this on to chase that adds an attack surface and
changes nothing.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Found while answering a question about the tenant layout rather than by anything failing, which is
the only way it would have been found: Auth0 classes http://localhost callbacks -- together with
custom URI schemes -- as NON-VERIFIABLE callback URIs, a redirect target nothing can prove belongs
to the application claiming it. That one entry is what this whole document is built on, and it is no
longer free.

Auth0 now shows the end user an explicit login confirmation prompt before completing such a
redirect. Tenants created before 15 Oct 2025 kept the old behaviour until 28 Apr 2026; after that the
prompt is the default and the toggle that suppressed it is gone. Both consequences are written up in
section 06, because only one of them is visible. The first is an extra screen in every vault sign-in
that nobody in this repository added, which is exactly how it gets reported as a bug in the login.
The second is that prompt=none is rejected outright for an application configured to show it -- which
does not bite today, since the vault does a full redirect login and then holds its own session
cookie, but which removes silent re-auth as a future option for that application, and silent re-auth
is precisely what anyone would reach for to make the desktop sign-in quieter. Section 11's SSO
paragraph claimed that silent half without qualification, so it is qualified there too.

The opt-out is per application and takes precedence over the tenant setting, which is the right
granularity here: the website's SPA has an https callback, is therefore verifiable, and is unaffected
either way. Only the Native application needs the toggle. Auth0's own advice -- move native apps to
https callbacks via Android App Links and Apple Universal Links -- is not available to us, because
the redirect target is a server on the user's own machine rather than an app the OS can associate
with a verified domain, so the answer is to turn the prompt off deliberately and record why.

Two stale things in the same table, found while editing it. The Allowed Logout URLs row said
http://localhost:8787/ with a trailing slash and explained itself in terms of auth0Logout, an
express-openid-connect option that no longer exists; what ships strips trailing slashes and sends the
public URL verbatim, and Auth0 matches logout URLs the way it matches callbacks, so the row as
written fails at sign-out. Server/.env.example carried the identical error and was already fixed, so
the doc was the last copy of it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The comment was accurate when it was written and stopped being so three commits later in the same
branch. It said there were two Auth0 tenants -- the website's and the vault's -- and the federation
work settled the opposite: one tenant across the site, the hosted game and a local vault, because a
single shared record is what makes one sign-in carry between them.

The assertion under it is unaffected and worth keeping, because what is still separate is the pair of
APPLICATIONS inside that tenant, and not as a preference: a Single Page Application and a Native
application are different types with different callback URLs, and the vault's is the loopback one
every install shares. If anything the rule is sharper now than when the comment claimed two issuers.
Cross-wire the two client ids today and the token is signed by the SAME issuer, so it verifies at
every step and nothing downstream reports the mix-up.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

# Conflicts:
#	Server/package-lock.json
#	Server/package.json

# Conflicts:
#	Handbook/dungeon-masters-guide.html

Reported as a missing feature, and it was worse than missing: the action was already in the editor's
Tools dropdown and REFUSED in the one window it had been put there for. remoteEmbeddedMedia asks for a
loaded save, and a world draft is edited with no game loaded — so a DM authoring a world, pressing the
one item in a menu named Tools, was told to "open the save you want to shrink". Reachable and
inapplicable reads as a broken feature rather than an absent one, which is exactly how it was found.

The button is scoped to the document the window is editing, and what that is differs by mode. A save
editor holds a whole save and keeps moving all of it, which is what the menu item already did. A draft
or vault editor holds a world and nothing else: no player and no story log to walk, no clock to freeze,
and the write goes through the editor's own Save rather than the game's.

That last one is the difference that costs data rather than patience. saveGameState writes NOTHING in a
detached editor by design — _flushGameSave says so — so the default persist would have moved every
picture onto the vault and left the world in memory pointing at data URIs that are no longer in it, a
rewrite lost on the next load with the bytes already gone from the save. It writes through
saveEditorDocument, so a draft is written to its draft and a vault world republished. pauseWorld is off
for the same class of reason: reanchorClock on a world nobody is playing is a no-op, but setupEncounters
in the finally is not — it would START timers this window never had, in a window whose whole purpose is
that the world is held still while it is edited.

The engine took a scope rather than a copy. collectEmbeddedMedia and scanResidualEmbeddedMedia now walk
what they are given, defaulting to the whole save, and remoteEmbeddedMedia takes options whose every
default is what it did before it had any. The rewrite loop, the residue scan and the four refusals are
the part of this with history in it — the audio that was moved for months while every word said
"images", the field nobody listed — and a second copy of that is a second place for the next such
finding to be fixed in only one of. One test assertion moved with it: it pinned the residue scan's call
site as literal text, which the scope broke while the property it cares about was untouched.

It is a button and not a third menu item because of what it is. A DM finishing a world publishes it, and
art still inline is the one thing that makes a published world too big to serve — so it sits between
Publish and Save, at the cost of one click rather than two. Drawn only when this session is playing
against a vault whose media store is on, which is its own question and not Publish's: publishing needs
the admin gate, moving art needs somewhere to put it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

The Missing tab kept every card a batch had just painted, listed exactly as it had been before, until a
green Confirm button was pressed. Reported from play: a mis-click on Confirm while the run was still
going turned it back into Generate with the finished cards still on the tab — and from there nothing on
screen distinguished a tab of completed work from a tab of outstanding work. The next Generate would
have re-written the prompt and re-painted the picture for every portrait that already existed, at full
price, which is the part that makes this worth more than a tidier button.

The fix is to delete the second piece of state rather than to protect it. A card is listed while it is
MISSING art and stops being listed the moment it has some, which is also what the tab's name has always
claimed. artGeneratedKeys, artConfirmPending and artConfirmGenerated are gone, and with them the
kept-for-review clause on all fifteen groups and the review banner above them. The button has two modes
again, Generate and Stop. Because the drop-off happens on the per-card re-render the batch already did,
the list now SHRINKS as the run works through it — a DM can tell how far a batch of forty has got by
looking at what is left, and can walk away and come back to a tab that says what remains rather than
what was asked for. A card whose generation failed stays listed, which is the same rule seen from the
other side: it is still missing art, so the next run picks it up.

Two things had to stop counting positions to make that safe, and both are the same bug in different
clothes. The batch marked the card it was working on by INDEXING the on-screen cards with its own loop
counter — correct only while the list cannot change under it, which is exactly what it now does, so
after the first success the spinner (and the scroll-to-top that follows it) would have landed on
whichever card slid up into that slot. It looks the card up by key now. The per-card open/collapsed
restore had the same shape: captured as an array by index and re-applied by index, so a card leaving
would have handed every card below it its former neighbour's state, quietly collapsing the card a DM
had expanded to watch. It is captured as a map keyed by card, and re-applied by card.

While fixing the first of those, renderArt's hand-written ordered-key list went with it: it was a second
copy of currentArtCards(), group by group, that had to be remembered every time a kind was added to the
tab — and the failure when it was not is a spinner on the wrong card, which nobody would file. Both
callers read artOrderedCardKeys() now, which is that one list. Five tests that pinned their own group's
line in the copy now pin the absence of the copy instead.

The name filter is left as the DM set it. Confirm used to clear it, which made sense only as part of
dismissing a review that no longer happens.

Tests/test_art_generate_all.js gains the two questions the failure asked — is a card that has art still
listed, and does a second batch spend anything on it — plus the mid-run half a test of the finished
state cannot see: the list is observed from inside the loop's own re-render and must be one shorter
after the first card. Tests/test_art_pulse_persist.js runs the real batch over a three-card tab and
reads where the marker landed for the SECOND card after the first had left. Sabotaged four ways, each
caught by a distinct named assertion: the arted card kept on the tab, the marker taken by loop counter,
a failed card dropped anyway, and the kept-for-review state reintroduced. The first sabotage pass
missed the loop-counter one, because the fake cards outlive the re-render that rebuilds the real DOM
and a mark left by the previous card answered for the next; the recorder wipes them now.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The DM's Guide's "What it is costing you" appendix gained a row for the per-call-site table and a
section explaining it, because it is the only view in /usage that is about a LIMIT rather than a cost
and it reads differently for that reason. A call that runs out of room is billed in full and returns
less than it meant to, which is the most expensive thing that can happen per unit of work: you pay for
every token and get an answer cut off in the middle.

The section names the real incident rather than describing the mechanism in the abstract — a nine-room
region's map prompt coming back mid-sentence while the button reported that the Game Master had
returned nothing — because the general shape of it is permanent even though that budget has been
raised. The app ships one number per call and the world decides how much writing that number has to
cover.

The part worth getting right is the honest one, and it took some thinking to write: a DM cannot edit
these numbers, so a readout that only said "this is at 92%" would be a worry with no action attached.
There are two actions and the guide says both. The DM controls the INPUT — the calls that run long are
the ones whose prompt is assembled from their world, and a region map prompt has to name every room
filed under the region, so splitting an overgrown region is a real fix rather than a workaround. And
reporting it is the other, with the table as the evidence.

Two things stated carefully rather than loosely. The p95 is described as "as big as or bigger than 95
in every 100", not "bigger than 95 of every 100", because nearest rank is an inequality; and the guide
tells the reader to read it against the calls column, since with four calls it is simply the largest of
them — the honest answer to a question asked of four data points and not a stable figure.

The Field Guide gets a note rather than a section. A player opening /usage sees the same dialog, so a
gold warning box naming an internal call site would otherwise be unexplained: it says what the line
means, that nothing there is theirs to change, that it is not a fault in their game, and where the
DM's Guide covers what can be done.

One defect of my own, caught by counting tags rather than by reading: the new table row shipped without
its closing cell. The div and paragraph counts in that file have been unbalanced since before this
change and are left alone.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Regenerated with Tools/gen-progress-report.js after unshallowing the checkout,
which had been sitting 163 commits behind origin/main. The report is a
point-in-time snapshot of git history, so a stale checkout produces a stale
report with no test able to catch it — nothing pins the report against live
git log, only against the content notice and generator wiring.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DH7eoFHCiYioWdEp3vhnGD

The owner has named the services behind the book illustrations: a combination of Nano Banana (Google
Gemini) and GPT Image 2 (OpenAI). That closes a gap two sessions recorded rather than filled — the
entries for the lang-book pages and for lang-fable.png both said which service was unknown and asked for
it instead of inventing an answer.

It is recorded as a combination across the set, not a division. The owner named two tools for the
illustrations as a group and did not say which picture came from which, so no entry assigns a particular
frame to a particular model and none should until somebody can.

The answer is applied to exactly what it was given about, which matters more here than it looks.
lang-fable.png is a book illustration and is covered. sheet-inventory.png is not: its generated content is
a dozen item paintings on inventory cards plus a portrait, a different art pipeline from a book's plate,
and neither what the owner was asked nor what they answered. The nearest precedent is the heraldry entry,
reported as AI-generated and found on inspection to be screenshots — an owner's statement applied past
what it actually said is exactly how that went wrong. So the item art stays unattributed until somebody
says.

What this widens is the tool-terms question, and D-5 now carries the correction rather than the old
sentence. That entry said the AI images were made with tools whose terms the owner had already stated,
which was true of the art that had been asked about and quietly false of the rest — within four days of
being written. With Suno for the audio there are three third-party generators behind the Game Content,
the question is identical for each, and nobody in this repository has read any of the three sets of
terms: whether what the output was made under lets the licensor grant it onward. That is a contract
question with a counterparty, not the unsettled-statute question D-10 records.

One consequence is flagged where it will be acted on: Q4.4 of the counsel brief is framed around a single
provider and asks about a fraction of the exposure it was written for until it is widened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaW12mLYASZw8sTbCyh5HJ

Runs 496 and 499 to 502 all failed the same way and for the owner's own pushes: landing-page images
arrived without ledger entries, `build-asset-inventory.js --check` reported them, and
Tests/test_asset_provenance.js failed with it inside the app suite. That is the check working. What was
wrong is everything around it.

The assets are declared. sheet-inventory.png and lang-fable.png were opened and are both the MIXED case
the heraldry and lang-book entries established, not plain screenshots: a dozen generated item paintings
fill most of the inventory sheet, and an engraving fills half the fable's reader, so neither may inherit
the sentence saying a capture of one's own software is authored work. The inventory sheet is also from a
different world from the rest of the landing-page set — The Salt Cantos of Verengrad — which is the kind
of detail that makes a determination checkable later. Which service painted those illustrations is left
open rather than invented, as it is for the lang-book pages.

settings-cog.svg is the owner's own AI-generated icon, on their statement, asked for because looking
could not settle it: a 24x24 gear in dense bezier path data has the shape of a glyph lifted from an icon
set, and if it had been one it would be Third-Party Content under LICENSE-CONTENT §1 and belonged in
THIRD-PARTY-NOTICES.md rather than here. Its C2PA manifest corroborates neither half and the entry says
so — com.anthropic.claude.provided with origin-confidence "unknown" is a handling credential, not an
origin claim.

That file is also why --check now fails on UNREVIEWED as well as UNKNOWN. The two mean the same thing
about what is known — no marker and no ledger line — and differ only in what the tool could have hoped
to read. The cog sat undeclared in a passing tree for eleven days because .svg is not in RASTER, so the
whole difference between reported and silent was an extension a regex happens not to list. A declared
file leaves both states, so this costs nothing for anything anybody has answered for.

The last part is the one a reader of that CI log would have been misled by. One undeclared asset produced
THREE failures, and two of them named causes that were not the cause: "--check walked the whole tree
rather than passing on nothing" parsed only the passing message, so a legitimate failure read as a sweep
that had examined nothing; and "an unmarked file that git ignores is skipped" asserted the tool exited
zero, which is a fact about the rest of the tree rather than about the probe, so it announced that the
ignore rule had regressed when it had not. Both now measure their own property — the scope is read from
whichever sentence the run produced, and the ignore probe is compared against the baseline exit code
instead of against zero, so what it tests is that a gitignored file changes nothing. The tool prints its
scope on the failing path too, since "2 assets unaccounted for" without "out of 251" is unfalsifiable.
The same probe now yields one failure naming the real cause.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaW12mLYASZw8sTbCyh5HJ

A short leaf-over on each move: the incoming spread starts tipped away on the side it is arriving from
and settles flat. Hinged on the SPINE rather than on the element's own middle, which is where a
transform-origin left alone puts it and where a page swings from nowhere — forward hinges right, back
hinges left, because that is the side the leaf comes over from. The opacity finishes early, at 55%, while
the rotation runs to the end: arriving at full opacity for the last of the turn is what makes it read as
paper settling rather than as a slide fading in, since the words stay readable while the leaf is still
moving, exactly as they do on a real one. One transform and one opacity, both compositor properties, so
it does not relayout a dialog holding a cropped image and a scrolling column.

Three things decide whether it is telling the truth, and none of them is the animation.

The direction is read from the CLAMPED pair rather than from the argument. Previous on the first chapter,
Next on the last, and the pip you are already standing on all ask for a move that does not happen, and a
page that turns to show the same page is the animation saying something the book did not do.

The flag is set by the mover and consumed by the render, rather than passed as an argument, because
renderBookView is called from three places and only one of them is a turn: opening the dialog is a book
being opened, and a re-render after the reader learns a word is the same page seen better. Both would
otherwise have to pass an empty direction through a parameter they have no business knowing about, and
the one that forgot would flip a page nobody turned.

And the class is cleared on EVERY render, with the add inside the guard rather than the whole pair. The
first form cleared it in the same `if` that added it, so a refused move left the previous direction
sitting on the element — invisible while the animation had already finished, and a phantom turn the
moment anything restarts it. It is restarted the way every other one-shot animation here is (removed,
reflowed, re-added), because paging 1→2→3 lands the same class on the same element twice.

Reduced motion REMOVES it rather than shortening it, which is the opposite of what the flashes elsewhere
in this file do and is deliberate. A flash is a pointer: it says "here", and a reader who has asked for
less motion still needs telling where to look, so a near-instant one keeps its job. A page turn says
"what you were looking at has been replaced", which the replacement already says.

One thing fixed in passing: the body's scroll is returned to the top on every render. On a wide screen
the words column is a fresh node and starts there anyway, but on a narrow one the body is what scrolls
and is not replaced — so a reader who paged down and pressed Next landed half way into the next chapter.

Sixteen sabotages, which needed the test mock's classList made REAL: the usual no-op stub answers
`contains: false` to everything, and would have let every assertion about the turn pass against a build
that never adds one. Two of them are the two mistakes above, and a third caught the fixture rather than
the code — the remembered place is keyed by book NAME and outlives the item, so an earlier section had
left this book on chapter two and the first move was genuinely backwards. It has a book of its own now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Two sessions declared the same three Languages screenshots within minutes of each other, and the conflict
is resolved in favour of the other one because it is right where this branch was wrong.

Both looked at the files and both called them captures. This branch then filed all three as plain
screenshots under the sentence the screenshot groups carry — that a capture of one's own software is
authored work, so the copyrightability doubt does not reach it. That sentence is true of lang-alphabet.png
and false of the two book pages, where the largest single element in the frame is a generated painting
filling half a book viewer. Session 01QUtzKjY3UJXiG6ZMpDfPp5 filed those two as the MIXED case instead,
matching the heraldry entry, and recorded that D-10 reaches those pixels even though the capture, the book
and the tongue are the owner's. It also read the C2PA manifest these files carry and said what it is —
com.anthropic.claude.provided, a handling credential that corroborates neither half — and left open which
image provider painted the illustrations, which nobody has asked the owner.

So its three-file group is kept whole and this branch's is dropped rather than reconciled clause by
clause: merging two descriptions of the same evidence would have produced a third that neither session
stands behind. What carries forward from here is the one group the other session did not have, the
clear-weather village square, which needed no testimony about its origin — SynthID and a Google
generated-media assertion answer that — only a line saying whose it is.

The two generated artefacts are rebuilt from the merged ledger rather than hand-resolved. A conflict
inside a file a tool writes is not a conflict to edit; it is a signal to re-run the tool.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaW12mLYASZw8sTbCyh5HJ

Four files arrived in the landing-page push and none was spoken for. Three are screenshots and one is a
generated image, and the split was settled by opening them rather than by reading the filenames.

The three lang-* files are captures, unmistakably: 2560 wide with the whole application in frame — the
title bar, the tab strip, the character panel showing Venia Woodcloak at level 1, the weather and exits
panels, the command line. They are one sitting, which is the kind of detail that makes a determination
checkable later: the same character in South Gate on Forgeday, 24th of Harvestfall, Year 438, with the
clock reading 1:45, 1:51 and 2:11 am. One is the alphabet designer with the Tundari glyph sheet open; two
are a book read in the tongue it was written in.

Their doesNotClose carries an observation rather than a doubt, because it is the sort of thing somebody
rediscovers and mistakes for a finding. Each frame CONTAINS generated material — the book pages show AI
illustrations inside the reader, and the alphabet modal's own tooltip says Generate "asks OpenAI for
another". That is true of most screenshots of this game and does not change what a capture is. It is,
though, why the screenshot groups are kept apart from the AI-generated ones instead of merged: the
question a licensee asks about a capture of our own software is not the question they ask about a
generated picture.

VillageSquareClear.jpg needed no testimony about its origin — it carries C2PA provenance with a SynthID
note and a Google generated-media assertion, and the inventory had already classified it AI — Google
without help. What the declaration adds is the half a marker cannot carry, which is whose it is: the
fourth of the village-square set, beside the snow one declared on 7 September and the three skies on the
15th. Its doesNotClose records that the tool-terms question raised against the Suno track does not
obviously carry over here, since a SynthID marker implicates no plan tier — and that nobody has read the
image tools' terms into the record either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaW12mLYASZw8sTbCyh5HJ

The images the Languages & Lore Books section needs arrived in commit 8c67521 with no ledger entries, so
`Tools/build-asset-inventory.js --check` reported three assets nobody had looked at and
Tests/test_asset_provenance.js failed with it. They have been looked at now, and this records what they
show rather than what their filenames suggest.

All three are captures of The Lost Realms running, identified by the app's own chrome in frame — the
header and clock, the tab strip, the Editor's tabs, the character sidebar. They are not the same case as
each other, which is the whole reason the entry describes them separately. lang-alphabet.png is a plain
screenshot: the Culture › Languages tab with the "Draw an alphabet for Tundari" window over it, a sheet
of glyphs, one letter's path data and a three-line lexicon. The two book pages are MIXED, in the shape
the heraldry-* entry above them already set: the largest single element in each frame is a generated
illustration filling half a book viewer, with Tundari glyph text beside it. So the sentence the plain
screenshot groups carry — that a capture of one's own software is authored work and the doubt over
generated images does not reach it — is only half true for those two, and the entry says so in
doesNotClose rather than inheriting it.

The C2PA manifest all three carry is named for what it is, because its presence reads like an answer and
is not: the action is com.anthropic.claude.provided with an origin-confidence field, which records the
file passing THROUGH Claude and corroborates neither half. That is why the inventory called them unmarked
— handling is not origin — and it is the same manifest the heraldry screenshots carry. VillageSquareClear.jpg,
which landed in the same commit, needed nothing here: it carries a real origin claim of its own
(digitalSourceType trainedAlgorithmicMedia, Google), which is why the check never asked about it.

One question is left open rather than answered convincingly: WHICH service painted the two book
illustrations. Nothing in the repository says, the file says only that Claude handled it, and this session
did not ask. The heraldry entry names Nano Banana on the owner's own statement; there is no equivalent
statement for these, so the entry asks for one instead of inventing it.

The generated report and its CSV are regenerated alongside — the CSV only when the tool is run with
--csv, which the test checks for, since it otherwise goes stale silently.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The section comes from a fresh export of the design tool: a heading and two paragraphs on generating a
tongue and setting down books written in it, a three-slide carousel (the alphabet window, a book opened
by a character who cannot read it, and its illustrated second page) with its own dots and arrows, and
three cards beneath — a real alphabet, books worth carrying, literacy is earned. Its state (lgSlides,
lgDots, lgTitle/lgDesc, the three opacity flags and the prev/next handlers) sits with the other
carousels' in the same script.

It was MERGED rather than copied over, and that is the whole of what this commit is careful about. The
export drops the two things the page's own comment says an export drops: the Auth0 SDK and auth.js
script tags in the real <head>, and the #auth-btn sign-in button in the corner row. Replacing the file
would have silently removed both — the page would still build, sign-in would simply stop existing, and
Tests/test_landing_login.js is the only thing that would have said so. So three blocks were lifted out
of the export by hand (markup, slide data, state keys) and spliced at their anchors; the diff is 66
insertions and no deletions, which is the shape a merge of a new section should have.

THE SECTION'S THREE IMAGES ARE NOT IN THE REPOSITORY YET — images/lang-alphabet.png,
images/lang-book-page1.png and images/lang-book-page2.png. Until they land the carousel renders three
broken frames. They also each need a line in Evaluations/asset-provenance-declared.json with an
authorshipBasis when they do, or Tools/build-asset-inventory.js --check fails and takes
Tests/test_asset_provenance.js with it.

One further change in the same export is deliberately NOT here: the time-of-day carousel gains a fourth
"Clear" state (renaming Day to Overcast, adding images/VillageSquareClear.jpg, a clearOpacity/clearBtnStyle
pair, showClear, and a rewritten phaseTitle/phaseDesc). It is a separate change to a different section,
it needs an image the repository also does not have, and it was not what this merge was asked for.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

It shipped at 760px wide wearing the STORY PANE's plate rule — flex: 0 0 148px — so it drew a tall narrow
column with a thumbnail at the top of it. That rule is right where it lives: a chapter printed into the
story sits in a column of narration, and a small facing plate is the correct weight beside it. It is the
wrong shape for the one surface in the app whose whole job is to look like a book, and sharing the rule is
how the wrong one arrived without anybody choosing it.

The plate is the left page now: half the width, the full height, and object-fit: cover so it fills the
leaf rather than sitting letterboxed in it. A painting shown whole in a box of the wrong aspect is a
picture with two bars of background beside it, and losing the edges is the trade a printed plate makes
too. The words are the right page, and they are the only thing in the dialog that scrolls — a scroll on
the body instead rides the plate off the top as the reader goes down the page, which is precisely what a
facing plate exists not to do.

Three things are load-bearing and none of them looks it. A DEFINITE height on the box rather than a max,
because two leaves can only match and a column can only scroll on its own if there is a height for them
to be. align-items: stretch on the row, without which the plate collapses to its own aspect and the crop
does nothing at all while every other rule still reads correctly. And min-height: 0 on the words: a flex
child defaults to min-height: auto, so without it the column refuses to shrink below its content, the
overflow never engages and the dialog grows instead — which is the bug being replaced, one level in.

Narrow screens get a different layout rather than a smaller copy. Stacked, a 50% leaf is a letterbox strip
above the words, so the plate becomes a band and the scroll moves back to the body: two stacked scrolling
regions in one dialog is a reader trapped in whichever one their finger landed on.

The assertions resolve the CASCADE rather than looking for a rule, because every selector here is also
declared by the story-pane rules this overrides — "is there a rule for .book-chapter-plate" is trivially
yes and says nothing, and which one wins is the whole question. That needed one thing the earlier version
of that helper lacked: @media blocks split out, brace-matched, since a flat later-wins pass folds them
into the answer and reports the narrow-screen layout as the layout. It is not hypothetical — the first run
read overflow-y: auto on the body and min(86vh, 720px) on the box, both true, both from the 620px block,
and both the opposite of the claim being made. A second test bug followed it: the narrow block was found
by its query, and this file has several at that width, so it picked the wrong one and reported the layout
as missing while it sat there. It is found by its contents now.

Thirteen sabotages, including each of the three invisible rules on its own.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Three things, and the bug first because it was making the count lie. Three NPCs in the reported world
were showing the picture of something in their inventory. An NPC's `inventory` is a list of whole item
records, each with its own `image`, and the sweep that finds a picture under an unlisted field name
walked straight into it and took the first one it found.

The fix is structural rather than another list of field names. NOTHING in this engine keeps a record's
own picture in an array: bannerImages is a map of slots, conversationImages is a map of moods. An array
on a record holds OTHER THINGS — the items it carries, the beings standing in it, the abilities it has
— and their pictures are theirs. So the sweep no longer descends into one. The named fields keep their
full recursive search, because there the field has already been identified as this record's picture and
how deep it is buried is not the reader's problem. Art coverage on the reported world goes from 110
records to 95, which is the correction: fifteen of those were somebody else's picture.

A record page now gives its subject a taller column and crops to the shape that subject wants. The
grid card is a thumbnail, one of forty on a shelf; the record page is the one place the picture IS the
subject rather than a label, and reusing the thumbnail there wastes it. Which shape is declared per
shelf in the template — a being, a device or a blade is taller than it is wide, which is why the engine
calls that field `portrait`, while a room or a region is a landscape and a wide painting cropped into a
column loses its ends. Nineteen shelves ask for the tall crop; the rest keep the banner.

And the crop is a crop, so clicking it opens the original. `object-fit: cover` keeps the middle and
loses the ends, which is right on the page and wrong the moment somebody wants to look at the art. The
lightbox is delegated from the document rather than bound per image — a record page has one picture
today and a gallery is the obvious next thing, and a handler per image on a three-hundred-card shelf
would be three hundred handlers for a page that cannot zoom at all. Escape and a click on the backdrop
both close it. A grid card is deliberately not a target: it is a label, and the page it links to is
where the picture lives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

A View button in a book's Actions row, opening the book the way the character would find it: the plate on
the left, the words on the right, in the book's own tongue and translated only as far as this reader has
got, one chapter at a time with a row of pips to move between them. It is the only player-facing thing
reachable from an item card.

It exists because the Chapters editor structurally cannot answer the question, and never could. That
editor shows the English, since the English is what is being typed — so the plainest question anybody has
about a book in a world's own alphabet, can they read any of this yet, meant putting a copy in the pack
and reading it in play. The View draws through bookPageHTML, which is the renderer the story pane uses,
so what appears is letter for letter what the character would see holding it open. Writing a second
renderer here is how the two would come to disagree about what the player can read, and they would
disagree silently, because both would look plausible.

It reads player state and never writes it. Nothing is learned, nothing spent, nothing consumed, and there
is deliberately no Translate control: that is one attempt per book per character level and it prints its
result into the story, which is an act of play on the page the player is reading rather than something a
preview should be able to burn from the editor.

The pip tooltips are the part with an argument in them. A title attribute is markup like any other and
View Source is the universal translator, so a contents page the reader cannot read must not name its
chapters there. But the rule is not blankness, it is AGREEMENT WITH THE PAGE: a pip names a chapter
exactly when the page beside it would show that title in English. That is decided by the same test the
page is rendered by — languageTextBeyondReader, split out of passageBeyondReader so there is one
definition of "beyond this reader" rather than two free to drift, keeping both halves, the shapes and the
romanisations, because state 2 is a word you can carry to somebody and not a word you know. Asked per
title, because blanking chapter one on account of chapter six would be the view lying in the safe
direction.

Two defects, both found by assertions rather than by looking at it. The title was resolved with
itemApparentName, which reads like the resolver and is its leaf: it answers with the apparent name
unconditionally and falls back to the literal words "an unfamiliar thing", so every plain chapbook in the
game was headed that. displayItemName is the one that walks the tier. And the dialog shipped without
position: relative or a padded title, so its × would have anchored to the viewport and a long book name
run underneath it — test_dialog_close_buttons.js derives that roster from the markup and caught both, as
it did for the folklore lightbox before it.

Seventeen sabotages, and one of them caught the test twice over. The pip section first asserted the row
named nothing at all, and failed on two titles whose words were not in the fixture's lexicon — words that
fall through as English on the page too, so the pip naming them was the code being right and the
assertion being wrong about the invariant. And the claim that the title goes through the resolver was a
grep for displayItemName(it), which passes against a dialog reading it.name directly, because that call
appears a dozen other places in the file. A gated, unidentified book is the only thing that separates the
two from the outside, and that is what it builds now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The attached export settled the last question, and not the way either of us expected: the Skeleton
King's portrait is present, on both its catalogue entry and its room placement, as
`compendiumImage: "/vault/media/f6/f64210c5….jpg"`. The reported field list was missing exactly
`portraitPrompt` and `compendiumImage` — so the file that run was reading was an older copy of the
world, published before the portraits were made. The current build finds all four monster portraits in
this export.

That is the third round of this, and every one ended the same way: the world being built was not the
world the Editor was showing. So the tool now reads the world out of a running vault —
`node Tools/build-encyclopedia.js http://localhost:8787 --audience dm` — over the two admin routes the
vault already has. An export is a photograph: right when it is taken, silently wrong a week later, and
nothing in the file says which. Read from the vault there is no gap for that to open in.

It settles the art as well, which is the other half. A world exported "linked" carries root-relative
references — `/vault/media/<shard>/<sha>.jpg` — which name no host, so the bytes are wherever that
world is served from and a file on its own cannot say where. Read from a vault we know; given
--media-base we are told. Either way the bytes are fetched and the site is standalone, which is the
shortest path there is from a linked export to a finished encyclopedia while the vault is up. Measured
on the attached world, served locally: 110 of 150 records carry a picture, against 41 from the file
alone.

The failures are as carefully worded as the success, because each has a different fix. An empty vault
says it has no published worlds rather than building an encyclopedia of nothing. A vault with several
lists their uids so the next command can be typed straight out of the error. And a 403 explains the
admin gate and that a vault treats loopback as an admin, rather than looking like a world with nothing
in it — which is exactly how somebody concludes their world is broken when it is their machine that
is wrong.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

"The monsters are not rendering their portraits" was not a picture-resolution bug at all. The Beings
shelves were reading the wrong population.

The Editor keeps a being twice. `entityCatalog` holds the TEMPLATE; every room that stands one holds a
full INSTANCE, with its own uid and its own copy of the portrait fields. And the Editor's NPCs,
Monsters and Fauna rosters are allWorldEntities() — which walks the rooms and collects the INSTANCES.
Only the Catalog tab shows templates. So a portrait written on a Monsters card lands on an instance,
and a shelf built from entityCatalog gets all the right names with none of the pictures. The field
dump asked for last round is what showed it: `name, type, race, classes, hp, description, lore, stats,
abilities, inventory, reputation, profile` — a template, untouched by the portrait work.

Reading the rooms instead would have been the other half of the same mistake. renderEntityCatalog's
own comment says a template no room references is "absent from both rosters" in the Editor, and that
an encyclopedia has no business inheriting: a being with a portrait and no placement is still a being,
as the report said in as many words. So a shelf source may now be a UNION, `a + b`, and the three
being rosters are `world.entityCatalog + world.rooms[].entities`, merged by name — one entry per
being, taking the picture from whichever copy has one, because which placement got the portrait is an
accident of room order. `+` rather than the `|` a picture binding uses, since they mean different
things and must not look alike: `|` is the first source that answers, `+` is all of them together.

Two bugs surfaced on the way. A tile's count was a re-count of the world rather than the shelf's own,
which was already wrong on a player build — a tile showed the full number over a shelf that had
dropped records nobody is allowed to see. It reads the shelf now. And `rooms[].entities` was written
the other way round at first, taking `rooms` off the world as though the world were the collection;
the [] marks the collection and the next segment is the field.

Finally, the strange character in the report: it was the log's own arrow. A Windows console runs code
page 437 or 850 unless somebody changes it, and a UTF-8 "→" arrives as "ΓåÆ" — read, understandably,
as corruption in the data rather than in the terminal. Every line the progress log prints is ASCII
now. The pages stay UTF-8; this is about the one surface whose encoding we do not control.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

The verdict was being reported without its reasoning, and that cost a round. A DM looking at a monster
whose portrait is plainly there in the Editor cannot tell from that line which of three things
happened: the tool read a field and rejected it, the tool read a different file from the one the
Editor is showing, or the field the Editor reads was never in the export at all. Three faults, one
identical line, and the page looks the same under all of them.

Each is now named, under the line it explains:

  Skeleton King → (no picture found)
      it carries none of the picture fields at all
      fields on this record: name, type, description
      no placement of it in any room carries one either
      and no encounter that names it carries one

The field list is the part that matters, because it is the only way to hold the record this tool read
against the record somebody is looking at in the Editor. A stale export and a bug in here are
indistinguishable without it, and they have been confused twice.

A rejection reads differently on purpose — "rejected bannerVideo: a field about a picture, not a
picture — https://…/v.mp4" — because that is the one case that is this file's fault rather than the
data's. And a record whose picture fields exist but are blank says so with the values, since "the
field is there and empty" and "the field was never written" are different stories about where a
portrait went.

The reasoning goes into the markup as data-tlr-art-why as well as into the log, and the log is made by
reading it back off the built page. The log scrolls past, a built site outlives the run that made it,
and the report is only worth anything if it describes the artefact rather than the intention.

Checked while writing this: the URL shape in the report — an absolute http://localhost:8787/vault/
media/…jpg — is accepted by the resolver under ANY field name, so a record carrying one is never
turned down. Which means a record reported empty genuinely had no such string in the file that was
read, and the field list now says what it had instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

A ✨ to the right of the title box, asking the Game Master for a heading. It runs the other way from the
two buttons already in the dialog: there the book is the material and the chapter is what gets written,
and here the PAGE is the input and the book is only framing.

It refuses an empty page rather than calling at all. A model asked to name a chapter nobody has written
invents a title, and the author then feels obliged to write towards it — the tail wagging the book. The
refusal says so in the dialog rather than greying the button out, because a control that is simply dead
does not tell you what would make it live.

The book's title and description are still sent, and the brief says in as many words that the title must
come from the page. A chapter heading has to sit in the register of the volume it is in — "Of the
Fen-Lights" and "What I Saw in the Marsh" are the same chapter of two different books — and a model shown
only the page picks the register of the prose, which is the narrator's rather than the book's. But
framing offered without that instruction is material: shown a book and asked for a heading, a model
describes the book, and the result fits every chapter of it equally badly. The other chapters are
deliberately not sent; bookChapterDirective needs them because it continues a story, and this one names
a page.

What comes back is stripped of wrapping quotes and a trailing full stop, straight and curly alike, and
cut to the cap the input's own maxlength enforces. A model adds both however plainly it is asked not to,
and a heading is neither a quotation nor a sentence — they survive into the contents page, where they
read as a rendering fault rather than as the model's punctuation.

Fifteen sabotages, and two of them were the sabotage at fault rather than the code — worth recording
because the second says something about the code that was not stated anywhere. A sabotage writing the
title straight through to the record SURVIVED, and it should have: bookChapterAt hands back a normalized
copy, so the write landed nowhere. Rewriting it to reach ITEM_CATALOG directly is what caught it, and
turned that copy from an accident of normalization into a stated property of the function — the dialog
holds a draft so Cancel can discard it, and a reader handing back the live record would let any future
line in that dialog write through by accident, invisibly, to the one field a DM closing the dialog is
least likely to look at twice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

"Every image for the monsters is the same and points to the banner image" — and the log was right,
which was the first thing to fix. It listed only the pictures a page HAS, so a monster page whose
frame was empty listed the masthead header and nothing else, and read as though the world map WERE
the monster's portrait. An empty frame is the answer to that question, so it is in the list now,
named: "Bog Wraith → (no picture on this record)". The masthead's own pictures are marked
[page header] so they cannot be mistaken for the page's subject, and an empty one is not reported at
all, since a world with no login crest would say so once per page.

Behind it, the real fault. A Beings card does not draw `compendiumImage`; it draws
Entity.portraitImage(), and that resolves three sources before it gives up: a location-matched
conversation close-up, then the compendium thumbnail, then the picture on the ENCOUNTER that spawns
the being — "a picture given to, say, the Villager encounter shows on the villagers it spawns", in
that method's own words. So a monster can have a portrait on its card and nothing whatever on its own
record. Reading one field of the three found a quarter of what the Editor shows.

All three are read now, in the Editor's order, because an encyclopedia showing a different picture
from the card the DM authored is wrong even when both pictures are of the right being. A fourth was
found while wiring it: a being exists twice in a world, once in entityCatalog as the type and once in
each room that holds one, and BOTH carry the portrait fields. The Beings shelves are built from the
catalogue, so a portrait that reached only the placement was a monster with a picture in the Editor
and a placeholder here. Room items are the same shape and get the same treatment.

The one step of portraitImage() deliberately NOT reproduced is compendiumImageByName(), which reads
the player's discovered compendium. This dump is of the world as the Editor holds it: that is play
state, it is not in a world export, and a picture whose provenance is one person's game has no
business in a reference to the world.

A record's picture is now resolved ONCE, in generate(), and carried on the record. It was resolved at
each frame that drew it — a tile thumb, a card in a grid, the record's own page — and a fallback that
only some of those consulted would have shown a monster's portrait on its page and a placeholder in
the grid beside it. The coverage count, --explain-art and the missed-picture report all read that one
answer too, or they would report placeholders over records the pages had drawn perfectly well.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

The item card's "Passage" section was a single textarea, so a book was a single page. It is "Chapters"
now: a list of chips, each a title, a page of text and optionally a plate with its own image prompt,
authored one at a time in a dialog the chip opens. The plate is on the left and the words on the right,
in the editor as well as on the page, because an editor laid out differently from its result makes the
DM compose against one arrangement and publish into another, and the picture is the half that moves.
The cap did not move either: BOOK_PASSAGE_MAX was always the budget for a page, and a chapter is a page.

Every chapter goes through the SAME renderer, and that is the part with a trap in it. The obvious build
gives chapters a plainer path — a heading and some paragraphs, the way any list of records draws — and
the first world with an alphabet loses it the moment a book gains a second page. So bookPageHTML was
split out of bookPassageHTML rather than duplicated, and the book renderer is a loop over it: one
description of what a page looks like, applied to one page or to six. The TITLES go through the
substitution too, which is the half that would have been forgotten — a heading left in English over a
body of shapes hands back the one thing the shapes are hiding, on the most prominent line of the block.
bookPassage joins titles and bodies for the same reason: the translate DC, the beyond-the-reader test
and the bilingual grant all measure the whole book, and six titled chapters must not translate at the
difficulty of their bodies alone. The plate is the deliberate exception and is outside all of it, since
a picture is not written and a reader who cannot follow the hand can still look at the engraving.

NOTHING MIGRATES A SAVE. bookChapters lends a book carrying a legacy `passage` one untitled chapter, so
it shows on the card and reads as a chapter everywhere above that line, while bookPassage falls through
to the old field and every reader below it is unchanged. Saving any chapter materializes the borrowed
one and deletes `passage` in the same write, because bookPassage prefers the chapters and a surviving
passage would be an authored page that nothing reads and nothing shows. A pass over every item of every
save would do the same job and can be half-applied; the half that failed is somebody's authored book.

The GM's ✨ is continuity or it is nothing. It sends the book's title and description, this chapter's
title, and every chapter BEFORE it in full — without which a model asked for chapter four writes a
fourth opening chapter, re-introducing the narrator and re-discovering what the book is about, because
nothing told it those had happened. The chapter being written is not shown its own current text, or the
model edits rather than writes and the button stops being able to replace a draft its author dislikes;
later chapters are withheld because continuity runs forwards. And the chapter is asked for in English
even for a foreign book, the substitution being a render-time thing — a model not told that invents
words, and invented words are in no lexicon, so the page renders as shapes that teach and translate
nothing.

Three defects older than the feature fell out of building it. The Translate control was suppressed by
RETURN ORDER — the worked-out branch returned before the control was built, so nothing said in words
that a cracked book offers no second attempt, and splitting the renderer moved that return one level
down and the control outlived it. applyItemTypeField could not retire a field at all: it assigns, so
the best it could leave behind was `passage: ''` on every chaptered book, an own field that serializes
and reads in a world file like a page somebody emptied; deleteItemTypeField is its other half. And its
array copy is one level deep, which is enough for a list of ids and not for a list of records — every
copy of a book would have shared one set of chapters, so painting a plate onto the copy on a table
would paint it onto the catalogue entry, which is the one that gets exported. applyItemTypeRecords is
the version for those, and the three-place walk all three share is eachItemCopyNamed.

Twenty-three sabotages, one of which caught the test rather than the code: the assertion that no English
reaches the DOM was anchored on ">stone<", and the head renders as the title followed by the tongue
chip, so a title escaped straight in came out as ">stone <span" and sailed past it. That is the third
time a check in this repository has matched the neighbourhood rather than the claim.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Chasing art that would not render has cost several rounds, and each asked the same question a
different way: what does THIS page think it is loading? The summary counts records, --explain-art
answers per record, and neither says what ended up in the markup. So the log now names every page as
it is built and, under it, one line per picture on that page — the name of the thing it is of, and
the path the page actually points at.

  rooms/village_square.html — The Village Square
      The Village Square → ../media/32/3220fc…c2fd.png
  monsters/wraith.html — Bog Wraith  (no pictures)
      UNRESOLVED Gullswater → /vault/media/ab/cccc…cccc.png

It is read back OFF the finished page rather than collected while building it, and that is the whole
point of doing it this way. What a log claims a page carries and what the page carries are two
different facts, and only the second is worth printing: a report assembled from the intentions
upstream would go on agreeing with itself if a later pass dropped or rewrote an img. So the path in
the log is the path in the file, relative prefix and all — reporting a site-relative path where the
page carries a page-relative one would send somebody looking for a file that is not where the log
said it was.

Three things fell out of making it accurate. Pictures are deduped by src within a page, because the
masthead header is on every page and a record shown in a grid and again in its own card would
otherwise be listed twice. A placeholder now carries data-tlr-art-for as well as data-tlr-art-src, so
an unresolved line can name the record and not only the missing file — the pairing the last two
rounds of this needed. And every page is emitted through one helper rather than pushed from the three
places that build them, so a page added later cannot be left out of the report by being pushed
somewhere else; the test asserts the reported count against the pages actually returned.

A page with no pictures says so on its own line rather than silently, so a run of them reads as a run
of them rather than as the log having stopped. It is a few lines per page — useful while art is not
rendering and noisy once it is, which is what --quiet is for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

The ledger recorded what every GM call produced and nothing about what it was allowed to produce, so
the question §14 of Prompt Economics could not answer — is this budget right? — had nothing to be
answered from. A p95 needs a ceiling to be a p95 of. The way that question got answered instead was a
DM reporting a button that did not work.

So the ceiling is recorded now, read off the REQUEST rather than declared anywhere. gmFetch tags the
parsed reply with the max_tokens it sent, gmTextFromResponse passes it to the recorder along with one
bit saying whether the reply was cut off, and the row carries both. A label to budget table beside the
call sites was the obvious alternative and is the thing this file has a rule against: a roster
hand-copied out of seventy-one literals goes stale on the first edit with nothing to say so. What is
stored is the number that was actually sent, which cannot drift from itself. The tag rides on the
parsed body rather than on the Response because a Response is passed around by callers reading .ok,
.status and .json(), and a hand-rolled forwarder would have to get all of those right seventy-one
times; non-enumerable, so it cannot reach a log, a save or a JSON round trip.

The readout is a per-call-site table — calls, p95 out, budget, used, cut off — sorted by pressure
rather than by name, because a reader opens it to find out whether anything is about to break. The p95
is nearest rank so the answer is always a size some reply actually was; an interpolated 612.4 tokens is
a number no call ever produced. A site with no ceiling recorded reads "not recorded" rather than a
dash, because a dash reads as zero and zero is a claim. A site that has actually lost a reply is
flagged whatever its p95 says, since the p95 of replies that were cut short understates what they
wanted to be.

The objection recorded against building this at all was that it would be a readout nobody looks at
until something breaks. That is answered rather than accepted: the table sits behind the toggle where
detail belongs, and one line above it appears only when a site is under pressure — naming it, and
saying plainly when a reply has been cut off that the call was billed in full and returned less than it
meant to.

Four of the sabotage pass's nineteen breaks were missed on the first run and three were real defects in
my own assertions. The absent-not-zero contract was asserted on the grouping, which reads the ceiling
through a truthiness test and so cannot tell 0 from null — it is asserted on the expansion now, where
the difference exists. "Most recent ceiling, not largest" was tested on a budget that was RAISED, which
reads the same under either rule, so Math.max passed it; it now tests one that was lowered, with
explicit timestamps, since "most recent" is a claim about order. And the "not recorded" check read the
whole dialog and passed against a table rendering a dash, because the explanatory note UNDER the table
contains those words — the assertion was reading the sentence that describes the behaviour instead of
the behaviour. The fourth was not a defect: a redundant clamp with another clamp behind it.

Two things caught by the suite rather than by me. test_usage_ledger pinned recordGmUsage's exact
argument list and broke on a fourth argument, a change that moved nothing it was about; it asks for
membership in gmTextFromResponse's body now. And the warning box reached for --gold-deep, which is the
Designs palette's token and not one this file defines — test_css_tokens_defined named it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The previous commit made TLR_NO_DM a preference and called it a setting, which was the right shape for
the wrong problem. The goal is commercial: a world sold without authoring tools must not hand them
back to the buyer. A URL parameter cannot do that, and the hole is one step wide — the vault runs on
the buyer's own machine, they know its address, and opening it in a browser without ?nodm=1 returns
the Editor. Reported by the owner, and correct.

SO THE GATE MOVES INTO THE FILE. Tools/strip-dm-editor.js removes #editor-view and the tab that
reaches it from a build's copy of text_adventure.html — 219,738 bytes, cut by walking tag depth
rather than by a regex, because the panel holds 1,322 elements and better than a thousand nested
divs and "up to the next </div>" is wrong at the first one. Electron/tools/after-pack.js runs it
during packaging, on the copy the app's own vault will serve, which is the first moment that copy
exists and the last before it is sealed into an installer. There is then no parameter to leave off.

THE PAGE NOTICES ITS OWN ABSENCE, which is the half that makes this hold together rather than being
two mechanisms that must agree. DM_DISABLED asks the document whether #editor-view is there BEFORE it
asks the query string — the game's whole body precedes its script, so the question can be answered
at parse time — and a stripped page therefore refuses the role at a bare address, with nothing on
the query at all. The ordering is load-bearing and is pinned as such: asked the other way round,
?nodm=0 would re-enable a role on a build with nothing behind it.

WHAT THIS IS NOT. The editor's JavaScript stays. It is threaded through a 110,000-line script and
named by inline onclick attributes, so carving it out is a different and much larger job, and the
owner's judgement was that the markup alone is a sufficient deterrent for now. What a stripped build
costs somebody is re-authoring 216 KB of markup that is nowhere in the file. That is a deterrent, not
a lock, and it is written down as such in the tool, the hook, the README row and the test, because it
is exactly the kind of claim that gets overstated by accident.

Verified in Chromium across the four cases rather than reasoned about: the original page at a bare
address offers DM; the original with ?nodm=1 does not; the STRIPPED page at a bare address does not,
carries no #editor-view and no tab, and paints its login screen with no console error; and the
stripped page with ?nodm=0 still does not. The packaging hook is driven in the test against a fake
packed tree for every spelling of on and off, including the case that must never pass quietly — asked
to strip, found nothing, which fails the build rather than shipping the tools it was sold without.

Two notes on the test. The strip tool REFUSES rather than writing a file it cannot vouch for, which
is right and which arrived here as a stack trace: two sabotages — a depth walk that stops at the
first closing tag, and a marker that is never placed — ended the file in a trace that says where it
stopped rather than what it could not do. The first call is caught and reported now. And the marker
itself was silently never inserted on the first run, because the insertion looked for the literal
'<div id="view-editor"' while the host writes its class first; nothing failed except --check
disagreeing with the strip it had just performed, which is the only reason it was found.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

A build of a real world is not quick and almost none of the wait is legible: a few hundred pictures are
fetched one at a time, and the tool said nothing at all between "go" and the summary. On a world whose
art is remote that is minutes of silent terminal, which is indistinguishable from a hang — and the one
thing anybody wants in that minute is to know it is still moving. Every pass now reports: the world
read, the shelves declared, the records found, each reference resolved, each shelf built, and the
write. Elapsed time on every line, because a clock answers "is it moving" better than a spinner does
in a log somebody is reading after the fact.

It is a CALLBACK rather than console.log() scattered through the passes, for two reasons. The vault
will call generate() to serve a page and must not print to a server's stdout. And how often to print,
and how wide, and whether to carry a clock, are presentation decisions that belong beside the other
presentation decisions in main() rather than beside the fetch loop. So the passes emit events and the
CLI decides what to say about them; `onProgress` absent is the silent case, which keeps every call
site a one-liner with no `if (verbose)` in it. --quiet resolves to one shared no-op rather than a
silent printer, so a quiet run does not pay to format lines it throws away.

The media pass is rate-limited to a line every 400ms, plus the first and the last. It fires once per
reference and there can be hundreds: unthrottled it scrolls the summary off the screen on a fast
build, and throttled without that guaranteed last tick it stops short of its own total.

One bug came out of testing it rather than watching it. The per-reference report was written after the
try/catch at the foot of the loop, and every branch of that loop body ends in `continue` — so it was
reached only by the single case that falls through, and a run where every reference resolved reported
nothing at all. Exactly the silence the pass exists to end, and invisible on a run with a failure in
it. It is in a `finally` now, and the test asserts one tick per reference rather than asserting the
printed words, which would fail on every rephrasing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Regenerated from git history via Tools/gen-progress-report.js; the checked-out
clone had gone shallow and was missing most of the log, so the previous
snapshot understated the project's actual activity by a wide margin.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YMYdSg6ijJuS2ThEkYYLRq

The second half of the federated-login work, and the surprise is how little of it is code: the vault
reads its issuer and client id from the environment, so which tenant it trusts is configuration. One
tenant with several applications -- a Single Page Application for the site and the hosted game, a
Native application for the vault -- gives one record rather than two joined ones, which is the whole
of what seamless means here. Tenant-to-tenant federation stays available as a configuration change,
because the vault genuinely cannot tell the difference between a shared issuer and a federated one.

What is not configuration is the consequence, and it is the reason this is a commit rather than a
paragraph in a README. isPlayerUser ended with `if (list.length === 0) return true` -- no allow-list
means any authenticated user may play -- and that was correct while "authenticated" meant "holds a
session this vault established" against the owner's own tenant. Point the vault at the tenant that
also signs people in on a public marketing page and the identical line means every visitor who ever
created an account there may play on every default-configured vault. Nothing in the code changed; a
default written for local authentication stopped being true when authentication became shared, and
nothing would have reported it.

So the implicit route to an open vault is gone and the explicit one stays. anyoneCanJoin already
existed, already means exactly this, and is already on Settings › Access; an empty player list now
admits the owner and the admin list. This WILL lock out players on an install that relied on the old
default, so the boot banner names the effective policy in all three states and tells an operator
which variable to set -- a silent change to who may play would be worse than the change.

The desktop shell mints one more per-install secret. AUTH0_SESSION_SECRET is part of whether the gate
is configured at all, so an install given the tenant's two public values and nothing else would not
get a weaker login: it would decide Auth0 was not configured, serve the game to anyone who could
reach it, and say so only in a line of its startup log. Nobody exports anything to press Start, so
that would have been the state of every installed copy. It sits beside the access token and master
key the shell already mints, and it is the most clearly right of the three -- it signs that install's
own cookie and is shared with nobody, which is exactly what the client secret was not.

Two of the design doc's own recommendations are reversed by contact with the running code, and both
are recorded as settled rather than quietly changed. The vault's login stays in an app window rather
than the system browser: RFC 8252 prefers the system browser and the argument applied to us strongly,
but the callback is served to whichever browser followed the redirect, so a system-browser login puts
the session cookie in Chrome and leaves the app window signed out -- and recovering it means
inventing a handoff, which section 04 is a long argument against. One password entry per install is
the price, paid once, because the window's cookie jar persists. And per-install secrets are generated
at first boot rather than demanded, which was the recommendation and is now built twice over.

PRIVACY.md moves with it, because what the play gate admits is a claim it makes: a login is no longer
by itself permission to play, the session cookie is one the vault signs itself with a secret that
never leaves the machine, no client secret is involved anywhere, and the tenant's users are a larger
population than any one vault's players -- which is the reason for the first sentence.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Phase 3 of Designs/native-app-login.html. The vault now runs Authorization Code + PKCE against a
public Auth0 client -- application type Native, Token Endpoint Authentication Method None -- and
sends no client secret at any point, including on refresh. express-openid-connect is gone, and
openid-client, which was already on disk as its own dependency, is declared and used directly.

The secret was never there for a policy reason. express-openid-connect refuses the public shape
outright, in its own schema, with the message "Public code flow clients are not supported." That one
line was the entire reason, and it mattered because the desktop app hands a bundled vault to other
people's machines, where anything in the bundle is public whether we like it or not.

auth0Configured() no longer requires AUTH0_CLIENT_SECRET, and that is the headline rather than a
detail: before this, a vault without one did not fall back to a weaker gate, it decided Auth0 was
not configured at all -- so the admin page went loopback-only and THE GAME WAS SERVED TO ANYONE.
Every distributed copy would have been in exactly that state. AUTH0_SESSION_SECRET is a different
thing and is still required; it signs this vault's own session cookie, is shared with nobody, and
can be generated per install.

The session is now ours rather than a library's: a signed, HttpOnly, SameSite=Lax cookie holding
sub, email, email_verified and name, with an absolute seven-day expiry stated in one place instead
of inherited from whatever a library shipped. email_verified is carried as the tri-state Auth0 sends
rather than flattened, because isAdminUser refuses an explicit false and tolerates a missing one, so
a boolean would have changed a gate. SameSite is Lax and not Strict deliberately: the return leg from
Auth0 is a cross-site top-level navigation, and under Strict the transaction cookie is withheld on
exactly the request that needs it, so every login would fail its state check.

Three things are written as refusals rather than as branches that fall through. A callback with no
transaction cookie gets a 400 and sets no session -- on a local install any process on the machine
can reach /admin/callback with a code of its own, and the state it cannot guess plus the verifier it
does not have are the whole defence. returnTo must be a same-origin absolute path, which rules out
the two cases that get missed: "//evil.example" starts with a slash but is another origin, and the
backslash variant is normalised to it by some browsers. And unsign() compares lengths before calling
timingSafeEqual, which throws rather than returning false on a mismatch -- unguarded, a junk cookie
would be a 500 on every request instead of a signed-out one.

Two tests, because the two halves fail differently. test_identity_seam.js forges cookies rather than
reading code, since a signature check that is not performed works perfectly for every honest user:
it edits a payload to another email and asserts the refusal. test_pkce_login.js boots a real vault
with AUTH0_CLIENT_SECRET absent from the environment entirely and reads the /authorize query string
the browser is actually sent -- S256, a real challenge, state, nonce, and no client_secret anywhere
in it -- because the claim being made is about a wire format rather than a return value.

Also corrected: Server/.env.example told operators to register <VAULT_PUBLIC_URL>/admin as the
Allowed Logout URL. The returnTo sent is the public URL verbatim, with no path, so that registration
fails as a mismatch at sign-OUT -- the end of the session nobody reports, because they are already
leaving. The config page now says the client secret is no longer used and safe to remove rather than
listing it without comment.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

Phase 2 of Designs/native-app-login.html, and nothing about the vault's behaviour changes: every
question the server asks about a caller's identity now goes through Server/identity.js, which for the
moment answers them exactly as before by wrapping express-openid-connect. Sixteen direct reads of
req.oidc and res.oidc across server.js and admin.js become three functions -- identity(req),
beginLogin(req, res, returnTo) and logoutUrl().

The point is what it makes possible next. The vault holds AUTH0_CLIENT_SECRET today for one reason,
and it is not a policy one: express-openid-connect refuses the public client outright, in its own
schema, with the message "Public code flow clients are not supported." A secret cannot be shipped
inside software handed to other people, so the flow has to become Authorization Code + PKCE against a
public client, and that means a different library. With the reads scattered across two files that
would have been a rewrite of the authentication path; behind this seam it is one file.

The authorization decisions deliberately do not move. adminGateDecision, playerGateDecision,
isAdminUser and isPlayerUser already take { authenticated, user } and know nothing about how it was
obtained, which is the property that makes this contained rather than sweeping, and every one of
their tests is untouched.

Two things identity(req) does that the scattered reads did not. It answers { authenticated: false,
user: null } when no gate is configured, which is what lets callers drop their own `auth0On &&`
guards rather than repeating the condition at every site. And it never returns a user alongside an
unauthenticated session: that half-state is a real hazard here rather than a tidiness point, because
isPlayerUser returns true for any user object when the allow-list is empty, so a leaked one is an
open gate rather than a wrong label.

Server/test/test_identity_seam.js keeps it true, because the regression it guards has no symptom of
its own -- a single req.oidc.user added back into a gate works perfectly while the old library is
still installed, and is found only on the day it is removed. It strips comments before looking, so
explaining the rule does not break it, and re-runs each rule against a deliberately broken copy so it
cannot pass by describing a tree that moved on. It also checks the game's sign-out footer against the
seam's own logout path, which is a second literal in vault-core.js and would otherwise be free to
drift into a 404.

The three route paths are unchanged and commented as load-bearing: /admin/login, /admin/logout and
/admin/callback are registered in the tenant, matched exactly, and refused before the session is
consulted -- so renaming one is a tenant change that presents as a broken login.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

TLR_NO_DM packages the desktop app for players rather than authors. The shell puts ?nodm=1 on the
address it opens, and the game hides the Dungeon Master checkbox on its login screen and refuses the
role however it is asked for.

THE SECOND HALF OF THE ASK NEEDED NO MECHANISM, which is the finding worth keeping and was not
obvious from outside: applyDMVisibility ALREADY tears #editor-view out of the DOM for a plain player
and rebuilds it for a DM. So a build that can never be a DM is a build whose Editor is never built,
and the only thing this flag has to do is make the role unreachable. Measured rather than assumed —
at the login screen the page carries 13,556 nodes and 1,231 listeners; after the teardown runs it
carries 9,096 and 667, and the subtree is replaced by a hidden placeholder rather than merely
display:none'd. Adding a second removal path beside that one would have been a second thing to keep
in step with no gain at all.

THE CHECKBOX IS THE LEAST OF IT, and a flag that covered only the visible route would have looked
finished while leaving two doors open. The role is decided in three places: New Game reads the box,
Continue reads it and overrides the save with it, and a SAVE carries its own isDM — and the boot
auto-resume passes no override at all, so a game made in DM mode revives as DM with no checkbox
involved anywhere. That third path is the one with no visible cause, and it is the reason this is not
a one-line change. The two login readers are now one function, loginWantsDM, because two separate
`.checked` lookups is precisely the arrangement where New Game honours a build setting and Continue
hands the same person DM mode one button along. The resume branch comes FIRST in its if/else for the
same reason, since the auto-resume supplies no override to fall through to.

It is a product setting and NOT a security boundary. That is said in the code, in the README row and
in the test, because it is the kind of claim that gets made by accident: the whole game is
client-side script and a devtools console can set player.isDM in any build. What this decides is what
the app offers.

Stripping the markup at build time was considered and is not here. It is 216 KB of an 8.7 MB file —
2.5%, where 86% of that file is the inline script the strip would not touch — it needs a tool and a
test of its own, and it would only apply to builds that ship their own vault, so a thin client
pointed at a remote vault would differ from its sibling in what it contains. The flag works for both.

Two notes on the tests. test_config's URL assertions were regexes over the VAULT_WINDOWS descriptors
and went red when both addresses started going through one vaultUrl() helper — a change that altered
nothing they were about. They RUN the helpers now and check the addresses produced, which is both
stronger and able to cover the build settings folded into them; the first attempt at that lifted a
slice from withParam to the NO_DM block and swallowed nine thousand characters of somebody else's
staged-worlds code, requires and all, so each helper is cut at its own closing brace.

And the resume-decision slice in the new test was written to match its two branches literally, so
deleting one or swapping them stopped the slice matching and fired the fixture check instead of the
assertion that names those bugs. It gathers the if/else-if statements around the dmOverride line now.
A slice has to survive the edits it exists to catch, which is the third time that has been written
down in this suite.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Integrates the Auth0 SPA login into Web/LandingPage/index.html as a single toggling control at the
right-hand end of the corner action row, beside the audio, progress, support and repository icons.
Signed out it is a door with an arrow going in; signed in it is the arrow coming out, the border
takes the brighter gold, and the tooltip carries the address that is signed in. This is phase 2 of
Designs/website-login.html -- sign in and nothing else -- which is the phase worth shipping alone,
because it is verifiable in a browser against no infrastructure at all.

There is no server and no secret. An Auth0 Single Page Application authenticates with Token Endpoint
Authentication Method: None, so the domain and client id in auth.js are public by design and PKCE
does the secret's job per request. The flow is the redirect one rather than the popup the design doc
prefers: a popup answers over web_message, which requires the tenant's Allowed Web Origins list to
name the origin, and until that is set loginWithPopup fails in a way that reads as a broken button.
Both paths are written; USE_POPUP flips between them and the popup path falls back to redirect when
a browser blocks it.

Nothing of the flow lives in index.html, because index.html is generated by a dc-runtime design tool
and anything in its script block is destroyed by the next export -- silently, leaving a page that
still renders and a button that does nothing. Two lines in the template reach auth.js, and
Tests/test_landing_login.js fails if either goes missing, asserts the button carries no onClick
binding of its own, and asserts auth.js holds nothing shaped like a credential. Each rule is re-run
against a deliberately broken copy so the test cannot pass by describing a page that moved on.

Three defects were found by driving the real page in Chromium rather than by reading it, and all
three would have shipped. The control went live before createAuth0Client resolved, so the earliest
clicks hit a null client and vanished -- the state now stays pending until there is something behind
the button. The handler was attached to the node found at load, which is the raw markup inside
<x-dc>; dc-runtime renders afterwards by reading that markup as a template string, so the bound node
is discarded and, worse, the "already bound" marker is captured into the snapshot, leaving a fresh
unbound button that reports itself wired and swallows every click. It is delegated on document now,
which React cannot replace. And the label was re-applied on requestAnimationFrame, which left a
measurable window where a signed-in visitor's button read Sign in; a MutationObserver callback runs
before paint, so the re-application is synchronous.

The design doc is corrected where building it proved it wrong: the scripts belong in the real <head>
rather than in <helmet>, which is template content React re-renders and where a <script> is not
reliably executed.

Two things a reader should know are deliberately not done here. The SDK is loaded from
cdn.auth0.com without Subresource Integrity, because this container's egress policy refuses that
host and a hash must be computed from the file rather than guessed. And the session is left at the
SDK default of in-memory caching, so a reload asks the tenant over a hidden iframe whose cookie is
third-party until an Auth0 custom domain exists -- section 07 of the design doc is the reasoning, and
CACHE_LOCATION is the lever for anyone who would rather trade it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The doc measured the input end to the character — 38,911 tokens, 91.9% cached, priced per call — and
had never looked at the other one. Seventy-one call sites each carry a hand-picked max_tokens and not
one of them had been measured against what the call actually produces. §14 is that end.

The finding is worth the section for its economics rather than its mechanics. A region map prompt came
back at 1,866 characters with stop_reason max_tokens, so the JSON was an unterminated string, the parse
threw, and the caller reported "the GM returned no prompt" — while the reply carried
usage.output_tokens 700, which both the client ledger and the vault price. The call was billed in full
and delivered nothing, which is the worst cell in this document's table: not an expensive call and not
a cheap one, a paid one with nothing on the other end.

The rule that came out is to size a budget by what the output SCALES WITH. The three map prompts must
name every room in a region, so their output grows with the world and 700 was under the typical case;
the other thirteen describe one record and are bounded by their subject, so 400–600 stays. And the
corollary reframes the tradeoff in both directions: a cap is not a reservation. The ledger prices
tokens PRODUCED, so headroom is free until used, a tight ceiling buys nothing except as a deliberate
spend cap, and a ceiling that costs the whole call is the most expensive possible outcome per unit of
work. Anthropic's own SDK guidance is not to lowball it — ~16,000 non-streaming, lower only for a hard
reason such as a deliberately short output, which is what these are. They stay low by a reason now
rather than by inheritance.

One claim was corrected while proofreading it, and it was mine. The draft said the failure was silent
because the Logs showed a JSON parse error. They were not: gmTextFromResponse reads stop_reason on
every one of the seventy-one calls and says outright that the reply was cut off and which budget to
raise. What was silent was everything the DM was looking at. That is the more useful sentence anyway —
the diagnosis existed and never reached the surface where the decision was being made.

Two header chips were counting wrong, which is the same defect as everything else this week. "2
decisions open" was stale against one; adding §14's makes it true for the first time, so the number is
unchanged and now means something. "5 enhancements proposed" was six, three of them built. The README
row said four parked and is now three of six.

§14's own open decision: the ledger already stores usage.output_tokens per call with the calling
function's name beside it, so "is this budget right?" is answerable from data already on disk — a p95
per label against that label's max_tokens would name every call flying close to its ceiling before one
of them hits it. Leaning yes, as a column rather than a mechanism, with the argument against being
that it is a readout nobody reads until something breaks — which is what was said about the cache hit
rate before a bill arrived.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Three things from a report, and the third is the one that should have come first.

A REGION's picture is its map. A region has no portrait — normalizeRegions gives it `mapImage` and a
`bannerImage` that is a scene inside it, and the map is what a region looks like. `mapImage` is named
in the picture roster now rather than being reached only by the accident of key order in the sweep,
and the declared binding still leads, so a region that has a scene as well still shows the scene the
template asked for.

THE PAGE HEADER is Map › Background. A binding may now name alternatives —
`world.mapBackground|world.mapImage` — because which of the two a world carries is a fact about that
world rather than about the design: the world committed to this repo has a mapBackground and an empty
mapImage, and hard-coding either field gives some worlds a header and others a hatched band. Stated in
the template, resolved here; the alternative was sweeping the whole world object for a picture, which
finds the login logo.

AND A PLACEHOLDER NOW SAYS WHAT IT CONCLUDED, which was asked for in as many words after two rounds of
"most of the images are placeholders". The page could not answer it and neither could anything else: a
record with no art and a record whose art this build could not fetch draw exactly the same frame, and
the two have completely different fixes. A frame now carries `data-tlr-art="none"` or
`data-tlr-art="unresolved"` with `data-tlr-art-src` and a title, so the path a placeholder wanted is
readable by hovering it. `--explain-art` gives the same answer for every record at once, including the
field list of a record where nothing was found, which is what turns the next report of this into one
round trip instead of three.

One real bug came out of writing that. An unresolved reference was still being emitted as an <img>,
which is a broken image on a site that is supposed to be standalone AND a page that contradicts the
run's own report — the summary has been saying such references "draw a placeholder" since the copying
landed, and they did not. They do now. `--assets keep` still emits the reference, because there the
caller has said they want their vault to serve it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Sixteen call sites ask the Game Master to write one prompt for one record, and all sixteen had the same
four lines written out by hand: parse, pick a key, refuse an empty result, report "the GM returned no
prompt" whatever went wrong. That is why the truncation bug existed at all, and why fixing it at the
Regions button fixed it nowhere else. Those four lines are one function now.

The budgets are LEFT ALONE, which is the finding rather than an omission. The three map prompts had to
name every room in a region, so their output grew with the world and 700 tokens was under the typical
case — one nine-room region overran it. Every other caller here describes a single record: an item, a
spell, a face, a room at one time of day. Their output is bounded by the subject, and 400–600 tokens is
several times what one art prompt takes. Raising them would buy nothing and would make the map floor
look like a house style rather than the measured thing it is. The reasoning is written where the next
person will be standing when they wonder.

Two call sites turned out not to be doing what the others did. suggestSkillPrompt and
suggestFolklorePrompt parsed with a bare JSON.parse(extractJsonObject(…)) rather than parseGmJson, so
they had neither the BUG-039 expression salvage nor the BUG-056 brace ranking — a model that opened
with a sentence containing a brace lost the whole reply. Both arrive with the shared reader.

The failure reason now tells a reply that PARSED and carried no prompt from one that did not parse:
the first is the model answering the wrong question, the second is the model writing prose around its
JSON, and they send you to different places. Only generateTestImagePrompt distinguished them before,
in a bespoke catch it no longer needs. That mattered more than it looks — the tooltip switches on the
error's WORDING, so a button wired to promptButtonFailureTitle while still throwing a hand-written
message would have kept offering the retry and looked fixed.

The test now walks all sixteen and asserts each reads through the shared reader and throws the reason
the reader worked out, plus that no button anywhere hard-codes the retry advice. That is the assertion
that stops a seventeenth copy arriving. The sabotage pass caught fifteen breaks and missed one: the
parsed-versus-unparsed distinction was added without an assertion, so reverting it passed. Three
assertions cover it now, including that a truncated reply is reported as CUT rather than as invalid —
it is invalid BECAUSE it was cut, and naming the symptom sends a DM after the wrong thing.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Reported again: most images still placeholders, with a monster whose portrait exists in the Editor and
was published to the vault. The sample markup settled it — the frame still carried its binding, so the
resolver had come back empty rather than come back with something broken. Two faults behind it.

The room one is exact. A room's `bannerImages` is not a map of time-of-day to URL; every slot is a
{ static, gif } PAIR, and has been since animated banners arrived — normalizeBannerSlot in the engine
says so and the Room constructor builds six of them. The resolver read one level, found six objects and
not one string, and answered "no picture" for every room in every world while the URL sat one level
further in. It recurses now, depth-limited, which also picks up a conversation close-up nested under
its mood key.

The second is the reason there was a second round at all. A list of field names for "where the picture
is" is the equipment-slot roster again — correct the day it is written, wrong the first time a record
keeps its art somewhere else, and wrong with no symptom, because a record whose art was not FOUND and a
record with no art draw exactly the same placeholder. So the named fields stay, as a preference that
picks the right picture where a record has several, and behind them is a sweep of every field on the
record. A picture that exists is now found whatever it is called.

The sweep is stricter than the named fields, because it is guessing. A data: image or an image
extension is self-evident; a bare URL with no extension is taken only where the key is named like a
picture. Three things it must not take, each pinned: a room's bannerVideo (a sweep that took any
media-looking string would put an .mp4 in an img), a prompt that happens to quote a URL, and a bare
link under a field named nothing like art.

And the thing that should have existed from the first report: the run now names what it missed. A
record with no picture found but something picture-shaped on it is a gap in this file rather than in
the world, and the CLI says which record and which field. The next report of this arrives with the
answer already in it instead of costing two round trips to guess at.

Two smaller findings came with that. The media sweep was collecting audio and video — a world's whole
sound library fetched into a directory nothing links to, each failure then reported as an unresolved
picture — so it now skips what no page will ever point at, while keeping extensionless URLs because a
CDN serves plenty of images that way. On the world committed here the art found rose from 34 records to
40, which is the six rooms whose banners had been invisible all along.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Reported from a real world: the race portraits render and almost nothing else does — some shelves draw
placeholders and the NPCs page is broken images. Both symptoms are one fault. The generator rewrote
`src` attributes and copied no bytes, so the output was only ever as portable as the URLs already
inside the world.

A world hosted on a vault stores its art as `/vault/media/<shard>/<sha><ext>`, and that is a ROUTE
rather than a file — Server/server.js matches it before static hosting is ever reached, which is the
same fact Download Vault Pack's own header explains about why a media pack and a vault pack lay their
files out differently. Open such a page anywhere but that vault and the path resolves against the
filesystem root. So every picture stored in the vault broke, and the ones that survived survived by
accident: a record carrying an inline data: URI or an absolute link rendered fine. That is why it read
as "only Races work" rather than as one problem with the art.

Every reference is now resolved to bytes and written into the output, and the pages point at the copy.
Three kinds, three ways: a data: URI is decoded here, which is also the biggest single saving on a
portable export where one room banner is a megabyte of base64 repeated into every page that names it;
a /vault/media/ path is copied off disk, out of the vault pack the world arrived in or out of a media
directory beside it; an https link is fetched unless --no-fetch, which is the only one that can fail
for reasons outside this machine. The output is content-addressed for the reason the vault's own store
is — one portrait is reachable from the hub, its shelf and its record, and stored by content that is
one file rather than three.

A vault pack is now the best input there is: its media travels with it, so it builds a completely
standalone site with no network and no vault at all.

An unresolved reference is reported and never invented. On a content-addressed store a guess cannot
produce a plausible-but-different picture, it produces nothing — so the placeholder stays, and the run
says how many references it could not reach and why. That report is the other half of this change and
arguably the more useful one: "some of my portraits are missing" is not answerable from a page, because
a placeholder means the record has no picture and a broken image means it has one the build could not
reach, and on the page those look identical. The summary now separates them, and says how many records
of how many carry art at all.

--assets keep is the opt-out for somebody who does want their vault to serve the art, and it says in
as many words that the result is not standalone. --media-dir names where the bytes are when they are
neither beside the world nor in its pack.

Two smaller things came with it. PICTURE_FIELDS now records where its order comes from —
CARD_PORTRAIT_KINDS in the engine, which is why races, factions, dungeons, religions, heraldry and
classes take `portrait` while folklore, biomes and ailments take `image` — and notes that a BEING is
the kind that registry explicitly leaves out, its picture being `compendiumImage`, which is the first
thing to check when an NPC shelf draws placeholders. And `conversationImages` is now a last-resort
probe: the wrong crop for a portrait, and better than nothing for a being whose only art is one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Reported from play on Geography › Regions: the ✨ map-prompt button said it had failed, on a reply that
had come back perfectly well. The model wrote 1,866 characters of a genuinely good map prompt for a
nine-room region and stopped at max_tokens mid-clause — "…a torch-lit archway opening on" — so the JSON
was an unterminated string, parseGmJson threw, and the caller reported "the GM returned no prompt".
Every word of that was false: the GM returned nearly all of one, the engine binned it, and the call was
billed for it. The button then advised "try again in a moment", which is right for a blip and wrong for
this — the next press stops in the same place.

Three halves, because the bug had three.

THE BUDGET was not tight, it was under the typical case. 700 output tokens, overrun by one nine-room
region, on a call a DM might make against twenty. The three map-prompt authors ask for 2,000 now, and
the test asserts a floor in the units the overrun was measured in so "raise it a bit" cannot put it
back.

THE READ salvages a truncated single-string reply rather than losing it, and trims back to the last
complete sentence, because a prompt ending "opening on" is one an image model finishes for itself,
badly. The saved reply now yields 1,664 clean characters ending at a full stop. Salvage is OPT-IN at
three call sites and deliberately not inside parseGmJson, which sixty-nine callers share: reading a
partial reply is safe for one string field a DM sees before anything acts on it, and unsafe for a game
turn, where half a directive list is a turn that gives an item and never charges for it. It is never
silent either — a prompt that arrives shortened without saying so is a DM pressing Generate on less
than they asked for.

THE MESSAGE says what happened. A failure that was a truncation says so, and the button stops offering
a retry that cannot work. That choice is one named function rather than a ternary written out three
times, which is also what let the claim be tested by calling it.

Four of this commit's own defects were found by testing rather than by reading. The suite caught a
stale `return prompt;` left behind by the rewrite in two of the three request functions — every press
would have thrown ReferenceError after doing all the work correctly — and it was test_region_map that
caught it, not the new file, because the new file asserted the call sites USE the reader without ever
running one. It runs two of them end to end now, against the saved payload through a stubbed fetch. The
sentence trim searched for ". " and missed a sentence that ended at a newline, which the model emits
inside these prompts. The escape repair stripped a trailing /\u[0-9a-f]{0,3}/ and ate the `u26` off a
legitimately escaped backslash, leaving the backslash behind and turning a parseable string into an
unparseable one — it shortens the tail until the string parses now, because enumerating the shapes a cut
can leave is how you miss one. And an assertion about the three catch blocks compared the ORDER OF WORDS
IN A COMMENT, failing against a comment that opened `NOT "try again in a moment"` while the behaviour
was right the whole time.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

On Editor › Art › Missing, a batch over two dozen cards works down a list taller than the panel, and
within a few subjects the card being painted has walked off the bottom of the screen. The DM watches
an empty stretch of list while the interesting thing happens below the fold, and the pulse that marks
the current card — the one cue the tab has — is somewhere they would have to go looking for.

scrollArtCardToTop puts the card's top on the view's top, called where the loop marks the card and
before the await, so the view arrives with the card rather than behind it. The same call joins
renderArt's mid-batch pulse re-apply, which runs when the DM leaves the tab and comes back while a
card is still painting: the argument that re-applies the pulse there is the same argument for putting
it back on screen, since a cue you have to scroll to find is not a cue.

THIS REVERSES what the batch loop used to do, and only half of it. That loop captured scrollTop before
each per-card re-render and put it back afterwards, with a comment reading "so the view doesn't jump".
That restore is still there and still right: a re-render must not move the ground under a reader, and
it is what keeps the finished card where the batch put it. What it could not do was follow the batch
down the list, because nothing had ever moved the view in the first place — the jump it guards against
is a re-render shifting things under someone, which is a different act from the batch taking them with
it. The two do not fight: the loop clears artProcessingKey BEFORE its re-render, so the renderArt
branch does not run on that path and the captured scrollTop stands.

Measured from getBoundingClientRect deltas, not offsetTop. offsetTop answers relative to the nearest
POSITIONED ancestor and #art-view is not positioned, so it reports a distance from somewhere up the
editor and would land every card at a constant offset below the top — one that changes with how much
chrome sits above the panel. The two readings are indistinguishable on a container at the origin,
which is why the test fixture deliberately puts the view at y=100 with the list already scrolled.

One guard came back out during the sabotage pass. The clamp to the end of the list and the floor on the
assignment were both written with a Math.max(0, ...), and each alone produces the right answer for a
list shorter than the panel — so neither could be shown to be doing anything, and removing either left
every assertion passing. The floor on the assignment is the one that stayed, since both sources of a
negative end up there; the clamp is now a bare Math.min, and deleting it fails.

The new test drives the real artGenerateAll loop with a stubbed generator rather than grepping the call
site, because a grep passes against a call placed after the await. Its failure message names both
shapes and the trailing one reproduces exactly: [0,0,200] instead of [0,200,350].

test_art_pulse_persist.js needed its second bounded gap widened. It spanned the lookup and the
classList.add with 120 characters, 15 of them spare, and the line gained a call plus four lines of
comment — which failed it with a message about the pulse rather than about the prose. The comment moved
above the lookup, where it reads better, and the bound is 400 now: a proximity test with a handful of
characters to spare reports the next unrelated edit as a broken feature.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The masthead was eight facts and a dead end. On a site of a few hundred pages the two things a reader
most wants from it are a way back to the front and a way straight into the shelf whose number they are
looking at, and neither was there: the title was text, the chips were spans, and the only navigation
was the breadcrumb in the toolbar.

Both are declared in the design rather than assembled in the generator, and they work in the prototype
as well as in the built site. The title carries `href="#"` and `data-tlr-home`, which in the standalone
design means "back to the top" and is exactly right there; the populator rewrites it to index.html at
whatever depth the page sits. Each object chip carries the anchor of the group it belongs to, which is
a real jump in the design because the whole hub is one document, and the populator rewrites it to that
shelf's page.

That fallback is the reason there is no mapping table in the generator. A chip names a figure; where a
shelf answers to that name it wins, and where none does the template's own anchor stands, rebased onto
the hub. `Beings` is the case that needs it: it counts the entity catalogue, which this encyclopedia
splits into NPCs, Monsters and Fauna, so no single shelf is the whole of it and it goes to
index.html#g-peoples. Somebody reorganising the groups will see that href sitting in the design where
they are working, which is not true of a table two thousand lines away in a tool.

A withheld shelf loses its chip and not just its tile. Leaving it made the one number on a player build
that pointed at something unreachable — "Quests 4" beside no Quests anywhere — and a count of withheld
things is the registry's rule broken in miniature. An EMPTY shelf keeps its chip, because nought is an
honest figure and a reader is better off learning this realm has no dungeons than wondering where the
dungeons went. A chip that is a fact rather than a shelf, Version and UID, stays a span.

Two defects came out of checking it rather than looking at it. Crawling every internal link in a built
site found twenty-four dead ones, all alignments: a record's filename was derived at each of the three
places that needed it — the index, the shelf grid, the write — and only the write ran it through
safeName, so an id of "True Neutral" produced a page at one name and links to another. The ones that
worked worked because their ids happened already to be slugs, which is agreement by luck. The filename
is now settled once and carried on the record. And every generated page still carried the design's own
<title>, so a built site would have put "Front Page Prototype" in every tab, bookmark and search
result; a page now names itself, its shelf and its realm, most specific first, because a tab strip
shows the front of the string.

Tests/test_encyclopedia_build.js gained the link crawl over both audiences, which is the cheapest
assertion in the file and the one that found the most.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

Two things on the Rooms card's Music row, both small and both about the row saying what it is.

The picker carried `flex: 1`, which stretched a dropdown holding "— None —" and two short titles across
the entire width of a room card, beside a 26px button. At that width it reads as a text field rather
than as a short list of Area sounds. It is capped now — `min(260px, 100%)`, so it fits a title and
still shrinks on a narrow card — and the row no longer stretches it.

The ▶ started a track and then did nothing: the only ways to stop a preview were to let it finish or
to reload the page. It is a toggle now, ▶ to ■ and back, and the part worth stating is that it runs on
the app's EXISTING preview channel rather than a second one of its own. `_playingSoundCard` is what
the Art › Sounds cards already use, so a room's preview and a sound card's preview cannot both be
sounding: starting either reverts the other's button. Two independent channels would have let a DM
stack three tracks over each other with three ■s on screen and no way to tell which one stopped which.
The preview still does not loop, unlike the same track in play — a preview that loops has to be stopped
to end, which is the trap the missing ■ already was.

Two details that are invisible when they work. The button carries a stable id and is resolved by it
rather than through the element that was clicked, because a card re-rendered mid-preview detaches that
element and the revert would then update a node no longer in the document — leaving a ■ on screen over
silence. And the button is BUILT in whichever state the preview is actually in, so a card rebuilt while
its track plays draws ■ rather than a fresh ▶ over playing audio. `stopSoundCardPreview` reverts both
kinds of button, the card's by sound id and the room's by room id, since the same track can be on
screen in both places at once.

Tests/test_room_music.js pins the toggle, the shared channel and the re-render, each sabotage caught by
a distinct named assertion: the toggle branch removed so a second press restarts the track, the room id
dropped from the preview record, the room-button revert dropped from stopSoundCardPreview, and `flex: 1`
put back. The stop assertion reads the play COUNT as well as the stopped flag, because a second press
that restarts the track also leaves it "stopped" at some point and would otherwise pass.

The DM's Guide gains the sentence it never had about the Music box and its ▶/■, and carries a new
Last Update stamp.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The encyclopedia prototype landed with no producer: a template with every count, name and picture
carrying the attribute saying what belongs there, and nothing to put anything there. This is the
producer. It takes a world export or a vault pack and writes a static site — a hub over every shelf,
a page per shelf, a page per record — and it reads the shelf roster out of the template's own tiles
rather than carrying a copy, so the forty-nine shelves live in the page a person edits and this file
has no list to keep in step with it.

--audience is required and has no default, and that is the substance of the change rather than an
ergonomic choice. The Realm Registry already answered a version of this question: browse.html refuses
to enumerate rooms because "a registry enumerating rooms would hand any reader a walkthrough of every
published realm", and it refuses categorically because it is not allowed to know who is looking. This
tool is not in that position — it runs on somebody's own machine over their own world — but it writes
a SITE, and a site gets served. Defaulting to everything publishes a solution guide the first time a
web server is pointed at the output; defaulting to the redacted view hands an author a hollowed-out
copy of their own world with no indication why. Neither default is honest, so the error names both.

Where `player` draws the line is a judgement and it is written down in the file's header so it can be
argued with rather than rediscovered. A shelf whose content IS the solution comes out whole, which is
Quests and the Guide. A record nobody has earned comes out: `unlocked: false`, `seen: false`. And a
room keeps its name, its region and its description and loses its exits, items and beings — the
registry's argument taken seriously, because a gazetteer is not a walkthrough but a room list with its
doors and its loot is the game solved. It is deliberately not a security boundary: whoever holds the
world file holds everything in it.

Three fields are dropped for every audience, the DM's included, and each was found by reading a
generated page rather than by reasoning about one. A room's banner prompts were four fifths of its
page — an account of the art pipeline filed under a place. `descriptions` restates `description` once
per time of day. And `visited` is one player's progress riding along in an export, which an
encyclopedia over the world must not report as the world's.

The generator refuses two things loudly and is silent about a third, and the distinction is the one
the whole template was built around. A collection the world does not carry is EMPTY and normal — the
world committed at Server/worlds/e1xfr50 predates districts, biomes, ailments, languages, folklore,
religions, heraldry, history, recipes, reagents and schools, and every one of them is legitimately
missing. A collection of the wrong SHAPE stops the build and names the shelf, because a tile declaring
a map over an array counts zero keys and draws an empty shelf that reads, on the page, as a DM who
authored none. That is not hypothetical: the first real run reported Quests and Lore, both declared
map here and both lists, and every other check in the repository passed over them.

Four more defects came out of the tests and the screenshots, each fixed where it happened. A locked
loreKey was reading as an unearned RECORD rather than unearned lore, which dropped the whole of
Geography out of a player build — a page that hides the village square because there is a rumour about
it. The filename dedupe was keyed across the run rather than within a shelf, so every page of every
derived shelf came out numbered, flora being itemCatalog filtered to plants. An exit was probed for
`room` where the field is `to`, so every exit in the world rendered as "north → …". And the entry
card's picture binding is written with Rooms bound into it, so an Items shelf drew thirty-seven
placeholders over records that had art until the binding became a preference with fallbacks.

The theme is answered too, and is the reason the template moved. Both palettes and a toggle were
already there; what was missing is that a site is many pages, and a toggle that forgot on every
navigation would make a reader re-make the same choice a few hundred times. The choice is now
remembered and applied before paint, --theme sets what a page opens in for a reader who has not
chosen, and a reader's own choice still wins over it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

# Conflicts:
#	Handbook/dungeon-masters-guide.html

Generate Music filed its track the moment it arrived, and that got two things wrong at once. The press
ended in silence — a re-rendered card, a new row on a tab the DM might not have open, and a log line
were the only evidence anything had happened — and a take nobody wanted was already the room's music
and already in the library, with the previous track still sitting behind it. Both are now the same
fix: the press opens a dialog, and the dialog is where the feature lives.

While the provider composes, the dialog says who is composing, for which room, and how long it has
been at it. The spinner, the sweeping bar and the elapsed clock are the World Builder's Generate Brief
block rather than a second waiting idiom invented beside it, because it is the same kind of wait: one
call, tens of seconds, no measurable progress, and a bare spinner implies something shorter than
composing a minute of music actually takes. When the track arrives the dialog shows the name it will
be filed under, says whether that name came from the provider or from the room, and plays it — the
browser's own transport, so there is a scrubber and the end of a loop can be heard as well as its
opening.

The gold Accept is the only thing in the flow that writes. It stores the bytes, files the track as an
"Area" sound on Art › Audio, and sets it as the room's Music — the same three steps as before, in the
same order, through the same writers, so the generate door and the upload door still leave the world
in the same state. Cancel discards the take: the generation is already paid for either way, so this is
deliberately the cheap direction, and it is the one that keeps a library from filling with takes
nobody chose. A discard says so in the log, because it did cost a call. The inline-track upload moved
to Accept with the rest, which means a take that is turned down never reaches the vault's disk.

Three things the dialog has to get right that are invisible when they work, each with its own
sabotage-checked assertion. A failure stays INSIDE the dialog — that is where the DM is looking, and
an error that closed it and left a tooltip behind would report nothing at all — so Accept disappears
and Cancel becomes Close. Every press takes a run number, and a reply carrying a stale one is dropped:
without it, giving up on a slow take and asking again ends with the first arriving late and replacing
the second, and the two are indistinguishable once they are on screen. And closing silences the player
and lets go of its source, because the dialog is hidden rather than destroyed — an <audio> element
left with a data: URI on it keeps playing, and keeps a megabyte alive.

The two refusals stay on the button rather than opening the dialog. Neither is a generation, and a
modal that opens only to say "write a prompt first" puts a dismissal between the DM and the field they
need to type in, which is behind it.

Tests/test_music_provider.js now pins the dialog as well as the filing: the waiting half is read while
a held promise keeps the provider in flight, rather than inferred afterwards from what is on screen.
Four sabotages, each caught by a distinct named assertion — the track filed on arrival instead of on
Accept, the run number dropped, the preview left set after Accept so an accepted track is reported as
discarded, and the player left holding its source. Designs/music-ai.html §01 records why the split is
the point rather than decoration, and its playtesting notes lose the question the dialog answers ("is
a silent success legible?") for the two it raises: whether one listen out of context is enough to
accept on, and whether the elapsed clock keeps the promise the note beside it makes.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

The tab read "District", which is a tab announcing its own category rather than saying where you are.
The strip already reads World, Region, Dungeons, so a fourth word for the KIND of thing tells the
player nothing they could not infer, while "Quill Ward" tells them the quarter they are standing in
without opening it. That is also the shape the interior-structure subtabs beside it already have: one
per structure, labelled with the room's own name.

Making them one per district retires the inner strip the single tab needed for a room filed under two
quarters. Once a tab says Quill Ward, a strip inside it offering Quill Ward and Tanner Row is the same
switcher built twice — so the tab strip is the switcher now, and switchDistrictMap and
activeDistrictMapId go with it.

The keys are namespaced. Structure subtabs are keyed by ROOM ID, and a district id and a room id are
slugs out of the same alphabet, so a world with a room and a quarter both called `shambles` would
otherwise have had one key naming two subtabs. The colon cannot occur in either, which is what makes
`district:<id>` a namespace rather than a convention somebody has to remember. Every element id inside
a subview is suffixed with the district's own for the same reason one level down: the markup is built
per subtab, and duplicate ids would have every lookup answer for whichever quarter happened to be
first in the DOM, so the second district would quietly draw into the first one's elements.

The per-district split reaches further than the markup. Each quarter now has its own pan/zoom state,
and "what picture is mounted" became a Map keyed by tab rather than one variable — a single one reset
a quarter's view because a DIFFERENT quarter had been drawn, which is exactly what the old inner strip
did on every switch. Walking from one quarter into another now falls through to the new quarter's tab
rather than to World: the tab they were reading has gone, but what they were reading it for is what
the new one answers, and World would be correct and useless. That is what activeDistrictMapId's
follow-the-player did from inside; with a tab per district it belongs where the tab set is decided.

The sabotage pass found four assertions that could not fail, all of them mine from the commit before.
Sizing check: it asked whether sizing Tanner Row left Quill Ward alone, which a sync ignoring its id
passes trivially by writing Quill Ward's own numbers back over themselves — it now asks whether the
NAMED district's layer was written, which cannot be satisfied that way. Layer-clearing: it read
`innerHTML === ''` against a layer that had never been filled, so it passed whether the branch cleared
anything or not; the fixture now gives Tanner Row a map and pins to lose. And the view-reset behaviour
had no assertion at all, so it gained one in both directions — a re-render keeps the pan, a new picture
resets it — because a test for "does not reset" passes against a renderer that never resets anything.

One hardening while in the line that renders these keys: the subtab bar interpolated a key raw into an
inline onclick. Room ids come out of world data an author writes, and one apostrophe would have closed
the attribute's string and taken the button with it. Never observed, because ids are slugged on the
way in; the escape is there to stop depending on that, and the test plants a quoted room id so the
escape is reachable rather than decorative.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The encyclopedia tiles went stale within a day of being written, in the half nothing checked. Every
tile carries two claims: where its data lives, which is held to serializeWorld's allowlist, and where a
DM authors it, which was held to nothing at all. Regions and Districts were two tabs on the Editor's
World strip when these tiles were authored and became one Geography tab with two inner tabs eleven
commits later, on main, while this branch was open. Both tiles went on naming the old places and every
assertion in the file passed.

The first guard written for it asked whether each segment was still a tab label somewhere in the app,
and it did not catch this — Regions still IS a label. It moved; it was not renamed. A label check
passes on every reparenting, and reparenting is the common case: a strip gets reorganised far more
often than a tab gets a new word. So the path is walked instead. Each segment has to name a tab on the
strip the previous segment opens, which is the claim the line makes to a reader, and a path that skips
a level fails — "World › Regions" resolves under containment, because Regions does sit somewhere
inside the World panel, and that is exactly the stale path this exists to catch.

Nothing in the walk is a roster. A button's slug comes from its own onclick and its panel is the
element whose id ends in that slug, because label-to-slug is not guessable: Beings opens `entities`,
Background opens `art`, Audio opens `sounds`. Three things had to be right before it worked, and each
is recorded where it bit. The scan runs over a copy with HTML comments and the inline script blanked to
spaces — offsets preserved — because both are full of markup that is not markup, and counting it closed
the Items and Magic panels in the wrong place. The panel prefix comes from the button's class rather
than from the slug, because `map-inner-world` sits earlier in the file than `editor-sub-world` and a
slug-only lookup resolved the World strip to the Map tab. And the first segment is restricted to the
editor-tab class, because the Compendium's Magic sub-strip carries four of the same labels and sits
earlier still, so "Items" was answering out of the Compendium.

The visible line on a tile stays abbreviated to fit its column; `data-tlr-editor` now carries the same
location in full, on all forty-six tiles that claim a tab path. That is what the walk reads, and it is a
deep link out of the encyclopedia for free. A tile whose visible line shows a path must carry one, so
the check cannot be silenced by deleting the attribute.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

One conflict, in the halo roster, and it is a UNION rather than a choice. Both sides added a selector
to the list of unmasked text that carries the page's text-shadow: this branch added #nowplaying, when
the Now Playing line lost its scrim and had to carry its own legibility, and origin added
#install .what for the staged-world installer's progress line. Neither is an alternative to the
other — they are two separate pieces of text with nothing behind them — so both are in the list, and
taking either side alone would have left that side's text unreadable wherever the village is bright,
with nothing failing to say so.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The line sat in a scrim-and-border box like the lore panel beneath it. It comes off, and legibility
moves into the TYPE instead — the trade this page already makes for its title and tagline, and the
reason the halo roster exists at all. The colours go up with it: the label from --gold-dim to --gold
and the track name from --text to --gold-bright, which makes the name the brightest thing in the
corner. That is the right emphasis rather than merely a brighter one, since the track is the single
fact on the line and "Now Playing" is its caption.

Right-aligning is what makes losing the box work. Left-aligned and unboxed, the line and the panel
under it disagree about where the corner begins; sharing one edge, the two read as a block with a
caption over it. Both halves of that are pinned, because dropping the background without joining the
halo roster is a failure that LOOKS fine in a screenshot taken over the guard's cloak and washes out
completely over the lantern or the sky — the corner is bottom right, and the picture behind it is not
uniformly dark.

THE SPEAKER IS DRAWN AND NOT TYPED, which is the one place this departs from what was asked, so it is
stated rather than quietly done. The ask was the emoji, coloured in the app's style. An emoji is a
COLOUR glyph supplied by the system's emoji font and CSS `color` does not reach inside one, so those
two requirements cannot both be met: 🔊 would have arrived blue and grey beside gold type, which is
precisely what it was asked not to be. The platform makes it worse rather than academic — a Linux box
with no colour-emoji font installed draws a replacement box, on the one page in this app that exists
to look right on a machine nobody has configured. So it is the app's own speaker mark, the same path
the strip's toggle uses, at 13px, taking its colour from the text through currentColor so it cannot
drift from the line it sits on. Swapping the character back in is a one-line change if it is wanted.

Two notes on the test, both about assertions reading prose rather than code. The emoji check was
written against the whole page and matched the COMMENT above the markup, which names the emoji
because that is what the comment explains; it is scoped to the line's own markup now. That is the
second time in this suite — test_build_button's preload check did the same thing — so it is written
down in both places.

And the file was destroyed and restored in the course of writing it, which is worth a sentence
because the mechanism is not obvious: a Python `open(path, 'w')` truncates the file before anything
is encoded, so a UnicodeEncodeError on the way in leaves zero bytes where 227 lines were. The write
is encode-then-replace now. Nothing was lost — the file was committed — but an uncommitted one would
have been gone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

# Conflicts:
#	Handbook/dungeon-masters-guide.html

A room has carried a General music prompt since the Audio prompts landed — the mood score for the
place itself, whatever the hour — and the only thing under it was Upload Music. The prompt was
written by the GM, copied into a music service somewhere else, and the file carried back by hand.
Generate Music closes that loop in one press: compose the track from the prompt, store the bytes,
file the track on Art › Audio as an "Area" sound, and set it as this room's Music. It writes exactly
where the upload door writes, because confirmAddSound's room door is the same four steps with a file
picker in front of them, and two doors leaving the world in two different states is the kind of
difference nobody finds until a picker is mysteriously empty. The Area type is the load-bearing part
of that: a room's Music list holds Area sounds and nothing else, so a track filed without it lands on
the Art tab correctly and is missing from the very picker the button sits under.

The cheap way to build this was a second entry in SOUND_PROVIDERS, and it is wrong for a reason that
is about the endpoint rather than about taste. The same ElevenLabs account answers two APIs:
/v1/sound-generation refuses text past 450 characters and hands back a few seconds of noise, while
/v1/music takes a paragraph and composes minutes. One registry would have offered each provider for
the other's job, and the failure would not have been loud — a room's score sent to the effects
endpoint still comes back as audio, just not as music. So Music is a slot of its own on both sides of
the wire and a descriptor `kind` of its own in the vault's vocabulary, which is what makes
validateSlotSelection refuse the effects descriptor for the Music slot on the admin page. The two
providers carry separate ids because the generation catalog is keyed by id and two entries sharing
one would collapse; they share the stored KEY, because it is one account and an operator who has
pasted their ElevenLabs key once has said everything they have to say about it. server.js already
resolves a generation's key by auth.ref rather than by provider id — it is how "pollination" reaches
the "pollinations" key — so the music descriptor's ref is 'elevenlabs' and nothing new is asked for.
The admin page's ElevenLabs card grows a second chip, Music, so that is visible where the key is
entered rather than discoverable by finding a dropdown empty.

Where the bytes go is the split the rest of the app already makes, and it matters more here than
anywhere: a minute of MP3 is about a megabyte and a save carries its media in full on every write. A
vault-routed generation is written to the media store on the way through and comes back as a short
path; an inline track is uploaded where an upload is possible, and an upload that fails keeps the
track rather than losing it and says so. With no vault at all the data URI is kept, which is the only
thing Direct mode can do and is what the upload door does, and the log says so rather than leaving a
save to quietly grow. What the track is CALLED comes from the provider when it names the file —
carried out of a Content-Disposition header the descriptor asks for by name, and through the media
store, which otherwise returns only url/bytes/sha256 — and from the room when it does not. The
fallback is reached often and deliberately: no published contract promises that header, so the vault
omits the field entirely rather than inventing a name that would be indistinguishable from a real one
and would beat the room's own.

Only the General prompt gets a generator. A room loops one Area track, so a score per time of day
would be six paid generations of which five could never be heard; the hour is what the Sounds
prompts are for, and they already generate. The six per-time music prompts keep Upload Music.

api.elevenlabs.io is unreachable from the environment these sessions run in — the egress proxy
denies the CONNECT — so the descriptor carries their published contract and nothing here has been
exercised against the live service, the footing Vectorizer.AI shipped on. What is exercised, through
an injected fetch, is every request the vault builds and every way it can decline.
Server/test/test_music_provider.js and Tests/test_music_provider.js are written against the failures
rather than the shapes, because most of these are quiet — a track still appears, it is simply the
wrong one, in the wrong place or under the wrong name. Sabotages caught by distinct named assertions:
the type changed from Area to Ambient, the selection step dropped, the upload skipped so the bytes
stay in the save, the provider's name discarded for the fallback, the shared auth.ref pointed at an
id with no key behind it, the filename header no longer read, the length sent as a string, an unnamed
length sent blank, each descriptor claiming the other's slot, a url off the declared host, and an
empty 200 treated as a track. test_slot_parity.js needed no change and is why the slot works under a
vault at all — it pins that the client's slot list and the vault's agree in contents and in order.

Designs/music-ai.html is the write-up, with the playtesting notes the desk cannot settle: whether the
GM's General prompt reads as a brief for a composer or as a description of the room, whether a
one-minute clip loops without an audible seam, and whether a silent success reads as nothing having
happened. The DM's Guide says what the button does and carries a new Last Update stamp.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QUtzKjY3UJXiG6ZMpDfPp5

A vault pack was a thing you unzipped by hand. That is a fine answer for an operator with a shell on
the server and no answer at all for the desktop app, whose vault lives under userData on a machine
whose owner has never opened a terminal — so a build could not arrive with a world in it, and adding
one to an install meant finding the data directory and copying files into it correctly.

Electron/tools/worlds.js is the build script: list, install and remove, over either of two targets.
By default it writes a STAGING AREA, Electron/worlds/, which electron-builder ships as a resource and
the main process copies into the player's own library on first launch. With --library it writes
straight into a real library instead, which is the no-rebuild route and the answer to installing a
world before ever launching the game. It takes a vault pack zip, a bare world file or a directory
already in vault layout, telling the difference by content rather than by extension, and refuses a
media pack by name the way Server/admin.js does — its files are named by a hash of their URL, so
re-filing them here would mint names no world references.

THE ZIP IS READ AT BUILD TIME, NOT AT LAUNCH, and that is the shape of the whole change. Expanding a
pack needs a reader, a CRC check and a per-file content hash; all of it runs in a checkout where
Server/zip-read.js is at hand, so the shipping app carries no archive code and every check happens
once, on a developer's machine, with a sentence for an answer instead of on a player's machine with a
progress bar that stops. What reaches a player is a directory already verified, and the launch-time
operation is a file copy.

Electron/world-library.js holds the decision and is shared by the tool and the shell so the two cannot
drift. Copying is the easy half; knowing NOT to copy is the feature, and on disk every case looks the
same. A receipt of what was installed and what it hashed to is what tells "the player deleted this"
from "this has never been installed", and "a newer build staged a revision" from "the player edited
it" — the Editor republishes into that very directory, so overwriting is how a session's work
disappears. Without the receipt a discarded realm returns on every launch, which is the bug
backfillWorldFromBuiltIn carries knowingly elsewhere in this tree and had no reason to be reproduced
here. A hash rather than a flag, because a flag can say we installed this but not that it is still
exactly what we installed.

Media is copied before any world.json, because WorldStore._reconcile adopts a world the moment its
file appears and one written first is a realm the player can start and find pictureless; each file
lands through a temporary name and a rename, since a half-copied world.json is a file the vault will
try to parse on its next start. Media is priced once per run rather than per world, because content
addressing means two realms sharing a picture share the file — counted per world the bar would stop
short of its own end by whatever the two had in common.

The install runs before the vault is started, from Play, Build and Admin alike: the stores rebuild
from the filesystem so copying under a running vault corrupts nothing, but it shows a login screen
listing three realms out of four, which reads as a lost world. The launcher asks what is happening as
it paints — which also starts the work, so the copy happens while somebody is reading the news feed —
and shows the world's name and a progress bar beneath Play and Build, holding both until it finishes.
The hold is not strictly necessary, since the main process awaits the install either way; it is there
because a button that goes quiet for eight seconds reads as one that did not work, the same argument
that put the vault-start line under Play. installStaged awaits its progress callback for the same
reason the bar exists at all: a synchronous copy loop runs to completion in one tick, and a bar that
paints nothing and then jumps to the end is a delay with a picture of one.

Two test files. test_world_library.js hands what it installs to the vault's own WorldStore and asks
the operator's question — does the realm appear — rather than matching a path, and works through each
case the receipt exists for. test_staged_worlds.js runs the shipping findStagedWorlds and the
launcher's own showInstall rather than reading them, because the failures here are a missing candidate
path and a released button, both of which read correctly in every line that is there.
test_config.js's hand-maintained bridge roster gains the two new members deliberately, and
test_vault_launch.js gains the case where an empty status arrives with files still moving.

Designs/world-packs.html §11 is the write-up and §14 its playtesting notes; Electron/tools/README.md
documents both build scripts with worked examples, and Electron/README.md points at it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ltw9jdqJQvU2azibPq1iDn

Reported from the app: the Geography strip's tabs are a different height and size from Weather's. They
are, and Weather's is the right one. The quieting that Weather and Culture wear is not decoration —
it is the reason the note above .world-inner-tab gives at length: those strips are siblings one click
apart in the SAME World bar, so a reader moving between them must not see the inner bar change weight
under a bar that did not move. Geography is a third sibling in that same bar, so it belongs to the
set, and being a step louder than the two beside it is exactly what the treatment exists to prevent.

What it shipped with was half of it. The quieting is two separate rules — a transparent, tighter
CONTAINER (.X-inner-tabs) and a smaller TAB (.X-inner-tab) — and Geography got the container and not
the tab, so it kept the base 10px / 9px 14px while Weather and Culture sat at 9.5px / 7px 12px. The
split was easy to make because the two halves were not written together: Culture's container rule and
its tab rule had drifted three lines and a comment apart, with Geography's container inserted between
them. All three pairs are one two-line block now, and the comment says that keeping them adjacent is
what stops a fourth strip landing half-done.

The test is the part worth reading, because the first version of it was inert and said so with eight
passing sabotages. It asked whether any rule in the file declares `.geo-inner-tab` — and the SHARED
base rule does, correctly, since that is where the base look lives. So the assertion was satisfied by
the very rule whose insufficiency was the entire defect, and passed against a build with the override
deleted, against each half removed from each of the three strips, and against a Geography quieted to
values of its own. It now resolves the CASCADE instead: every rule declaring the selector, in document
order, merged later-wins, which is the number on the screen rather than the presence of a rule
somewhere. Then it compares the three against each other and against Art's un-nested strip, because
"all three agree" is equally true of three strips that are not quieted at all — that comparison is
what fails when the block is deleted outright.

The members are derived from the markup — every -inner-tabs strip inside the World subview that is not
the World strip — rather than listed. A fourth nested strip is covered the day it is written, which is
the only version of this assertion that would have caught the third.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

A world is currently legible only through the Editor, fourteen tabs deep, and only to somebody who
already knows which tab holds what. This is the prototype of the other reading: one page listing
everything the world carries, grouped the way the Editor groups it, with a count and a sample against
each shelf. Forty-nine shelves across geography, peoples, things, magic, culture, story, environment,
art and rules, plus the two layouts beneath them — a shelf opened into its records, and one record
opened into its fields and its cross-references.

It is both the design and the template, which is the decision worth recording. The obvious shape was a
design document describing a markup contract plus a mockup implementing it, and that is two copies of
one roster: the description goes stale the first time a tile moves and nothing reports it, which is the
equipment-slot roster failure this repository has now paid for three times. So the specification lives
inside the artefact, as a section carrying data-tlr-strip that the populator deletes on the way out,
and every count, name and picture on the page carries the attribute saying what a future Server Vault
function should put there. The file stays openable in a browser on a specimen realm of placeholder art
and invented names, which is the property that dies the moment a page becomes a template language.

The bindings are the save's own field names, read straight off serializeWorld's allowlist rather than
through a vocabulary of their own. A second vocabulary would be one more roster to keep in step, and it
would go stale in the silent way: a tile pointing at a field the save no longer carries renders as an
EMPTY SHELF, and "this world has no reagents" is indistinguishable on the page from "this template
forgot reagents exist". Interpolating the roster is not available here — the file is hand-edited and
hand-reviewed — so the claim is checked instead, the answer test_remedy_coverage.js already gives to
the same problem. test_encyclopedia_template.js reads the allowlist out of text_adventure.html and
fails on a tile bound to a field that is not on it. Its mirror matters as much: Culture › Castes has a
tab and no world.castes behind it, so its tile is marked unbuilt, and the test fails if that claim ever
stops being true — nothing about shipping world.castes would otherwise make anybody open this file.

The last assertion is about the licence and guards a failure with no symptom at all. content-notice.js
writes the Game Content notice before the file's last </div>; the contract section is deleted whole on
populate. Move that section to the bottom and the notice lands inside it — the design file still looks
right, --check still passes, and every page the vault serves from then on carries no notice. It is
checked positionally, because both halves are present and correct in the broken case and only their
order is wrong.

Two things came out of rendering the page rather than reasoning about it, and both are recorded where
they happened: a max-height on an aspect-ratio box narrows the box instead of flattening it unless the
width is stated, and a sticky toolbar whose jump links wrap to three rows on a phone costs more
viewport than the scroll it saves. The field list's specimen mark came out of the test — it was on both
the dt and the dd, which is two specimens in one region, and the second would have been dropped in
silence.

Four decisions are left open on the page with their leanings: whether the vault serves one page or
three routes over one file, who decides a record's field list, what the encyclopedia does about
GM-eyes-only content, and whether a shelf page needs a search of its own.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UNrJp81rK1Unm1e8y7A1f5

# Conflicts:
#	Designs/districts.html

Designs/gm-rulebook.html writes down the convention the 3e and 10d fixes were made under, which until
now lived only in a test file's header. The argument it makes is a count rather than an impression:
25 of the rulebook's 47 rules are cited by another rule, text_adventure.html carries 159 mentions of
the form "rule NNx" naming 32 distinct rules — in the rulebook, in the per-turn dossier headers the
model reads every turn, in field specs, in log messages a DM sees, in comments a maintainer reads to
find out what a rule says — and Designs/ adds 56 more naming 19. The most-cited is 13c at 49. So a
rule label is an identifier with a hundred-and-fifty-odd references and no compiler, which is the
whole case for treating it like a world-map key rather than like a heading.

Four sections carry the parts that were not obvious. The convention itself, including the one rule it
broke in its own first application: when two rules collided, the NEWCOMER kept the number and the
incumbent moved, because two design docs already cited the newcomer's label and nothing outside the
file cited the incumbent's. The convention minimises broken citations; it does not award seniority.
Adding a rule, where the expensive case is renumbering, which touches five places and where the guard
sees four — Designs/ is deliberately not read, and the reason is an open decision rather than an
oversight. The guard, and the thing it had to learn: it reads the BUILT prompt because a rule can sit
behind an escaped newline on the same physical line as its predecessor, exactly one does, and this
test was first written on the strength of a grep that therefore reported it missing. And the sabotage
pass that moved one of its own assertions, whose general form is worth the paragraph it gets — a
checker has to admit the broken case before it can report it.

The playtesting notes ask the question the suite cannot: whether a model FOLLOWS a cross-reference at
all. If it does not, this is bookkeeping for an audience of maintainers, and the third open decision
turns on the answer.

Two stale things fixed in passing, both made stale by the two commits before this one. The districts
doc's header still read "authoring only" and "nothing reads a district in play yet", which stopped
being true when the dossier line and the Maps tab landed, and its README row still described Rev. 2.
Two of its own section cross-references pointed at Open decisions by its old number, which is the
defect this new doc is about, committed in the doc that caused it.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Three things, and the one worth reading first is the one that is not what was asked for.

THE MUSIC TOGGLE MOVED RATHER THAN MULTIPLIED. The ask was to add a toggle to the strip in the left
corner, and there was already one among the window controls in the title bar. Adding the second would
have left two controls for one boolean — two things that must be kept showing the same state, which
they will not, and the first report of it would be somebody pressing the one that had stopped
agreeing. So there is exactly one toggle and it is on the strip, which is where it was asked for and
is the better home besides: under the five links, separated by a wider gap because those all go to
the same website while this changes something about the app in your hand, and outside the <nav>,
because a button inside a navigation landmark is announced as a sixth place to go. It wears the
links' own box, scrim and hover, written as one selector rather than a #music block repeating them.
Putting the title-bar one back is a small change if it is wanted; the state would then need sharing.

NOW PLAYING FOLLOWS THE SOUND, NOT THE SETTING. The line above the lore box names the track, and it
is hidden whenever the score is not actually sounding — muted, or the window hidden by Play, which
hides the launcher rather than closing it. Tied to the preference alone it would survive that, and a
launcher coming back an hour later still reading "Now Playing" would have been claiming it the whole
time. The name is READ OFF THE PATH rather than written beside it, for the reason this repository has
a rule about: a title typed here is a second copy of the one fact this feature has, and the launcher
would go on playing a replaced track under the old track's name with nothing anywhere to report it.

The corner is a column now, and that is a structural change rather than a wrapper for its own sake.
The line has to stay above the lore box whatever height the box takes, and positioning it separately
meant a `bottom` computed from that height — five scraps of different lengths rotating through, plus
a box hidden entirely when a world has no lore, so the number would have been wrong more often than
right. The container owns the position and the two children own nothing but their order. The narrow
window media query moved with it: hiding only #lore left the line hovering over the news block it had
been clearing.

THE TRAY CARRIES BUILD, in the launcher's own order, because the tray is the same set of doors seen
from somewhere else and a menu that reordered them would make somebody check which one they were
pressing. What it deliberately does not carry is the key gate: that gate is a dialog in a window, and
the case this menu exists for is reaching a door while that window is hidden behind a game. A vault
with no key still opens the World Builder from here, and the builder says so when it is asked to
forge — where a tray item that silently did nothing would leave nothing to try.

FOUR EXISTING TESTS FAILED AND EACH WAS RIGHT TO. The lore carousel pinned `#lore {` for the corner
position, which is now the container's; the legibility check pinned `#rail a {` and the rail's rule
is shared with the toggle, which is the point rather than a regression; the tray test pinned the menu
as Play, Admin, Launcher. Each is re-pointed at where the property went and widened rather than
loosened — the corner's position and the panel's own scrim are asserted separately now, since they
fail separately, and the tray's Build item is RUN against a stub to show it calls openBuilderWindow
and not openGameWindow, which is the copy-paste this could most easily have been.

Verified in Chromium across all five states — on open, window hidden, restored, muted, un-muted —
with the line, the audio, the icon and aria-pressed agreeing at each.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The Editor's World strip had twelve tabs on it, and Regions sat at position three while Districts sat
at position seven, with Calendar, Weather and Culture between them. They are the same subject at two
scales — a region is a stretch of the map with an outline and cardinal neighbours, a district is a
named part of one — and nothing about their positions said so. Districts' own design doc spends its
first section arguing that a district is not a second kind of region, which is a claim about what the
records are and reads, from the strip, as a claim that they are unrelated subjects. They are not:
they are the two questions an author asks about where a thing is.

So the World strip gains GEOGRAPHY in their place, holding both on a strip of its own along its
bottom edge. The nesting copies Culture down to the shape of the code, which is deliberate rather
than convenient: switchGeographyInnerTab is switchCultureInnerTab with two names in it, including the
one-list rule WORLD_INNER_TABS' comment sets out at length — the guard and the render loop read the
same array, because two copies of that literal fail quietly in opposite directions, missing from the
guard normalizing a live tab away to nothing and named in the loop throwing on a null that takes the
whole strip down rather than the one tab. The dispatch names its tabs rather than falling through a
trailing else, for the reason switchMagicInnerTab's post-mortem records.

The one behaviour here is that the tab reopens on the face it was left on. switchWorldInnerTab hands
off to switchGeographyInnerTab(activeGeographyInnerTab), not to a literal, which looks identical on
the first visit and differs on every one after: a DM who was editing districts, stepped out to
Calendar and came back would otherwise land on Regions every time. The test for that leaves and
returns rather than asserting the call, because the literal passes any assertion that only checks a
handoff happened.

The geo selectors join the six shared inner-tab CSS lists beside Culture's rather than at the front
of them, which keeps the two-selector anchors test_items_inner_tabs.js uses to find each rule intact
and puts Geography next to the strip it was copied from.

Two test anchors moved rather than being widened. test_districts.js derived the panels it checks for
a position:relative anchor by looking up #world-inner-<name>, and that lookup silently DROPS a toolbar
whose panel it cannot find — so the rename would not have failed it, it would have quietly stopped
checking the one panel the block was written for. It asks both prefixes now, with a fixture assertion
naming where each panel was found so the skip cannot come back. test_calendar.js claimed Calendar sits
between Regions and Weather; the claim it was making is that the world's shape comes before the
world's clock, which is now Geography's position, so it reads that.

One defect fell out of the sabotage pass rather than review: nothing asserted that exactly ONE panel
in a strip carries `active` in the markup. A second one passes every "X is the default" assertion
above it and draws both rosters stacked, because .active is display:flex and no code runs over those
classes until the DM presses a tab. Asserted for both strips, World's included.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The rulebook's paragraphs cite each other by label — "see rule 3b", "the opposite of 13f", "3g's
'somewhere they have never been'" — and that is the only way one paragraph in thirty-six thousand
tokens points at another. So a label is load-bearing text, and every way it can go wrong is silent:
the prompt stays well-formed, the game still plays, and the paragraph that was meant to be read
simply is not.

Two rules were both numbered 3e — HIDDEN BEINGS, and travelling to a place you already know. A model
meeting "the ONE EXCEPTION to 3e's 'somewhere they have never been'" resolves it against whichever it
reads first, and the first one is about creatures in long grass. The travel rule is 3g now and the
district rule 3h; hidden beings keeps 3e, which is the label its neighbours and its design doc cite.
3c moved with them: it is about DIRECTIONS and had drifted to the end of the block, after two rules
about concealment, so it reads in company with 3a and 3b again. Nothing else in the file cited 3c or
3f by number, which is what made moving it safe.

Rule 10d did not exist. Five places cited it — the per-turn Tasks dossier header, the taskPromoted
field spec's "Set per rule 10d", two engine comments — and Designs/factions.html cites it twice by a
clause name, "Rule 10d says PROMOTE RARELY". Task promotion is fully built: the engine authors the
quest, unlocks its first beat, strips the payments, binds the order. Only the paragraph governing it
was missing, so the model was told five times a turn to consult something that was not there. It is
written now, transcribed from the field spec, the apply path and promoteTaskToQuest's own refusals
rather than from a fresh opinion, and it carries PROMOTE RARELY by that name so the design doc's
quotation is of words that exist.

Tests/test_rulebook_numbering.js asks four questions — labels are unique, each family's letters run
in sequence, a label is well-formed, and every rule that is cited exists — and the last one is what
found 10d. It reads the BUILT prompt rather than grepping the file, and that is not a convenience.
The rulebook is a template literal, and a rule can sit behind an escaped newline on the same physical
line as its predecessor: 13f does exactly that, tucked after 13e. This file was first written on the
strength of a file-level grep that reported 13f missing, and a rule was drafted to fill a hole that
had never been there. Build the prompt and read what the model reads.

The sabotage pass moved one assertion. The label pattern required whitespace after the stop, so
"3h.." — a real slip made while renumbering, a three-character prefix sliced at two — was not
collected as a label at all, and the assertion written to catch exactly that never saw it. Other
assertions caught it, which is the trap: the break was caught, the reason named was wrong, and a
malformed label with no citations would have gone through in silence. A checker has to admit the
broken case before it can report it.

test_map_room_return pinned the travel rule by its old label and now uses the new one.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

A prior regeneration ran against a shallow checkout, which truncated the
report to a small tail of recent commits and understated the project's
history. Re-running the generator from a fully unshallowed clone restores
the complete log: 3,978 commits across 79 days, June 30 through today.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Md6i38WeC7sU38k4NCFQxp

A district exists because some places are too close together to deserve a compass. A market with a
dozen stalls, a dock ward with nine wharves, the yards inside one keep — a person crosses those
without thinking, and authoring them as cardinal exits means ninety edges nobody will ever type and a
rose drawn over somewhere that has none. The pins were already the picture of that; now they are the
way through it. Press one, confirm, and you walk.

The sentence the whole change rests on is that filing two rooms under one district SAYS they are
within walking distance of each other inside that place. That is the same statement an exit makes,
made once for a set rather than pairwise, so this is not a second movement system — compoundRoute,
the router that already refuses the teleport BUG-066 was about, takes district edges alongside exits
and puts them through the same two gates. A shut or locked door still refuses, by the same
doorRefusal every other movement path asks, because a strongroom filed under the same district as its
hall would otherwise be a lock with a bypass drawn on a picture. A room on the way must still have
been visited; only the destination is exempt, which inside one quarter is every case, since its
members are all adjacent to each other.

What it loosens is exactly one clause of rule 3e: a place inside your district need never have been
visited. You can see the fish steps from where you stand. It loosens nothing about directions — rule
3g says in as many words that rule 3 and 3a hold in full and that a crossing must never be narrated
as a compass move, because "you head east to the fish steps" where no east exit exists is the failure
a model trained on exits will reach for first.

The press goes through an ordinary turn, typing the command the way the sidebar's exits and the Maps
tab's Return button do. Writing player.currentRoomId is the teleport this engine spent a bug on, and
it would cut the Game Master out of a journey that is its to narrate: crossing a market at noon is
something that happens to somebody, and a district whose map moved the player in silence would be a
fast-travel menu wearing a picture. But a button that sometimes does nothing because a model read the
room list differently is worse than no button, so the press arms a one-shot intent and a reconcile
forces the move onto the turn's own moveToRoom when the reply did not. It is matched to the command
it wrote, so a player who presses a marker and then types something else gets what they typed; it is
consumed by that one turn whatever happens, because an intent that outlived its turn would walk
somebody somewhere they never asked to go; and it re-asks reachability against where the player is
standing when the reply lands. It runs before the directives rather than beside the container and
rest nets, because a move is what the directive block reads first and the door check, the walk and the
despawn all hang off it. When it fires it says so in the story, the way the compound-move stop
learned to.

That needed the Game Master to know the district, which the design doc had parked as an open
question. A model cannot route on a picture, so the Current Room section now carries one line per
district — its name, its short description, the other places in it by name and id. Live, never
stable: its value changes the moment the player walks into another quarter. Rule 3g is the opposite
case and sits in the cached half, where a rule belongs.

Tests/test_district_travel.js pins all of it against twenty-two sabotages. Its door section was
rewritten during that pass: it asserted over the source text, which caught a deleted check but would
have passed a check that read `state === 'closed'` and let every locked door through — so it now
builds the strongroom-in-the-hall shape and crosses it. Two other assertions were replaced for
choosing test rooms that happened to sit behind an exit of the starting room, which made them pass
whatever districts did.

Four open decisions in Designs/districts.html are settled by this and the pin-readers before it, one
of them against its own leaning: the room-side district field is read-only, because a picker there
would be a second writer onto a relationship the district owns.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Play opens the game. Build, beside it, opens the World Builder — the screen a browser reaches by
pressing "New World" on the login screen — so forging a world no longer begins by logging in to a
game that does not exist yet. It is the same vault at the same address with ?builder=1 on it, which
text_adventure.html reads at boot.

THE PARAMETER IS NOT A DETACH VALUE, and that is where it nearly went, since every other window-mode
parameter in the app lives under `detach`. Every detach mode is a second view of a session that
already exists: it resumes the save, mirrors one tab, and deliberately never writes play state. The
builder is the opposite end — there is no session, nothing to resume, and what it produces is a world
nobody has played. Filed under detach it would have made IS_DETACHED true, and IS_DETACHED gates the
whole "do not disturb the main window" boot path, so the builder would have skipped its own boot to
avoid disturbing a game nobody was playing. The boot step runs last in the DOMContentLoaded handler
for an ordering reason rather than a stylistic one: openWorldEditor hides the login overlay, mounts
ACE and focuses a field, and every line above it in that handler is the page arranging itself.

THE SHELL NOW HAS TWO SURFACES ON THE VAULT AND ONE OPENER FOR THEM. They agree about everything
difficult — start the vault before opening anything and narrate the wait, explain a vault that will
not start instead of showing a blank window, explain one that cannot be reached instead of Chromium's
error page, inject the drag CSS a frameless window needs, hide the launcher on show and give it back
on close. openGameWindow became openVaultWindow(kind) over a two-entry table, with openGameWindow and
openBuilderWindow as the two-line callers; the launcher page took the same shape, so its held state,
its settle loop and its key gate are written once. A second copy of any of that is the copy that
stops matching, which is the note this file already carries about settleStart.

BUILD GOES THROUGH THE KEY GATE, which is the part most open to argument since the gate is named for
Play everywhere it appears. Forging a world is a call to the Game Master before it is anything else,
so a World Builder opened without a provider key takes a brief and fails on the press that matters —
a worse place to learn it than the launcher. The dialog's own wording still reads "before you play"
and is left alone: it is the vault's roster of required keys either way, and rewording it per caller
is how two dialogs begin to drift.

Both buttons are held while either is opening. The window takes a moment to appear and hides this
page when it does, so a press on the other one in between can only ask for a window nobody will look
at — and on a cold start it would ask while the vault is still booting, which is the wait the held
state exists to cover.

THREE EXISTING TESTS FAILED AND ALL THREE WERE RIGHT TO. test_config pinned gameWindow.loadURL
(CONFIG.url) and the bridge's exact member roster; test_vault_launch extracted openGameWindow by name
and ran the status listener with only startBtn in its world; test_key_gate matched `async function
start()`. Each is re-pointed at the new shape and widened rather than loosened — the gate assertion
now names the WAYS_IN table, so a third button wired straight to the bridge fails there rather than
opening a window with no key check at all.

Tests/test_builder_boot.js runs both halves rather than matching them: the flag IIFE against eleven
addresses a player can actually arrive on, and the boot step against a stub, including a throwing one
to show a builder that fails to open cannot take the rest of the boot handler with it. Its first
slice was anchored on the whole guard, so removing `!IS_DETACHED` — one of the bugs it exists to
catch — stopped the slice matching and fired the fixture check instead of the assertion that names
that bug; a slice has to survive the edits it is meant to catch.
Electron/test/test_build_button.js is the launcher's end, and evaluates the WAYS_IN table with a
recording bridge, because the failure being guarded is Build calling api.start(): two characters
different, and both buttons open the game.

Verified in Chromium at 160x49 and 136x49 on one baseline. Build takes the page's text halo and Play
does not: Play carries its own dark gradient so its letters never sit on the picture, while Build is
deliberately unfilled and its letters do.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

A question this audit raised yesterday against the Watchful Quiet entry assumed something false, and
the answer is recorded rather than the question quietly dropped. The entry asked whether terms saved
with the lawyer brief on 14 September could cover a track generated on the 15th, treating the saved
copy as a snapshot that a later download might fall outside of. The owner states it is not: the
saved terms are Suno's terms for the ACCOUNT and cover all downloaded and future downloaded content
generated there. There is no per-download grant, so there is no gap between one track and the next
and no separate question to ask about either of the two in the tree.

What the question was reaching for is real and stays open, and the owner names it: not which terms
applied to which file, but whether those terms have been AMENDED since the copy was saved. The owner
monitors that through Suno's direct notices of terms updates.

This narrows the lawyer's pass rather than closing it, and the distinction is the one this ledger
exists to keep. One grant covering every generated track, its saved date on the record and its
amendment watched, is a materially smaller thing to read than an unknown number of per-file
licences. But both statements here are the OWNER'S, made on 16 September 2026; nobody in this
repository has read the terms, and a session summarising what they grant would be the same failure
D-5 already corrects itself for two paragraphs earlier. So neither record says what they say.

Written in three places because three would otherwise disagree. The Watchful Quiet entry carries the
full statement, since that is where the wrong assumption was published. The Haunted Village Square
entry carries a pointer, because it is the one the other defers to for every open question and a
reader who lands there first would otherwise never see the answer. And licensing.html D-5 carries it
as prose, because that paragraph is the narrative the pass in §12 is briefed from.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Two sessions declared Watchful Quiet in the provenance ledger at the same time, from the same
evidence, without either knowing about the other. The conflict is resolved by keeping origin's entry
whole and dropping this session's, because origin's is the more careful of the two on the point that
matters: it says in as many words that the manifest's ASSERTIONS were read and the signature was NOT
cryptographically verified, where this session's read as though a chain had been checked. A ledger
whose basis sentence overstates its own evidence is worse than one that claims less, and this file
exists to record which.

Two sentences are added to the kept entry rather than a second entry beside it, since a path
declared twice is a duplicate the suite flags. The first is the one fact this session established
that origin's does not carry: the owner's 14 September report that the Suno terms are saved with the
lawyer brief PREDATES this file, which was generated on the 15th, so the documents sitting with the
brief are not necessarily the terms in force on its own generation date. That is a thing for the
lawyer's pass to check rather than a reason to doubt the retrieval. The second records what now
reads the file, which was not true when origin's entry was written: it is the launcher's score.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Watchful Quiet loops under the village square from the moment the launcher appears, with a speaker
button in the title strip to turn it off and the answer remembered per machine. Absence of a stored
preference means ON, written as `!== 'off'` rather than `=== 'on'`, so a machine that has never been
asked gets the score — reading it the other way would have shipped the feature switched off for
everybody, which is the one bug here that looks exactly like success.

THREE THINGS ABOUT WHERE IT PLAYS had to be right and every one of them fails quietly, which is why
each has an assertion of its own rather than a shared one about music working.

The page's Content-Security-Policy is default-src 'none' with an img-src for the backdrop, and audio
was not in it. A refused media load still constructs the element and still resolves play(); the
refusal goes to a devtools console nobody has open in a packaged app, and the launcher simply opens
quiet — indistinguishable from a missing file, a path that resolved somewhere else, or a function
nobody called. Checked rather than reasoned about: with the directive removed Chromium answers
"Refused to load media … default-src 'none'" and the element errors with code 4.

The path is relative, like the backdrop GIF above it, because one spelling has to resolve in two
layouts. In a checkout the page is Electron/landing.html and the track is Music/…; in a packaged
build the page is inside app.asar while the track is an extraResource beside it, so ../Music/… lands
on resources/Music either way and an absolute path would work in exactly one of them. package.json
names the file rather than the directory: Music/ is swept by .gitignore and admitted a file at a
time, each exception a claim the file is ours to publish, so a directory copy would ship whatever
lands there next under a claim nobody had made — and put the other track's five megabytes into every
installer for nothing.

And it stops when the window goes away. main.js HIDES the launcher when the game opens rather than
closing it, so without the visibilitychange handler the launcher's score would run underneath the
game's own audio for as long as somebody played, from a window not on screen to be stopped. It is
the same signal the lore carousel already uses, for the same reason. Driven in Chromium rather than
asserted: playing and looping at 0.4 on open, paused when the document goes hidden, resumed when it
returns, paused with the icon and label swapped on the toggle, and still muted after a reload.

TWO ASSERTIONS WERE WRONG FIRST, both found by breaking the implementation rather than by review.
The check that the play decision consults document.hidden was written against the whole of
startMusic and passed against an apply() with the condition stripped out entirely, because the same
words appear in the gesture fallback further down; it now slices apply() alone. And the claims are
made against a brace-matched slice rather than against the page, because landing.html is eleven
hundred lines and /loop/ matches the carousel.

test_news_feed.js needed a real fix, not an accommodation. It locates the launcher's keydown handler
by the FIRST occurrence of document.addEventListener('keydown', which was that handler only while
the page had one. The gesture fallback registers another higher up, so the extraction lifted a
one-line callback and every assertion below it ran against the wrong function, failing on an
identifier it had never heard of. The anchor now names the handler's shape and the fixture insists
that shape is unique, so the next control to grow a keydown listener fails there, saying so, rather
than inside a new Function.

The new test is named in ci.yml as well as written. Electron's tests are listed one by one because
test_launch.js needs the electron binary and the rest deliberately do not, and that file's own
comment records what happens otherwise: a test CI never runs is a test that passes forever.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The track arrived with its named .gitignore exception and nothing else, which left the suite red:
test_asset_provenance.js checks both halves for every tracked file under Music/, Sounds/ and Audio/,
because an exception there is a claim the file is ours to publish and the ledger is where that claim
is backed. One half without the other is the state the check was written to catch.

The entry is evidenced the way the Haunted Village Square score's was, by reading the file rather
than by taking the owner's word for it. It carries a signed C2PA manifest under the Suno C2PA Root
CA whose assertions include com.suno.provenance and the digitalSourceType trainedAlgorithmicMedia,
so the file states under a signature that it was generated rather than recorded, at
2026-09-15T23:18:53Z. The owner's statement agrees with what the file says, which is the situation
the marker readers exist for. Nothing here plays audio, so what is checked is provenance and not
what the track sounds like; its ID3 title reads Untitled, so the name is the owner's and not the
generator's.

What is new is a date. The owner reported on 14 September that the Suno terms are saved outside this
repository with the lawyer brief documents, which moved that item from retrieval to the lawyer's
pass. This file was generated on the 15th, a day later, so the terms in force on ITS generation date
are not necessarily the ones sitting with the brief, and the plan behind it is not separately
confirmed either. That is written down as a second date for the pass to check rather than quietly
assumed to be covered by the first, which is the mistake the earlier entry's correction was about.

The generated inventory is regenerated alongside it. The CSV had been stale since the heraldry
screenshots and the time-of-day squares landed, because it is only written under --csv and the
--check run that guards the tree does not write it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

b864abf added Music/Watchful Quiet.mp3 with a named .gitignore exception and no ledger entry, which is
the half of that pair with no symptom: the exception is a claim that the file is ours to publish, and
the ledger is where that claim is backed. Tests/test_asset_provenance.js checks both halves precisely
because a missing ignore rule or a missing entry fails nothing at the time it lands — this one was
found on the next session's merge, a day later.

The entry is written from what the file says rather than from what the commit message says, the way the
Haunted Village Square entry beside it was. The file carries a signed C2PA manifest: a c2pa.created
action with digitalSourceType trainedAlgorithmicMedia, a com.suno.provenance assertion naming Suno,
Inc., chirp-hawk-t1 and a content id with a creation timestamp, and a certificate chain reading Suno
Inc / Suno Content Credentials under the Suno C2PA Root CA. The commit message agrees with it, which is
the situation the manifest readers exist for.

Two limits are stated in the entry rather than left to be assumed, because an entry that overclaims is
worse than the UNKNOWN it replaces. The manifest's assertions were read; its signature was not
cryptographically verified, no verifier having been run against the chain. And the track has not been
listened to — nothing here plays audio — so what is recorded is provenance and not what it sounds like.
The paid-plan statement the sibling entry holds was made about that track on 13 Sep 2026 and is
deliberately not read across to this one.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

# Conflicts:
#	Handbook/dungeon-masters-guide.html
#	guide.html

A pin placed in the Map Pins dialog was, until now, visible only in that dialog. The card showed a
count on a button, the room the pin names said nothing about belonging to a quarter, and the player
whose map it describes had no way to look at it at all. That is a feature only the person who
authored it can check, against a memory of what they meant, which is the shape of a thing that
quietly stops being true.

So the markers are now drawn in three places and the membership is read in three, and every marker
comes from one renderer. Three copies of "a dot under a name at a percentage" is three chances for a
pin to mean something slightly different depending on where it is looked at, and the whole point of
placing one is that it is read somewhere else. That renderer also refuses to draw a pin whose room
has left the district or left the world, independently of the prune: it is reached from renders a
prune has not run through, and a labelled dot for a place that is not there is the one thing a map
must never show.

The card's map moved into a stage that shrink-wraps a block image rather than staying in the Regions
tab's full-width `.region-map-img`. That one is `width: 100%` with `object-fit: contain`, so its
element box is the panel's and the picture inside it is letterboxed; a fraction measured against it
drifts by the thickness of the bars, and only on maps whose aspect differs from the panel's, which
reads as a rendering glitch rather than as arithmetic. The player's viewport cannot use that trick —
its stage is the whole panel and the image really is centred inside it — so there the pin layer is
sized to the picture by hand from the image's own layout offsets, in layout offsets rather than
client rectangles so the stage's pan/zoom transform scales the layer with the map instead of having
to be divided back out of every number. It is sized again on the image's `load`, because an image
mounted for the first time has no box when the render that mounted it returns, and a layer sized
against zero puts every pin in the corner.

The room-side readings are read-only and plural. The district owns its `rooms` list and is the only
writer; a picker on the room card would be a second writer onto one relationship, racing to decide
which one meant it. Plural because nothing stops a DM filing a room under two quarters and there are
worlds where that is right — a gatehouse that belongs to the wall and to the dock ward at once — and
answering with the first match would draw a chip that is true and incomplete, which is the harder
kind of wrong to notice.

The player's District subtab is offered only while they are standing in a quarter, unlike Region,
which is unconditional because every finished room has one. Nothing about it asks whether a room was
visited: the world map earns its fog one room at a time because the party assembles it by walking,
but a district map is a single authored picture, and fogging parts of an illustration would mean
cutting it up.

Tests/test_district_room_links.js pins all of it, including the two measurements, and was written
against eighteen sabotages. Two of its own assertions were rewritten after that pass — an ordering
check that read `indexOf(Region) === -1 || ...` on a test room that carried no region, so it passed
whatever the order was, and a section that crashed rather than reporting when the renderer it breaks
threw. test_room_lore_editor's card-order assertion was anchored on `${containSection}`, a neighbour
it never meant to pin, and now runs from Meta.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The DM's checkbox was the only road into Compendium > History: a beat was published or it was not,
decided at authoring time, and a soldier could recount the siege at length while the player's tab
went on saying nothing. Now an account given aloud files the event. The GM sets `loreUnlock` to {
kind: "event", name }, the engine writes the beat into the player's Compendium and posts a line
they can click, and the publication flag becomes a record of what they have been TOLD rather than
only of what the DM decided in advance.

The half that needed the work is keeping it from becoming a reward. Every other kind `loreUnlock`
carries is one — a hook with a condition, a tale prised out of somebody who was not going to
volunteer it, each paying XP — and the tale rule sits one paragraph above this one in the same
prompt. A historical event was never a secret: the player asked an ordinary question and got an
answer anybody in the realm could have given. So this unlock has no condition, is never withheld,
and pays nothing, and that is said in three places a model will actually be reading: rule 13g, the
response contract's own line, and the dossier's per-event marker. The marker's wording is
load-bearing in the same way. An event the player does not yet have is "NOT IN THEIR HISTORY YET
(which is bookkeeping, not secrecy)", never "not yet heard" — the second phrasing is what turns a
public fact into a withheld one in a model's hands, and it is exactly what the Folklore section
directly above says and means.

The pairing from the last change is what gates it. `historyBeatFromHere` resolves a title only
from an NPC in THIS room who carries that event, the same guard `folkloreTaleFromHere` applies for
the same reason: without it a model that remembered a war from an earlier scene could file it in a
room where nobody was there, and the History tab would fill with chronicle the player was never
told.

Both roads to the flag now leave through one writer, `setHistoryPublished`, which is the lesson
the folklore twin already paid for — two roads into the player's Compendium that each write the
flag are two roads free to come to behave differently. It also reports whether anything actually
moved, which is how the GM path tells "I published this" from "they already had it" without
reading the record twice, and it redraws the player's History tab when that tab is the one in
front of them: the GM path writes the flag mid-turn with nothing else about to re-render, so
without it the story pane says the event was recorded and the open tab does not show it.

The authoring roster still may not set the flag, and the distinction is worth keeping sharp rather
than looking like an inconsistency: writing world data is not telling anybody anything. There is
no player in that exchange and nothing has been said aloud, so `applyHistoryChunk` goes on taking
the flag from the existing record and from nowhere in the reply. Designs/world-history.html
section 08 decision B stays settled for the sharper reason this change gives it — what reopening
it would mean is GATING, a beat somebody must earn the right to be told, which the engine already
does three ways under the name lore hook. Decision A is now partly answered too: the dossier
carries the beats the people in this room are paired with, which is relevance-scoping by
authorship rather than by retrieval.

Two playtesting notes went in ahead of the rest, because they are what a desk cannot settle here.
Does the model treat a told event as a reward despite being told four times that it is not —
withholding, gating, or over-firing on a passing mention? And does an account actually come from
where the person stood, or does it come back as a paraphrase of the dossier with a name attached?

One defect the suite found rather than a reviewer, and it was a test's rather than the code's:
test_lore_unlock_why.js read the loreUnlock contract as `slice(0, 2200)`, which is a claim about
the paragraph's LENGTH, so a sentence added early in it pushed the counted-conditions clause past
the window and failed an assertion about text that had not moved. The contract is one line per
field, so it now reads to the end of the line.

Eighteen sabotages of this change were each caught by a distinct named assertion, and two of the
new assertions were rewritten after surviving the break they were written for: a checkbox that
sets the field itself instead of delegating still gets the VALUE right and only drops the redraw,
so the assertion had to exercise the DM's road with the tab open; and "the contract says this is
not a reward" was an OR that the sentence after the one under test satisfied.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

# Conflicts:
#	Handbook/dungeon-masters-guide.html

Map Pins sits left of Regenerate on a district card, disabled until there is a map to pin onto, and
opens the picture at one side with the district's rooms at the other. Click a room, then click the map.
The marker carries the room's name above a dot, and clicking a room that already has one re-arms it —
which is how a pin is moved. Two clicks rather than a drag, deliberately: a drag needs the pin to exist
before it can be moved, which leaves no gesture at all for placing the first one.

Two pieces of geometry decide whether this works, and both are the kind that fail quietly. Pins are
stored as FRACTIONS of the image rather than pixels, because the same map is drawn at more than one size
and a pixel measured against one of them is wrong in the other. And the click is measured against the
stage, which is an inline-block wrapped around a block image, so the rectangle it reports IS the
picture's. Measuring against a letterboxed container instead is the classic version of this bug: every
pin drifts by the height of the bars, and only on maps whose aspect differs from the panel's, which
reads as a rendering glitch rather than as arithmetic.

A pin is not the room's position in the world and cannot be — a district map has no directionality and
the design doc spends a section on why. The illustrator arranges the places; the pins record where they
ended up, which is also why they are placed by hand and never generated.

The rule that took the most thought runs BACKWARDS from the one beside it. A pin exists only while its
room is filed under this district AND the world still has it; a dangling room id, one field up, is kept
and shown as missing. Those look inconsistent and are not. A dangling id is recoverable information — it
names a room that was deleted, the card shows it, and restoring the room restores the meaning — while a
dangling pin is a dot on a picture labelled with the name of something that is not there: it cannot be
acted on, it cannot be told from a real pin at a glance, and it silently claims the map shows a place it
does not.

Pruned by derivation rather than by hooking the paths that can orphan one. A room leaves a district
through the card's picker, through a GM edit that returns a whole new list, through an import, and
through being deleted somewhere else in the app entirely — and a prune that has to be remembered at each
of those is a prune that will be forgotten at the next one. So the question is asked instead, at every
write and on every render: is this pin's room still filed here, and does the world still have it? The
render path deliberately does not save; the next save carries it, and writing to disk from inside a
render is a habit worth not starting.

Nine sabotages, each caught by a distinct assertion, including both halves of the pruning rule
separately and the two geometry decisions. The test drives the real click handler against a controlled
rectangle rather than asserting markup — and the first version of it was wrong about where the centre of
that rectangle was, which the implementation correctly disagreed with. One assertion was removed rather
than fixed: it carried an `|| true` and could not fail.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Two halves of the same gap. The chronicle shipped yesterday with nothing reading it in play: the
Game Master narrating a conversation about the old war was working from whatever it could infer,
and the player's Compendium tab showed every beat a DM had ever written, whether or not they meant
it read.

An NPC card now carries a History field directly beneath its Folklore one — the same three
controls in the same order, because a DM who has learned one field has learned both. It stores ids
into world.history, a dangling id is kept and marked, and it is an NPC field for the reason the
folklore twin gives: the point of it is conversation and a monster has none. A per-turn dossier
then tells the model which of the people standing HERE can speak to which event, and what happened
in each. What the pairing buys is standing, not permission. Everyone in the realm knows of the
siege — that is what makes it history rather than a secret — and the list says who was AT it, so
the soldier who was inside the walls tells you about the ninth day while the miller tells you what
it did to the price of bread. Rule 13g governs it and spends most of its length on the one thing
that would quietly break the feature: the section sits directly under Folklore, which tells the
model to hide its contents until earned, and a model handed two adjacent lists will apply the
stricter rule to both unless stopped. So 13g says in as many words that nothing here is secret,
that there is no unlock to set and no XP to pay, and that unrecorded history is not the model's to
invent at the table.

Two differences from the folklore field are deliberate. The picker is flat and in chronicle order
where folklore's is grouped by kind — folklore has four kinds and a flat list of forty titles is
unreadable, while history has one kind and an order that is already the meaningful grouping — and
every chip and option carries its date, because a title alone does not say whether this person
lived through the thing or is repeating their grandmother.

The second half is the DM's publication switch. Every beat carries an `unlocked` flag with an
"Unlocked for the player" checkbox, off by default, and only the ticked ones reach Compendium >
History. It is publication and not discovery, which is the distinction the whole thing rests on:
Folklore carries an identically-named, identically-labelled box that a player EARNS by drawing the
tale out of somebody and is paid XP for, while a historical event is earned from nobody because
everyone already knows it. So this one has no XP box beside it and nothing in play ever ticks it.
The label is shared on purpose and the tooltip is where the difference is said.
Designs/world-history.html section 08 decision B stays settled — a beat is still not discoverable
— and the doc now says what reopening it would actually mean, which is the GM unlocking one when
an NPC tells it: a second premise for the tab rather than a field on a beat.

The Game Master may not publish. The directive says so and applyHistoryChunk enforces it, taking
the flag from the existing record and from nowhere in the reply, in both directions — a model
asked to "add the siege the player heard about" will helpfully return unlocked:true, and the beat
would land in the player's Compendium without the DM ever seeing the box. An export the DM made
themselves is their own data and does round-trip the flag; dropped there, reimporting a chronicle
would un-publish the whole tab with nothing reporting it.

Two consequences for the tab I shipped yesterday. Reveal all works on it now and is no longer
hidden — there IS an unpublished half to reveal, dimmed and badged, exactly as on every other
subtab — so that special case is gone. And it grew a third empty state: a world with no chronicle
at all and a chronicle none of which has been published are different facts, and "no chronicle
survives for this realm" is a flat lie about a world with forty events in it.

Two defects the checking found rather than a reviewer. The publish row was first written as a
.history-entry-row, which styles its direct-child label as an uppercase field caption and gives
every input inside it width 100% — so the checkbox drew as a full-width gold bar with its words
wrapped into a caption beside it, two rules meant for text fields applied to a checkbox. And rule
13g's example named Ashfen, which test_prompt_no_builtin_leak.js exists to catch: a proper noun
from the built-in world hard-coded into the rulebook reaches every world the engine ever runs.

Twenty-eight sabotages were each caught by a distinct named assertion. Two of the new assertions
were themselves rewritten after surviving the break they were written for: "the picker is in
chronicle order" passed against a build that did no sorting, because the test seeded its events in
chronological order, and "a monster contributes nothing to the dossier" passed against a build
with no NPC gate, because the monster it used happened to be standing in a different room and the
room gate excluded it first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Under every one of a room's music prompts is an Upload Music button. Nothing in this app composes a
score, so where the Sounds prompts carry Generate Audio, Music carries the other way a track gets
here: the prompt above it is what a DM feeds to a music model somewhere else, and this is where what
comes back lands.

It opens the Add-a-Sound dialog. Not a copy of it - the same one, retitled "Add Music", because the
alternative was a second set of those four fields to drift from the first. What the room door adds is
what happens on Add: the file goes to the vault, the entry lands on Art > Audio, and the room's Music
picker is set to it. The Art door is unchanged and still synchronous to the end, so every existing
caller that does not await it still sees the world mutated by the time it returns.

AREA IS KEPT RATHER THAN DEMANDED, and this is the decision the feature turns on. A room's Music
picker lists Area sounds and nothing else, so a track added without that type would land on the Art
tab correctly and then be missing from the very picker the DM opened the dialog to fill - a record
created, a room set to an id its own select does not list, and the select falling back to "None".
Refusing would be refusing over a field they had no reason to think mattered; they opened this from a
room's Music section, so "this is the room's music" is the whole of what they said. The hint on the
Type label states the addition before it happens rather than explaining it after.

WHERE THE BYTES GO follows the split the rest of the app already makes. A music track is the largest
thing a DM uploads here - minutes of audio rather than a picture - and a data: URI is rewritten into
the save on every write of it thereafter, which is what the 441 MB file this codebase measured looks
like. So with the vault's media store reachable the bytes are POSTed there as raw bytes (base64 in a
JSON body inflates by a third and would meet the vault's ceiling) and the world keeps the short
/vault/media/ path; in Direct mode there is nowhere to put them and the data: URI is kept, which is
the existing behaviour and the only one that can work. An upload that fails falls back to embedding
and says so, because a DM who picked a file and pressed Add should end with a working track or an
explanation, never with neither.

That third state is why the sound card's embed note grew one: "embedded - saved with the world" was
about to be false for exactly the tracks most worth knowing about.

Six sabotages, each caught by a distinct named assertion - the button gone, the room never bound, Area
not kept, the upload skipped, the binding not cleared, and the failed-upload fallback dropped. The
fifth is the leak worth naming: a room binding left behind by a cancelled or completed Add Music would
quietly make every later sound added from the Art tab that room's music, so it is cleared on open and
again on close, and the test opens the Art door straight after a room add and after a cancel.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Filed yesterday, the mixed-case entry rested on a session having looked at three images and disagreed
with what it had been told about them. That is a real basis and it is the weakest kind in this ledger:
a judgement about pixels, made by the party with the least standing to make it.

Put back to the owner the same day and confirmed — shown the reading, they agreed the three are
screenshots of generated art. So the classification is the owner's own statement, corrected by them
once the files had actually been looked at, which is the strongest basis here short of a signed
manifest. The entry says so, and says it in a way that distinguishes these three from the rows that
rest on a statement nobody has checked against the bytes, because that distinction is the whole reason
`authorshipBasis` is a sentence rather than a flag.

Nothing else moves. The paths, the origin, the authorship and both outstanding questions are as filed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

By Card / By Portrait was built for Races. It belongs on every editor tab whose cards carry a picture,
for the reason it was wanted on that one: a column of tall cards answers "what is this record" well and
"what does this world have" badly, two cards rarely fitting on screen at once. Twenty-one surfaces have
it now — Items, Flora, Magic items, Spellbooks, NPCs, Monsters, Fauna, Rooms, Classes, Skills, Spells,
Concoctions, Reagents, Ailments, Biomes, Dungeons, Races, Factions, Religions, Heraldry and Folklore. The
Art tab is left alone: it is already a gallery grouped by kind, which is the thing this adds.

IT IS ONE REGISTRY, NOT TWENTY-ONE COPIES, and that is the whole shape of the change. PORTRAIT_VIEW_SURFACES
holds a row per surface saying only what cannot be derived — where its cards go, what to call its records,
how to reach one record's picture, name and id, how to draw one record's card, how to find one by id, and
how to redraw its tab. Everything else is written once: the persisted setting, the two toolbar buttons, the
gallery, the dialog. The house rule that a roster must be interpolated rather than hand-copied applies to
the list of SURFACES as much as to a list of equipment slots, and Tests/test_editor_view_modes.js walks the
registry rather than a list of its own, so a surface added there is tested by the act of adding it. The
rows deliberately do NOT say how to build their list: the renderer already has it, filtered, and passes it
in, so the gallery and the cards can never disagree about what is on screen.

Two things let one dialog serve twenty-one card builders. The first is that every editor card is
`<details class="npc-card" data-…-id>` with a `<summary class="npc-card-head">` by construction, so the
frame and the summary are dropped in CSS and the card is forced open through the DOM — threading a `bare`
option through twenty-one builders would have been twenty-one edits and twenty-one chances to miss one,
and the option Races grew for its own dialog is removed again here. The summary is HIDDEN rather than
removed for the reason the first version of that dialog recorded: a <details> with no <summary> child
draws the browser's own marker, the literal word "Details", above the portrait. The second is that the
three entity tabs have no per-record builder at all — renderEntityCards draws a LIST — so they draw
through it with a list of one, which is exactly what its viewId argument already allowed. That viewId now
also routes a being's room link to a popup inside the dialog; without it the link would open the NPCs
tab's popup, behind the dialog and out of sight.

Three defects were found by the test walking the registry rather than by review. FOUR RENDERERS SYNCED
THEIR TOGGLE ONLY ON THE PATH THAT DREW CARDS — Biomes, Folklore, Heraldry and Religions return early on
an empty roster, so those tabs drew a toggle that did not follow the mode and a Collapse/Expand pair that
stayed put. The sync is hoisted above every early return now, in all twenty-one. SEVERAL FINDERS ANSWER
WITH A RECORD THAT DOES NOT KNOW ITS OWN ID: a roster function returns `{ id, ...def }` while the finder
beside it returns `world.races[id]`, the raw map entry, which has every field except the one it was looked
up by — and a card built from that drew `racelangadd-undefined` into every control it emitted. It is
stamped on centrally now, keeping the record's prototype the way reInstance does, because a being is a
class instance whose card calls its methods. AND THREE ROSTERS ARE `Object.values`, which drops the map
key that is the id: a record without an `id` field of its own — hand-written world data, an older export —
was listed under its name and then not findable by it, so the name was a link that did nothing. The key is
resolved by identity now, never by name, since two tales may share a title.

The test is a rewrite of the Races one, renamed and turned into loops over the registry: 643 assertions
across every surface. Its sharpest section is the one that proves a renderer actually SWAPS — a row can be
registered, have both buttons and a working setting, and still leave its renderer drawing cards, with the
toggle moving and the tab standing still, and nothing else in the file would notice. Nine sabotages, each
caught by the assertion written for it; the first pass of that swap assertion was not there and a surface
silently losing its gallery line passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

World History shipped yesterday with only the DM's half: Editor > World > Culture > History
authors the record, and nothing anywhere showed it to the person playing. This adds Compendium >
History, the same timeline read-only — the same historyInOrder / historyDateLabel /
historyPeopleFor readers, the same .journal-entry furniture, minus everything an editor needs.
Nothing opens, nothing is typed into, nothing is removed.

The part worth stating is that this tab does not work like the ten beside it. Every other
Compendium subtab is a record of what the player has FOUND, and is empty until play fills it. This
one shows every beat from the first turn, which is Designs/world-history.html section 07 decision
B applied rather than a shortcut: a historical event is not the sort of thing a character
discovers, it is what the realm agrees happened, and an ordinary person in it knows the last war
the way anyone knows their own century. Folklore is the tab-mate that works the other way round
and carries `unlocked` for exactly that reason. The decision is marked settled in the design doc
now, because it has been built on rather than merely argued: reopening it later would not be a
field added to a beat, it would be a second premise for the tab. Two consequences follow and are
deliberate — no card is ever drawn dimmed or badged Undiscovered, and the DM's "Reveal all" is
hidden on this tab alone, since a control that visibly does nothing is worse than no control. It
is hidden by DRAWING and only for a DM: writing a display onto that button for a plain player
would be a render handing back an authoring affordance applyDMVisibility had just taken away,
which is the DM gate undone from the other side.

One rule is inverted between the two views on purpose. A person the world no longer has is kept
and flagged with a dashed chip on the editor's card and is simply left off the player's. The two
readers want opposite things from the same broken reference: a DM has to see that somebody was
named and can no longer be found, because only they can restore or repoint it, while a player can
do nothing with it and what they would be shown is the raw id — not a name, not in their world,
and the internals showing through. The reference stays on the record either way; only the drawing
differs, and the test asserts both halves so a later tidy-up cannot turn the card's filter into a
prune of the data.

Two smaller things the build forced. The editor's timeline container was styled by id, and a
second element answering to #history-timeline is a duplicate id — the kind that makes
getElementById pick whichever the parser reached first, silently and only for a DM, who is the one
person with both views in the document. The styling moved to a .history-timeline class that both
wear, and the compendium's cards are keyed compendium-history-<id> rather than the editor's
history-entry-<id>; a test compares the two views' id sets and fails on any overlap. And the
shared Compendium filter searches the same text the editor's does — title, date, people and body —
rather than the title alone the name-filtered subtabs use, because a beat's title is a headline
and the word a player remembers is out of the account beneath it.

Eighteen sabotages of the implementation were each caught by a distinct named assertion, among
them the two that motivated the assertions in the first place: gating the tab on a discovery set
(which leaves it permanently empty, since nothing ever writes a history discovery) and reusing the
editor's element ids.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Editor > Rooms > Prompts > Audio > Music gains a GENERAL prompt above its six times: the score that
plays while a player is here, whatever the hour. The six slots answer "what does dawn sound like in
this room" and this answers "what does this room sound like", which is the question a DM has an answer
to first and the only one that has an answer before the clock is involved. It is the slot to fill when
a room should have a sound at all; the six are for a room that genuinely sounds different at dawn than
at midnight.

Its GM directive is deliberately not the time prompts' directive with the hour removed. It asks for
instrumentation, mood and tempo taken from the ROOM - its name and its description - and from the
world's TONE and PREMISE, and it says to describe the music rather than the room. The world framing is
restated in the directive even though buildSystemPromptBlocks already carries the world behind it, for
the same reason the six time prompts restate the room they are about: what a directive names is what a
model writes from, and a score for "a tavern" is the same score in every world that has one. It also
gets no time-of-day mood clause, which is the one way this field could look wired and be pointless - a
seventh dawn prompt wearing a different label.

One function still serves both, because everything after the directive is identical (the call, the JSON
shape, the salvage, the write-back into the open textarea, the button states) and a copy beside it would
be a second place for any of that to drift. What the general case swaps is the three things that differ.

The key travels in a declared roster rather than being written onto the record by the card.
normalizeRoomAudioPrompts rebuilds each category from NAMED keys and runs at build AND at restore, so a
key it does not list is not merely un-normalized, it is gone on the next reload with the card still
showing it all session. The roster is per category and Sounds gets nothing: an ambient soundscape with
no time attached is one the engine has no moment to play, where a mood score is exactly what an Area
track is.

Five sabotages, four of which are caught by a named assertion. The fifth is recorded rather than
claimed: removing the isGeneral guard on the mood clause changes nothing today, because
buildBannerPromptForTime already answers empty for a key outside its six - so the guard is
belt-and-braces and the assertion over the directive cannot fail. Rather than leave a check that is
evidence for something it never proved, the second reason is pinned directly: the lighting table is
asserted to have no general entry, and if one is ever added THAT fails and names the guard as having
become load-bearing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Reported from the app: the tab had no button row. Every markup assertion in its test passed while it was
broken, and each of them was right to — the toolbar was in the DOM the whole time, complete, with its
filter and all six buttons. What was missing was one CSS selector.

The shared rule makes every roster toolbar `position: absolute`, and an absolutely positioned element
anchors to its nearest POSITIONED ancestor. #world-inner-factions and #world-inner-weather each carry a
`position: relative` of their own for exactly that reason, with a comment saying so. Districts did not,
so its toolbar walked past the panel to .world-inner and pinned itself at the top of the whole inner
frame — outside the tab, behind the chrome, drawn but nowhere useful.

The lesson is about the test rather than the stylesheet. Asserting that markup EXISTS is a static check
that cannot fail for a layout bug, which is the "passes for the wrong reason" shape this repo keeps
paying for, and it was sitting in a test whose other assertions were carefully adversarial. The new one
is written as an INVARIANT over every World panel rather than a line about districts: for each panel
whose toolbar is named in the absolute rule, that panel must appear in a rule that positions it. It
fails if districts loses its anchor and it fails if FACTIONS loses one, because the next tab to copy
this panel will copy the markup and not the stylesheet — which is precisely what happened here.

Designs/districts.html is the write-up, with a row in Designs/README.md. Its argument is §1: this is not
a second kind of region, and everything else follows from that. A region is drawn and makes a claim
about where things are; a district is a name for part of a place and makes none. That decides the room
relationship (ids on the district, because a room sits in one region but a market on a boundary belongs
to both quarters that argue over it), it decides the map (names, no directions, because a district's
rooms are a set and several commonly do not connect to each other at all), and it decides all seven open
decisions. The one worth reading is whether districts reach the Game Master at all, where the leaning is
a live line keyed off the current room rather than a roster in the cached half — and the one worth
acting on is that map images as a class sit outside Editor › Art, region maps included, so the fix is a
Maps group rather than a districts-shaped patch.

§6 is its playtesting notes, per the house rule that a doc whose system is built ends with one. The
failure to watch for is a "+ Add" that invents a second region rather than a quarter: the directive asks
for a named part of a region and nothing enforces it, so the test is to press it six times and read only
the names back.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The brief for a login behind the landing page assumed a server-side component to hold the Auth0
client secret, and the first thing this design does is remove that premise. An Auth0 Single Page
Application authenticates with Token Endpoint Authentication Method: None -- it presents no client
secret at any point, including on refresh -- so PKCE does the secret's job per request and there is
nothing to protect. That is the same reasoning native-app-login.html applies to the vault's Native
application, and it lands the same way here: the intuitive broker, a Lambda that holds a secret and
completes the flow on the page's behalf, is not a safer version of the flow but a second
authentication protocol written by us, whose bugs are authentication bypasses rather than broken
features.

What actually decides whether a backend exists is not the login at all but what the login unlocks,
so section 04 is a table of candidate jobs against whether each one needs a credential a browser
must not hold. Identity-only needs nothing. A signup record, a profile write, a genuinely protected
artefact all do. Where one is needed the document constrains its shape hard: the Lambda is a
resource server that verifies an audience-scoped access token and never the id_token, preferably
behind an API Gateway HTTP API JWT authorizer so the verification is not code we wrote, and never a
login broker with a callback of its own.

Three things came out of reading the page rather than reasoning about the protocol, and they are the
parts a later session would otherwise rediscover. The landing page is a generated dc-runtime
template, so authentication logic written into its script block is destroyed silently by the next
export -- the page still renders, still animates, and the button does nothing -- which is why the
design puts everything in a hand-owned auth.js and reduces the template's contribution to two lines
a test can pin. The custom domain is load-bearing rather than branding: silent re-authentication
runs in an iframe answered by the tenant's own cookie, which is a third-party cookie under ITP and
Chromium's restrictions unless the tenant and the site share a registrable domain, so
auth.thelostrealms.com plus cacheLocation memory is a combination and not a choice, and Allowed Web
Origins is the setting whose absence signs every visitor out on reload. And with two Auth0 issuers
in the project, every verifier must pin its own by exact string, because a token from the wrong
tenant verifies perfectly at every step and the failure has no symptom.

Section 12 takes the second tenant seriously rather than treating it as given. The argument for it
is blast radius: the vault tenant's accounts are the authority for who may administer a third
party's installed vault, and a public sign-up form on a marketing page must not be a door into that
population. The cost is that the same human becomes two accounts, and the tempting join -- matching
on email -- is exactly the trust dependency native-app-login.html section 12 warns about. Federation
via an OIDC enterprise connection is the answer if that ever has to change.

Recorded as proposed, not built: two decisions settled by the brief, six open with leanings, five
phases where phase two is a complete shippable login with no infrastructure behind it. PRIVACY.md is
named as part of the change rather than as follow-up work, because a landing page that collects
nothing today starts holding an identity the day this ships.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016WFBV2vxcapvHASbMC5gyf

The three square-* scenes and the three heraldry-* files arrived unattributed in the owner's own
Heraldry section and Time of day carousel commits, and test_asset_provenance had been red on main
since. The owner states all six were generated with Nano Banana. Looking at them says that is true of
three and half true of the other three, so they are filed as two entries rather than one.

The squares are what they were said to be: 1025x447 painted scenes of one village square — the
fountain, the gate arch, the WANTED board, the halberdier — under three different skies, with no
application chrome anywhere in frame. Illustration rather than capture, which is what a time-of-day
carousel wants and what the statement describes.

The heraldry files are SCREENSHOTS. Each is a 2560x1440 capture of the game in a Chrome app window
with the title bar, the tab strip, the Editor's Culture and Heraldry tabs, the character panel and
the sidebar all in shot, and a lightbox in the middle holding one generated heraldic painting. The
owner's statement is about that painting and is correct about it; it is not the whole of the file. So
they take the shape the dungeon-catacombs.gif entry already established for this exact situation — a
mixed case, filed as one, with an explicit instruction not to inherit the sentence the plain
screenshot groups carry, because "a screenshot of one's own software is authored work and the doubt
over generated images does not reach it" is only half true when the generated painting is the largest
thing in the frame.

What the files say about themselves is HANDLING and not origin, which is why the inventory went on
calling all six UNKNOWN. Each carries a C2PA manifest whose action is com.anthropic.claude.provided
with com.anthropic.origin-confidence "unknown" and Anthropic as the claim generator: a record of the
file having passed through Claude on its way here, making no claim about what produced the pixels. No
SynthID note and no Google marker is present in any of them, so nothing in the bytes corroborates the
tool named, and both entries say so rather than letting a signature-shaped thing stand in for one.

Neither entry says anything about what Nano Banana's terms grant. That is one outstanding question
across this ledger and not three — the dungeon-catacombs.gif entry already names it — and the Suno
entry above records at length what happens when a session writes its recollection of a third party's
terms into a provenance file as though it were a finding.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

By Card and By Portrait shipped as a tab strip at the foot of the Races panel, wearing the same dress as
the Environment, Entities and Magic strips. That was the wrong affordance and the codebase said so before
anybody did: those strips belong to inner-tab FAMILIES, and a family is a set of panels — joining one
without any made Tests/test_items_inner_tabs.js fail, and the way round it was to widen that test's roll
until a member could have a strip and no panels. A test widened to admit the thing it was written to
refuse is a test doing less work than it did yesterday, and the reason it had to be widened was that
Races is not an inner-tab family at all.

It is the same control the Character › Inventory pack carries — By Type / By Item — so it is now that
control, in the tab's own toolbar: two .npc-tool-btn in a .npc-tool-group, the pressed one held gold by
.npc-tool-btn.active, and the mode a PERSISTED setting read back through a function rather than a module
variable. That last part is the Inventory's own shape rather than a flourish: there is no boot step to
wire up and therefore none to forget, and a stored value that has been corrupted falls back to By Card on
every read instead of sticking. The choice surviving a reload is the point of a preference about how a DM
reads a tab.

The toggle sits BEFORE Collapse all / Expand all rather than after, because that pair is hidden in By
Portrait mode — there being no cards on screen to collapse — and a toggle to its right would slide out
from under the pointer on the very click that hid them.

Everything the strip was switching between is unchanged: the gallery, the card dialog, buildRaceCard's
three dialog options, and the .race-card-box joins into the Item Card dialog's rules. What is backed out
is the strip itself, the four shared inner-tab selector lists it had joined, and the widening of
test_items_inner_tabs.js, which is restored to what it said before — every inner-tab family named in all
six rules of the look, no exceptions.

Tests/test_race_portraits_mode.js becomes test_race_view_modes.js, named for the thing rather than for one
of its two modes. Its §1 and §9 are rewritten around the toggle: that a browser which has never been here
opens By Card, that pressing either button sets the mode AND holds that button while releasing the other
(the buttons carry no state of their own, so a renderer that stops syncing them leaves the pair claiming
the wrong mode — which is how the Spells scope toggle once shipped), that the choice is written to the
settings and read back out of them rather than cached beside them, and that the toolbar's two buttons are
wired, labelled and declared ahead of the group they hide. §9 also asserts the absence: Races draws no
inner-tab strip, which is the shape this commit is restoring. Seven sabotages, six caught by the assertion
that names them; the seventh — storing an uncoerced mode — turns out not to be a defect, since the reader
normalizes on every read, and it is left unpinned rather than given an assertion about tidiness.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Editor › Races listed one tall editable card per race and nothing else, which answers "what is this
people" well and "which peoples does this world have" badly: two cards rarely fit on screen at once, so
the shape of a world's population could only be got by scrolling. It now draws that roster two ways.
Cards is what it has always been and remains the default, because it is where every field is edited.
Portraits is the gallery — a cropped square per race with its name beneath — and clicking a name opens
that race's card in a dialog of nearly the whole window.

The two are a view MODE rather than a pair of inner panels, and that is the decision the rest follows
from. Flora/Fauna and NPCs/Monsters are two rosters and get a panel each, with a toolbar each; these are
two drawings of one roster, so the tab keeps a single toolbar, a single #races-view and a single GM
request row, and only what goes into the view changes. Two panels would have meant two filter boxes, and
a name typed into one of them that the other did not honour. The strip that switches them is the same bar
at the foot of the panel the Environment, Entities and Magic tabs carry, joined into those rules rather
than given a copy, because a reader who has learned that such a bar changes what the panel shows has
learned it here too. Collapse all and Expand all go away in Portraits mode, there being no cards on
screen to collapse.

The gallery is the Art tab's own cell — .art-gallery-grid, -img, -ph and -caption already draw a square
crop with a caption under it and a dashed placeholder for a subject nobody has painted yet, and a second
set of rules for that shape is a second set to keep in step with it. Only the track size differs: the Art
tab bottoms out at 84px because it is an inventory of every picture in the world, and this page is a
handful of peoples whose faces are the point, so it takes the dungeon tile grid's 150px. Every one of
those overrides is compound, and that is load-bearing — the .art-gallery-* rules are declared some six
thousand lines further down the stylesheet, so a lone .race-gallery-* rule ties on specificity and loses
on ORDER. It shipped that way first: tiles that asked for 150px drew at 84px, in a rule that read exactly
right. The cell's two halves lead different places, which is why it is not the Art tab's single wrapping
button: the picture enlarges through the lightbox the card's own portrait opens, and the name opens the
card. Of the two it is the card — where every field is edited — that must not be reachable by mis-clicking
a face.

The dialog is the Item Card dialog throughout, down to the class its box wears, and its markup records
what the two share and the one thing they do not: #item-card-modal draws no backdrop tint because it only
ever opens over another dialog already dimming the app, while this one opens straight off the editor and
wants the ordinary tint and the ordinary z-index, which leaves the ability editor, the big-prompt box, the
confirm dialog and the lightboxes above it. It draws through buildRaceCard, the same function the tab
uses, rather than a second renderer that would show a race with the newest half of it missing.
buildRaceCard gains the three options buildItemCard already takes, by the same names, each answering a way
a second copy of a card in one document goes wrong: `bare` (a <div>, not a summary-less <details>, which
draws the browser's own "Details" marker — it did, above the portrait), `open`, and `idPrefix`. The prefix
is not hypothetical: the Art tab draws a race card for any race with no portrait yet, so with the dialog
open on that race the document holds two copies of a card that emits an element id, and getElementById
answers with whichever is earlier. Every control on a race card ends in renderRaces(), so that is the one
place that keeps an open dialog in step with the edit that redrew the tab, and a race deleted underneath
the dialog — or the DM switching back to Cards — closes it.

Tests/test_race_portraits_mode.js is new. Its §8 is the piece worth reading: it decides which CSS rules
contend from the MARKUP rather than from how a selector is spelled, because the first version looked for
race rules whose selector also named an art-gallery class — which is the fix, not the property, so
un-compounding a selector made the section stop examining the rule that had just broken, and it passed.
It then asks not whether one rule outranks another but which declaration the cascade would choose on each
element, since a race rule may lose to an art rule and the page still be right when a third, more specific
race rule is the one that lands. The staleness guard went the same way: asserting that the dialog's HTML
mentioned the added language passed against an implementation that never refreshed the dialog, the word
already being there as an option in the select, so what is asserted now is the tongue moving out of the
options and into a chip.

Two existing tests move with it. test_item_card_dialog.js read its rules by exact selector text and so
found them only while one dialog wore them — six assertions went from pinning a declaration to reporting
"no such rule" the moment a second surface joined, exactly as the house rule prescribes; its cssRule now
matches a selector as a MEMBER of the rule's list. And test_items_inner_tabs.js required every inner-tab
family to be named in all six rules of the look, which Races breaks by having a strip and no panels. That
roll is now split: all four strip rules always, and the panel pair both or neither — half-joined, the
failure that section was written for, still fails whichever half is missing — and a member in neither must
draw no panels in the markup either, so the clause cannot become cover for the original defect. Both were
re-sabotaged afterwards and still bite.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

# Conflicts:
#	Designs/README.md

Editor › Magic › Spellbooks had a name box and nothing else, so a Tongue filter there meant giving that
tab the funnel — one entry in ITEM_FACET_SURFACES, and three things that were not free.

The surface offers no Type group. Every item on that tab is type "spellbook" by construction, because
catalogItemsForEditor filters on exactly that, so the group could only ever answer one thing;
buildItemFacetMenu would drop it on sight, and naming it would be asking a question whose answer is
known. It keeps Equipment slot, which is the one worth having beside Tongue: a FIELD spellbook resolves
to the Spellbook slot and a reference tome to none, so the group separates the books a caster can
carry from the ones that sit on a shelf.

renderItemKind asked `kind === 'items'`. That was right while one tab had a funnel and silently wrong
the moment a second did — the menu would tick its boxes and the list would not move, which reads as
"the filter found no matches" rather than as a wire nobody connected, and is the worst of the failures
available here for exactly that reason. Each subtab names its own surface in ITEM_EDITOR_KINDS now, and
the renderer reads it from the config.

Export had to follow. Its tooltip promises on every tab that it sends what the tab is showing, and the
Items tab's listSpecs already filters through the facets for that reason; a funnel the export ignored
would have made one tooltip false while the others stayed true.

And the stylesheet is the part with no test behind it. Seven selector lists name each surface's id
prefix by hand, and a funnel added to the registry and forgotten there loads fine, opens fine, and is
UNSTYLED — which reads as a broken button, and nothing in a test suite sees stylesheets. Attribute
selectors would have removed the duplication and would also have dropped the specificity from an id's
to a class's, which is a change to how six working controls resolve; the lists stayed and the CLAIM is
checked instead, derived from ITEM_FACET_SURFACES rather than from a second hand-written roster.

Sixteen sabotages, and two of them caught the test rather than the code, which is the part worth
recording. The CSS check first asked only whether each selector appeared ANYWHERE in the stylesheet,
and passed against a build with the id stripped from one rule — because `#x-facet-menu` is a prefix of
`#x-facet-menu::-webkit-scrollbar` two rules further down; it splits the sheet into rules and matches
whole tokens now. And the assertion that renderItemKind no longer compares against a literal matched
the COMMENT that quotes the literal it replaced, which is the assertion-matched-the-prose trap this
repository has been bitten by before and was bitten by again here, on that check's first run.

One failure is left on main and it is not this change's: three landing-page images added by the
Heraldry section commit have no provenance entry, so test_asset_provenance is red. They are the
owner's own images and only the owner can say where they came from — inventing a verdict is precisely
what that ledger's UNKNOWN exists to prevent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

# Conflicts:
#	Handbook/dungeon-masters-guide.html

The tab shipped in the commit before this one; this is its test and its chapter, and both turn on the
one place districts deliberately part company with the regions they are modelled on.

A region's map prompt is built by walking each room's exits, so the picture can say one place lies north
of another. That is right for a region, which IS a piece of the map: a room drawn on the wrong side of
one gives the player a picture of a world they can walk out of. A district's rooms are a set rather than
a grid, and several of them commonly do not connect to each other at all — a dock ward's warehouses have
no exits to one another, only to the quay. So the district directive hands over the NAMES and says in as
many words that there is no fixed layout and the arrangement is the illustrator's to choose. Passing
exits there would be worse than useless: a layout assembled from the gaps is an authoritative-looking
picture of nothing. The test asserts the absence as well as the presence, because "it names the rooms"
would pass just as well against a prompt that also pinned them to a compass.

The reference rules run in opposite directions on purpose and the test pins both. Normalization KEEPS an
id that no longer resolves, because a room deleted today may be restored tomorrow and a dangling
reference an author can see is one they can fix. A GM reply that invents one has it dropped and named
back, because that is a new claim made against a roster the model was shown in full. The two meet where
an edit returns a list containing an id the record already carried: that one passes, or the
invented-id check becomes the prune the normalizer refuses to do.

Three existing tests had something to say about the change and all three were right to. The
prompt-no-builtin-leak check caught a comment of mine using the built-in world's own place name as an
example, which is exactly the rule it exists for; the example is generic now. The add-random registry
counts its tabs by hand, which is the point of that assertion, so it counts eighteen. The calendar tab's
position was pinned by a regex with a 200-character window between three ids — a proximity test wearing
an ordering test's label, which a new tab inserted between two of them pushed past. It compares offsets
now and says what its own sentence says.

The Dungeon Master's Guide gains a World > Districts section covering the fields, the two ways in, the
kept-versus-dropped rule, and a note on why the map has no directionality — the question a DM reading
the Regions section first will arrive with.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

# Conflicts:
#	Designs/README.md

Two things, and the second is the one a DM reported.

HERALDRY JOINS EDITOR > ART, on both halves. The Heraldry tab shipped with its card able to paint one
device at a time through the shared portrait driver and with nothing on the Art tab knowing the kind
existed, which was recorded in Designs/culture.html as a gap on the day it shipped rather than left to
be found. That note named the six touchpoints and they are all wired now: a group in
ART_MISSING_GROUPS, a bucket from artMissingLists, the render, a descriptor in currentArtCards so
Generate All actually walks it, a Review gallery group, and a branch in compendiumDetailBodyFor.

The last of those is the one this codebase has watched fail three separate times - a Races cell before
its branch was written, a Classes cell before its, a Reagents cell before its - and it is the quietest
failure in the feature: the gallery looks complete, the cell is drawn, the cursor is a pointer, and a
click does nothing at all, with no error anywhere. So the branch went in with the cell. It renders the
KIND and the bearer as words rather than as the ids the record stores, because this is the one surface
where nobody writes anything back and "coat_of_arms" in a reader's popup is debug output; a bearer the
world has since lost still shows, marked, for the reason the editor's own picker keeps it.

No markup was needed, which is worth knowing before anyone goes looking: renderArt builds each section
shell from the registry, so the heading, the order, the container id and the type filter's checkbox all
follow from the group entry. That is what the registry is for.

AND THE PICKERS ARE THEMED, including the list they open. Reported as "the Kind and Faction drop down
select boxes are all white", and the closed control was never the problem - the global
select:not([multiple]) rule drops the native slab and .npc-inv-select sets its own background. It is the
OPEN list: an <option> is painted by the UA from its own box, and with nothing set there that box is
transparent, so the popup comes up in the OS light palette. Measured rather than guessed - the computed
option background on one of these read rgba(0, 0, 0, 0) while .rooms-region-select's read
rgb(19, 17, 13), which is the one rule that class has and this one did not.

The fix is on .npc-inv-select rather than on anything heraldic, because that class is shared by every
"+ Add" picker in the editor - an NPC's inventory, a container's contents, a biome's flora and fauna,
a device's kind and bearer - and all of them were white together. Every other themed select on the page
already carries the same pair; this one was simply never given it.

Four sabotages cover the Art half and one the CSS, each caught by a distinct named assertion, and the
two absence assertions carry positive controls so they cannot pass for harness reasons. That mattered
here: section 12 needed an app instance of its own, because the test harness reassigns global.document
on every instance it builds, so a renderer called on an earlier one paints into a registry that
instance's own getEl cannot read - the bucket reads correctly and every view reads empty, which looks
exactly like a renderer that was never wired. Three more registry guards fired as designed and were
answered rather than worked around: the kind list in test_art_kind_filter, the done-message word map in
test_art_factions, and the refresher map in test_art_card_refresh, which asks the useful question -
renderHeraldry already called reRenderArtIfActive, so that one was a map to update rather than a hole.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

A region is a stretch of the map: an outline, a colour, cardinal neighbours, and a room that says which
one it is in. A district is the other half of how people actually name where they are — the shambles,
the dock ward, the terraces above the mill — and the editor had nowhere to put one.

Editor > World > Districts is a roster tab wearing the Factions panel chrome exactly, so it is learnt
once: the same toolbar, the same card view, the same GM request box. Two ways in, and they are different
acts. "+ New" opens a dialog asking for the name, the region and the two descriptions together, and
refuses a nameless district while what was typed is still on screen. "+ Add" is the GM inventing one
whole from this world regions, theme and tone, through the shared random-add driver.

The rooms are held on the DISTRICT as ids rather than through a field on the room, which is the one
place this deliberately parts company with regions. A room sits in exactly one region and the room says
so; a room can sit in two districts, because a market on a boundary belongs to both quarters that argue
over it, and nothing about a district needs the room to know it exists. Ids that stop resolving are kept
and shown as missing rather than pruned, the rule a religion races follow.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Editor › Items already had a facet menu — type, equipment slot, portrait, icon — and it is well enough
factored that a Tongue group is a data addition rather than new machinery: a row in
ITEM_FACET_GROUPS, a value in itemFacetValues, options, and a title. No new control, no new state, no
new menu. The menu already hides a group that cannot tell two things apart, so a world with no
languages is simply never offered it, and that half needed no code.

Two decisions were not free. It is the EDITOR's alone. The same funnel is on Character › Inventory and
Compendium › Items, and those two already drop Portrait and Icon on the argument their own comment
makes: "no portrait yet" is a DM's work queue, and beside a player's own sword it reads as a fault in
the sword. Which tongue a thing is written in is the same kind of question, and a player has Journal ›
Languages, which answers "what can I read" far better than a funnel over their pack ever could.

And it reads the RAW SLUG rather than bookLanguage(). That accessor answers '' for a language this
world no longer has, which is right everywhere it is used and wrong here: a book still pointing at a
deleted tongue would file under "No tongue", indistinguishable from a coil of rope, and a DM filtering
by tongue could never find it. Filed under its own broken id instead, the menu offers it and says "no
such tongue" beside it — which makes this funnel the one place in the editor that particular authoring
mistake is visible. It is the same instinct as the dangling-reference rule a religion's races and an
NPC's folklore already follow: keep the broken thing and show it, rather than resolving it quietly to
nothing.

"No tongue" sits last, the way "No slot" does, and covers a sword and an English chronicle alike —
which is correct rather than a compromise, since English IS the absence in this data model and an
ordinary book declares no language at all.

Two existing tests asserted the group roster by value and its count as four. Both are good assertions
about a real property, and the property genuinely changed; they say five now. Tests/test_item_facet_
tongue.js is the new file, nine sabotages, and the one that pays for it is the fourth — reading the
facet through bookLanguage() makes the broken book disappear into the absence, which is exactly the
implementation somebody would reach for first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The Fauna card's Notice box was reported as drawing at twice the width of the Size / Pace / Seen
pickers beside it, and fixing it raised the obvious question of where else that had happened. This is
the answer to it. Every editor tab and inner tab was walked in Chromium with its cards expanded, and
every visible input, select and textarea measured and grouped by the column it sits in; the groups
that disagreed were then read one at a time against the rule that sized them. Most of the
disagreements are deliberate and stay: XP keeps the full width its sentence placeholder needs, a row
carrying an inline generate button is narrower than one without by exactly that button, a gate row
proportions its three controls on purpose, and the Path field shares its line with Browse. Two were
the same defect reported on Fauna, arrived at from the other direction — a field sized by what its row
had left over rather than by the fields around it.

On a class card, the eight base stats are drawn as two grids, HP and MP on one row and the six
attributes on the next, sharing one rule whose columns were repeat(auto-fit, minmax(96px, 1fr)).
auto-fit collapses the tracks a grid has no item for and hands their width to the ones it does, and it
does that per grid, so the two-item row and the six-item row sized their columns differently: measured,
465px a box against 128px. HP and MP drew three and a half times the width of STR directly beneath
them, for the same two digits. auto-fill keeps the empty tracks, so both grids size their columns the
same way and HP now lands directly above STR. The trailing empty tracks are the cost and they are also
the point — the codebase's own argument for the 50% Race and Aggression fields is that a control
stretched the width of the card reads as far more important than the facts printed beside it.

On the Calendar tab, the weekday boxes were a wrapping flex row with flex: 1 1 130px on each input.
flex-grow is resolved per line, so the built-in world's seven weekdays drew six at 137px and the
seventh, alone on the line below, at 852px: one word in a box six times the width of the six above it.
Nothing about seven is special — any count that does not divide the line does this, so a world whose
author writes ten weekdays gets it too. It is a grid now, because a grid sizes its tracks once for the
whole container and the last row's boxes are therefore the width of the first row's; the 130px floor
and the 6px gap are the old rule's own figures, so the six that were already right are unchanged.

Tests/test_class_card_base_stats.js is new and pins the class card's block, which had no test of its
own: that the card really does draw two grids of different sizes (the fixture that makes the rule
load-bearing at all — one grid, or two of equal size, and auto-fit would be harmless and the file
would be proving nothing), that both wear the same class so one rule governs them, that the rule
states a column template which does not resize itself around how many fields a grid happens to hold,
and that no field or box carries a width of its own. It finds the grids by walking the card's div
nesting and asking what each stat field sits inside rather than by matching a class name, because a
grid renamed out of the shared rule is this defect returning by its tidiest route and a search keyed
on the old name would not see it. Tests/test_calendar.js gains the weekday half, which asserts the
property rather than the fix: a flex row whose children do not grow would be just as correct as the
grid and passes, while a container that both wraps and lets a child grow into its own line's leftovers
does not. Seven sabotages against the class card and six against the calendar, each caught by the
assertion that names it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

# Conflicts:
#	Handbook/dungeon-masters-guide.html
#	guide.html

The same reconciliation the Culture page itself needed, one file over: the index row for culture.html
was written while Heraldry was the fourth roster to ship and History landed in a parallel session
while it was being written. It now counts five, names History's own page rather than restating what
is on it, and drops the ordinal from the Heraldry sentence — the interesting claim there was never
which number it was, it was that an armour item reads one of these records, which is still true and
does not go stale the next time somebody ships a tab.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

test_editor_add_random.js had the new kind in its two completeness checks — the registry entry is
complete, it has an angle list of its own — and in neither of the two that actually press the
button. A registry entry is a claim that the shared driver can reach this roster, and the entry
alone cannot tell you whether the toolbar carries a + Add at all, whether it calls the handler for
its own kind, or whether the instruction the driver builds reaches requestHeraldryEdit with this
world's theme, tone and prologue in it. So Heraldry joins both tables: the toolbar scan, where it is
the second tab after Religions to carry a + New and a + Add side by side, and the driver table,
where a stubbed reply proves the created device is hoisted to the top of the list and named in the
output box.

The element registry needed the two ids as well, and its absence failed as a throw rather than as an
assertion — the output-box check read textContent off undefined. Worth knowing because it is the
shape a missing fixture takes in this file: the kind's own assertions all pass first, and the run
dies afterwards on a box the harness never made.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

A parallel session landed the History tab while this one was building Heraldry, and the merge left
the Culture document counting five systems where the strip now has six. The counts are reconciled
rather than re-argued: History has its own write-up in Designs/world-history.html, so this page
names it among the built rosters, records the one thing the pairing actually costs Culture as a
whole — that a tale and a chronicle entry are opposites rather than two rosters that mostly agree,
which is why the tab sits beside Folklore rather than at the end of the strip — and leaves the rest
where its author put it. Restating somebody else's reasoning second-hand is how a design document
starts disagreeing with itself.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

# Conflicts:
#	Handbook/dungeon-masters-guide.html
#	guide.html

Merging onto main picked up a same-day change that landed after the last guide pass: scrolls
are now readable (a scroll can carry teaches, teachesReagents, and the three tongue lessons,
same as a book — only a spellbook stays inscribed rather than read), and a fourth lesson,
teachesLanguage, hands over a whole grammar and marks a tongue Fluent rather than a tally of
letters and words. The DM's Guide and Field Guide still described the tongue lessons as
book-only and stopped at three, which the merge would have made stale on arrival rather than
in the usual few days. Updated both, plus the Player's Handbook's Journal chapter, to name the
fourth lesson and the Fluent chip it produces.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BTPxU7Monvfrev6LUNqSfr

# Conflicts:
#	Handbook/dungeon-masters-guide.html
#	Tests/test_culture_editor_tab.js
#	guide.html
#	text_adventure.html

# Conflicts:
#	Designs/README.md

Editor > World > Culture > Heraldry was the last Culture tab drawn but inert, and it is world data
now: world.heraldry, keyed by id, carrying a title, a kind, a faction, a description, a device
picture with the prompt it came from, and the DM's hidden lore. + New opens a dialog, + Add asks the
Game Master, and dmEditHeraldry opens the request box at the bottom under the same rule that opened
Religions' and then Folklore's -- a card is the Game Master's only when the roster it names can
actually make the edit, and requestHeraldryEdit is that roster.

The field the whole tab turns on is the KIND, and it is worth saying why it is a closed vocabulary
of four rather than a word in the description. A device is a charge on a thing, and the thing is
half the subject: the same wolf's head woven into a hall's hanging, flown from a mast, painted on a
breastplate and branded into a doorpost is four records, not one with four notes. Three readers
depend on it. The picture is painted from it, and a prompt naming only the charge gets a model's
default heraldic shield every time -- four identical shields under four headings, which is exactly
the outcome the field exists to prevent. The card head groups by it. And the armour select filters
on it. So the dialog refuses a device with no kind where the religion dialog beside it refuses only
a missing name, and a word outside the four resolves to nothing rather than to a default: a device
the Game Master calls a "pennant" is created without a kind and the drop is named back to the DM,
because filing it as a flag would be the engine deciding what the thing is, and the decision would
be invisible in the picture that came back.

That is also the second half of this change. An item of type armor now draws a Heraldry row in its
Details table -- a select over this world's coats of arms and nothing else, because a tapestry is
woven and hung and offering one to an armourer offers a DM something no armourer could put on a
breastplate. It writes through applyItemTypeField like every other field on that card, so it lands
on the catalogue type and on every live copy by name, and makeItem copies it onto armour and onto
nothing else. This makes heraldry the first Culture record anything outside Culture reads, which is
attachment arriving early and through a door the design document did not expect: the anchor it spent
its length arguing about is the region, and the first thing actually to reference one of these
records is a breastplate.

Removing a device clears the armour that bore it, and this is the one place the codebase's
keep-a-dangling-reference rule is inverted on purpose. Everywhere else an id that stops resolving is
kept and shown, because a record deleted today may be restored tomorrow and a silent prune turns a
recoverable mistake into an unrecoverable one -- and what makes that safe is that the broken
reference is visible on the card holding it. An armour bearing a deleted device shows nothing at
all: it would have to be hunted one item card at a time, and nothing would ever tell anybody to
look. Both removal paths clear it, the card's own Remove and the Game Master's remove list, because
whether the armour is left dangling must not depend on which button was pressed.

The reply harvester is the religions one's twin and takes one shape more: a bare top-level array.
That roster accepts a list inside the envelope and refuses one outside it, which is a distinction a
model has no way to know it is being held to, and the alternative is reporting "the GM changed
nothing" over a Logs entry holding every device it wrote.

Tests/test_heraldry_tab.js is eighty assertions and five sabotages -- the reload dropping the map,
the armour select losing its kind filter, the faction check going, the vocabulary opening up, and a
removal leaving the armour behind -- each caught by a distinct named assertion. Two registry guards
failed as designed and were answered rather than worked around: test_editor_add_random.js wanted an
angle list and a seventeenth registered kind, and test_card_generate_prompt.js wanted a fixture it
could address. Designs/culture.html goes to rev. 11 with the tab's playtesting notes as section 8,
and records what heraldry has NOT joined -- it is not a group on either half of Editor > Art, so
Generate All walks past an unpainted device and the Review gallery omits it, which is the omission
this document has already recorded three times and is named here on the day it shipped rather than
left to be found. The Dungeon Master's Guide and the Field Guide both said Heraldry was inert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

# Conflicts:
#	Handbook/dungeon-masters-guide.html

Culture already had a tab for the past and it was the wrong one. Folklore holds myths, beliefs, fables
and legends, and it is deliberately about hearsay — what a people SAY happened, handed down, shaped in
the telling, true or not. There was nowhere to write down what DID: the wars, the famines, the sieges,
the treaties, the year the river froze. So a world could have a legend about a drowned bell and no record
of the war that sank it.

THE DISTINCTION IS THE FEATURE, and it is legible in the data rather than only in a lede: a tale carries
a KIND, because what sort of telling it is matters; a beat carries a DATE, because when it happened is
the whole of what makes it a record. The test a beat has to pass is one sentence — could a clerk have
written it down at the time, and would an ordinary person today know it the way anyone knows their own
century? History sits BESIDE Folklore in the strip rather than at the end of it for the same reason:
split apart by Castes and Religions the two read as unrelated tabs, and a war gets filed as a legend.

Nothing in the engine plays a beat. They exist so the Game Master has geopolitical ground to stand on —
why this duchy distrusts that one, what the old soldier was too young for, which year the coin was cut.

DATES ARE THE WORLD'S OWN AND DELIBERATELY PARTIAL. Every date reads off world.calendar, so renaming a
month moves every entry that names it and there is no built-in month table anywhere in the feature. The
year is required and is the spine of the timeline; the month and the day are each optional, because that
is how history is known, and a record forced to invent a day lies with more confidence than a vague one.
The year is also ABSOLUTE — it is not put through realmDisplayYear, whose job is converting a live clock
off the Gregorian substrate; running a historical year through that offset would move every beat in the
world the day somebody edited the calendar's starting year, in the direction that makes a war predate
its own causes.

The chronicle draws as a timeline reusing the journal's own furniture rather than a second one that
would drift from it, and it is the one editor tab whose collapse set holds the OPEN cards: a chronicle
is a list you scan, and twenty events opened to full edit forms is not a timeline but a form. Two
buttons add one and they are genuinely different acts. "+ Add" hands it to the Game Master — which is
what you want for a beat that should FIT, since it is given the canon, the calendar, the events already
recorded and the tales already told — and pressed with an empty box asks for one this world implies and
has never had written down, because a button meaning "give me one" should not answer by telling you off.
"+ New" opens a dialog for a DM who already knows what happened, and refuses a nameless or dateless
event where the refusal can be read with everything typed still on screen.

People are ids, never names, and the two directions have OPPOSITE rules. An id already on a record is
KEPT when it stops resolving and shown as a dashed chip — that protects an author's data, since a being
deleted today may be restored tomorrow and a silent prune makes the treaty read as though nobody signed
it. An id the GM INVENTS is dropped and named back, because that is a new claim made against a roster it
was shown in full. The one crossing case is that a reference the record already carried survives a GM
edit, or editing an old beat would prune its people out because somebody has since been renamed.

THE BUG WORTH REMEMBERING, found by the test and live until it was: `+null` is 0 and
`Number.isFinite(0)` is true, so an explicitly-unknown month read as month ZERO — the first month of the
year — and an unknown day as the 1st. Every year-only beat quietly acquired a date nobody wrote, which
is exactly the failure partial precision exists to prevent. It was invisible from outside because a
record written with the keys simply LEFT OUT was fine (`+undefined` is NaN), and the only two surfaces
that write an explicit null are the dialog and the inline editor — which is to say both of them. The
same coercion sat on the year, where a cleared box would have been read as the year zero.

Thirty sabotages, each caught by a distinct named assertion; the round also found a redundant line in
the editor whose comment claimed the normalizer would keep a stale day, which was simply untrue, and a
missing case in my own §1 — with the month absent the day is dropped by a different rule, so
`month: null, day: null` could not tell whether the day guard worked at all.

Two assertions in test_culture_editor_tab moved with the tab: its panel count is read off the strip now
rather than from a literal five, so adding a tab is one edit instead of two.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

§9c is the write-up for the grammar and the readable scroll, and it is mostly about what fluency had to
be careful NOT to do. The tier that sounds simplest — grant every word — is the one that fails a week
later when a DM adds a word to the lexicon, and the one that reads correctly on the day it ships. The
section says that, and says the harder thing beside it: a fluency that answered true and stopped would
read the valley perfectly off a capital grammar, and §2's entire dialect mechanic would stop existing
with nothing on screen looking wrong.

It also records two sabotages that caught nothing, because both are the sort of gap a later reader
would otherwise rediscover and treat as an oversight. One was a redundant call, deleted rather than
kept as a line no test could protect. The other is guarded twice over, so only removing both guards
produces the failure — and the comments in the engine now say that rather than implying a guard that is
not there.

§10 gains three notes, which is the first time that section has had anything added since it was
written. They follow its own rules: each says what a single session can show (the kind, never the
frequency), each asks for the wording back verbatim where the wording is what a rule could be changed
against, and each says what a fix would cost. The most useful is the second — whether a player handed a
capital grammar reads the valley's forty as "oh, they say it differently here" or as the grant having
failed — because it is the one question where the cheap fix and the expensive one point in opposite
directions, and the expensive one deletes §2. The first is the only one that is really about the model:
the directive asks for a grammar to be rare and enforces nothing, and a Game Master that reaches for
the largest grant because it is the most interesting would end the collecting loop before it starts.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

On a fauna card the Notice field drew at twice the width of the Size, Pace and Seen selects beside it in
the same column -- measured, 473px against 236px, which is the two-to-one the report describes exactly.

It had been added to the selector that styles the XP box, and that box's full width exists for its
PLACEHOLDER: "not decided -- 30 by level" is a sentence, and the comment above the rule says as much.
Notice's placeholder is a single number. So are Discovery DC's and Identify DC's, both of which were
added to the same selector later and inherited the same width meant for prose -- fixed with Notice
rather than after it, since leaving two of three siblings mismatched would make the card less consistent
than the report found it, not more.

The three take the selects' own width and minimum. Matching the control they sit among is the whole
point, so the figures are read from that rule rather than guessed at a second time, and the assertion
derives them the same way: it compares the boxes against .npc-size-select rather than against a number
written down in the test, so a later change to the pickers cannot leave the boxes behind without
something saying so. XP keeps its full width and takes no minimum, which is the half of this that must
not move.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Two changes that turned out to want each other. Scrolls are read now, and the most natural thing a
scroll has ever been is a primer.

THE SCROLL. `scroll` was a type with no mechanic at all — carried between the icon map and the
inventory's Books shelf, pickable from the editor's dropdown, and branched on nowhere — so a DM who
chose it got a generic object with a scroll's picture. READABLE_ITEM_TYPES is book and scroll, and
everything readBook does suits one: a scroll says something, a scroll can carry a receipt, a scroll
can teach a craft. It sits beside WRITTEN_ITEM_TYPES rather than replacing it, because the two are
different questions and a spellbook is the case that separates them — written in a tongue, and
inscribed by readSpellbook rather than read, so sending it through readBook would give one object two
Read buttons doing different things. Yesterday's book/not-book split in the item editor becomes the
readable/not-readable one, which is what it was always reaching for.

THE GRAMMAR. The lexicon shipped with two tiers, and both are things you COLLECT: an alphabet, and
words one at a time. A world could therefore hand a player a hundred small grants and never the thing
those grants approximate, which is being taught the language. `fluent` is the third tier and it is a
different kind of record rather than a bigger pile of the second.

It is a FLAG and not a bulk grant of every word, and the difference is invisible on the day it happens.
Copying the dictionary into the save at the moment of reading leaves a fluent character mysteriously
stuck on the one word a DM authors next week; a flag answers for the lexicon as it stands whenever it
is asked. It also keeps the save small and the Journal honest, since the tally is computed rather than
stored.

And it does not erase the dialect stumble, which is the failure that would have cost the most. §2's
whole subject is that a reader of the capital reads the valley at a stumble — plainly where the valley
kept the capital's word, not at all on the forty it restated. A fluency that short-circuited to true
would read the valley perfectly off a capital grammar, and the mechanic the dialect tier exists for
would quietly stop existing with nothing on screen looking wrong. So fluency is held against the
RECORD, offers that record's whole lexicon as candidates, and then goes through the same pairing rule
every other word goes through. The alphabet is the one thing it does spread across the family, because
the letters really are one set with two names. A dialect's journal card therefore still reports how
much carried and how much did not, which is the only place in the game that stumble is ever visible.

`teachesLanguage` is the fourth lesson and the first that needs neither a passage nor a word list — a
grammar is a lesson whether or not it is also a story. It subsumes the other three, and the editor
draws them disabled rather than hidden when it is ticked: an author needs to see that a phrasebook's
word list is still on the record and has stopped meaning anything, which an empty space says neither
of. The directive tells the Game Master to reach for it last and to keep it rare — one per tongue in a
world is generous, and it is the object a quest is built around rather than something found on a shelf.

normalizePlayerLanguages names the field, which is the half that would have failed silently: it
rebuilds every record from named keys on every load, so a field it does not list is gone on the next
one and the reader goes back to knowing nothing with nothing reporting it.

Tests/test_language_fluency.js pins all of it against a deliberately broken build. Two sabotages were
not caught and neither was a defect: a redundant learnLanguageScript call inside the fluency grant,
which was deleted rather than kept as a line no test could protect; and readBook's skipping of the
three lesser lessons, which turns out to be protected twice over — the branch never calls them, and
they would refuse what fluency has already granted if it did. Removing both at once announces four
grants for one event, which is the sabotage that assertion was confirmed against, and both comments
now say so rather than implying a guard that is not there.

Two existing tests anchored on the literal `=== 'book'` guard in the item popup and threw rather than
quietly reading the wrong slice — which is exactly what their own fixture comments say they were
rewritten to do. Their anchors follow isReadableType now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

A player reading a long narration touches nothing for five minutes, and the world pauses underneath
them. Their next scroll resumes it — and the mask appeared and vanished in the same breath, a
full-screen announcement of a state that was over before it could be read. The pause was right;
announcing it that fast was not.

It now waits 600ms before drawing, and a resume inside that window cancels the pending mask so it is
never drawn at all. Long enough to cover a reader glancing back at their own screen, short enough that
somebody genuinely returning is told what happened before they start clicking.

ABSENT during the wait, not merely transparent, and that is the whole reason this is a timer rather
than a CSS animation-delay, which would have been the shorter diff. A mask held at opacity 0 still
takes the pointer — and taking the pointer is the point of the mask, so this is not a detail that could
be tuned away. A player returning inside the window would have had a click swallowed by something they
could not see, with nothing on screen to explain why the button did nothing. That is strictly worse
than the flash it was meant to remove: a flash is startling, an invisible dead zone is a broken app.

Two things the timer has to get right beyond simply firing. It re-checks the world when it fires rather
than trusting the state it was scheduled under, because a resume can reach the world through a path
that does not run the mask update, and raising a mask over a running world is the one failure this
delay must not introduce. And a second hold arriving while the mask is still pending must not restart
the wait — updateWorldPauseIndicator runs on every hold change, so a restart on each one would push the
mask out indefinitely and it would never appear at all.

The test now pins the property the delay exists for rather than the one it replaced. Not "the mask is
hidden again afterwards" — that was already true of the flash — but that a quick return leaves it never
having been shown, that a timer firing after a resume draws nothing, and that a second hold leaves the
original countdown alone. One harness guard came out of the sabotage pass: with scheduling broken there
is no timer to hand back to the fake clock, and pushing a null one turned the run that should have named
the broken assertion into a stack trace from inside the harness instead.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

A routine sweep of the Designs folder against the shipped guides found four places where the
prose had fallen behind the code since the last catch-up on 12 Sep. Hidden Beings shipped
today with the Field Guide already updated in the same commit, but the Player's Handbook and
Dungeon Master's Guide had nothing on it at all — no mention of a creature that can be present
and unseen, or one that can be seen and unnamed, and no field reference for seen/revealed on
the DM side. Added a player-facing "Doors & barriers"-adjacent section to Handbook Chapter
Four, and the seen/seenCondition/discovery and revealed/apparentName/identifyDC fields plus
the Wildlore/Vigilance note to the DM Guide's Entities table.

Reagent preparation has quietly grown two gates since rev. 16 of the reagents-and-concoctions
doc — a craft skill every reagent is worked under, and a per-reagent secret formula a receipt
book can teach — and all three guides still described preparing a reagent as "pure labour, no
roll" with nothing standing between a character and a mortar. Fixed the wording in the Field
Guide, the Player's Handbook, and the DM's Guide, and added the reagent's skill/secret fields
and the teachesReagents item field to the DM Guide's tables.

The Journal picked up a Languages tab and a Gallery tab a few days apart, and the Field Guide
and Player's Handbook were both still describing it as five subtabs (one of them, Professions,
explicitly called "a fifth" in the Handbook) with Gallery only ever mentioned in passing under
Victory Banners. Both books now list and describe all seven.

Last, a fix that shipped today made `language` a fact about a book, spellbook, or scroll
alike rather than a book's `passage` alone — the Field Guide and DM's Guide both still tied it
to `passage` specifically, which is now wrong for a spellbook that carries no passage at all.

Culture's open-decisions wording, the Guards faction prompt fixes, and the Electron key-gate
work were checked and found already reflected or out of scope for these three books. All 893
app tests still pass; nothing here touches text_adventure.html.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BTPxU7Monvfrev6LUNqSfr

Eight controls arrived yesterday with no CSS rule at all — Seen, Found by, Skill, DC, Tell, Species,
Reads as, Name DC. A control with no rule does not look slightly wrong; it falls through to the
browser's own widget, so a light-grey select and a white text box in the system font sat in the middle
of a card of gold-on-black fields. Nothing failed and nothing logged. It was reported by somebody
looking at it, which is the only way it could have been.

They join the rules their siblings already share rather than getting a dress of their own. Hiding a
creature is the same authoring act as setting its Aggression or its Size three rows up, and the whole
reason those three share one look is that a card of editable facts must not read as a card of unrelated
widgets. The class NAMES stay separate for the reason the block's own comment gives: a test counts
.npc-agg-select to prove there is exactly one per card, and a second control wearing that class would
have made it count two and call it a pass.

Two things beside them were the same omission, shipped earlier and never noticed. .npc-pace-select was
in the base rule and in none of the three below it, so the Pace picker had no hover, no focus colour and
a browser-default dropdown list. And .npc-xp-input / .npc-notice-input had no focus rule at all while
the text box two rules up always did — four number fields that stay dark beside three text fields that
light up is the same inconsistency read from the other end. Both fixed for the group.

The two new pickers also lost their explanatory option labels. At the 50% width they share with
Aggression they were cut off mid-phrase — "Hidden — must be fo" — and a clipped label is the one thing
a picker must not have, since it is the only thing saying what the control is set to. One word each
now, with the sentence moved into the title attribute where it has room.

THE ASSERTION TOOK THREE TRIES, and the two it took to get there are worth recording because both
passed against the bug they were written for. Asking whether the class appears in the stylesheet is
answered by a leftover `:focus` rule that survived the deletion. Asking whether SOME rule naming the
class sets a background is answered by `.npc-seen-select option`, which paints the dropdown list while
the closed control sits there in grey. What it asks now is whether a rule's selector ENDS at the class
and sets a background — and it asks it of every classed control on a rendered card, not of these eight
by name, because the failure mode is precisely "somebody added a control and did not think about CSS".

test_entity_gender needed three fixes of its own, all the same shape as the bug: its rule-finder wanted
the whole selector list on ONE LINE and mine wraps across two, so a rule sitting right there read as
absent; it then read this stylesheet's comments as part of the selector; and two of its checks quoted
selector lists verbatim — the exact brittleness that file's own comment warns about, in the file that
warns about it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

This engine could hide almost anything except a living thing. An item could be concealed in a dark room
and found with a light; a plant could be missed until studied, with Herbalism spotting it for free; an
exit could be a false wall behind a searchable tell with its own skill and DC. A creature could only ever
be plainly there. So a world could hold a trap nobody sees and a door nobody finds and not a bird in the
grass, and the gap showed exactly where the fiction reaches for it first: an ambush that has to be
narrated rather than played, a watcher on a roof who must be absent until the plot wants him, a marsh
that cannot contain anything living that is not announced on arrival.

TWO GATES, AND NOT COLLAPSING THEM IS THE WHOLE DESIGN. `seen` asks whether the player can see the
creature at all and is offered on every being; `revealed` asks whether they know WHAT it is and is fauna
only. All four combinations happen — a crow is seen and named, a heron is hidden and obvious once found,
a fish on a stall is visible and unidentifiable, a moth in a barrow is both — and when it is both,
finding comes first and tells the player only that there is something there, which is why a reveal
announces the creature by its apparent name. The rule binding them is that a creature the player cannot
SEE is never identified: without it the species gate leaks through the visibility gate and puts a true
name on screen for a thing that is not there yet.

NOTHING HERE INVENTS A VOCABULARY. `seen` / `seenCondition` is borrowed whole from hidden flora,
`discovery: { skill, dc, hint }` from the hidden door — including its rule that a DC with no skill to
roll against is dropped rather than stored — and apparent-versus-true naming from the magic item gate,
helper for helper. Each half can be read by somebody who already knows its sibling. Every field is read
by `makeEntity` because a restore rebuilds each creature through it, so a field the constructor does not
name is not merely unvalidated but gone on the next load; both gates are opt-in and an untouched world
serialises exactly as it did.

TWO SKILLS SEE WITHOUT SEARCHING, and the specialist is the cheap one on purpose. Wildlore is Herbalism's
exact twin at tier 1 — it spots hidden fauna and names any animal — and it fills the catalogue's one real
nature gap, since Tracking reads the sign a beast left, Animal Handling manages the one in front of you,
and Beast Lore knows what it will do next; none of them was "that is a marsh wren". Vigilance is tier 2
on Perception and sees anything hiding. So caring about animals is enough to find the bird in the grass,
and finding the man on the roof takes somebody who has made watching their business.

THE FAILURE NOTHING WOULD HAVE REPORTED is in the movement system. `blockingFoeIn` halts a compound walk
at a hostile creature, and a hidden one that still halted it announces itself without a word of prose:
the walk stops in a room the player was only passing through and they are told they were stopped. Every
surface would have looked clean. The answer is the one the door design already gave — a leak is worse
than a missing exit — so the walk goes through and what the thing in the reeds does about that is the
Game Master's. There is a quieter version of the same problem in every lookup by name, because the moment
a surface shows "a small brown bird" a handler matching `e.name` is matching a string that is nowhere on
screen; `entityByShownName` resolves either name and refuses a hidden one outright.

The Game Master keeps the hidden creature in its dossier, marked, because a GM told nothing would narrate
a room it believes empty and no reveal could ever be judged. Rules 3e and 3f sit beside the concealed-item
rule they are modelled on, and the clause that makes the feature worth having is the third one: it acts
while hidden. Something moves in the reeds. A hidden creature that does nothing is an absent creature with
extra steps.

Twenty-seven sabotages, each caught by a distinct named assertion — and the test earned itself twice
before that. It found a hidden MONSTER and an unnameable ANIMAL reaching the Game Master with nothing
said about either: the dossier's short line for a non-NPC returns early, so the gate notes appended at
the bottom of the function never ran, and two of the three creature types had no feature at all while
looking like they did. And the sabotage round found a weak assertion of my own — the identify DC was
compared against Wildlore's baseDC, which is 12, the same 12 a `return 12;` produces, so it agreed with an
implementation that had stopped reading the skill entirely.

One assertion elsewhere moved with the code: test_dungeon_pseudo_location pinned the literal
`entitiesInRoom` where its rule is the `!partyIsBelow()` guard beside it, and broke on a rename that
changed nothing it meant to protect.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

A stopped clock is indistinguishable from a broken one, and until now the whole of what said otherwise
was a class on the header clock and a tooltip nobody hovers. Come back to a session that paused itself
twenty minutes ago and the app looks hung: nothing moves, no beat arrives, and the one mark that
explains it is a chip in the corner.

The mask states it over the page, and it takes the pointer rather than passing it through. That is the
half worth arguing for: a player returning to a frozen screen can otherwise land their wake-up click on
Attack, and the resume and the action arrive in the same instant. Absorbing the first interaction makes
it a wake and nothing else. Nothing on the mask calls stopPropagation, so the event still bubbles to
document where noteActivity is bound — the mask dismisses itself on the very event it absorbed, and the
test pins that the element declares no handler of its own, because an onclick added later would leave a
player staring at a screen that will not wake.

The resume half was already built and already right. noteActivity resumes before its own throttle, so a
burst of mousemove lifts the world on its first event rather than up to a second later, and it does so
only for the idle hold. Nothing there needed changing, which is why nothing there was changed.

The mask is for the IDLE hold alone, and that is the distinction the whole feature turns on. A Pause
Story hold is the player asking to be left alone until they act; a mouse move is not acting, so a mask
reading "move to resume" would be a lie they could act on for a while before noticing, and masking a
scene somebody deliberately paused to read would be worse than a lie. The header chip already refuses
to share a sentence between the two for the same reason.

Writing the test for the both-held case found a defect older than any of this. holdWorld returned early
when a second reason arrived — correctly, to avoid re-capturing a time scale that is by then the frozen
0 — but the early return also skipped updateWorldPauseIndicator, which is not a first-reason concern at
all: what the indicator says depends on WHICH reasons are held, not how many. So pressing Pause Story
and then idling took the idle hold while the screen went on saying only that the story was paused, and
the next mouse move lifted a hold nothing had announced. Freezing stays first-reason-only; the
indicator now refreshes on every added reason.

Layering is a property rather than decoration, and is asserted: above every ordinary modal, because the
world is frozen and nothing under it should be reachable, and below the stale-server banner and the
app-busy modal, which report infrastructure and in-flight storage work that must stay visible through a
pause. The Dungeon Master's Guide said a held world "is marked on the header clock", which is now
understated, so it says what the mask does and which of the two holds draws one.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The Tongue row was never gated on type, so a spellbook or a scroll carrying a language has been
drawing it correctly since the row shipped yesterday. What it could not do was ever have one: Editor
› Items drew its whole Tongue section behind `type === 'book'`, so nothing in the game could set a
language on anything else, and the row had nothing to show for either. The gate was the bug, not the
row — which is worth writing down, because "add it to spellbooks and scrolls" reads like a change to
the popup and the popup needed nothing.

WRITTEN_ITEM_TYPES is book, spellbook and scroll, named once beside WEAPON_ITEM_TYPES on the same
argument: a set the engine branches on in more than one place should be a set rather than three
string comparisons that can drift apart. What tongue a thing is written in is a fact about the OBJECT
— true of a spellbook in another hand and of a scroll nobody can do anything with yet — and the editor
now offers the select on all three.

The three LESSONS stay with the book, and that split is the whole of the design here. They are facts
about READING a thing rather than about the thing: an alphabet learned, a bilingual page, a word list
granted, and readBook is the only path in the engine that grants any of them. readSpellbook inscribes
spells and knows nothing of tongues, and nothing reads a scroll at all — `scroll` is a legacy type the
icon map and the inventory's Books shelf carry between them and no mechanic branches on. Drawn on
either, those three checkboxes would be grants with no code path behind them, which is the
control-that-looks-ready-and-does-nothing this file keeps having to relearn.

So the card says so where they would have been, rather than leaving an absence. A DM who has just set
a tongue on a spellbook and is hunting for the checkboxes a book has needs to be told they are missing
on purpose and why; an empty space below the select is a bug report waiting to be filed. The
item-authoring directive tells the Game Master the same split for the same reason, since the GM is the
thing most likely to author a spellbook and a directive describing the tongue as a book's alone would
teach it to omit the field on the two types that now take it.

Tests/test_book_tongue_popup.js grows a fifth section and six more sabotages, nineteen in all. The
three that matter guard the split from both sides: narrowing the set puts the spellbook back where it
was, widening it puts a language select on a sword, and confusing isBook with isWrittenType hands a
scroll three checkboxes that grant nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Point-in-time snapshot per Tools/gen-progress-report.js's own comment, so it
goes stale a day at a time rather than breaking. Regenerated after unshallowing
the checkout (the container starts these sessions from a shallow clone, which
would have undercounted the history the report reads): 3899 commits across 78
days (2026-06-30 to 2026-09-15), busiest day 2026-09-07 with 166 commits.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015bSmu48HRnKBKRWFPSYyLc

# Conflicts:
#	Designs/README.md

The language a written thing is in was named only at the moment of READING: bookPassageHTML puts it
beside the title and nothing before that point did. So a player holding a book they could not yet read
had nowhere to ask what it would take — which is the one question such an object raises, asked on the
one surface they could not reach. A written item's popup now carries a Tongue row.

Nothing is leaked by moving it earlier. Which tongue a thing is written in is a fact about the object,
visible to anyone holding it, and quite separate from being able to read a word of it — which is why
the reading path has always shown it unconditionally. The row is not gated on type either, because the
editor's own Tongue section is not: an item declaring a language says so whatever kind of thing it is.

Beside the name is what this character has of that tongue — how many of its words they know, and
whether its letters are still shapes. Those are the two halves of reading, they come apart in both
directions, and this is the only place either is said about a tongue the player has not opened the
Journal for. The tally keeps Journal › Languages' refusal: it is what they KNOW and never a fraction
of what exists, because a denominator is the author's word list, a number the game states nowhere
else, and printing it turns a vocabulary into a checklist.

The name opens the journal's own words dialog rather than a second one. knownLanguageWords already
answers "what do I know of this", and a second answer beside it would part company with the first the
moment a word was learned by a path only one of them had heard of. It goes to that tongue's page
rather than to the Journal tab, because the tab is a shelf of every tongue and the question this row
asks is about one of them.

Two things had to change in that dialog, and both are about the reader who arrives without having
chosen a letter. The letter is optional now: the journal's strip always has one to pass and a book has
none, because the player clicked a LANGUAGE and there is no letter in that gesture. It opens on the
first letter with anything under it — falling back to A opens most tongues on an empty page, which
reads as "you know nothing of this" on the one screen whose whole job is to show what you do know. And
the empty page learned to tell two situations apart: "no word beginning with K" is true and useless to
somebody who knows none of the tongue at all, and sends them round the strip to be told the same thing
twenty-five more times. A reader with nothing is now told they have nothing — and told which half they
do have, since the alphabet without the words is a real state and the commonest one to arrive in.

Tests/test_book_tongue_popup.js pins all of it, thirteen sabotages deep, each caught by a distinct
assertion. One of them caught the test rather than the code: the assertion that there is only one copy
of the dialog in the document searched the extracted <script>, where that markup never appears, so it
counted zero whatever the file held and passed against a build carrying two. It searches the file now.

Designs/dialects-and-languages.html gains §9b's second half, and its header chips are corrected while
they are being touched: they claimed P0–P1 shipped, Rev. 7 and ten decisions settled, against a
colophon saying P0–P3, Rev. 16 and eleven. The colophon is the line that has been maintained and §9b's
own build date agrees with it, so the header was brought to the colophon rather than the reverse.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The stale claim was in §4, the entry asking whether the Game Master can author into these rosters. It
recorded the answer for Religions on 11 Sep 2026 and then said "Languages and Folklore are unchanged:
their records exist and their rosters do not". Folklore's roster shipped the same day, in the same
change shape — requestFolkloreEdit and dmEditFolklore, returning rosterOutcome from every exit so a run
is graded on whether the world moved rather than on the call having returned — and the entry never
caught up. Languages alone is in the state that sentence describes.

The document already knew. §1's opening said two of the three have a Game Master, §5 recorded P2 as
shipped for Religions and named "the one built roster that still has no Game Master" in the singular,
and the colophon listed Folklore's roster outright. Only §4 disagreed, which is worth writing down as
the failure mode rather than just correcting: a decision entry is the part nobody revisits, because it
reads as settled history rather than as a claim about today. It is now noted in the entry itself.

A second count in §1 was stale in the same direction and nobody had noticed because it is arithmetic
rather than prose: "the two tabs with models keep live filters… the other four stay disabled". Three
tabs have models, so two stay disabled, not four. That one is now bound to something that fails —
Tests/test_culture_editor_tab.js already pins the split tab by tab, seven disabled write controls on
each tab without a model and a live filter on each of the three with one, so the paragraph cites the
test and the count cannot drift again in silence.

Designs/README.md carried the same claim one layer up and in a sharper form: "The GM request box stays
shut on all five, built rosters included… no authoring roster exists for any of them", stated in the
present tense, several sentences before the later line recording the box open on Religions and
Folklore. A reader scanning the index hit the false sentence first.

One correction to a correction, which is the part worth reading. Rewriting that row I also deleted
"Folklore's roster has no + Add yet", taking it for more of the same staleness. It is true: folklore is
not in RANDOM_ADD_KINDS and religions is, so the Game Master writes a tale on request and never invents
one unasked the way it founds a faith. Checked rather than assumed, restored, and worded so it no
longer reads as the roster being missing — and the Dungeon Master's Guide chapter now states the same
difference, since it describes both tabs a paragraph apart and a reader would otherwise wonder why one
has two buttons and the other one.

Rev. 10, moved in the chip and the colophon together so the two cannot disagree about which revision
the page is.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The gate asks for the two keys a playable install needs and said nothing about the other nine the vault
can hold. That is right for the interruption it is — somebody on their way into a game should not meet
a list of eleven providers — and wrong for the moment they are in, which is the one moment they have
their provider consoles open and their keys to hand. Finding the admin page a week later to add the
ElevenLabs key they had in the clipboard is a worse errand than a link at the bottom of the dialog.

So the payload now carries EVERY key slot with a `required` flag rather than only the required ones,
the dialog draws the required pair as before, and "List more keys" opens the rest underneath — the same
rows, drawn by the same function, saved down the same channel. What does not change is which of them
can stop a Play: `keysAreBlocking` reads the flag, and the Play button's countdown is over the required
rows alone. A rule reading "any card not set" would have held the launcher shut until somebody had
bought a key from all eleven providers, which is why the count and the gate are now two lines that both
say `needed` rather than one that says `cards`, and why the blocking rule is given optional cards to
refuse in its own test. The flag itself is still the vault's: the shell copies `!!p.required` and
decides nothing, so a third required card in MANAGED_KEYS still adds a third row to the top block.

An optional row says "not set" where a required one says "needed". They looked identical in the first
draft, and "needed" beside a lit Play button is a row calling itself a blocker while the evidence two
inches below says otherwise.

Three things were found by rendering it rather than by any assertion, which is the recurring lesson of
this dialog. The disclosure took no styling at all and drew as a grey system button in the middle of a
panel, because `.klink` was scoped to `.kcard` and the toggle is a sibling of the card list — now scoped
to `#keys`, which covers both. The card area needed a height cap and a scrollbar, because eleven rows
push the note and the Play button off the bottom of a laptop screen and a modal you cannot reach Play
in is a trap. And opening the section scrolled nowhere, so nine rows landed below the fold and the link
appeared to do nothing but rename itself; scrolling to the first new ROW then carried the heading and
both required rows off the top, which is worse. The view is hung on the TOGGLE — the boundary between
what the reader has dealt with and what they just asked for.

Thirteen sabotages against the new assertions, each caught by a distinct named one. The last of them is
a gap the first round missed: `tlr:keys` re-projects each card into a hand-written field list, and
dropping `required` from it is invisible — the page reads undefined, every card becomes optional, the
gate stops blocking and all eleven rows fold themselves away, with nothing thrown and nothing failing.
That list is now compared against what keyPayload actually built rather than read for one name.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The third and last link into text_adventure.html, and the one easiest to forget because it is on a
different site: "Play The Lost Realms" on the Brave You Worlds page, pointing at the absolute
https://thelostrealms.ai/text_adventure.html rather than at anything in its own directory. With the
landing page's two buttons already sent to the coming-soon page, this was the only way left in, and a
gate with one unlocked door is not a gate.

The absolute form is kept rather than made relative, because this page is served from another site and
a relative comingsoon.html would resolve against that one. It assumes the coming-soon page sits at the
realm's root, which is what the landing page's own hero button already assumes by linking to it
relatively from the deployed index.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The hero's "Play Now" was pointed at comingsoon.html when the game stopped being open to the public, and
the closing "Begin Your Journey" was not. So the page said two different things depending on how far
down it you were: the first button held the door and the last one opened it, which is the failure mode
of a gate applied per-link rather than per-page — nothing announces the one that was missed, and the
visitor who scrolls is exactly the visitor most likely to press it.

Both now lead to the same place. Worth knowing there is a THIRD way in that this change does not touch:
Web/Website/index.html carries a "Play The Lost Realms" button pointing at the absolute
https://thelostrealms.ai/text_adventure.html. It is a different page with a different label, so it is
left as it is rather than swept up — but if the intent is that nobody reaches the game yet, that door
is still open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

A new desktop install announced itself by being quiet. The launcher started, Play opened the game, the
world drew, and then nothing answered — because the vault had no Claude key and no Nano Banana key, and
the only repair was to already know there was an admin page behind the cog and which two of its dozen
cards mattered. Play checks first now: it asks the vault which required keys are set, and where one is
not, it offers a box for it with a link to that provider's console. Both stored, encrypted, in the
player's own vault; the launcher is told present-or-absent and never a key.

WHICH KEYS IS THE VAULT'S ANSWER, NOT THE LAUNCHER'S. The roster already carried a `required` flag that
did nothing but draw a badge on the admin page, and Nano Banana is marked with it now beside Claude —
the game runs without imagery, so that is a product decision rather than a mechanical one, and it is
made in one place. The dialog is built from whatever the vault sends back carrying that flag: its label,
what the key buys (the roster's own "Game Master · Narrations" against "Images · Gallery · Portraits
· …"), and where to get one. Neither the shell nor the page names a provider anywhere, so a third
required card adds a third row and needs no edit on this side. That rule has a test of its own, because
this repository has the equipment-slot roster to remember: pasted into two prompts, stale the moment a
slot was added, and silent about it.

THE GATE FAILS OPEN, and that asymmetry is the whole design. Only a vault positively saying a required
key is missing may stop a Play. An unreachable vault, a 401 from a remote one behind Auth0, a 403, a
reply that will not parse — each is "we do not know", and each opens the game exactly as before. A
player locked out of their own game by a failed lookup has nothing to try; a player who reaches the game
and finds the Game Master silent has the cog and this dialog. The rule is its own function so the test
can run it against every answer the bridge can produce, `info.ok !== true` included — a regex cannot
tell that from `!info.ok`, and the difference is a gate against a lock-out.

A KEY FROM THE ENVIRONMENT IS A KEY, and the admin API did not say so. `status` describes the key store,
which knows nothing about the ANTHROPIC_API_KEY fallback `resolveKey` has always used — so a vault
started that way reported its working Claude key as unconfigured. The admin page had been quietly
showing "not set" beside a provider it was making calls with; the new gate would have demanded a key
that no amount of typing could satisfy, since saving it changes nothing status reports. The payload
carries `envKeys` now, ids only, and both surfaces read it.

AND THE VAULT COULD NOT HAVE STORED A KEY ANYWAY. VAULT_MASTER_KEY is read from the environment, and
without it the key store is disabled and every POST answers 409. On a server somebody exports it beside
the access token; on a desktop nobody exports anything to press Play, so until now the admin page's own
Set button could not work either and env vars were the only route in. The shell mints one, on the same
argument as the access token it already mints — sealed with safeStorage where the platform has a
keychain, and kept outside the vault's data directory either way, because the claim in PRIVACY.md is
that the master key is never written beside the ciphertext and one directory copied off a machine is
the case that means. A Linux box with no keyring falls back to a 0600 file; that is a real downgrade,
so it is reported rather than assumed away — the dialog says which of the two happened, and says
neither for a vault this shell did not start, where how the key is kept is somebody else's business.

The channels are the narrow kind the launcher's others already are. A key is sent against an id the
main process matches to the roster it just read; the target is always CONFIG.url, so the page never
names a host; a provider's console opens by id like a news post opens by index, because
`tlr:open-external` is pinned to one hostname on purpose and these are four other people's domains.
Twenty-four sabotages were run against the new test and each is caught by a distinct named assertion.

Two older assertions moved with the code rather than being worked around: the status listener's "the
wait is over" must not release Play while the gate's own lookup is still running, and the settle loop's
name changed when the dialog's Play needed the same one — the first is a new case in test_vault_launch,
the second a rename that broke an assertion pinned to a local variable's name rather than its rule.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The Lore & Legends panel rotates every nine seconds, and the dots under it said how many scraps there
were and which one was showing. That is the read-out the first version set out to build, and the case
it does not cover is the ordinary one: a scrap starts to fade while you are still on its last line, and
the only way back is to sit through the rest of the rotation. The dots were already pointing at the
thing you wanted. They are buttons now.

The press has two halves and the second is the one easy to leave out. Moving the card without
restarting the clock hands back the scrap you asked for with whatever is left of the interval that was
already running — sometimes a second of it — which is precisely the complaint the control exists to
answer. So a jump restarts the timer. That in turn had to be reconciled with the hover pause, which
until now was expressed as "clear the timer on mouseenter": a restart that does not know a pointer is
resting on the panel undoes the pause the moment a dot is pressed, and the fade resumes under the
reader's cursor. The pause is a `held` flag now, and `tick` refuses to schedule while it or
`document.hidden` is set, which also collapses the visibilitychange handler into `tick` itself.

A 4px dot is not a target anybody can hit. The button is a 14px square whose background is clipped to
its 4px content box, so the padding is transparent and the row still reads as a line of small dots
while the thing you have to land on is the size of a fingertip; the gap is zero so the targets touch
and no press falls between two of them, and the negative margins take the padding back off the panel's
spacing so adding the hit area did not move the row. The container loses `aria-hidden` — buttons inside
an aria-hidden element are focusable and announced as nothing, which is the worst of both — and each
dot is labelled with its scrap's own title rather than a position, because "The Lantern in the Fen,
current" is the panel read aloud and "entry 3 of 8" is only meaningful to somebody who can see the row.
`jump` is declared before the cards are built and assigned after the single-scrap early return, so the
one dot of a one-scrap panel does nothing rather than throwing.

The test now runs the carousel instead of reading it. Everything a regex can establish about a dot —
that it is a button, that it carries a label, that a listener is attached — is true of an implementation
that shows the wrong scrap, leaves aria-current on the dot before it, or leaks a timer per press, so
`startLore` is lifted out of the page and driven against a small DOM and a clock that can be wound on.
Twelve sabotages were run against it and each is caught by a distinct named assertion. The hover
assertion above it was pinned to the exact text `box.addEventListener('mouseenter', stop)` and broke on
a refactor that changed nothing it meant to protect; it now asserts the listener rather than its body.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

A Lore & Legends panel in the bottom-right of the desktop launcher, cycling through eight short pieces
of the built-in world — the Shattering, the Fable of the Hollow Lantern, the Border Skirmish, and a few
of the things and people the world has written a history for.

THE TEXT IS GENERATED, NOT TYPED, and that is the whole of why this is a tool rather than six lines
pasted into the page. The obvious way to build this was to paste them, and this repository has a rule
about that written from having been bitten twice: the equipment-slot roster was copied into two prompts
and both went stale the moment a slot was added, with nothing anywhere to report it. So
Tools/build-launcher-lore.js reads WORLD_DATA and writes the block into landing.html, and `--check`
fails once the two have drifted. The desktop suite runs that check, so a session that rewrites a piece
of the world's lore finds out there rather than shipping a launcher quoting a sentence the world no
longer contains.

It writes INLINE rather than emitting a file the page loads, which is forced rather than chosen:
landing.html's CSP allows `script-src 'unsafe-inline'` and names no source at all, so there is no
<script src> this page could ever load. The same constraint that keeps the launcher working with the
network down decides how its generated data gets in.

The selection is a function of the world and nothing else, because `--check` compares the output and
anything shuffled would fail on alternate Tuesdays. The world's authored `lore` array comes first, in
its own order — those entries already carry the title the panel wants — then records with a `lore`
string by collection and id, titled with the thing's name, because a wraith's history reads as a legend
beside the canon.

The carousel is the small half. It pauses on hover, because having a scrap taken away mid-sentence
because nine seconds were up is the whole reason people dislike these; it stops entirely while the
window is hidden, or the launcher sitting behind the game for an hour wakes owing an hour of rotations;
a single scrap starts no timer at all; and the rotating area has a fixed height, without which the
corner resizes every few seconds and reads as a fault. It is absolutely positioned like #rail and
#admin rather than added to the body's flex column, which is title → news → footer and centres each of
them, and it takes itself off screen below 1120px where it would otherwise overlap the news column —
the window is resizable, so that is a real state.

THE FIRST RENDER SHOWED THE BUG THE TESTS DID NOT. A 230-character budget against a fixed 104px slot
cut the last line off inside the box. The budget is 160 now, and the browser check measures every
card's scrollHeight against the slot it rotates through rather than trusting that number — put the old
budget back and six of the eight report themselves 14px over.

CI named its desktop tests one by one, which is right (test_launch.js requires `electron` and the rest
deliberately do not) and had quietly fallen behind: test_tls had never been added, and the two tests
written for the news feed would not have run either. All five dependency-free ones are named now, the
lore check joins the item taxonomy's under generated references, and the list carries a note saying a
new test has to be added there as well as written. A test CI never runs is a test that passes forever.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

# Conflicts:
#	Handbook/dungeon-masters-guide.html

Culture was documented, which was not obvious from inside the guide and is why this was worth checking
before writing anything. It was spread across three places that did not point at each other: an
overview sentence buried in the World tab's opening paragraph, an h3 on Folklore and Religions at the
foot of that same section, and Languages — which has its own tab with a glyph sheet, a tracer and a
dictionary behind it — covered only over in Items, "alongside the item fields it feeds". A reader
looking for how to author a culture had to already know to look under World, and would still not find
Languages there.

It is now one chapter, Building Cultures, placed where it reads in the document and entered in the
table of contents. The World section keeps a one-line pointer instead of a second account of the same
features, and its own heading and opening sentence now name the five subtabs it actually covers.

Every claim was re-derived from the source rather than carried forward, which is how the stale one was
found: the guide said Folklore has no + Add button and a new tale must be authored through the box or
by hand. Folklore has had a + New menu for some time — a menu rather than a button because the kind is
chosen before the tale exists, a tale having to be drawn under a heading the engine will not guess.
The design doc had gone stale in the same direction, recording Folklore as a record without a roster
when dmEditFolklore is built and its box is live.

What is new rather than moved: Languages gets a proper account of its own tab — the record's fields
including speakers and the parent that makes a language a dialect, the glyph sheet dialog and its trial
run before a set is committed, the lexicon and its starter dictionary, and the two-and-a-half providers
behind all that. The four folklore kinds are given with the hints the New menu shows, and the fact that
an imported world's own kind is kept rather than rewritten into ours. Both tables now state the fields
a record actually carries, read off the normalizers, since those are what a DM sees on a card.

Three explanations are written down because they look like omissions and are not, and each one has cost
somebody an argument: why every control on Castes and Heraldry is disabled rather than wired to a
handler answering "not yet"; why a tale carries `unlocked` and `xp` rather than reusing `loreUnlocked`
and `loreXp`, which would have put every tale into the lore-hook readers as a subject whose lore is
empty; and why a religion has `worship` rather than `temple`. The chapter closes on the question that
decides whether Culture is a system or a notebook — what a record attaches to — with the answer the
region, and the standing caution that a line added to the world half of the system prompt is paid on
every cached turn in every world forever.

Two smaller things the pass turned up. The section wrapper needed closing by hand, since the chapter
was cut from inside World and would otherwise have inherited its closing tag; tag balance was checked
against the file as it stood before the edit rather than in the abstract, and the two deltas match. And
every in-page anchor in the guide now resolves to an id that exists, which is worth running again next
time a section moves.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Reported as nothing happening when a card is clicked, and that is exactly what it looked like. The click
was firing. The card builders are shared with the panels and each carries one hardcoded popup id, which
was right while every card had one home — so a card clicked in the dialog opened its popup in the panel
behind it. Measured: charinv-item-popup duly appeared, at zero by zero pixels, at z-index 45 under an
overlay at 200. No pixels and no error is indistinguishable from a control that does nothing.

The fix is one host resolved from WHERE THE CLICK CAME FROM rather than a second set of cards for the
dialog. charsheetPopupHost(el, fallback) answers the dialog's own popup when the element is inside
#character-sheet-modal and the panel's otherwise, so openInventoryCardItem serves the Inventory tab and
four tabs of the dialog from one path, and a card added tomorrow gets this by going through the same
opener. The panels are untouched.

The dialog's popup lives INSIDE .charsheet-box, which is already position:relative, so it is placed
against the dialog, clipped to it, and stacks inside the overlay's context instead of behind it — a
sibling of the body rather than a child, so redrawing a tab cannot tear down an open popup mid-read. It
sits below the tab strip rather than at the app's usual top:14px, because a popup over the strip covers
the one control a reader needs to put it away. It is registered in BOTH id rosters: unregistered in
ITEM_POPUP_IDS an item edited while the dialog is open would not refresh in it and Consume would leave it
standing, and unregistered in ENTITY_POPUP_IDS the same subject could sit open in two popups at once.

Factions needed their own branch. Everything in showFactionDetailFromLink positions the global popup in
VIEWPORT coordinates measured off a .panel-view or .editor-subview ancestor, neither of which the dialog
has, so it fell back to the window's top-right corner beneath the overlay. From the dialog it renders
into the dialog's host instead.

Skills were inert on the panel — no onclick anywhere, cursor:auto — because the Skills tab puts
everything a skill has on the face of the card and has nowhere to open a popup. The dialog has room, so
its skill cards are WRAPPED in a clickable element rather than the shared builder being taught about it:
the panel did not ask for this, and the wrapper leaves the card's own markup byte-for-byte what the panel
draws. Spell cards already expand in place and are left alone; an ability has no popup to open.

Verified in Chromium: all five card kinds open a 264×~350 popup at 979,160 inside a 1080×738 box at
180,81, with the right subject in each and no stray popup anywhere else.

Two things worth recording. Tests/test_skill_card_xp_pinned.js failed on the hover rule, and it was right
to: it finds the card's rule by regex on the FIRST occurrence of ".skill-card {" in the stylesheet, this
block sits earlier in the file, and a selector ending in .skill-card silently shadowed the real one — so
every assertion about the card's layout began reading my three-line hover rule instead. The child rules
are written `> *` now, with the collision recorded above them. And my own first assertion for the faction
route grepped the function source for 'charsheet-entity-popup', which survives happily in a branch that
has been switched off; disabling the route passed. It calls the function and reads what landed in the
popup body now, which needed the test's DOM mock to memoise querySelector — returning a fresh element per
call meant the app could write into a body the test could never read back, quietly turning behavioural
assertions into no-ops.

Thirteen sabotages, each caught by an assertion naming its own cause.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

THE TITLES. Each post's heading is now pressable and opens that post in the system browser. It opens BY
INDEX: the page says "open number 1" and the main process opens the link it parsed and validated itself,
so no URL ever crosses from the renderer. The alternative was widening `tlr:open-external`, which is
deliberately pinned to one hostname — a feed's links are on somebody else's domain, and loosening that
guard to fit them would have turned a one-host channel into "open anything in the system browser",
reachable by any script that ever runs in the launcher, for the sake of three links this side already
holds. It is a <button> rather than an <a href> for the same reason there is nothing to put in an href,
and because a middle-click or a "copy link address" on an anchor with no URL comes up empty. A post the
feed gave no link is still drawn — as its title, not as a dead control.

AND THE BUG THAT FOUND ITSELF ON THE FIRST KEYPRESS. The launcher's "Enter / Space anywhere plays"
handler cancels the key so the page never needs a mouse, and it stepped aside for exactly two things:
`e.target === adminBtn || e.target === startBtn`. That was the complete list while those were the only
focusable elements on the page. A news title is a button, so Enter on a focused one was preventDefault'd
there and turned into Play: the launcher opened the GAME instead of the post, with nothing on screen to
say why. The rule asks what the target IS now rather than naming controls one at a time, so the next
control added to this page does not have to remember to come here. Caught by pressing Enter on one in a
browser, not by reading the file — which is why the test RUNS the shipping handler against a focused
button and a bare page rather than matching its text. The two-name version fails it.

THE HALO TEST was failing on #admin, and it turns out not to have been the design question I took it
for. #admin has no text in it at all: it is a <span class="cog"> drawn as a CSS mask with a
background-color, and text-shadow has nothing to act on. It was on that roster while it was the word
"Admin"; #news took its place in the rule and takes its place here, being three posts of headings and
body copy straight over the backdrop. Dropping #admin from the list is not dropping the requirement,
so the requirement it actually meets is now asserted instead: a glyph button solves the same problem
the other way, with a dark scrim and a border so the shape sits on its own ground rather than on
whatever the village is doing behind it. #rail a is built the same way and is checked beside it. The
roster's own comment now says how to decide membership — every element that renders TEXT over the
picture — which is the question that was being answered by habit.

Two guards tripped on the way and both were working as intended. test_config pins the preload's exact
member list because a new member there is a new capability handed to the page; `openNews` is one, and it
took an edit somebody had to think about. test_vault_launch pinned the keyboard exemption by its old
spelling; it matches the new rule, and test_news_feed runs it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The three posts on the launcher were hand-written. Not because nothing had been built to replace them —
landing.html already had the block, the rows, a NEWS_URL and a call to `api.news(url)`, and
landing-preload already exposed `news()`. What it did not have was anything on the other end: no
`tlr:news` handler existed in main.js, so every call rejected, the page's own `.catch(() => {})`
swallowed the rejection exactly as designed, and NEWS_STUB stood in for a feed that was never read. A
bridge with one end missing fails silently by construction, and it looked like a working launcher.

So this builds that end, pointed at the blog's RSS feed, and takes the three most recent posts.

THE PAGE STILL FETCHES NOTHING, which is the constraint the whole shape follows from. landing.html
ships `default-src 'none'` with no http(s) source anywhere in it, and its own comment says why: "the
moment this page could fetch from the network it would stop being the thing that works when the network
does not." A launcher is what you see when the vault is down. So the main process fetches and parses,
the renderer is handed rows of plain strings, and the CSP is untouched — a connect-src for the feed
would have been one line and the wrong one.

A FEED IS THIRD-PARTY HTML. Whoever controls it writes the titles, and beehiiv puts a whole post's
markup in <description>. Every field is reduced to text here: CDATA unwrapped, tags stripped, entities
decoded, and the renderer writes textContent into elements it creates. The order inside that is
load-bearing and is pinned by its own assertion — tags are stripped BEFORE entities are decoded,
because decoding first turns an escaped `&lt;script&gt;` into a real tag the stripper has already run
past, and `&amp;` decodes last or `&amp;lt;` decodes twice into one. The rows carry no links, so nothing
here can ask the shell to open anything, and the handler refuses any URL that is not https — it takes a
URL from the page, and one that fetched any scheme any caller named would be a "fetch this and hand me
the body" gadget living in the main process.

Two things the first real render showed rather than the tests. A tag becomes a SPACE (or
"<em>a</em><em>b</em>" reads "ab"), which left "the builder , so" wherever a tag closed before a comma;
and the date came out "9 Aug 2026" where the stub beside it pads to "09 Aug 2026", which shifts that
row's month a character out of line in a column that is the left edge of every row. Both are fixed and
both have an assertion. The date is also spelt out from a three-letter table rather than
toLocaleDateString: en-GB renders September as "Sept" on a full-ICU Node and "Sep" on a small-icu one,
so the format would have depended on how the shipping binary was built.

PRIVACY.md said there is no phone-home in the game, the vault, the registry or the desktop shell, and
that stops being true the moment this works: the launcher now makes one outbound request on its own
account. It is named there rather than left to be discovered — what it sends (the request, and nothing
else), what it does not (no identifier, no version, nothing about your worlds), that it is kept for half
an hour so re-opening the launcher between games does not ask again, and that TLR_NEWS=0 turns it off.
The switch exists because the document promises it; the test asserts both halves, because a documented
opt-out that was quietly dropped is worse than one that never existed.

Two Electron tests were already failing on a clean tree and are fixed here, both for the same reason —
each pinned a SPELLING rather than a property, and the news block's own arrival moved it.
test_vault_launch lifted the status listener by slicing between two landmarks and taking the last `});`
in between; a block of link-wiring landed in that gap, the fragment came out unbalanced, and the test
died of a SyntaxError describing nothing about the listener it tests. It brace-matches now. test_config
pins the preload's exact member list, which is right — a new member there is a new capability handed to
the page and should take an edit somebody thinks about — but `news` and `openExternal` were never added
to it. A suite with a known-red test in it stops being read, which is how the missing handler survived.

One failure is left and is not mine to settle: test_vault_launch asserts that #admin carries the text
halo, and #admin is now a cog glyph rather than a word. Whether an icon wants that halo is a question
about somebody's in-flight design, not a spelling, so it is reported rather than guessed at.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Four changes to the dialog, three of them about the fact that a sheet is one object and ought to behave
like one.

THE BOX NO LONGER JUMPS. It had max-height, so it shrank to its contents — a short Abilities tab and a
long Inventory one gave two different dialogs, and the tab strip and the footer moved under the cursor
every time somebody changed tabs. It is a fixed height now. Measured in Chromium rather than reasoned
about: every one of the seven tabs renders a 1080×738 box at the same top, with the footer at the same y.

THE PORTRAIT STAYS PUT. The body used to be the scroller, which meant it scrolled the portrait away —
the opposite of what a render beside a column of numbers is for. The body no longer scrolls at all;
each tab owns its own scrolling, because Profile needs two scrollers and the others need one. Profile is
now a fixed left column with the render pinned at its top and the facts column scrolling beside it: the
portrait's top is unchanged after scrolling the right column 291px. Below 780px it collapses to one
column that scrolls as a whole, since a fixed portrait is worth its space beside the numbers and is only
in the way above them.

THE GALLERY rides under the render, through the panel's own galleryThumbs — the same thumbnails, the same
drag-onto-the-portrait and remove affordances — and scrolls within the column rather than pushing the
portrait down it. A character with no portraits gets no empty frame. What did NOT come with it is the
prompt box and its Generate button, and the reason is technical rather than editorial: they are addressed
by id, and a second #char-gallery-prompt would give the document two elements with one id, where
getElementById answers with the first — so the panel's box would quietly swallow what was typed into the
dialog's. Generating a variation stays where the rest of the portrait-making lives.

PRINT AND CLOSE sit in a row outside the scrolling body, so they cannot scroll away. Print lays the whole
character out as one page — every section, not the open tab, because the tabs are a screen affordance and
mean nothing on paper — and opens it in the same chromeless popup Make a Book uses, through the same
openBookWindow / printBookWindow pair, so the two printable things in this app behave alike and a
pop-up blocker is reported the same way.

The printed sheet is written for paper rather than reusing the screen's markup, and that is the one place
in this feature where a second rendering is the right answer. The dialog is a dark theme: printed, a
browser either floods the page with black or drops the backgrounds and leaves pale gold on white. Bars do
not print either — a bar is a picture of a number, and it comes out an empty rectangle — so vitals print
as numbers. It composes from the same DATA the dialog reads, so what the sheet SAYS is still shared
upstream of both; only the presentation differs, because the medium does.

Fourteen sabotages, and three of them failed to fire first time — each because of a flaw in my assertion
rather than in the code, which is worth recording. "charsheet-render" is a PREFIX of
"charsheet-rendercol", so an indexOf on the bare class always matched the column and the gallery could be
moved above the render without the ordering check noticing; it matches the full attribute now. The
footer's position was compared against indexOf of the body, and a sabotage that DELETED the body gave -1,
which every position beats; it requires the body to exist and to close first. And the paper-markup check
listed four class names by hand and missed char-coin, so pasting the screen's wealth block straight into
the printout sailed through; it matches the app's class prefixes instead.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Clicking the portrait block used to call switchTab('character') and switchCharacterTab('profile'): it
answered a glance at your own sheet by taking the story off the screen, and the reader had to find their
way back. It opens a tabbed dialog now — Profile first, then Abilities, Skills, Factions, Inventory,
Magic and Treasure — over whatever they were reading, and closing it leaves them exactly where they were.
The quick-popup's own portrait rides the same entry point, so the two portraits in this app answer a
click the same way; the comment there claimed the old behaviour and has been corrected.

Profile puts the full-body render on the left and what the sheet SAYS on the right: who they are, their
wealth, vitals, attributes and current statuses, with ailments beside the statuses where they belong.
Appearance and Background are deliberately absent. They are the two long click-to-edit prose fields, and
this dialog is a glance rather than an editor — they stay on Character › Profile, which is also why the
render here carries no upload or paint controls and why the Gallery did not come along. The panel keeps
its own entry point, openCharacterProfilePanel, for the things that mean the editing surface.

The real risk in a second surface is not that it looks wrong, it is that it computes the character a
SECOND time — a dialog with its own idea of a vital drifts from the panel the first time either changes,
and nothing fails, because both screens go on rendering. So three builders were lifted out of their
renderers to be shared: buildCharacterSheetParts out of renderCharacter, buildCharacterFactionCard out of
renderCharacterFactions, and buildSkillCard and inventoryCardHTML were already standalone. Both
extractions were proved neutral before anything was built on them — the panel's Profile and Factions
views were rendered from the pristine file and from the refactored one and compared byte for byte, 16,388
bytes identical. The test asserts the sharing rather than trusting the comment: it looks for the
builder's own wealth, attribute and vitals HTML inside BOTH renderings, which a reworded call cannot
satisfy and a lookalike card cannot fake.

Two defects in the new dialog were caught by things other than me, which is the part worth recording.
test_dialog_close_buttons — a guard written for exactly this — failed on the day the box was added:
.modal-box declares no position, so a box that does not name itself the positioned ancestor sends its ×
to the corner of the SCREEN, and an unpadded title runs underneath it. And the cards came out enormous,
with thumbnails the height of the dialog, because I had invented a grid: an item card is drawn for the
Inventory panel's 132px column and I dropped it into a 240px one. Every assertion passed — the markup was
right and only the box was wrong — and only a screenshot showed it. Each tab now reuses its panel's own
container too: .invc-grid for items, .skills-grid for skills, a plain stack for the two kinds the panels
stack rather than grid.

An open sheet follows the character. updateSidebar refreshes it, guarded on the dialog actually being
open, because a snapshot left on screen across a turn that spent a potion or took a wound would be lying
about both and the reader cannot tell a stale dialog from a true one.

test_portrait_block asserted the old jump and is retargeted rather than deleted. Its second assertion is
worth a word: "openCharacterProfile selects the Profile subtab" went on PASSING after the change, because
activeCharacterTab is 'profile' from startup and nothing had moved it — it was asserting a default rather
than an effect, which is the kind of green that hides a change instead of catching it.

Sixteen sabotages, each caught by an assertion naming its own cause, including the portrait reverting to
the tab jump, Appearance creeping back onto Profile, each card tab regrowing a card of its own, the
Spellbooks group losing its caster gate, and the open dialog going stale.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The desktop shell could not start its vault: "The Server Vault did not start. It started and then
stopped", over a raw Node stack naming syscall 'listen', address '::1', port 8787. The vault was
fighting itself.

`server.listen(port, 'localhost')` does not bind localhost. It RESOLVES the name and binds whichever
family comes back first, and since Node 17 the default result order is `verbatim` — so on Windows that
is ::1 and on most Linux it is 127.0.0.1. Separately, a loopback bind also opens a SECOND listener on
::1 so that both stacks answer whichever way the name resolves, which is a good thing that has been
right since it landed. Put the two together and they are a collision: the twin takes [::1]:8787, the
main listener resolves `localhost` to ::1 and finds the twin already there, and the bind fails
EADDRINUSE on a port nothing else on the machine is using.

It took the desktop shell to expose it, because `node Server/server.js` defaults VAULT_HOST to the
literal 127.0.0.1 and never resolves anything. Electron passes VAULT_HOST=localhost — correctly: the
hostname in its own configured vault URL is the one fact both halves must agree on, and it sets it
rather than trusting the server to default to the same place it will look. The name was always going to
arrive one day; the twin is simply what made a name fatal.

So the listen target is a literal now, decided by core.loopbackBindHost rather than by a resolver: a
loopback NAME becomes 127.0.0.1 and the twin keeps ::1, both stacks are served, and the two addresses
cannot be the same one. `::1` asked for outright is left alone — that operator wants v6, and no twin is
drawn for it. A non-loopback host is untouched, since a real hostname is the operator's to resolve.
cfg.host is not itself rewritten: it is what the operator said and what the startup banner and the
origin URL quote, and those were never wrong.

THE SECOND DEFECT IS THE ONE THAT WILL MATTER NEXT TIME. The main listener had no 'error' handler at
all, so any failed bind — this one, a port genuinely in use, a privileged port, an address that is not
on the machine — was an unhandled 'error' event: Node printed a stack trace and the process exited.
That is what the shell put in front of a player, and it is why a bug about IPv6 resolution reached
somebody as a screenshot of a Node dump. There is a handler now, it names the address and the code, and
for the three causes worth telling apart it says what to do — a second vault on the port being much the
likeliest, and the one the next report will be about.

The test spawns the real server the way the shell does and asserts it is still alive, then starts a
second on the same port and asserts that one exits with words rather than a stack. It also says plainly
what that half cannot do: the collision needs a machine where `localhost` resolves to ::1 first, and a
container with no IPv6 loopback at all cannot stage it — the twin fails EAFNOSUPPORT and nothing
collides however the bind host is computed. The sections above it carry the property everywhere, and
one of them states it outright rather than by proxy: whatever VAULT_HOST says, the two addresses the
vault binds must differ. Reproduced before the fix by pointing the twin at the address `localhost`
resolves to on this machine, which is the same collision with the families swapped, and it failed
exactly as reported.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Reported by the owner: the Google Nano Banana Pro terms are saved alongside the Suno terms and the lawyer
brief documents, outside this repository in the same place as the D-2 founder assignment. That was the
outstanding item on two ledger entries and in D-10, all three of which named it as retrieval by a person.

Recorded as what it is and no more. The retrieval half is done; the reading half is not, and deliberately
so — nobody in this repository has read those terms, no session has seen them, and this record still says
nothing whatever about what they grant. That restraint is the whole point: the first version of the Suno
paragraph asserted flatly what Suno's paid tiers grant, which was a session's recollection of a third
party's terms written into a provenance record as though it were a finding, and it was corrected at
length. Writing a second such sentence now, with the documents finally in a drawer somebody can open,
would be the same mistake with better cover. So the item does not close, it MOVES: from a retrieval task
to part of the lawyer's pass in §12, which the documents are now sitting with, and §12's blocking line
says so. The Suno plan receipt is not separately confirmed in the owner's report and stays named.

Two more assets arrived unaccounted in the same merge — the Modder's Guide illustrations of the
SampleBlock extension, in the owner's commit "modder images" — so the suite was red again on main for the
same reason as the dungeon GIF. Both were opened and looked at: a full-window capture of the game with the
chrome in shot, showing the sidebar carrying the extension's FIELD NOTES panel and its MOD tag, and a crop
of that same sidebar at the same rendering. Both carry a drawn callout reading "Added by the Sample
Sidebar Block mod", which is an authored addition on top of the capture rather than anything the app draws.

They are the same MIXED case the catacombs recording is filed under, and are recorded as one rather than
left to the bucket's blurb to cover: the capture and the annotation are authored, while the character
portrait, its gallery thumbnails and the room art inside the window are the game's own generated
illustration and already declared here as OWNER — AI generated, so D-10 reaches those pixels. It is a far
smaller share of the frame than in the GIF — most of what these show is interface, type and chrome — but
the distinction is the same one and eliding it because the proportion is favourable is how a bucket ends
up promising what it cannot.

Which is the second time in two days that correction has earned its keep: the screenshot blurb stopped
claiming authored-in-the-ordinary-way for every member yesterday, and today two more mixed files landed in
that bucket.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The checkout had been a shallow clone again, so the report was regenerated
from a truncated log. Ran git fetch --unshallow against origin, then
Tools/gen-progress-report.js against the full history: 3,866 commits across
77 days, June 30 through September 14th, busiest day September 7th (166).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AAnZMg7vkzkzaL6RNeQHL

The previous commit put the two screenshots in Designs/modding.html alone, which is the design
document rather than the guide somebody reads to write a mod. Both editions of the Modder's Guide
describe the sample block in prose and neither had ever shown it, so both carry it now — the screen
edition and the print one — and the design document keeps its pair as well.

The captions are not the same text in the two places, because the readers are not the same person.
The design document is arguing that the white-box approach pays for itself, so its captions say what
the pictures PROVE: that everything above the block's body is the engine's markup copied, and that
every row of the conventions table is visible in the wide shot. The guide's reader is about to fork
the folder, so its captions say what to DO — which parts are yours to replace, which to keep, and what
it means if your block lands at the bottom of the sidebar or without a caret. Both name the MOD badge
for the same reason, and it is the one worth repeating: it is the only thing on screen that tells a
player a block came from an extension rather than from the game, and hovering it says which extension,
so a fork that drops it leaves a player with something they cannot trace and therefore cannot turn off.

One copy of each file, under Handbook/modders-images/, referenced by the guide beside it and by the
design document one directory up. That also undoes the inventory change the previous commit made:
Handbook/ is already in DIRS and the scan recurses, which is how Handbook/dmg-images has been covered
since it was added, so the pictures land somewhere already walked and a new directory under Designs/
never has to be named. The reasoning that entry carried — that a media directory the scan does not
reach is absent rather than UNKNOWN, so --check passes while the report stops describing the tree — is
right and is why the files went to the side of the repository that was already covered.

Both editions gained a narrow-figure rule and the crop uses it. It is a portrait cut of a single
sidebar block: at the full column width it would print about nine inches tall, larger than the screen
it came out of, which is emphasis nobody meant.

THE TWO IMAGE FILES ARE STILL NOT IN THE REPOSITORY, for the reason the previous commit gave — they
were supplied as attachments and a session cannot write an attachment's bytes to disk. Four figures
across three documents now render their alt text until the owner drops
Handbook/modders-images/sample-block-closeup.png and .../sample-block-sidebar.png into place, and the
provenance ledger entry is written in that same pass, since a declaration naming a file that does not
exist is the stale entry Tests/test_asset_provenance.js exists to catch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Section 01's claims about Extensions/SampleBlock/ are all claims about how it LOOKS beside the
engine's own blocks: that it wears the same header, sits where it was injected, survives every sidebar
refresh, and carries the native affordances without being given an API for any of them. A table
asserting that is asking to be taken on trust, and a picture settles it — so the section now carries
two, a close-up of the block and the same block in place in a running game.

The captions carry the argument rather than restating the surrounding prose. The close-up's says that
everything above the body is the engine's own markup copied, that what the mod actually wrote is the
heading, two lines and the Refresh button, and that the MOD badge is the only thing on screen saying a
block is not the game's — hovering it names the mod, because a block that cannot be traced back to its
extension is one a player has no way to turn off. The wide shot's points out that every row of the
table above it is visible in the picture, and then names the window: it is Chrome, with the extensions
puzzle-piece in its title bar, which is what makes the callout immediately below it land as a fact
about the screenshot rather than as a caveat about somewhere else.

These are the first pictures in any document under Designs/, so the shared style block gains a
figure.shot rule, and the inventory gains a directory. Designs/modding-images is named as a LEAF, on
the same reasoning the four Web/ entries in that list already carry and for the same reason Handbook/
is in it: Designs/ holds the documents themselves, which are source, so the entry names the folder
that holds only pictures. That list's own comment records what the alternative costs — a media
directory the scan never walks is not reported UNKNOWN, it is absent, so --check passes while the
report quietly stops describing the tree, which is how two shipped files sat unmentioned for a week.
Adding the directory alongside the markup means the two PNGs are demanded by the suite the moment they
land rather than whenever somebody next regenerates the inventory.

THE TWO IMAGE FILES ARE NOT IN THIS COMMIT. They were supplied as attachments in the session that
wrote this, and a session cannot write an attachment's bytes to disk — so the markup, the styling and
the inventory entry are here, pointing at Designs/modding-images/sample-block-closeup.png and
.../sample-block-sidebar.png, and the document renders its alt text until the owner drops the two
files in. The provenance ledger entry is deliberately absent too: a declaration naming a file that
does not exist is the stale entry Tests/test_asset_provenance.js exists to catch, so it is written in
the same pass that adds the files.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The landing page's dungeon GIF had no marker and no ledger line, so the inventory reported it UNKNOWN and
the suite was red on main from the commit that added it. The owner states they recorded it from their
desktop and that the dungeon tile imagery in it was generated with Nano Banana Pro. That settles it, and
the file was looked at rather than taken on trust: two frames decoded out of fifty, both showing the
Dungeon Builder in a browser window with the chrome in shot — tab strip, window controls, the title bar
naming the world — over the app's own interface, and differing by a step and a turn, so it is a recording
of somebody walking the corridor and not a still.

What the file says about itself is HANDLING and not origin, which is why the marker readers left it
UNKNOWN and why a declaration was needed at all. It carries a C2PA manifest whose action is
com.anthropic.claude.provided, with origin-confidence "unknown" and a description saying Claude provided
the file and may have created or modified it, plus an ezgif marker further in. Those name a conversation
the file passed through and a web optimiser that processed it; neither is a claim about what made the
content, and the sibling Dungeon Builder GIF recorded on 7 September carries the same shape of credential
for the same reason.

Filed as a screenshot, because that is the mechanism, and recorded as a MIXED case rather than under
whichever half is more convenient. The capture, the route walked and the framing are the owner's; most of
every frame is the generated tile set, which is declared separately in this ledger as OWNER — AI
generated. So D-10's question reaches the pixels even though it does not reach the act of capturing.

Which turned out to be a defect in the report rather than only a subtlety in the entry. The generated
blurb for the screenshot bucket ended "Authored work in the ordinary way: the copyrightability question
below does not touch these" — true of every member until this one joined, and now a blanket claim the
report makes over a file where it is false, in a document whose own header calls it evidence for D-5. A
generated sentence cannot know which members are mixed, so it no longer claims for all of them what is
true of most, and points at the individual declarations for the judgement.

Nothing is written here about Nano Banana Pro's terms. What is known is the owner's statement naming the
tool; what nobody in this repository has seen is the grant, which plan, or the output-ownership clause in
force on the generation date. The Suno entry in this ledger was corrected once for exactly that mistake —
a session's recollection of a third party's terms written down as though it were a finding — and it says
so at length. This is a retrieval task for a person.

The CSV export needed the second flag: it is written only under --csv, so the plain run left it a row
short of the report, and Tests/test_asset_provenance.js caught the mismatch and named the command.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Asked whether the races and dungeons rosters can write lore, the answer turned out to be one of each.

Races were the first kind this was fixed for and are complete: raceFieldPatch takes lore, loreKey and
loreXp, the scope line names all three, the lore bullet asks a price where it mandates a secret, and the
roster row reports an unpriced race as unset rather than blank. Tests/test_race_lore_xp.js pins all four
layers and tells that story; nothing needed doing beyond a guard here against a quiet regression to the
shape the other two were found in.

Dungeons were the half-case, and it is the same half as factions had. That roster could always write a
dungeon's lore and loreKey — its bullet mandates the pair in as many words, "if you set one, set both" —
and had no way to say what the secret was worth, so every buried place in every world paid the flat
default. The bullet now asks a price on the absolute scale shared with rooms, beings, items, orders and
peoples, and loreXp joins DUNGEON_GM_FIELDS so the scope line and the roster both pick it up from one
list rather than three hand-kept copies.

That list is prose apart from this one field, and both readers had to learn it. The applier stringifies
every field it copies, which is right for the seven that are sentences and wrong for the one that is a
number: String(35) stores "35", which compares unequal to itself on the next pass and reads as a string
anywhere a card or a comparison expects a number. The roster renders `d[f] ? … : '(empty)'`, and 0 is
falsy — so a secret deliberately priced at nothing would have been reported as unwritten, which is the
opposite of what it says. Both now carve the field out and go through normalizeLoreXp, the one gatekeeper
that clamps, accepts a numeric string and keeps null distinct from 0.

Proved end to end against a stubbed GM rather than assumed: the roster line reads UNPRICED before the
call, the directive carries the field and the bullet, a model answering with the string "35" leaves a
NUMBER 35 on the record, it survives serialize and rebuild, and loreHookXp pays 35 where an unpriced
dungeon still pays 12.

The Dungeon Master's Guide was wrong in three places, in the way the code comments were wrong: its
Dungeons row called the lore fields a "trio" and listed text, key and the unlocked flag, omitting the
price entirely — the same word that let the fourth field go missing from two normalizers. Races and Items
had the same gap in their tables. All three now name loreXp, and the Last Update stamp is current.

Six sabotages, each caught by an assertion naming its own cause: the field removed from the list, the
bullet's price demand and its absolute-scale clause each removed, the roster reporting an unpriced
dungeon as "(empty)", the applier's carve-out deleted so the price stringifies, and the roster reading the
raw field instead of normalizing. One of those assertions was worthless when written — it sliced forward
from requestDungeonEdit looking for dmEditDungeons, which sits EARLIER in the file, so indexOf returned
-1 and five checks passed against an empty string. The slice is fixed and the section now asserts it
caught a body before asserting anything about it.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

There was no inline text to move. The Drink / Eat / Use button has always carried a native `title`
rather than a paragraph, so the clutter this was asked to remove was not there — but bringing it to the
same standard as the map's Return button turned up three things that were.

The tooltip repeated what the reader was already looking at. It read "Drink Health Potion — this takes
a turn, and the Game Master decides what it does": the first word is the button's own label and the
next two are the title at the top of the same popup, so two thirds of it described the screen it was
floating over. What is left is the part that is nowhere else — that pressing it spends a turn, and that
nothing in the engine decides the outcome.

It was also the one unlabelled bubble among the app's titled ones. A `title` does become a tooltip —
adoptNativeTitle moves it into data-tip on first contact — but it arrives with no HEAD, so this one
rendered as a bare body while every tooltip beside it carries a gold heading. It is an explicit
data-tip/data-tiphead now, headed with the verb, and the title is gone rather than left beside it:
adoptNativeTitle's rule is that the newest title wins, so a leftover one would silently overwrite the
head-bearing tip on the first hover. On the button rather than the row, which is where Return's had to
go — that one has disabled states and a disabled button fires no mouse events; this one is never
disabled, so it can anchor to the control itself. aria-label carries the same words label-first, so
anyone who cannot hover gets the cost and the item without the button losing its name.

And nothing in the Field Guide had ever mentioned the button. "Short on hover, the rest in the guide"
is half a sentence if the second half does not exist, so Everything you carry now says the three things
a tooltip has no room for: that there is no hidden table of effects and the Game Master settles the
outcome from the item's own description, that a thing on the floor offers Loot instead because it is
not yours yet, and that the popup shuts as the turn goes because the turn is about to spend the thing
the card was describing. Its Last Update stamp moves with it.

The existing assertion for the turn cost searched the whole rendered popup for the words, which an item
whose description happened to contain them would have satisfied with the tooltip gone entirely; it
reads the tip's own text now. The new ones are written against deliberate breaks — the title coming
back, the head being dropped, the tip growing the verb and the item name again, prose returning to the
row, and each of the guide's three claims removed one at a time.

One thing worth recording because it cost twenty minutes and was not a bug: driving this in a browser,
the tooltip kept appearing and vanishing. The event log showed a real mouseout on the button
immediately after the mouseover — the popup was still smooth-scrolling when the harness fixed on a
coordinate, so the button slid out from under a cursor that had been placed where it used to be.
Settling the scroll first fixes the test. Nothing about the page needed changing, and a human hovering
a button that is standing still never sees it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The roster that knows what an order IS could not write the one thing about it that is hidden.
normalizeFaction has carried lore, loreKey and loreUnlocked since the field existed, and
factionFieldPatch took none of them — so a DM asking the Factions box for an order's secret got a
refusal that was true of the whitelist and false of the data model. That is word for word what
raceFieldPatch was doing before it was fixed, and the note there says so; this is the same four layers,
on the tab one over.

The whitelist now takes lore, loreKey and loreXp, the price through normalizeLoreXp so it is clamped and
so a quoted number arrives as a number. The SCOPE line lists them, because the model reads that line as
the whole of its permission and correctly refuses a field missing from it. A bullet beside "reveal"
explains what they are and — the part that started this — asks a price wherever it mandates a secret, on
the absolute scale shared with the world's places, beings, items and peoples, saying plainly that an
omitted price is not free but the flat default. And the existing-factions roster now says, per order,
whether a secret is authored, how it is earned, and whether it has a price, because a field the GM may
write has to be one it can read — the rule the rank ladder, the order's values and its duties each had
to learn in turn, reached a fourth time by a fourth field.

This is a SECOND door and not a replacement. The Lore tab could always write a faction's lore and still
can; what it cannot do is write an order's hidden history in the same breath as its public one, which is
how the two come out consistent. `loreUnlocked` is deliberately not in the whitelist and the directive
refuses it in words as well: whether a character has EARNED a secret is play state, not authorship, and
a roster that could flip it would hand the player a hook they never earned.

Proved end to end rather than assumed, per the rule that a roster is the GM's only when it can actually
make the edit: a spec through applyFactionSpec lands on the record by both branches — merged onto an
existing order and assigned onto a newly created one — survives serialize and rebuild, and loreHookXp
reads 38 back out of it where an unpriced order still pays the flat 12.

Two test repairs, and the second is the more interesting. Tests/test_lore_xp_survives_normalize.js gained
the roster sections, and its first version of "the row carries the secret" was worthless: it grepped the
function for the sentence, which goes on sitting in the source when nothing interpolates it, so dropping
the bit from the template passed. It pins the row template now. test_faction_duties had exactly that
assertion already — the comment above it records learning the same lesson — but spelled as the literal
run `${values}${dutyBit}${ladder}`, which asserted the NEIGHBOURS rather than the claim and broke the
moment a fifth bit was inserted between two of them. It pins ${dutyBit} in the row instead, and anchors
inside requestFactionEdit first, because four rosters in this file open a row with the same prefix and a
bare indexOf was landing on the religions one.

Twelve sabotages, each caught by an assertion naming its own cause: every whitelist line removed
separately, the price left unnormalized, loreUnlocked forced in, the scope line stripped, the bullet's
price demand and its absolute-scale clause and its loreUnlocked refusal each removed, and the roster row
stripped of the secret, of the price, and of the interpolation. The Dungeon Master's Guide documents the
widened box and carries a fresh Last Update stamp.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

A tooltip earns its place where a control is ambiguous or destructive. A pair of arrows that steps a
picture is neither: it says what it does by its shape, and the other arrow undoes it. The block they sit
on already carries a tooltip of its own — "Open your character sheet" — so a second hint sprouting over a
corner of the portrait on hover was chatter laid across the thing the player came to look at.

The accessible name stays, and is not the same thing. `aria-label` is what the button is CALLED rather
than a hover hint, and without it a screen reader announces these as the bare glyphs ‹ and ›. Removing
the tooltip is a decision about visual noise; removing the name would be a decision about who can use
the control, and only the first was asked for.

The test now pins both halves rather than only the removal, because they are easy to conflate and the
conflation costs the wrong one: one assertion fails if a `title` comes back, the other if the
`aria-label` goes with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Reported from play: a player talked to a Town Guard about a guard's duties and job — which is, word for
word, what The Guards' authored reveal condition asks for — and the order was never revealed.

Nothing was missing from the Factions section. It said exactly what it should: HIDDEN, present here via
Town Guard, watchman, with the condition on the line. But that section is keyed by ORDER, and the block
a Game Master reads to BE this person — name, stats, routine, appearance, personality, mannerisms,
speech style, history, motivation, secrets — said nothing about any order at all. Measured on the
shipped world before touching anything: the Town Guard's entry mentioned neither "Guards" nor "faction"
nor "watchman". Both halves of the prompt were correct and nothing joined them, so a model deep in a
conversation was reading the card of a character that did not know it belonged to anything.

Each member's card now carries a "Belongs to:" line: the order, the role, and while the order is still
hidden, the instruction not to speak it, the reveal condition itself, and the exact directive to return
with entityName filled in — so the model is told in as many words that the person it is talking to is
the one this reveal comes through. That last clause is the reported gap stated plainly; the rest is
context it needs to act on it.

The Lore: line one line above is the same problem already solved once, and this is deliberately its
twin with one difference. Lore POINTS at its section; a reveal pulls the condition IN. A lore hook is
earned across a whole playthrough and the Lore Hooks section is where attention already is when it
lands; a reveal is earned inside one exchange with the person whose card this is, and sending the model
to another section asks it to leave the conversation to find out what the conversation is for.

Two economies keep it honest. The condition is a property of the order, not of each member, so it is
spelled out once across the members' cards and the others point at it — two guards on duty must not buy
two copies of it on every turn — while the do-not-name warning rides on every member, because it is
what stops the name being spoken and the model may be reading any one of those cards. And the whole
apparatus is gated on the order still being hidden: once revealed the card drops the warning and the
spent condition and says the player may be told freely, the Factions line collapses to "already
REVEALED", and the condition leaves the prompt entirely. Measured both ways — the per-turn half of the
prompt is smaller after a reveal than before it, so the reveal pays for the lines it retires.

Writing the test cost two corrections worth recording. Its first version picked one room for every
section, and the first room holding a member holds exactly one member and nobody else — so the dedupe
section and the negative both skipped silently and the run still said all passed. Each section now
selects a room by the shape it needs, and makes one when the built-in world has none. The second: the
dedupe assertion counted the condition across the whole prompt and failed on a correct build, because
the Factions section keeps its own copy and should — the two are different reading paths. It counts the
member lines now, and says why the duplicate across sections is intended.

Designs/factions.html §07 records it, and opens a question it uncovered rather than answering it:
recordFactionMet writes the Journal entry and calls trackStat and nothing else, so discovering an order
pays no XP at all, while every other kind of discovery in this game carries a price on a shared
absolute scale. The shape of the fix is an authoring decision, so it is written down with its lean and
left for its author.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The portraits a player generates collect in a gallery on the character sheet, and the only way to put one
on was to open that sheet and drag a thumbnail onto the portrait. The sidebar block showed the one they
were wearing and offered nothing. Two small arrows now sit in its bottom-right corner while the block is
hovered, and step the worn portrait along the gallery in either direction.

They are drawn only when there is somewhere to go. A gallery holding one image that IS the worn portrait
is not a gallery anybody can walk, and an arrow that returns you to the picture you are looking at reads
as broken rather than as a boundary, so the ring has to be longer than one before either appears.

THE RING'S ORDER MUST NOT DEPEND ON WHICH IMAGE IS WORN, and the first cut of this got it wrong in a way
worth recording. Building the ring with the current portrait at index 0 — which reads as the obviously
helpful thing, since "next" is then simply the one after it — makes the neighbour the same every time:
walking forward through three pictures went first, second, third, and then back to the second instead of
round to the first. It looks like a wrapping bug and is an ordering one. The gallery's own order is the
ring, which is also the order the player curated and therefore the one they expect.

AND STEPPING MUST NOT LOSE A PICTURE. A portrait can be worn without being in the gallery — an upload, a
GM-supplied image, the one a character started with — and the ring holds such a portrait only while it is
worn. Step away and nothing remembers it: there is no way back, and the image is simply gone. So the
first step away files it into the gallery, once, however many laps the player walks. That is a small
write on a navigation click and it is the honest place for it — the gallery is precisely the store for
"the portraits this character has", it is visible on the character sheet, and the player can remove it
there. The alternative, a hidden ring that remembers what the gallery does not, keeps the picture
somewhere its owner cannot see or curate.

Both arrows stop propagation. The block carries onclick="openCharacterProfile()", so without the guard
every step would also jump the player out of the sidebar and onto the character sheet — the same
collision the chip ✕ carries a guard for, and the reason that one has a comment about it.

Driven in a browser rather than only asserted: the walk wraps, a step back undoes a step forward, the
arrows do not fire the block's handler while a click on the block still does — which is what proves the
guard is working rather than the click being inert — and the portrait stepped off is in the gallery
afterwards.

Tests/test_portrait_gallery_nav.js covers all of it with four sabotages, each caught by its own named
assertion: the ring rebuilt around the worn portrait, the stepped-off portrait not retained, the arrows
drawn with nothing to step to, and the propagation guard removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Found in play: the Old Gatekeeper called a female character "lad". The field was not missing. The
gender was in the dossier the whole time — but as a bare word appended to the "Player:" line, with
nothing anywhere in fifty thousand tokens of rulebook telling the Game Master what to do with it.
Meanwhile the same prompt handed that NPC a "Speech style" note reading "lets a softer, more
grandfatherly tone slip through". One side was an unexplained attribute and the other was an explicit
instruction, and the explicit one won. The model got it right in earlier sessions, which is the whole
character of the failure: nothing was broken, the odds were simply worse than they needed to be.

Rule 2aa now governs it, beside 2a because 2a already owns how the player is referred to and settles
only the NARRATION voice. Second person rarely needs a pronoun for the player at all, so everybody
ELSE was ungoverned: the endearment, the honorific, the noun of address, and any third-person pronoun
in a line one NPC speaks about the player to another. The rule names all four, because a rule that
fixed "lad" alone would leave "sir" and "she" where they were. It says out loud that it BEATS a
characterisation note, and says what such a note is actually for — a "Speech style" or a
"Personalized identity" tells the GM what REGISTER to speak in and never which gender to assume, so a
grandfatherly old soldier calls a woman "lass", and the innkeeper whose note reads 'nicknames
("friend", "lad/lass")' is being handed both words so he can pick the right one rather than either.
For a character who is Non-binary, Other, or unstated it asks for forms that carry no gender and
names some, because "do not guess" with no alternative offered is a rule a model satisfies by
guessing anyway; and it names the places NOT to guess from — the name, the class, the trade — which
is what the NPC-side comment has said since it was written.

It is in `stable`. A rule about how to address somebody cannot differ between two consecutive turns.

The field the rule points at is now labelled and always present, including when it is unspecified,
where the line used to drop it silently. A rule that points at a field is worth exactly as much as
the field being there to point at, and "no line about gender" reads as an oversight where
"unspecified" is something a model can act on. playerGenderForPrompt() is the one place that renders
it, so the prompt cannot carry a word the Character sheet could not have produced.

And the restore backfills it, which is the half that was failing quietly. `player` is rehydrated with
reInstance, which copies the SNAPSHOT's keys onto the prototype and never runs the constructor, so a
save that predates a field comes back without it. Every other line in that block guards a COLLECTION,
and a collection read as undefined[id] throws — a bug that reports itself. `gender` and `summary` are
strings read behind a truthiness test, so they fail in silence: the Player line just stops saying it,
and the Game Master is back to guessing with nothing on any screen to say why. Both lines sit at the
END of that run rather than beside the collections they belong with, because two sibling tests slice
the block by byte window from an anchor above and a long comment inserted mid-run pushes the lines
they assert out of their windows — a property of how they read the file rather than of what they pin.

Tests/test_player_gender_address.js pins all three pieces against a deliberately broken build, nine
sabotages, each caught by a distinct assertion. It also asserts the two built-in cases the rule is
answering — the gatekeeper's grandfatherly note and the innkeeper's "lad/lass" — so the rule cannot
drift into answering something the shipped world does not contain.

No change to the ambient-remark path, which is where an NPC aims a remark directly at the player and
was the other candidate: every GM call site sends buildSystemPromptBlocks(), which is stable then
live, so rule 2aa and the labelled field both already reach it. A second instruction in the user
message would only give the model something to weigh the rulebook against.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

It shipped with its explanation printed beneath it — three lines about the walk being a journey and
anything in the way stopping you where you meet it, sitting permanently inside a 264-pixel popup. That
is a manual embedded in the interface: read once, and in the way for every reading of the room after
it. A control needs a LABEL. What it means belongs on hover, and the long version belongs in the Field
Guide, where somebody who wants the whole answer goes looking for it.

So the four states are now one shape rather than four — a Return button, live or disabled, with a
tooltip. The visible text in that block is the word Return and nothing else, in every state, which is
the property the test now pins: it strips the tags and asserts what is left. "You are here." went too,
and became the disabled button's own reason; a state that drew a sentence where the other three drew a
control was the same clutter one word shorter.

THE TOOLTIP IS ON THE ROW RATHER THAN THE BUTTON, and that is not tidiness. A disabled button fires no
mouse events in any browser, so a data-tip on one is a tooltip that can never be shown — and the
disabled states are exactly the ones a player most wants explained. The delegated resolver walks up
from whatever the pointer touched (initAppTooltips), so the wrapper catches every state through one
code path. aria-label carries the same words for anyone who cannot hover, LABEL FIRST — "Return — …" —
which is the pattern the sidebar's exit badges already use, so the control still announces as Return
and the reason follows it rather than replacing it.

The Field Guide's Maps section gains the paragraph the popup gave up, and it says the three things a
tooltip has no room for: that a hostile standing on the way stops you in that room rather than being
skipped past, that a door shut since you came through it stops you the same way, and that a detached
Maps window is a read-only view of the session and cannot take a turn at all. The test reads that
section and checks those are in it — "short description in the tooltip, the rest in the Field Guide"
is only half done if the second half does not exist, and nothing else would notice its absence. Its
Last Update stamp moves with it.

The sabotage pass covered the ways this regresses: the prose coming back under the button, the tooltip
disappearing, the aria-label being dropped, the reason going vague, the guide dropping the half the
tooltip is too short for — and the tooltip itself growing back into a paragraph, which is caught by a
length bound rather than by anybody's judgement. Checked in a browser too: hovering the row raises the
app's own themed tooltip, headed Return, and the block reads "Return" and nothing more.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Reported from play: walking from the Village Square to Market Row printed the room banner, a climate
narration under it, and then the whole room scene again — banner, description, "You notice", "Present".
Two banners for one walk, with a weather beat wedged between them.

It is a race with a window you can measure. The move commits in applyStateChanges, but the arrival
scene is deferred — setTimeout 200ms, so the Game Master's narration renders first, and the flee path
defers 180ms the same way. updateRealmCalendar runs on a one-second interval and has two branches that
print a room-scoped scene beat, each leading with a title and a full banner: the hour turning, and the
sky's condition turning over. Either one landing inside that window draws the room the player has just
walked into, above the arrival scene that is about to draw it properly. Nothing was wrong with the beat
or with the arrival; they simply both described the same room, and the wrong one went first.

describeRoom already called syncWeatherBriefBaseline for exactly this, and says so in its own comment —
arriving in a new region under a different sky must not instantly fire a weather beat. It was 200ms too
late to help, and could never have covered the time-of-day branch at all, which has its own baseline and
its own emission.

So the engine is asked a question about its own state rather than told by whoever deferred the describe:
is the player standing somewhere the story has not drawn yet? _roomSceneDrawnId is set on every
describeRoom — unconditionally, not gated on `arrival`, because a look-around redraws the room just as
completely and an import redraws one nobody walked into — and seeded on resume beside its twin, which
draws no room but restores a story already showing one. The condition is then true for precisely the
length of the gap, on every deferred mover including ones not written yet, and needs nothing set by any
of them. That is the same reasoning updateRealmCalendar's own livingWorldActive guard records a screen
above: a path that has to remember is a path that can forget, and forgetting is the bug.

The predicate is fail-OPEN, and the first version was not. Written as "the drawn room is not the current
one", a null tracker — nothing drawn yet — read as a scene being owed and held back every beat there
was; test_timeskip_room went from all-pass to eight failures and was right to. The balance is not close.
One duplicated banner is a blemish, while a path that leaves the tracker unseeded would stop the hour
turning in the story for the rest of a session with nothing at all to see. Suppression now needs
positive knowledge: a room actually drawn, and the player since moved off it.

Only the scene is held back, never the world. The time-of-day branch still despawns its encounters,
walks the routines, redraws the map and the sidebar and saves; it baselines the weather on the way past,
or the beat fires on the next tick instead and the doubling returns a second late.

The test counts BANNERS rather than messages, because the banner is the complaint — a beat that stopped
emitting some other way would satisfy a message count and leave the player looking at the same thing
twice. It pins the other direction just as hard: with the player standing still, a sky turning over and
an hour turning both still print their scene, since suppressing those would trade this bug for a larger
one.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The World map shows every room the player has been to, and clicking one told them about it and left
them where they stood. Getting back meant retyping the way there a direction at a time, which is a
chore the map is already the answer to — it knows where the place is and the player is looking
straight at it.

WHAT THE BUTTON MUST NOT BE is the reason most of this change is small. There is no teleport in this
engine and this had to not become one. BUG-066 is the whole history: a moveToRoom naming a room three
hops away WAS a teleport, the rooms between were never entered, never marked visited and never did
whatever an arrival does, and a room crossed four times across two characters was still unvisited. The
fix was to walk the route instead. So Return writes no position of its own. It types "return to <the
room>" into the prompt and submits it, exactly as the sidebar's exit badges do with "go <direction>"
and the item popup's Consume does with its verb — which is what puts this walk under every rule those
are under: the door refusals, the compound-route check, and a hostile in an intervening room stopping
the walk there rather than being skipped past. The Game Master narrates the journey; the engine decides
whether it happened.

It is offered on the player's own map and nowhere else, through an opt-in the World map's click handler
passes. The same builder draws the DM editor map's room popup and the location link on every NPC and
monster card, and on those it stays absent: moving the player's body as a side effect of looking
something up in a card is not a thing to offer, and on the DM's map it would be an authoring tool that
walks somebody else's character.

Where it cannot be used it says so rather than vanishing. The room you are standing in reads "You are
here."; below ground the button is drawn and disabled, because the dungeon owns movement and the GM is
told in as many words that it does not make it; and in a DETACHED Maps window it is disabled too, with
the reason, because a detached viewer is a read-only mirror — saveGameState refuses to write from one,
so a turn started there could not be recorded. Four states rather than one and three silences, on the
argument this file already makes about a shut door: the difference between a locked door and a wall is
something the player is entitled to know.

The rulebook gains 3e, and without it the button would mostly have spent a turn being refused. Rule 3
is emphatic that movement uses the exact exit keys listed, which is right and is about DIRECTIONS — but
the button types a PLACE, and the likeliest reading of "return to the village square" under rule 3
alone is "there is no path that way". 3e says a place the player has already been may be walked to with
moveToRoom naming that room however far off it is, says in as many words that rule 3 still holds in
full so it cannot be read as licence to substitute a direction, and tells the GM what the engine does
on its behalf: walks the route, refuses one that does not exist, stops early at anything hostile and
says where they actually got to. So narrate the journey, not the arrival. It is a constant line, so it
sits in `stable` — a rulebook line in the per-turn dossier moves the cache prefix every turn and bills
2x (Tests/test_prompt_cache.js).

The note printed under the button promises that this is a journey and that anything in the way stops
you. That is a claim about code in applyStateChanges, not about this feature, so the test checks it
rather than trusting it: a note promising a guard that has since been removed is worse than no note.
Every other assertion was written against a deliberate break — a Return that teleports, one that skips
the isProcessing or below-ground guard, a popup that offers it everywhere, a state that draws nothing
instead of saying why, a 3e that stops affirming rule 3 — and each is caught by its own named
assertion. Driven in a browser too, over a real world with two walked rooms.

test_map_room_links pinned the World map's popup options as an exact object literal and broke when a
third option joined them, while the property it names — clickable contents, no exit list — was
untouched. It matches the options it sets now. Its check() also took two parameters while a call site
passed three, so the diagnostic it was written to print had nowhere to go; that is the same defect
test_admin and test_admin_page each carried and fixed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

loreHooks settled half of this long ago and its own comment states the principle: the player's own race
and memberships travel with them, which is the whole point of a hook about what was taken from your own
kin. raceHere reads player.race and factionHere reads player.factions, so a hook on the character's own
bloodline or order is marked HERE wherever they stand.

loreReachable — the other half, which decides what is to hand and therefore what else becomes earnable
— walked the room, the beings in it and the pack, and nothing about the character. The engine held both
halves of one idea and disagreed with itself: a Moorborn was told their own race's secret was here, and
that race could not open a single other hook in the world. It now walks what the player is alongside
what they hold, outside the room block, because both travel for the same reason and both survive a
descent into a dungeon where the room does not.

The reverse link gains most, and that is the point rather than a side effect. An order or a bloodline is
exactly the sort of thing that knows what a distant barrow means, and unlike a book it does not have to
be found first — so unlocksLore, which yesterday's commit documented as deliberately not carried on
these two kinds because nothing walked them, is now carried on both. Leaving it out would have made the
capability work until the first reload, which is the loreLinks bug from one line up, shipped the day
after it was fixed. normalizeAilment still omits it correctly: an ailment is not walked, so there it
really would be inert.

Every source now carries how it got here, and this is not presentation. The reason goes into the label
the Game Master reads and acts on, and a bare "The Moorborn here unlocks it" reads as a Moorborn
standing in the room — a model handed that will put one there, the engine having invented a person to
justify its own sentence. So a travelling source says it travels with the character and that nobody need
be present, and a source that is physically present reads exactly as it did, byte for byte, which
matters because this sits inside a cached prompt and a reworded line saying the same thing is a cache
write for nothing.

Rule 13d was part of the change and not a follow-up to it. It told the Game Master that REACHABLE FROM
HERE meant a subject "that something in this room reaches", which the change makes false, and its
account of HERE had been incomplete for longer than that — it named the room and the beings in it and
not the sickness the player is carrying or the race they are, both of which the engine has marked HERE
all along. It now names all of them and says in as many words not to narrate an absent person to account
for a travelling source.

The test finds a room with neither a member of the order nor one of the race in it rather than naming
one, so nothing it asserts can be satisfied by presence, and it carries the negative that separates
reading the character from listing the world: a race the player is not and an order they have not joined
are not sources. Updating one existing test was unavoidable — a source is { name, how } now, and
test_lore_hook_unlock builds one by hand to prove the matcher is whole-word for a name too short to pass
loreReachable's own floor. That fixture is right to be hand-built and now says why.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

normalizeFaction and normalizeRace each return a fresh object literal, so a field they do not name is
rebuilt away on the next load, and neither named loreLinks. The Lore tab offers it — it is on
LORE_EDITABLE_FIELDS — applyLoreUpdate lands it on world.factions or world.races, the Compendium card
renders it, and the next reload returned it to nothing. Authored, applied, displayed, gone.

This is the same mistake these two functions have now made three times. loreXp was lost this way on
races and had it fixed, with a comment saying so; it was then found lost the same way on factions,
which earnt a second comment reasoning that "the lore trio" is three fields and the set is four. The
set is five, and the fifth is this one. Both comments are now joined by a third that says what the
field does rather than only that it was forgotten, because the previous two did not stop it happening
again a line apart.

It costs more on these two kinds than on a room or an item, which is the part worth knowing. Those are
reachable on their own terms — a room's hook is visible in its own room, an item's wherever it is
carried. An order has no room and is not carried: it is HERE only where one of its people stands, and
loreHookDossier drops a hook that is neither here nor linked. So on a faction the forward link is not a
convenience for disambiguation, it is the only road to the hook that does not require authoring a
member into the right room. The Guards' own loreKey names the Old Gatekeeper and reaches him through
his membership, which was written because the link did not work.

Carried as a conditional spread, matching normalizeAilment, which is the one kind that already had
this right: absent and empty are different answers, and writing loreLinks: [] onto every record in
every world would turn "nobody has said" into "somebody said none". Run through loreNameList so a
comma-authored string becomes a list — stored raw, hook.links would be a string, and
loreHookLinkReason would spread it one character at a time.

unlocksLore is deliberately NOT carried on either kind, and the comment says so where the next reader
will look, so the gap is not closed by somebody who finds it. It is the reverse link and loreReachable
collects it from the room, the beings standing in it and the player's pack — never from the faction or
race maps. Measured rather than reasoned: set directly on a live world object it does not reach that
table at all, so an order declaring it unlocks something would be stored, shown, and consulted by
nothing. normalizeAilment leaves it out for the same reason.

The test asserts the normalizer, then the serializeWorld/rebuildWorldFromSnapshot round trip that is
where the loss was actually visible, and then the dossier itself in a room where the order is not HERE
— because "it round-trips" is exactly the assertion that would still pass against a build where
loreHooks had stopped reading the field, and a stored value that changes no behaviour is not worth
carrying. Writing that last part cost a false failure first: a hook is a leading line plus indented
continuation lines, and the referents live on those, so slicing to the header alone looked somewhere
the answer could never be.

Designs/factions.html §07 carried the claim that a faction cannot use loreLinks and now records what
changed, along with the reverse link's standing exception.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

An order carries two gates and they are easy to collapse into one. `reveal` earns the faction itself —
the name, the Compendium card, the Journal row — and The Guards already had one: ask a guard what the
work is, with genuine interest. `lore` is what the order keeps once you know it exists, and it had
none, so the only thing behind the reveal was the description on the card.

The lore is what the watch was actually raised to do. The militia buried its dead the autumn after the
Skirmish in ground turned over first with iron, and within the month three of those graves had been
opened again from the inside; the gate faces south because the moor is south, and every recruit is set
to counting the fog without being told what the counting is for. That last part is deliberate: it is
the same routineDescription the engine already ships for the guards, read from the other side, and it
is why a guard will answer the reveal question and not this one.

The unlock condition names two roads, and the constraint on a faction's loreKey is sharper than on a
room's or an item's. A room's hook is visible in its own room and an item's wherever it is carried, but
an order is HERE only where one of its people stands, and loreHookDossier drops a hook that is neither
here nor linked — and a faction record does not keep loreLinks through normalisation, so a condition
satisfiable only where no member stands is unreachable however well it reads. The first road is the
guards themselves at the gate through the midnight hour, when their own routine already has them tense
and watching the fog. The second is the Old Gatekeeper, and he is a member of the order now for exactly
that reason: his lore has him on that wall the night his son died on it, the fiction had him as the
gate's keeper all along, and without the membership the road his order's key names ends in a room where
the Game Master is never shown the hook. Measured in both rooms afterwards rather than argued: the hook
reads [HERE] at South Gate and in the Village Square, and is absent in Market Row.

Priced at 20, against The Bogiron Taint's 20 in the same file, the scale being absolute across every
kind of hook in the world. Leaving it undecided beside a neighbour that is not would have been a
decision either way.

The test gained the pairing rule the repo states in its own authoring directives and states only to a
model — lore and loreKey are given together or not at all, because lore behind no condition can never
be reached and a condition guarding nothing pays out nothing — plus the reachability of the hook that
follows from it. Writing that assertion exposed a leak in the block above it, which planted a loreKey
on the faction to exercise the vouching path and restored only the lore: deleting the real loreKey from
the world left the new assertion passing against the scaffold. Both fields are put back now.

Three existing tests were resting on the built-in world having no faction lore and no member in the
Village Square, which is the kind of fixture that holds until somebody authors something.
test_faction_reveal asserted the dossier named its own Gate Sentinel, and the dossier prints one member
per order — the first the room walk reaches, now the Old Gatekeeper — so the fixture makes the sentinel
the sole carrier rather than accepting whichever being comes first, which would pin nothing.
test_lore_rooms_missing asserted no faction carried lore at all; it now tests the filled shape first,
which the world finally has, and blanks the fields itself for the empty one. test_adopt_world's count
of notes on a `factions` key is read off the file instead of stated, so authoring another member does
not edit a test.

Designs/factions.html §07 records the two-gate distinction and the HERE constraint on a faction's key.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The flora and fauna chips were clickable and did not say so: no pointer on hover. Chasing that found the
cause was not a missing cursor rule but a missing class name.

Every chip in this editor is written `class="npc-chip npc-inv-chip"`, and the look hangs off both of them
together — `.npc-chip.npc-inv-chip` carries the pill's inline-flex row, its padding and its pointer, and
`.npc-chip.npc-inv-chip-missing` carries the red border on a dead one. The Biome card wrote only the
second half. The single-class hover rules still applied, so the chips brightened and underlined and
looked half-alive, while the two-class rules did not: no border, no pill, `display: block` instead of
inline-flex, no pointer — and a binding whose subject had been deleted was indistinguishable from a live
one, because the red border is on the two-class selector too. The rule beside those selectors already
records that the cascade needs both names; nothing checked that the markup supplied them, so now
something does.

That left a third state to answer for. The shared rule makes every chip a pointer, and this card has
chips that are neither clickable nor broken: a climate names something real that simply has no card
anywhere in this app to open. A pointer over one is the same false affordance the missing-chip rule was
written to remove — the cursor promising a click before the user finds out there is none. So a chip with
no handler is marked `-static` and keeps the look while losing the pointer and the hover underline.

Verified by computing styles against the canonical chip markup rather than by eye: flora and fauna now
match an NPC inventory chip on display, border, background, colour, size, padding and radius, and differ
from it in exactly one property — cursor, on the climate chip, which is the intended difference.

Two sabotages, each caught by its own named assertion: the chip written with only `npc-inv-chip` again,
and the static marker dropped so a climate chip claims to be clickable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The chips are a roster of things authored on other tabs, and the question a DM has while looking at one
is "what IS that?" — so clicking a chip now answers it instead of doing nothing. It is the reading every
other chip in this editor already offers: a reagent's ingredient opens that item's card, a quest's
reference opens the room or being it names.

Each kind opens what suits it. Flora is an item, so it opens the editor's own item card dialog — the
full editable card rather than the player's read-only popup, which is what a DM wants from this side and
exactly what the reagent ingredient chip opens. Fauna is an entity and has no editor card dialog, so it
opens the shared entity detail popup, the same body the Quests tab's NPC chips show. Climate opens
nothing and is deliberately not clickable: no card for a climate exists anywhere in this app, and a
handler that opened nothing would be worse than none because the chip would invite a click it cannot
answer.

A CHIP WHOSE SUBJECT IS GONE STAYS INERT. Marking it missing and then offering to open it is the worst
of both: the card would promise a plant this world no longer has. The handler is omitted entirely there,
which also keeps the hover underline off it, matching the CSS rule that already cancels the underline on
a missing chip.

The ✕ keeps stopping propagation, which is not a detail. Those were one action on the Teaches chips once
and clicking a chip deleted the thing you meant to look at — the exact opposite of what a chip that shows
you what it names should do. Driven in a browser to check it: removing a plant removes it and opens
nothing.

A TEMPLATE IS NOT AN ENTITY, and that cost the first cut of the fauna opener. A biome binds the KIND, so
the picker offers both a catalogue template with nothing placed and a one-off standing in a room with no
template behind it — and buildNpcDetailHTML calls ent.portraitImage(), which lives on Entity.prototype.
Handed the raw catalogue object it threw "ent.portraitImage is not a function" at click time, which
reaches a DM as a chip that silently does nothing and an error nobody is watching. The resolver builds
the real thing with makeEntity({ ref }), which is how the engine spawns one everywhere else, and rebuilds
a live entity too if it somehow arrives without its prototype. Found by clicking the chip in Chromium;
the string assertions were all green while it was broken.

Tests/test_biome_tab.js §8 pins the handlers per kind, the inert climate, the inert missing subject, the
✕'s propagation guard, and that the resolver hands back something with the prototype on it. Three
sabotages, each caught by name: the raw template returned, the missing guard dropped, and a handler put
on the climate chip.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The owner states the Haunted Village Square track was generated on a paid Suno plan. That is the fact the
ownership question turned on, so it goes in `closes` with the date and the session it was given in, and
what was an open risk becomes a documentation task.

The correction matters more than the addition. The previous entry said flatly that Suno grants commercial
ownership of output on its paid tiers and withholds it on the free one. That was this session's
recollection of a third party's terms of service, written into a provenance ledger as though it were a
finding — the exact move the audit exists to prevent, and it sat beside an authorshipBasis boasting that
the origin was read off the file rather than taken on trust. The discipline held for the file and slipped
for the sentence about the file. It is corrected in place rather than deleted, because an audit record
that quietly loses its own bad claims is worth less than one that keeps them.

Verification was attempted and failed for a recorded reason: suno.com is unreachable from the session
container, blocked by the network egress proxy — the same obstacle that sent the BSL text verification to
the SPDX registry rather than mariadb.com in §09. A secondary source's reading of somebody's terms of
service is not evidence worth writing into a legal record, so nothing was substituted for it.

What remains is retrieval by a person rather than a question for a session: the Suno terms in force on the
generation date and the plan receipt, held alongside the D-2 founder assignment outside this repository.
Until those exist the honest statement is the one the ledger now makes — the owner generated the track on
a paid plan, and the licence that plan carries is undocumented here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaW12mLYASZw8sTbCyh5HJ

Two copies of the owner's own generated audio arrived: Music/Haunted Village Square.mp3 for the game and
a byte-identical Web/LandingPage/audio/haunted-village-square.mp3 for the landing page. Both are declared
in the ledger, and this is the best-evidenced entry in it. The file carries a signed C2PA manifest whose
assertions include com.suno.provenance and the digital source type trainedAlgorithmicMedia, chaining to
the C2PA Root CA — it states under signature that it was generated rather than recorded, and the owner's
account agrees with what the file says. That is the case the marker readers were written for, and worth
naming because the Envato breach was the opposite one.

It also opens a question the ledger has not had to ask before, recorded in doesNotClose rather than
answered here: who owns a generator's output. The AI images were made with tools whose terms the owner has
already stated; this is the first file whose own manifest names a third-party generator, and for audio the
answer turns on the plan it was made under, since Suno grants commercial ownership of output on its paid
tiers and withholds it on the free one. "The owner generated it" therefore does not by itself establish
that the owner may license it onward. That is a different question from the copyrightability doubt in
D-10, and it has a counterparty behind it rather than an unsettled statute. The plan and the date live
outside this repository, so the ledger carries the question against the file for the D-2 legal pass.

Two defects surfaced on the way, both the same shape: a guard that was described but never written.

.gitignore's own comment says Music/, Sounds/ and Audio/ stay ignored so the same material cannot walk
back in by accident — and there was no /Music/* rule at all. For the week since the Envato removal, the
one directory those items actually came from was the one with no guard on it, and Music/Intro.mp3, which
that same paragraph singles out as the file that must never return, would have been committed without a
murmur. A missing ignore rule has no symptom. It was found by checking the claim, not by anything failing.

And the inventory scans a list of directories rather than a tree, so Web/LandingPage/audio/ and
Web/Website/uploads/ were invisible to it. A file the scan never walks is not reported UNKNOWN, it is
absent, so --check passed while the report quietly stopped describing the tree. Two shipped files sat
that way: the landing page's score and the Brave You Worlds lockup, the latter looked at here and declared
as the brand mark it is. Naming leaf directories under Web/ is still right — Web/ also holds the pages and
the progress report, which are source and not assets — so the fix is a test rather than a wider scan.

The suite now checks all three claims. Every tracked file under the audio directories has a named
.gitignore exception AND a ledger entry, since the exception asserts the file is ours to publish and the
ledger is where that assertion is backed. Every directory under Web/ holding media is one the inventory
scans. And the ledger-agreement check reads the HTML report rather than the CSV: the CSV is written only
under --csv and had drifted to 209 rows against 234 files, so every file added since the last run with
that flag was absent from what the check read — including, when it was written this way, the two audio
files this commit is about. An assertion anchored to an artefact nobody regenerates does not fail, it
empties, which is the failure mode that looks most like success. The CSV is regenerated and pinned to the
report's file count so it cannot drift again in silence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GaW12mLYASZw8sTbCyh5HJ

The Biome card showed both descriptions read-only and sent a DM back to the New dialog to change either
of them. That was defensible while the dialog was the only way to write one, and it stopped being so the
moment the tab grew a Game Master worth asking: a biome is written FROM ITS NAME more completely than
almost anything else in this editor — "The Salt Moor" already says most of what the country is — so the
one card where the ✨ pays for itself was the one card that did not have it.

Both fields carry it now, through buildDescEditFields, which is the shared pair every other card of this
family uses: the same rows, the same sizing, the same save-on-change. They are editable as well as
generated, because a generate button beside a field nobody can then correct is half a control.

The registry entry is what makes the button do anything. An unregistered kind falls through find() and
runTypeDescriptionRequest returns on its first line — the ✨ spins down, the field is untouched, and
nothing reaches the console to say why. That is the same silent failure the portrait ✨ has one row over,
which is why both are now asserted rather than assumed.

THE CONTEXT IS THE NAME, AND DELIBERATELY NOT THE CLIMATE. The roster's ordering is a chain of
consequence — the biome decides the climate, the climate decides what can grow, what grows decides what
can live — and the descriptions sit at the head of it. Feeding a bound climate back into the description
request would invert that: the country would be described by weather somebody had already guessed for it,
and the ordering the rest of the tab is built on would stop meaning anything. So the context is the name,
plus the short description when writing the long one, which is the ordinary reason every kind here passes
its sibling field — two lengths of one statement contradict each other about half the time otherwise.

The ask says what a biome IS, twice, because it is the thing a model gets wrong here: a kind of country
rather than a place on the map, so it names no town, road or landmark.

Tests/test_biome_tab.js §7 pins the buttons, their wiring to the right id and field, the registration,
and the name in the context. Three sabotages, each caught by its own named assertion: the kind
unregistered, the name dropped from the context, and the climate fed back in.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

A button that answers "nothing, actually" on most presses teaches an admin to stop pressing it, and on
a tidy vault that is every press. "Find unreferenced files" asked the admin to press it to discover
whether it had been worth pressing, which is the wrong way round for a control whose whole job is to
report an absence.

So the count comes down with the tab payload and the offer is conditional — which means the scan now
runs on every Media tab load, and its own comment previously said it would not. That is the price, and
it is the honest one: you cannot hide a control behind a question without asking the question. It is a
read of each hosted world.json, a handful of files on any real vault, and nothing polls that route —
it runs once per admin page load and once per media change, where the single-file Remove already paid
the same cost through worldsUsingMedia. The comment now says so, and names the fix if a vault ever
holds enough worlds to feel it: cache the hash set against the world index's own fileMtime, rather
than making the button unconditional again.

Three states, not two. Zero unreferenced files with worlds published is a clean result said out loud,
because drawing nothing where a control used to be reads as the feature having gone rather than as
good news. A vault with NOTHING PUBLISHED is the one case that gets no message at all: with nothing to
compare against every file is unreferenced, so the honest answer is that the question has not been
asked, and an offer made on that basis would hand somebody their whole store. The label names the
count and the size before the press, which is what the old one could not.

Everything the tab draws now comes from one mediaPayload(), because four routes redraw it — the load,
the store switch, a single removal and the sweep — and the button is drawn from what they return.
Built separately, it appeared after a load and vanished after a toggle, which reads as breakage rather
than as two spellings of one answer. Folding them together fixed two things that were already wrong:
the store switch answered with no `recent` at all, so toggling it emptied the list of stored files
until the page was reloaded; and the single-file removal spread `...out` and then `...media.stats()`,
so the file's own `bytes` lost to the store's total and the page reported "Removed 25.7 MB" for an
8 MB file. The file's size is `removedBytes` now, in the sweep's vocabulary. `worldsRead` rather than
`worlds` for the same class of reason — the single-file DELETE already answers with a `worlds` array,
the ones its removal broke, and one of the two would have quietly won.

The sabotage pass caught one assertion that was not doing its job: every check of the tab payload ran
against a store that had just been swept clean, where a payload hardcoded to report no orphans passes
and the button then never appears again. There is one taken while two files really are unreferenced.
Driven in a browser across all three states as well — no button with nothing published and no
clean-store line either, a button naming "2 unreferenced files · 8.5 MB" once a world is published,
and neither after the sweep but the clean-store line instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Reported from play: a player spoke with the Town Guards at length, asked about their leader, praised
their duties, asked about joining and about what recruits do, reached reputation 22 — Friendly — and
The Guards never appeared in their Compendium. Nothing was wrong with the conversation and nothing
was wrong with the reveal machinery. The world defined the order and not one being in it said they
were a member.

The Factions section of the GM dossier is built from exactly one field: the `factions` array on the
beings standing in the room. Measured at South Gate with both guards present, the section read
`none`, so the Game Master was never told the order exists — it cannot set `factionReveal` for a
faction it has not been shown, and the author's reveal condition, which rides that same line and is
written nowhere else, was never delivered. Two more systems read the same field and were equally
dead: `factionHere()` decides whether the order's lore hook is listed, so the authored secret was
unearnable, and `canVouchFor` refuses anyone whose memberships do not name the order, so no guard
could ever speak for the player however devoted. All three were dead from the first turn and nothing
anywhere reported it.

Both Town Guards now carry the membership, with a note at the field saying what reads it, because the
field looks like colour and is not. Tests/test_faction_membership_reachable.js asserts the general
form rather than these two guards: for every order the world defines somebody claims it, that
somebody actually stands in a room — a member with a location naming no room is present nowhere and
the dossier is built from entitiesInRoom — and standing where they stand, the prompt names the order
and carries its reveal condition. It then exercises the other two readers, including the negative
that proves the vouching check is testing the membership and not the reputation.

Writing that note broke test_adopt_world.js, which is the test doing its job. Comment blocks in the
WORLD_DATA literal were anchored by the bare key they introduce, and `factions` is also the name of
the world's own faction map — so the two notes collapsed into one Map entry, the survivor was placed
at the first `"factions":` in the emitted file, which is that top-level map, and `orphaned` came back
empty over nine deleted lines and nine more moved onto an unrelated object. A key name is not an
address in a document with a thousand `"name"` keys in it. Blocks are now anchored by path, and
same-path blocks are held in a queue rather than a lookup, so two commented objects inside one array
keep both notes in the order they were written and anything genuinely left over still reports. The
path walk truncates its stack at each key, without which an array element's keys inherit whatever
object was walked last — an anchor that depends on unrelated preceding structure, in a tool whose
whole job is to emit a different world under the current one's prose.

Designs/factions.html §07 records the authoring consequence, which is not visible from the Editor:
writing a faction record does not put the faction into the world, a member does.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The Biome roster could only bind what the world already had. On a world whose Fauna tab is empty that
made "create a coastal biome with flora, fauna and a climate" a request it answered by ignoring two
thirds of it — the country arrived with a climate, perhaps a plant, and nothing living in it.

It can ask for them now, and only when asked to. A DM who typed "add a plain" gets a biome; a DM who
asked for the plants gets the plants. The directive says so in as many words, because the failure in the
other direction is just as bad: four plants nobody requested are four things to review.

IT DOES NOT AUTHOR THEM ITSELF. It writes a one-line BRIEF and the engine hands it to the roster that
owns that kind — requestItemEdit('flora'), which knows a plant must carry a consumeEffect to be edible
and how to price one against what it does and when to gate its name behind Herbalism; requestEntityEdit
('animal'), which knows a creature needs stats, a race and abilities. Those rules run to hundreds of
lines and gain a clause every time the kind learns a new trick. The item directive already says this
about its own forEntity path and reuses the contract rather than copying it, for exactly this reason: a
copy is wrong the first time the original changes. A climate is the one exception, authored inline,
because the Climates tab keeps no roster to hand a brief to — and a climate is a name, a band, a swing, a
gustiness and a table of weights, which is why that is tolerable where a plant is not.

THE ORDER IS A CHAIN OF CONSEQUENCE, NOT A SEQUENCE OF STEPS, and that is the substance of this change
rather than a detail of it. The biome decides the climate; the climate decides what can grow; what grows
decides what can live. Each call is made knowing everything settled before it — the flora brief carries
the country and its sky, the fauna brief carries both of those AND the plants this same pass just
authored — which is why the context is assembled at call time rather than when the brief was captured.
Asked for in one breath instead, a model invents both against the biome's name alone and produces fruit
that could not survive its own winter and grazers with nothing there to graze on.

The reason is stated to the model and not only implemented around it, because the model is the thing
exercising the judgement. The brief handed downstream says the climate DECIDES what may grow and the
plants DECIDE what may live, with the failure named on both sides; context alone invites a model to
acknowledge the weather and then author whatever it first thought of.

Each brief is a separate call, so the ask is capped at four of each kind per biome and the overflow is
reported rather than run. Bindings are made by diffing the PICKER's own options across the call rather
than by trusting the id a roster reports: the two rosters answer in different currencies — the item
roster in catalogue ids, the entity roster in names and instance uids — and the fauna picker addresses a
kind. Whatever the DM could have picked is what binds, which is correct for both by construction.

Tests/test_biome_tab.js §6 stubs both rosters and reads what each was actually handed. Six sabotages,
each caught by its own named assertion: fauna authored before flora, the flora omitted from the fauna
brief, the briefs never delegated at all, and the two constraint statements downgraded to bare context.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The notice a told tale raised was one line with a link on it, and the line said as much about the
event as a line could. That was the problem: a lore hook is a fact the player now knows, where a tale
is a thing a PERSON just told them, and it has a name, a kind and a picture of its own that the line
had nowhere to put.

So it is a banner now — gilt like the Title Earned one, because both announce something earned, but
laid out as a row rather than a centred card, because this one leads with a picture and a portrait
centred over three lines of text reads as a poster rather than as a thing that just happened to you.
It carries the tale's picture, its KIND, its title and what it paid, with a link on through to the
Compendium entry it made. The kind is on the banner rather than left to the Compendium because a
legend and a belief are different sorts of statement and that vocabulary is only ever learned by
meeting it. A tale with no picture gets its kind's glyph in the same square, so the text does not
shuffle sideways between one tale and the next, and a tale priced at nothing says nothing about XP
rather than claiming "+0 XP".

The TITLE is a button, and it opens the tale itself in a lightbox: the words, under the picture, with
the Compendium card one click further on. The ordering is the decision — what a player wants the
instant they are told a story is the story, and a card that files it among everything else they have
learned is the answer to a later question.

Two things the lightbox does are about reading the WORLD rather than the message, and both are the
rule that already governs how an NPC carries a tale. It resolves at CLICK time, so a tale the DM has
since retitled or rewritten opens as it now is. And it refuses a RE-LOCKED tale rather than showing
it: the temptation is to show the words regardless, since the banner is a record of a thing that
happened and nothing un-happens it — but un-ticking "Unlocked for the player" also takes the entry
out of the Compendium, so showing them here would make this one banner the single place in the game a
re-locked secret still reads, which is the DM's edit not taking effect, dressed up as a memento. A
tale deleted since the banner was raised, and one nobody ever wrote the text of, each say so rather
than opening empty.

The picture is emitted with its bytes and STORED by reference, through the same STORY_SCENE_KINDS
registry the victory and rest banners already use, and it joins that registry for their reason and
then keeps going for one of its own. Theirs: a tale portrait a DM uploaded is a data: URI, and a
banner that stored its bytes would write a copy of them into the save on every reveal. Its own: a
tale is a world record the DM may repaint at any moment, so resolving from world.folklore at mount
means an old banner shows the picture the tale HAS rather than the one it had. A tale whose picture
was removed says so in the square instead of drawing the broken-image glyph an emptied <img> renders.

Tests/test_folklore_reveal_banner.js pins all of it, sixteen sabotages deep, each caught by a
distinct assertion naming the failure. The half worth having a test for at all is the storage one:
nothing on screen would ever show you that a reveal had just put a portrait in your save file.

And the roster in Tests/test_dialog_close_buttons.js earned its keep the day it was written for — the
new lightbox shipped without `position: relative` on its box, which would have sent its × to the
corner of the screen, and the derived roster asked about a dialog that had existed for ten minutes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Removing stored art one file at a time answers the wrong scale of question. Media accumulates from
every generation the vault has ever proxied, including the ones nobody kept: a banner regenerated four
times leaves three files behind, a world published and then unpublished leaves all of its art, and
worldStore.remove says in its own comment that it will not touch media because the bytes are
content-addressed and may be shared. Nothing anywhere reclaimed any of it, and the only tool was a
Remove button on the forty most recent entries — which on a vault that has been running a while is a
window onto the newest fraction of the problem.

WHAT "UNREFERENCED" MEANS HERE is the whole design, and it is narrower than it sounds. The vault can
answer one question: does any world published to THIS server point at this hash. It cannot answer
"does anything need it". Art generated in the World Editor and not yet published is unreferenced. So
is art that only a player's own save refers to, and that save lives in their browser where this server
has never seen it. So the feature does not delete on a button: it scans, lists what it found with
thumbnails and provenance, and says on the panel — not only inside the confirm — that unreferenced is
not the same as unwanted. Each listed file also keeps a Remove of its own, because a sweep is
all-or-nothing and keeping one of two hundred has to be possible without it.

A vault with NO hosted worlds is refused the offer entirely. With nothing to compare against every
file is unreferenced, which is a true sentence and a catastrophic thing to act on — a vault that
serves the game without publishing anything would be handed its whole store. The scan reports how many
worlds it read, and the page treats zero as an unasked question rather than a clean result.

The delete RE-COMPUTES the set rather than accepting the hashes the page listed. That is the guard
that matters: a client's list is a snapshot, and a snapshot acts on a world that has moved. A file
published between the scan and the sweep is simply not in the recomputed set and survives, which is
the safe direction; the reply says how many actually went, so a page can tell its own list was stale.
The test proves it by publishing a world for a listed file after the list is taken and asserting one
of the two goes.

Two route details worth knowing before touching them. '/api/media/orphans' is registered BEFORE
'/api/media/:sha' because express matches in order, and behind the parameterised route the word
"orphans" arrives as a hash, is refused by the store as malformed, and answers 400 — a sweep that
reads as a typo. And referencedMediaHashes reads each world.json once and pulls every 64-hex run out
of it, rather than calling worldsUsingMedia per file: twenty worlds and two thousand files is forty
thousand reads the other way round. It over-matches on purpose — a hex string that is not a media hash
marks a file as spoken for and keeps it, whereas a pattern narrow enough to miss one spelling of a
reference deletes art a published world is using.

removeMany shares _removeOne with the single Remove instead of repeating its work. One index write for
the whole sweep rather than three hundred, but mostly so there is one place the traversal guard lives:
a bulk delete with its own copy of that check is a second place to get it wrong. The save happens even
when some entries failed, because the ones that succeeded are already unlinked and an index left
naming them counts bytes that are not there.

Verified in a real browser as well as in the suite: with nothing published the Remove-all button is
not drawn and the panel says why; with one world published the scan finds exactly the two files it
does not reference; a swept row's thumbnail opens the viewer (which needed mediaKnow — the lightbox
resolved hashes against the newest forty and a swept file is often not among them); declining the
confirm changes nothing; and accepting it leaves the two the world uses. The admin gate is asked where
its absence would actually destroy something — against a store holding one sweepable file, asserting
the FILE survives, not the status code.

PRIVACY.md records the sweep beside the single removal it already described, including that this vault
can only see worlds published to it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

Reported from the editor: when the Game Master writes lore for a faction it does not price the XP at the
same time. It does not — but the surface complaint was the smaller half of this, because pricing one
changed nothing anyway.

normalizeFaction returns a fresh object literal and named three of the four lore fields, with the comment
above them calling it "the same trio items/beings/places carry". A field a literal does not name is
rebuilt away on the next pass, so the price survived the save and died on the load: 45 written, 45 in the
serialized world, undefined back out of rebuildWorldFromSnapshot. Measured rather than argued, with races
as the control — they came back 45, because this was found and fixed for races already.

That makes factions the second kind to have it and dungeons the third. normalizeDungeon carries the same
literal and the same wording — "the hidden-lore trio" — and loses the price identically; it turned up
while confirming the faction one and is fixed in the same breath, because leaving a known break of the
same shape in the branch the next session starts from is not a smaller change, it is a worse one. Calling
a set of four fields a trio is how the fourth kept getting left out, so the word is gone along with the
bug. Both now read through normalizeLoreXp, so null — nobody has priced this, pay the default — stays
distinct from 0, which is somebody deciding it pays nothing; Number(null) is 0, and that difference is
the entire meaning of the field.

The failure is quiet in the worst way. Nothing throws, the editor writes, and the card redraws from the
object it just set, so the DM watches the price take and it is correct right up until the reload. What
they notice eventually is not a wrong number but a uniform one, which is the live evidence for BUG-027:
a whole category priced identically is a category nobody priced.

Then the half that was actually reported. The Lore roster — the only GM path that can write a faction's
or a dungeon's lore at all, since factionFieldPatch has no lore fields and world generation authors none
— described loreXp as "OPTIONAL … omit to leave it at the default", which is an instruction to leave
every secret unpriced. It now demands a price whenever `lore` is written, on the absolute scale shared
across every kind of subject, and says plainly that omitting it is not neutral. It also names its own
carve-out: a references pass is told elsewhere to return loreLinks and nothing else, so an unconditional
demand would have set the two instructions against each other.

And the roster's subject rows now say whether each secret is priced. Without that, "price the ones that
have none" was an instruction the model held the permission for and not the list — it could not tell a
secret priced at the default from one nobody has priced, and those want opposite answers. It is the same
"it had the permission and not the list" fault the comment above that roster already records for blank
subjects, reached a second time by a different field.

Tests/test_lore_xp_survives_normalize.js asserts the property over the whole family in a loop rather than
one kind at a time, so a fourth lore-bearing normalizer is covered the day it joins the list — which is
the only way this stops recurring. Fourteen sabotages, each caught by an assertion naming its own cause:
every normalizer's line removed separately and shown to leave the other two intact, since one "the price
survives" assertion passes with two of the three deleted. test_world_factions' canonical-shape fixture
gained loreXp: null, which is a real assertion rather than appeasement — it pins the default as null and
not 0. Recorded as BUG-095.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Regions say WHERE this world's places are. Nothing said what any of them are LIKE, so the answer was
implied across forty room descriptions and stated nowhere: a salt moor was a moor because six rooms
happened to mention brine. The Biome tab is that statement made once — a kind of country with a name, a
description, a detailed description and a picture, plus the three bindings that say what the sky does
here and what grows and lives in it.

THE BINDINGS ARE HELD BY ID AND RESOLVED LATE, which is the decision the rest of the tab follows from.
A biome stores climate, flora and fauna as id lists and looks each up when it draws, so renaming a plant
does not strand the biome naming it and a deleted one leaves a chip that says it is missing rather than a
stale copy of a name that no longer means anything. The pickers and the Game Master's directive read the
SAME live rosters — a picker offering what the prompt does not is two answers to one question — and an id
the GM invents is dropped on the way in and named in the error, because a biome claiming a plant this
world never had is worse than one claiming none: the chip reads as real until somebody goes looking.

FAUNA IS NOT AN ITEM ROSTER, and the first cut of this had it wrong. Animals used to be animal-TYPE items
and are ENTITIES now — BUG-014 records the same confusion one layer down — so catalogItemsForEditor
('fauna') answers empty in every world that authored its beasts the modern way, and a permanently-empty
picker looks merely unused. It reads the entity catalogue instead, binding the KIND rather than a placed
beast, which is the level flora binds at too: "wolves live here" is a statement about wolves, and tying it
to the wolf standing in room twelve would break the moment that wolf was killed. A one-off animal put
straight into a room with no template is still offered, under a slug of its name, so a DM can bind the
thing they just placed. Found by driving the tab in a browser and seeing an empty dropdown, not by
reading the code.

New writes a biome by hand through a dialog — name, description, detailed description, the three fields
it cannot exist without — while the chips, the picture and the prompt are authored on the card where the
live rosters are. + Add asks the GM to invent one. Two buttons because they answer different states: New
is for a DM who knows what the country is, + Add for one who wants the world to suggest what it should
have.

world.biomes is a new world-level map, so it is named in the World constructor, in serializeWorld's
allowlist and in rebuildWorldFromSnapshot, and joins WORLD_BACKFILL. Tests/test_biome_tab.js §1 asserts
that by SAVING AND RELOADING rather than by checking three functions mention the word, because missing
the third place is silent: the tab works all session and the map is gone on the next load, which is how
this codebase lost its ailments once. The tab also joins ENV_INNER_TABS, EDITOR_CARD_VIEWS, EDITOR_IO,
CARD_PORTRAIT_KINDS and compendiumTypeContext — the last is what makes the card's ✨ do anything at all,
and without it the button spins down and changes nothing with no error to say why.

One thing the screenshot caught that no test would have: the panel CSS is long hand-written selector
lists, one id per tab, and a tab missing from them renders with its Game Master bar crushed against the
left edge. The biome ids are in all ten.

Five sabotages, each caught by its own named assertion: the snapshot rebuild dropping the map, the
serialize allowlist dropping it, the fauna picker reading items, the GM's unknown-id filter removed, and
the chip de-dupe removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The lightbox that landed one commit ago is reachable only by mouse. Its opener is a <span> carrying a
click handler, and a span is not in the tab order, answers neither Enter nor Space, and is announced
as nothing — so the one way to look at a stored file does not exist for anyone navigating by keyboard,
and a screen reader is told there is nothing there to press. The overlay says aria-modal="true" and is
a plain div: no focus moves into it on open and none comes back on close, so a keyboard user who did
somehow open it would carry on tabbing through the page behind it.

A viewable thumbnail is a <button> now and an unviewable one stays a <span>, which is the same
distinction the viewable class already draws: a mesh has no viewer, so it must not become a control
that presses to nothing. The glyph inside is aria-hidden and the picture's <img> has an empty alt, so
each button carries its own aria-label or it announces as a control with no name. The page's global
button rule reaches these now — `.thumb` already wins on border, background and layout by specificity,
but padding, colour and font it does not, and a 40px picture wants none of the three — and the focus
ring is added with them, because a tab stop nobody can see they have reached is worse than no tab stop.

Opening moves focus to Close and closing puts it back on the thumbnail, guarded on isConnected: every
removal rebuilds the list, so the element focus came from may no longer be in the document, and
forcing it then would be worse than leaving it. The click is also cancelled, which fixes a second
thing: the opener sits inside the row's <summary>, so one click was opening the viewer and toggling
the row open behind it.

The store's removal now takes an emptied shard directory with it. The shard exists so that no single
directory grows unbounded, which means a vault that has churned through generations accumulates up to
256 of them, each left behind holding nothing. It is rmdir and never a recursive remove: rmdir
succeeds only on an empty directory, which is exactly the condition meant, and two files sharing a
shard is the ordinary case rather than the rare one — forcing it would delete a neighbour nobody asked
about. The test searches for a real collision rather than assuming one, because a directory with a
single file in it cannot tell a correct cleanup from a destructive one; a recursive remove fails it by
name.

The page assertions that already existed passed throughout this, and could not have done otherwise:
they pin the class and the data attribute, both of which the span and the button carry identically.
The element was the property they could not see. Verified in a real browser as well as in the suite —
Tab to a thumbnail, Enter, the viewer opens with the picture in it and the row still closed, Escape,
and focus is back where it started.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mHeLeHVmQXJK4x4pTG9MU

The Media tab could say how much art the vault was holding and nothing else about any of it. A row
showed a 40px thumbnail, a date and a size; there was no way to see the picture properly and no way to
delete one. The second gap is the one that mattered: worldStore.remove deliberately does not touch
media — the bytes are content-addressed and may be shared with another world, which is the entire
point of addressing them by content, and its own comment says so — so unpublishing a world leaves its
art behind forever with nothing anywhere able to reclaim it.

The viewer is a lightbox over the page: images shown as large as the viewport allows, sound and video
PLAYED, because "what is this file" has no other answer for those and the list can only ever say
audio. A mesh gets an honest refusal and its URL rather than an empty frame pretending a preview
failed. Only the three kinds it can actually show are given the zoom cursor. Closing replaces the
stage's contents rather than hiding them, so a closed lightbox is not still holding a video's decoder
and buffer.

Removal is two steps and the first one is the SERVER's. The DELETE is sent without force; a file a
published world still references comes back 409 carrying the worlds by name, and only then is the
admin asked — with the names in front of them rather than a generic are-you-sure. A file nothing
references goes on the first call, so the common case is one click and no dialog. The refusal is not a
confirm box because this is an HTTP API: a guard that lives only in the browser is one an admin skips
with curl without ever learning what they skipped. The forced answer still carries the worlds it broke,
so the page reports that rather than a clean success.

The store's own removal takes the index entry even when the unlink fails, and reports the two facts
separately. put() already refuses to trust the index alone — "an index entry whose file was removed by
hand must rewrite rather than hand back a URL that 404s" — so the index is a cache of the disk rather
than the record of it, and an entry kept back because the file had already gone would carry on
counting bytes that are not there.

Three things the sabotage pass found, and two of them were mine. The route carried its own 64-hex check
on top of the store's, and no sabotage could break it: every path it guarded was already refused
downstream with the same status, which is the signature of a guard that is decoration rather than
defence. It is gone, and the validation lives with the code that computes a path from the hash. The
gate test asked its question of the REFERENCED file, so deleting requireAdmin still produced a refusal
— a 409 from the in-use check instead of a 403 — and "the file is still there" passed for a reason
that had nothing to do with admin; it runs against an orphaned file now, proved deletable by an admin
first, so the gate's absence actually destroys something. And two assertions carried `|| true`, which
made them pass whatever happened.

test_admin_page pinned `class="thumb"` as an exact attribute and broke when a second class joined it,
while the property it names — that the picture sits in the fixed-size box the rows share — was
untouched. It matches the class now.

PRIVACY.md gains the row this belongs in. Its media line said only "whatever you generate or upload";
it now records that each stored file carries a provenance record including the prompt it was painted
from — the one place a prompt is written to disk rather than held in memory — and that Admin › Media
can remove a file and that record together.

Verified against a real vault in a real browser over CDP: the lightbox opens and Escape empties it,
declining the confirm leaves the file and says so, and accepting it removes the file and reports the
world it broke.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Two reports from the screen, and they turn out to be one idea: the diamond means SHOW ME THE 3D WORLD.

IT WAS PAINTING A SINGLE FRAME. The banner showed the panorama, which is a picture OF the world where
the reader had asked for the world. The diagnosis in the report is right -- the splat renderer is a
separate document, and it has to be: it is a real sorted alpha-blended renderer built on ES modules, and
this app is deliberately openable from file://, which rules modules out. What the report did not have to
follow from is that the document can only live in a WINDOW. Framed, the same page runs inside the story:
same origin, same vault, no change to either side. So the live banner is the renderer now.

What is STORED stays the panorama. A story is rebuilt from its log on every mount, and a save that
remembered three rooms in 3D would open three WebGL contexts before a word had been read. The log
remembers the CHOICE and the picture; pressing the diamond again is what asks for the renderer, which is
one deliberate act per scene. For the same reason exactly one runs at a time -- browsers cap those
contexts and discard the oldest, which reaches the reader as a scene going black for no visible cause.

Outside a vault there is nothing to frame and nothing to walk: the renderer and the splat both live
there. The panorama stands in, and says so rather than offering a door that opens on nothing.

THE EDITOR'S DIAMOND ALWAYS BUILT. Pressing it on a room whose world had just been made from the story
spent another few minutes of World Labs and replaced the world with a new one. Nothing on the button
said a world already existed -- it said "Build", and a DM reads that as "the 3D one". It now shows the
world when there is one, and names the banner it was built from, because a world is one per room and the
answer is the same in every slot's row. A rebuild is still reachable through Remove on the card's own 3D
World block: a deliberate two-step for something that costs minutes and overwrites.

The one-renderer rule was wrong on its first writing and a browser caught it: it excepted the ROOM, so
two scenes of the same room both kept a renderer -- and a room is somewhere you come back to, which makes
that the ordinary case rather than a corner. It excepts the NODE being replaced, and for one reason only:
the caller is about to overwrite that node and would otherwise detach the reference it still holds.

Two assertions were rewritten after failing to earn their place. One read the source for the
screen-versus-log split and passed against a sabotage that kept the line and changed only the value it
picked; it drives the switch now and looks at what lands in each place. The other asserted that the
demotion was CALLED rather than what it spared, which is how the room-versus-node bug reached a browser
at all.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

A reader has no way to tell how current either guide is against the game underneath it.
Both covers now show a "Last Update MM/DD/YYYY:HH:MM" line, upper right, in the same
font-mono/dim styling the tag line uses — static and stacked under the title on narrow
screens rather than overlapping it. CLAUDE.md records the convention: update the stamp
whenever either file's content changes, and leave it alone otherwise.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XxvekQg7HGXx1yVv2pPrp

An ability is a standing grant that lives OUTSIDE the object carrying it. Wearing is only the commonest
way one gets attached to a character — it is where the engine grew the idea — and it is not the only
binding the magic system needs. Eating is another, and for enchanted flora it is the one that matters: a
bloom whose gift is permanent rather than an hour of +1 WIS.

There was no way to author that. consumeEffect is explicitly never permanent and is capped at a day; no
item effect trigger fires on consumption at all; and player.abilities — which is permanent, deduped and
survives save/load — could be written only by the Game Master choosing to in the moment, so a lasting
gift could not be designed, balanced or reviewed, only improvised.

"consumeGrants" is that field, and deliberately NOT "abilities". That one means "while EQUIPPED" to its
single reader, equippedAbilityGrants, which walks the worn slots; and since the Items tab stopped drawing
the Grants section on anything unwearable, a gift put there would be invisible on a plant's card as well
as unread by the engine. One field meaning two things by type is the tier collapse this codebase has
already been bitten by, so the two sit side by side instead: Grants (equipped) on a ring and never on a
flower, Grants (consumed) the reverse, and the consumed pair reads down the card as what swallowing the
thing does — the gift that stays, then the hour afterwards.

It is authored here and applied by the Game Master, which is not a shortcut. There is no consumeItem() in
this engine and Tests/test_consume_button.js says outright that there must not be: what a consumable DOES
is adjudicated from what the model is told, exactly as consumeEffect already is. So the gift reaches the
GM as a per-turn note beside the consumption status, naming each ability as authored, naming
abilityChanges as the field that grants it, and saying it does not expire — because the GM is the only
thing that can apply it, and a gift nothing is told about is a field the DM filled in that never once
fires. abilityChanges already supports removal, so a gift given this way can be taken back later by
something else in the world, which is the flexibility the magic system wanted rather than a one-way door.

The other half is the Magic checkbox, without which none of this was reachable for flora. The flag was a
read-only "yes"/blank row, so the only ways to enchant a thing were the Game Master and the Save Editor —
and the flag is not cosmetic: it decides the Compendium tab, opens the identity gates, and is what lets a
plant reach the Sensed tier at all. It writes the property and never the removed legacy type, so an
enchanted dagger unenchanted is still a dagger, and an enchanted herb still catalogues as Flora and is
still read by Herbalism.

Two test fixtures were wrong in the same way and are fixed rather than worked around: ITEM_CATALOG entries
carry no `id` of their own — the key is the id, and catalogItems() attaches it on the way to the card — so
a card built from a raw catalogue value wires every control to fn('undefined', …). That renders
identically and does nothing when clicked, and the discovery editor's assertions had been checking only
the setter NAME, which waved it through. They name the id now, which is what caught this.

Four sabotages, each caught by its own named assertion: the applier dropping the field, the GM note never
hung on the roster, the card section gated on wearable instead of edible, and setItemMagic writing the
legacy type.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Regenerated from a full (previously unshallowed) checkout: node Tools/gen-progress-report.js
against origin/main now walks all 3,796 commits back to 2026-06-30, rather than whatever slice
a shallow checkout happened to carry. The prior committed report was badly stale as a result —
its point-in-time snapshot had frozen at a small fraction of the actual commit count.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MYhdD4BNjuNC1k97jYYBwH

The button undoes a switch. It was resetting the scene to the room's configured art for that hour
instead, and those are very often not the same picture: "Show Weather Imagery" re-skins a banner in
place, and a pinned time slot answers for every hour. Press it on a scene that had been re-skinned for
rain and the rain went away -- so the control that promised to put things back visibly changed them.

Recomputing was the mistake. The picture on screen is the only thing that knows what the picture on
screen is, so switching away now captures the live <img> src and coming back restores exactly that. It
has to be read from the element, and read BEFORE the swap: patchLiveRoomBanner re-skins by swapping the
src and stamping the sky in the LOG ALONE, so the element itself never says it happened, and after the
swap there is no <img> left to ask.

That covers the session. The reload is covered by the sky travelling with the switch in BOTH directions,
which is where the rest of the bug was: the stamp was dropped on the way out to a clip, so by the time
the reader pressed back there was nothing left to say the scene had ever been rained on, and the next
mount resolved the room's plain art and changed the painting by itself.

Two more faults came out of fixing it, both mine and both from the commit that added the toolbar.

THE BLOCK REGEX INSISTED class CAME FIRST. A stored banner is turned into a lean reference by
noteStoryBannerWeather, which inserts its marker AHEAD of class -- so the form matched the markup as
first written and never matched its own output. Switching one banner twice across a reload would find
nothing to rewrite and revert on the next mount, silently. STORY_BANNER_IMG_RE carries a comment about
this exact trap, immediately above; this fell into it anyway.

THE REWRITE WROTE LIVE MARKUP INTO THE LOG. A still's src can be a base64 data URI -- every weather
re-skin produces one -- and one player's save reached 441 MB of them frozen into messages, which is the
whole reason stored banners keep a reference and resolve the pixels at mount. A still is now written
back in that lean form. A clip and a 3D world are written whole, as a video banner already was, because
their pictures are not the room's art to resolve back to: the stripper would empty a 3D banner's
panorama and the resolver would refill it with the still, leaving a scene showing a painting while
still calling itself 3D. The stripper skips them by name for the same reason.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Pressing a banner's clip or 3D-world button started a generation and showed nothing. The old picture
stayed exactly where it was for the whole wait -- tens of seconds for a clip, MINUTES for a World Labs
world -- which is indistinguishable from a button that did nothing, and long enough that the honest
reading is a hang.

Over the whole picture, unlike the weather ring in its corner, and the difference is the wait. A
re-skin for the weather is seconds and the scene it produces is the one already on screen; here what is
on screen throughout is the thing about to be replaced. So the banner is dimmed, which is the surest way
to say "not this, yet", and the ring is centred rather than tucked away.

It carries a line of text, which the corner ring does not need. The generators already report progress --
through setEditorStatus, which is the DM EDITOR's status line. Pressed from the story, the existing
feedback goes somewhere the reader is not looking, so the overlay says what the wait is for and the 3D
one says it takes minutes. A reader told that waits; a reader told nothing reloads a minute in and loses
the run.

pointer-events: none, for the reason the weather ring's own comment gives: the banner is click-to-expand
and a dead rectangle over it is a bug nobody would connect to a generation. What has to refuse is the
BUTTONS, and all of them, not only the one pressed -- a second generation started over the first is two
provider calls billed for one scene.

Built with createElement into the live DOM and never into the stored html, which is the rule
syncWeatherBannerSpinner states for its own ring: the story log is persisted, and a spinner written into
a saved message is a scene that spins for ever after a reload. Under reduced motion it breathes instead
of spinning, because an animation merely switched off leaves a still ring, and a still ring says broken.

The attempt is also CAUGHT now, not merely un-frozen. The generators report their own failures, so this
is for the case they cannot: one that throws rather than returning. This runs from an inline onclick,
where a rejected promise is an unhandled rejection in the console and nothing else -- the overlay would
clear and the press would look, again, like it did nothing.

Two assertions in the banner test were rewritten after they failed to earn their place. One matched the
catch block in the SOURCE, and still matched with its body disabled behind an `if (false)` -- so the
sabotage that swallows the error passed. It now drives a throwing generator and asserts the handler does
not reject and the failure reaches the log, which is the property rather than the shape. The other pinned
its subject within 40 characters of another line and broke when a comment was written between them; it
asserts the ordering instead, a distance being no part of what was meant.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Two small corrections to the Discovery editor, from reading it back against the rest of the system.

The tier dropdown offered Sensed on every gated card. Play cannot reach it on most of them:
resolveItemIdentify produces the middle tier only for what itemSupportsSensed accepts, and the Game
Master's room note has one phrasing for a sensed thing that special-cases contraptions alone — so a
bitterroot set to Sensed told the GM the player "can tell this is clearly magical" about an ordinary
root. The option is now filtered on itemSupportsSensed rather than on the type, which is the distinction
that matters: magic flora is a first-class thing in this engine — an enchanted herb keeps the Flora tab
and is still read by Herbalism, because itemCompendiumCategory and identifyingSkillFor both let the
natural kind win — and its near-miss is precisely what the tier is for. Asking the predicate keeps the
enchanted flower's option and takes the plain root's. An item already sitting on a tier keeps that
tier's option whatever the predicate says, because a select whose value is absent from its options
displays the first one instead: a gated item would read "Known on sight" and be written that way the
moment anybody touched the control.

The other is one line of the item directive. "apparentName" was described only as "a mundane descriptive
stand-in", so a Game Master authoring a gated plant writes "a pale night flower" — a description of a
thing nobody has a word for. The stronger shape for a plant or for a relic ordinary people handle is a
REAL COMMON NAME the thing already goes by: everyone knows the root as bitterwort and only a herbalist
learns it is Emberleaf, the wound-knitter. The engine never cared — both are strings, and the apparent
name has always been free text — but nothing told the model the option existed, so it did not produce
it. A common name is not a lesser name, and the reveal lands harder when the player already had one.

Tests/test_item_discovery_editor.js §3b builds a plain plant and an enchanted one and asserts the option
moves for one and not the other, that nothing else moved with it, and that an already-sensed item keeps
its option. Two sabotages: gating on the type instead of the predicate, which costs magic flora the tier
and is caught by name, and dropping the current-value escape hatch, which strands a gated item on a
control that shows the wrong state.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

A room can carry three pictures of itself: the painted still, a clip generated from that still, and the
3D world World Labs builds from it. Two of the three were reachable only from the DM editor, so a player
never saw them and a DM saw them on a different screen from the one they belong to. A banner now carries
a small vertical toolbar in its upper-right corner, revealed on hover: play the clip, show the world,
come back to the painting.

WHICH BUTTONS ARE DRAWN is a question about what each could DO, not about what exists. A button appears
when it can SHOW something already there, or ASK for it -- and only a DM can ask, since a clip costs a
provider call and a world is minutes of World Labs behind the vault's key. A player in a world with
neither gets no toolbar at all, rather than two controls that answer "nothing to show" on a screen
people read. The generators are the same ones the editor's buttons call; this is a second door, never a
second implementation.

The choice belongs to the BANNER. Scrolling back through a long story should show each scene however it
was left, so the swap is written into messageLog -- that string is what the transcript is rebuilt from on
every mount, and a DOM-only swap looks right until the reload and then silently reverts. It is addressed
by ORDINAL: the transcript renders from the log in order, so the Nth banner for a room on screen is the
Nth in the log, and that holds for the banners already saved in everybody's existing games, which an id
minted into new markup would not.

Four things here are quiet when they go wrong, and each has an assertion naming it.

NO <div> IN THE TOOLBAR, which is why it is made of spans. Three regexes carve a banner block back out of
the stored log by matching to the FIRST </div>. One <div> here ends those matches early and what they
write back is half a banner plus the orphaned tail of the old one -- saved, for every scene in the story.
Nothing throws; the transcript starts coming back broken a session later.

TWO VOCABULARIES. A banner's data-banner-time is a LABEL ("Morning"); bannerImages and every generator
are keyed by SLOT ("morning"). getBannerImageFor lower-cases for you and hides the difference;
roomBannerImageForTime and roomBannerGenerateForTime do not, and handed a label they report that a slot
whose picture is on screen has no image. That bug was written and then caught here, not in review.

THE CLICK. The banner is click-to-expand and the toolbar sits inside it, so a tool press bubbled to the
width toggle. Caught centrally in that handler rather than with a stopPropagation in each button, so a
fourth button added later cannot resize the scene it was meant to switch.

THE DEMOTION SWEEP. Only the newest banner per room animates, so that walking a dozen rooms does not
leave a dozen clips playing at once. A reader who pressed play on one scene asked for exactly that one,
and undoing it on the next room entry is the silent revert this file pays for elsewhere -- so a
deliberately chosen banner is exempt, in the log pass and the live DOM pass both.

The 3D button shows the PANORAMA, which is the world seen flat and is what a banner is. The walkable
splat stays where it has to be: an ES-module renderer in its own window.

Two existing tests changed rather than being deleted. test_pin_room pinned its subject within 400
characters of a function name and a comment pushed it past; it now slices the function, because a
distance is not the thing being asserted. test_equipment_slot bans the word "interchangeable" outside
commentary and stripped only // comments, so the /** */ written about the label-versus-key distinction
tripped it -- block comments are stripped too now, and the guard still catches the word planted in a real
prompt.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Three things, found by pulling on one thread.

THE SPLIT ENTRY. An unidentified magic ring reads to the player as "a plain iron band" — nothing about
it looks enchanted — so the Game Master, told by rule 13 to choose the single best-fitting category,
files the sighting under "items". That is the honest answer to what the player saw. Identifying it then
wrote the true entry under "magic", because itemCompendiumCategory reads the magic flag the player now
knows about, and recatalogIdentifiedItem hunted for the stale apparent-name entry only in the item's
TRUE category. It never found it: two entries for one ring, in two tabs, one of them still calling it by
a name that is no longer true. Invisible in testing, because the Magic tab on its own looks exactly like
a clean rename. The sweep now crosses every item category, keeps the entry already in the true one where
there is such an entry and otherwise promotes and MOVES the first, and removes-then-re-adds rather than
filtering in place, since a keeper changing tabs would otherwise be filtered out of its old list and
never put back.

Rule 13 gained the other half, which stops the split rather than repairing it: an unidentified thing is
not a discovery yet. The engine already catalogues an item the moment it is identified, under its true
name, so an entry written before that either names a thing the player cannot name or — worse — files it
under "magic" and hands them the enchantment the identify check existed to earn.

THE GATE WAS INVISIBLE ON THE ITEMS IT WAS BUILT FOR. The card asked itemHasIdentityGate(type) where
every other caller in the file passes the item, and the two differ for exactly the case this section is
about: magic is a FLAG now rather than a type, so an enchanted ring is type "misc" and the bare string
answers no. The Barrowking's Signet — the world's one magic item, authored with an apparentName, a
falseName and a falsePayload — drew no Discovery section at all, while an ordinary plant drew one.

AND IT WAS A READ-OUT. The section was a row of chips whose own comment said the fields were "authored
by the GM / the // command / the edit box; shown here for reference", so a DM could see that a ring was
gated and had no way to say so — setting an apparentName, or moving a thing between the four tiers, meant
asking the Game Master in prose for a field the card was already displaying. Every gate field is a
control now: the tier, whether the thing is in plain sight and how it is found, the apparent name, how
its identity could otherwise be learned, the skill that reads it, the false name that makes a near miss
mislead rather than half-inform, and the one-shot attempt. The tiers are interpolated from a new
REVEALED_TIERS roster rather than typed into the select, and each carries the sentence saying what the
PLAYER gets, because a dropdown reading Sensed and Misidentified with no explanation is two words nobody
can choose between. Identify DC stays up in Details where it has always been — it is one number, read
beside value and weight during a repricing pass — but it is named under the skill that uses it, and only
while the item is actually gated.

Two deliberate choices worth knowing. Every field is shown whenever the type is gated, including ones
that only bite at a tier the item is not on: an apparentName is authored BEFORE the item is set Unknown,
so a control that appeared only once the tier was set could not be reached in the order anyone authors
in. And these write through to live copies like every other field on the card, which for `revealed`
means a copy the player already identified is set back to whatever the DM picks. The alternative — the
catalogue type only — means marking a ring Unknown leaves the ring already in the room unchanged, which
is the same surprise pointing the other way. The control says so in its tooltip.

Tests/test_item_discovery_editor.js covers both halves, with five sabotages each caught by its own named
assertion: the sweep narrowed back to the true category, the keeper never re-added, the tier stored as a
raw string, the select hand-written, and the card asking the bare type again. Tests/
test_flora_identify_dc_display.js was re-pointed rather than relaxed — the DC is still asserted present
while gated and absent once known, which is the property it was written for; only the control it rides
on has changed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The section had twenty-six good questions and no way in. Somebody sitting down to test the craft got a
list ordered by informativeness, mixing notes that want a character with notes that want an editor tab,
and nothing about how to arrange either — which is most of the reason a section like this goes unread.
§15.1 is the missing half: the setup, the order, and what to keep.

The setup is four `//` lines, and the first one matters more than it looks. As of rev. 16 a character
without the Concoction skill has no Prepare button anywhere, so a tester who makes a Bladeward and
starts playing finds every note in the section unreachable and nothing telling them why. `// learn
skill concoction` is local, deterministic and force-granted — it does not ask for Herbalism the way
spending a skill point would — so it is one line and no API key. The ingredients and the receipt book
go through the `//` router instead, which classifies anything it does not recognise as an item
directive, so those are GM calls and the note says to check the Inventory tab rather than trust the
narration. There is deliberately no `// learn reagent`: readBook is the only thing in the engine that
calls learnReagent, so a shortcut past the book would skip the feature under test.

The warning worth the callout is that an existing save is the wrong place to test this, and the reason
is the backfill rule rather than a bug. backfillWorldFromBuiltIn is additive and never overwrites, so
`venomers_receipt` arrives in an old save because its id is new, while `cured_venom` is already there
and keeps the version with no `secret` on it. The tester then finds the book, reads it, and is told
they already know every receipt in it — and reports the feature broken. Measured rather than reasoned:
backfilling a pre-rev.-16 snapshot adds one item and leaves `secret` at false.

Three observations are one-shot and have to run first, because each is destroyed by anything said
beforehand and none can be repeated on the same person — whether a player finds the middle tier at all,
whether a missing Prepare button reads as "not yet" or as "broken", and whether the Compendium's silence
about a secret reads as completeness. That makes two characters the honest shape of a session: the gated
observations need somebody who does not know, and most of the rest need somebody who does.

On recording: the session already records itself. `prepare` and `brew` both call capturePlaythroughTurn,
so the save's messageLog is an exact replayable log and is the artefact worth keeping rather than a
written summary. And neither tier calls the model at all, which is worth knowing while budgeting a
session — the craft is free and only the story turns around it cost anything.

§15.2 now names which six notes belong to a playthrough as against a sitting at the editor, so a tester
with one session in them knows which to run.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Two halves, and the reason for two is that "can a character put this on?" cuts ACROSS the taxonomy.
Armour is worn, a ring is worn, a robe is worn, a staff is borne, and no single type gathers them —
so a type alone could never answer it, and a label alone leaves jewelry and dress sitting in the
residual bucket with the rope and the cookware.

The TYPE gathers what is worn for what it IS rather than for what it stops: jewelry, dress, regalia,
the marks of office. Its border is against `armor` and the border is real rather than a matter of
taste — `armor` is the type that carries base `ac` and the only type the Item Editor draws the Base
AC field for, so a circlet typed `armor` is handed a field it must not fill. That line is stated in
`means` for the same reason the staff entry names quarterstaff: both readings are reasonable, and an
author who guesses wrong gets an item that behaves like the other one.

Unlike staff, this type took vocabulary away from another. `misc` gave up "jewelry" and "clothing",
because `misc` means "everything with no mechanical kind of its own" and those two now have one;
leaving them would have been the two-reasonable-ways problem with no meaning to separate the
readings by. `weapon` kept "quarterstaff" when `staff` arrived because a plain fighting stick
genuinely IS a weapon, and there is no comparable sense in which a ring is miscellaneous. The two
cases look alike and were decided opposite ways, so the test pins both.

The SUBTYPE is the cross-cutting half, and it is the first entry in ITEM_TAXONOMY_UNIVERSAL to carry
`always` — a condition that makes it required rather than available. The other three are genuinely
optional: an item that omits "masterwork" has said something true by omission. This one is not like
that, so the prompts state it as a requirement instead of listing it among the options, in the full
authoring rendering and in the brief per-turn one alike — the per-turn prompt being where items are
most often created, and a rule stated only in the authoring passes being absent from the turn that
grants a cloak. The sentence is interpolated from the `always` string rather than typed out, so a
second required label cannot leave the prompt still describing it as optional.

And the piece that makes the type more than a word: a wearable that declares no `equipmentSlots`
takes them from its form, through the slot synonyms the doll already reads. Without it a worn thing
authored without the field is simply unequippable, which is the failure the type exists to end and
the one least likely to be noticed, because the card looks complete. It is narrow in three
directions and each is asserted rather than assumed: an explicit array still wins, a thing that never
said it was worn infers nothing, and a wearable naming two forms takes the first rather than fitting
two slots at once. A form with no place on the doll — a brooch, a mask, an earring — resolves to
nothing and stays unequippable, which is the honest answer; a synonym pointing at the nearest slot
would equip a mask as a hat.

`equipmentSlots` remains the mechanism and `isWearableItem` is deliberately the weaker question,
asked in exactly one place. Nothing may come to gate equipping on the subtype: it is a label an
author can leave off, and two sources of truth for "can this be worn" is how gear authored for a new
slot went silently unequippable the last time.

Three smaller things fell out. `ring` and `amulet` shelved under Treasure in the inventory pack,
which the taxonomy's own definition of treasure contradicted — "a trophy kept to admire, NEVER worn,
wielded or used" — so they move to the new Worn shelf. Six clothing synonyms and three jewelry ones
were added for the forms the armoury never had a word for; every one of them normalized to "not
equippable" before, so no gear already authored or equipped moves slot. And the generated reference
said "twelve types" in four places while the badge beside it, interpolated, said sixteen; every count
on that page is spelled out of the data now.

Tests/test_item_type_wearable.js pins all of it, and each of its assertions was checked against a
deliberately broken build — thirty sabotages, each caught by a distinct assertion naming the failure.
One of them found a real defect before it shipped: ring and amulet had been removed from the Treasure
shelf without being added to the new one, which would have dropped both onto the trailing Other
group.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The question this answers had been sitting in the design doc since the tier was built — how does a
reagent become known? — and answering it turned up something worse than the gap. Every reagent record
has carried a `skill` field since rev. 13 and nothing read it. A character with no craft at all could
grind comfrey to meal and cure spider venom; only the brewing one tier up ever asked for a skill. That
is the quiet kind of failure: the preparation succeeds, the measures appear, and the only evidence is
a Skills tab nobody consulted.

So there are two gates now, and the whole point is that they are two. The CRAFT is `skill` on the
record — can you work a mortar at all — defaulted to `concoction` rather than to ungated, so a world
cannot open the tier by omitting a field. The FORMULA is `secret`, answered against
`player.reagentsKnown` — do you know what goes into what. Both are required, which is the shape
spellcasting already has: the Spellcasting skill says you can cast, the spell list says what. They are
separate refusals with separate reasons because they send a player to two different screens, so each
names itself: "You do not know how to prepare Cured Venom" sends them looking for a book, "Preparing
Knitbone Meal is Concoction work, and you have not learned it" sends them to the Skills tab. One
message covering both would send them nowhere.

`secret` is opt-in, and that was the decision rather than the default. Flipping it — every reagent
unknown until taught — leaves a fresh character able to prepare nothing at all, which is a different
game, and one arrived at as a side effect of adding books rather than as anything weighed. The flag
also had to exist before a book could mean anything: knowsReagent answered true for every reagent with
no class gate, which is all four shipped ones, so learnReagent had nothing to unlock and teaching a
formula changed nothing anybody could see. Every surface would have agreed that something happened.

A receipt book is an ordinary `book` carrying `teachesReagents`. It rides readBook, the generic
multi-lesson path a skill book and a lexicon stone already share, and it sits beside the TONGUE lesson
rather than the craft one: `teaches` costs a learning check and spends the book, because a craft is
practice, where a formula is knowledge and reading it is learning it. So no roll, nothing spent, the
book kept — and a thicker one holding four formulae teaches the two you did not have without charging
you for the two you did. The shipped example is The Venomer's Receipt, stocked by the Herbalist, and
cured_venom is the one shipped secret: drawing venom off a living gland without poisoning yourself is
knowledge somebody keeps, where grinding a dried root is not, and the world already had a keeper for
it. The Herbalist's stock line is a `ref` rather than an inline entry, because an inline one slugs to
`the_venomer_s_receipt` and collides in the catalogue with the id it was written under — which the
evaluation pass caught, in test_name_collision_fix, exactly as it is meant to.

A book teaching an OPEN formula is the failure that looks like success from every angle, so the
surfaces say so where somebody can act on it: the item card's Receipts picker labels each reagent
secret or "open — teaches nothing", the chip on a book already carrying one says so, and the GM's item
directive lists this world's reagents with the secret ones marked. A dangling id is handled harder,
because nothing downstream refuses one — the item roster drops an unknown reagent id with a warning
naming it, and bookReagents filters again at read time. Both rosters interpolate from the live record
set rather than a pasted list, which is the rule this repo has paid for twice.

Tests/test_reagent_gating.js pins all of it, with the two gates asserted separately and a section whose
only job is to prove neither stands in for the other — a single "can this character prepare it" check
passes against an implementation with either gate deleted. Fourteen sabotages were run against it and
each is caught by an assertion naming the right thing. Two existing fixtures learn the craft now, or
every preparation in them is a refusal. test_world_keypair's "no field is even named for one" guard
read /privateKey|"secret"/ and was tripped by a reagent's boolean; it names key-shaped fields now,
since a world is full of secrets and a guard that fires on the word rather than the thing is one
somebody eventually silences.

Not built, and recorded in §14.8: nothing checks that a secret formula is REACHABLE. A world may mark
a reagent secret, ship no book and no keeper for it, and the reagent is unobtainable with no finding
anywhere — which is the shape of question the evaluation pass exists to answer over world data.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Yesterday's paragraph routed each kind of enchantment to the field that carries it, and left the
decision to reach for one at all with the model. Those are different claims, and only the second is the
one a DM feels. The tell came from the desk: asked to try the change, the next move was to type "a magic
ring THAT PROVIDES AN ABILITY WHEN WORN" — spelling out the half the directive had not asked for. A DM
should not have to. Magic and wearable are both already in "a magic ring", and together they are the
whole trigger: the request is for a ring that does something.

So the paragraph now states the default rather than the taxonomy. It names the two facts as a pair, says
arming the item is part of answering the request rather than an extra, and points at "abilities" FIRST
because that is the field that says what the bearer can DO and it is what usually makes a worn
enchantment worth wearing. The other fields stay where they were, as what to reach for when the power is
plainly something else — a Ring of Protection is still an acBonus, and a ring still never sets "ac".

The counterweight had to be narrowed in the same pass, because it was the escape hatch. "NOT every magic
item is mechanical" is true and was stated flatly, which reads as permission to leave a RING purely
narrative — the exact behaviour the paragraph above exists to stop. It is the UNWORN relic that is
exempt: an orb, a quest token, a thing that opens one door. A worn one may still be narrative when the
instruction asks for a keepsake or a signet whose point is what it signifies, but that is the unusual
case and the model is asked to be able to name the words that requested it. The built-in world agrees,
for what one item is worth: its only enchanted thing is the Barrowking's Signet, worn on a ring slot,
and it carries an acBonus of -2 rather than nothing at all.

The test gained §3 and §3b for the two halves, and the sabotage that matters is yesterday's own wording
— which routes every field correctly, states the gate, and applies cleanly, and now fails six
assertions naming exactly what it does not say. Getting that discrimination meant fixing the test as
well: the paragraph lookups were anchored on their headings, so any rewording failed them whether or not
the rule survived. They find their paragraph by something it SAYS instead, and the presence checks ask
whether the line exists rather than whether it is long enough, so a shorter wording of a rule that still
stands is not reported as its absence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Journal › Languages is a card per tongue this character has the alphabet or a word of, the twenty-six
English letters under it with a count on each, and a letter opening a filtered list of the words behind
it. It is the first screen in the game that answers what do I actually know, and the engine has been able
to answer it since the lexicon shipped: knownLanguageWords, with the dialect pairing rule already inside
it, had no caller anywhere in the file. The tab is a reader over player.languages and holds nothing of
its own, because a tally kept beside the save would be a second answer to a question the engine already
answers, and the two would part company the first time a word arrived by a path the tally had not heard
of — a bilingual page, a grant in the Save Editor, an imported character.

The card appears for tongues the player never studied, and that is the point rather than a side effect.
A reader who learned the capital's words reads the valley dialect's wherever the valley did not override
them, so the valley gets a card saying how much carried, and the words it says differently are simply not
on it. That claim has been true since dialects shipped and until now was only ever observable as a
stumble in the middle of a page.

Four decisions in it each look like a detail and are not. The index is on the ENGLISH word: gate =
kelthar is filed under G, and filed under K it is an index into the answer, usable only by somebody who
already has it. The letterforms are drawn only for a reader who holds the alphabet, and this is a leak
and not a nicety — a word whose meaning is known renders in English wherever it appears, so its shapes
are precisely what such a reader would otherwise never see, and printing them here hands over the script
one learned word at a time, out of the player's own journal, with nothing on screen ever looking wrong.
Spellings are grouped by the spelling rather than listed one row per tongue, because knowing a word is
knowing a pairing and a dialect that never restated its parent's word is the same pairing under a second
name: grouped, one row carries both names and a second row appears exactly when the dialect really did
say it differently, which is the fact somebody opened the dialog to find. And there is no denominator,
which would state how much of the tongue exists — a number the game gives nowhere else, and one that
turns a vocabulary into a checklist.

The dialog emits the glyph sprite with the letters that point into it. A hand-drawn letter is an svg use
into a sprite emitted per block, and a use with nothing to point at draws nothing at all, so the letters
without the sprite would have been a column of blanks on the one screen whose whole job is to show them.
The filter searches the whole tongue rather than the chosen letter and clicking a letter clears the
filter — two doors into one list, last one used wins — because a filter confined to a letter answers
"not under A" to somebody who typed gate looking for where it was.

Tests/test_language_journal.js pins it, the leak first, and ten sabotages were run against it: drawing
letterforms unconditionally, filing a word under the wrong letter, keeping only tongues with a record of
their own, resolving spellings through the merged lexicon without the pairing check, dropping the sprite,
printing the denominator, confining the filter to the letter, leaving the filter in place when a letter is
clicked, dropping the live refresh, and reporting an undrawn alphabet as unknown. Each is named by a
distinct assertion. Designs/dialects-and-languages.html §9b is the write-up, with two playtesting notes.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

"magic": true is a label. It routes an item to the Compendium's Magic tab and changes no number by
itself — every mechanical thing a worn item does is read off "acBonus", "damageBonus", "abilities" or
"effects", and every one of those is read only from gear the character is actually WEARING. So a DM who
types "make me a magic ring" could get back a beautifully named band whose enchantment existed entirely
in its prose: nothing in the game would ever do anything with it, and nothing would say so.

The directive already specified each of those fields in full, and that turned out not to be the
shortcoming. What was missing was the step before it — which field carries which idea. A model that
knows "abilities" exists still has to decide, unprompted, that protection is an acBonus rather than an
ability and that a ring never sets "ac" (which would replace the wearer's base AC instead of adding to
it). So the new paragraph routes rather than specifies: protection to "acBonus", an enchanted blade to
"damageBonus"/"damageType", a standing grant to "abilities", a worn status to an "onEquipped" effect
with a zero duration, each pointing at the rules already stated below rather than restating them, and
the Ring of Protection +2 worked through to the field and the number.

The gate they all share is stated next, as a gate. An item with no "equipmentSlots" cannot be put on the
figure, so none of those fields is ever read — and since the Items tab stopped drawing the grants
section on gear nothing can wear, a grant authored without slots is now invisible as well as inert,
which is the case a DM has no way to notice and correct. The slots themselves are not restated here:
they are interpolated once in the Fields list, and this paragraph points at that rather than making a
third copy of the roster whose pasting CLAUDE.md already records twice.

The last paragraph is the counterweight. Read alone, the two above say "put a number on everything
enchanted", and a world of +1 keepsakes is worse than the problem. A scrying orb or a relic a quest
turns on may carry nothing but its name and its lore.

Tests/test_item_magic_grants_gm.js asserts the routing and the gate, then drives a reply shaped the way
the directive asks for all the way through requestItemEdit to the character: the ring reaches the
catalogue with its slots, abilities and acBonus intact, the grant is read by equippedAbilityGrants once
worn, playerAC answers 12, and the DM's card draws the section. The same reply WITHOUT slots is pinned
as the failure rather than argued about — stored, wearable nowhere, and drawing no grants section.
Five sabotages, each caught by its own named assertion: the gate paragraph removed, the routing
paragraph removed, the slot roster hand-written into it, and the applier dropping "abilities" and
"equipmentSlots" in turn. The roster's interpolation is proved by adding a slot to EQUIPMENT_SLOTS in
the SOURCE and rebuilding, since the list is derived once at load and mutating it afterwards would have
proved nothing either way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Giving the Cleric, Druid and Ranger a focus repaired the three classes that shipped unable to cast and
nothing else. Any caster authored afterwards — by a DM, by the Game Master's class roster, or in a save —
with spells and nowhere to prepare them is still silently uncastable, and the class editor will happily
produce one. The fix was data; this is the part that generalises.

WHERE THE MISTAKE IS MADE. A class card whose caster carries no field spellbook draws a warning under its
Starting inventory. It says what goes WRONG rather than what is missing — a new character of it cannot
cast at all until they find one — and it names a focus, because "field spellbook" is true and useless to
a tradition that has no books. A warning and not a refusal, deliberately: a DM may well want a caster who
has to find their book before they can cast, and the engine has no business overruling that. What it has
business doing is not letting it happen by accident, which is how three classes shipped.

WHERE IT IS DISCOVERED. castSpell's refusal read "You need a field spellbook to carry X", which hands a
player the name of a thing the engine could not find. It now says that casting draws on prepared magic,
that prepared magic has to be held in something — a spellbook for the arcane, a psalter or a carved token
for a tradition that uses none — and where to prepare it once they have one.

One line came out of the check while it was being tested. It opened by asking isSpellcasterClass, which
answers from the very list the next line reads — a class is a caster when its startingSpells are not
empty — so the guard could never change the answer. A sabotage run proved it by deleting the guard and
failing nothing, which is the useful form of that result: a line that cannot fail is a line that is not
doing anything. It is gone rather than given an assertion written to justify it.

Tests/test_caster_focus.js gains a section covering both surfaces, against eight sabotaged versions: that
a complete class reports nothing, that a non-caster reports nothing, that one authored the way the Cleric
first was IS reported, that the card draws it, that the wording names a focus rather than only a
spellbook, and that the refusal a player actually meets does the same.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Since the last sync (10 Sep), the game gained more than the guides said it had. Culture
shipped Folklore and Religions with real data and GM rosters, not just Languages — the DMG
still described six inner tabs with only Languages behind them; it is five, with three now
live, and a new World › Culture subsection plus an Entities `folklore` row and cheat-sheet
entries cover the rest. All three guides picked up a Folklore mention: the DMG and Field
Guide describe authoring it, the Handbook gets one player-facing callout on hearing a tale.

Reagents & Concoctions moved from "authorable, not playable" to genuinely playable — a
player prepares an ingredient into a reagent and brews a concoction from it, with a real
Prepare/Brew verb, a grade, and a batch/scale — and every guide's warning box said the old
thing. All three now describe the two-step craft; the Handbook gains its first mention of
it at all, in a new Chapter Twelve subsection.

Dialects & Languages' P3 grew a Glyph AI tracing workflow and a Language AI provider that
authors a whole alphabet and dictionary, and shipped a built-in Foreign Languages skill
(a one-time Translate on an unlearned page, teaching nothing) that no guide mentioned. The
skill catalogue gained three built-in classes — Cleric, Druid, Alchemist — so every "the
built-in world offers Warrior, Rogue, Mage, and Ranger" line was off by three; fixed
everywhere it's enumerated, plus the DMG's per-class signature-skill list and a tier-3 note.
Ailments gained a real Diagnosis mechanic and its first player-facing surface (a card on the
Profile sheet, not a new subtab — checked against the actual UI rather than assumed) that
only the Field Guide's DM-authoring section had any trace of. Item taxonomy's two new types
(Mineral, Animal Part) and a fifth Magic subtab (Schools, with its governing-attribute
override) needed one line each. Evaluation, server-vault, modding, and licensing changes in
the same window turned out not to touch anything a guide claims — checked, not assumed.

node Tests/run.js: 872/872 passed. node Tools/build-item-taxonomy-doc.js --check: current.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XxvekQg7HGXx1yVv2pPrp

Stated as an axis by the world author: not all magic is spell magic, and not all spell magic is READ. A
spell is cast at a moment, usually aloud, and has no physical source — arcane spells are read from a
spellbook, divine ones are spoken. A concoction is made, is physical, and applies its effect by the
substance whenever the substance is: thrown, applied, ingested.

The engine had built the first half of that and quietly assumed the second. castSpell's loadout gate
requires an ACTIVE FIELD SPELLBOOK of every caster — the arcane model applied universally — so a fresh
Cleric was refused its own Minor Heal, a Druid its Cat's Grace, and a Ranger its Cat's Grace since long
before either of those classes existed: it carries no book and never has. The Mage worked, because the
Mage is the class the gate was written around. Nothing reported any of it. The classes are playable, the
spells are listed on the character sheet, and the refusal arrives only when somebody tries to cast.

THE ANSWER IS A FOCUS, and deliberately not a new mechanism. What differs between the traditions is where
the day's prepared rites are HELD, not how they are spoken — so the Cleric carries a psalter, the Druid a
greenwood token, the Ranger a hunter's knot. isFieldSpellbook reads nothing but `type: 'spellbook'` and
the `field` subtype, so each is a loadout to the engine and nothing a reader would call a book, and the
preparation limit that rations every caster's day stays exactly where it was. The Ranger needed its own
rather than the Druid's: one shared item cannot carry two different default loadouts, and the token's
second rite is one a Ranger never learns.

The alternative — divine casters need no focus at all — is truer to "a spell has no physical source" and
was rejected on BALANCE rather than on fiction. Loadout slots are what ration a caster, so a Cleric
without one would cast anything it knows, any time, while the Mage stays rationed. Wanting that means
inventing the limit that replaces it, which is its own piece of work.

AND THEN THE SUITE CAUGHT THIS COMMIT OVERREACHING, three times, which is the part worth keeping.

The test written for the above also flagged the Mage's grimoire for carrying detect_magic — which the
class table does not grant — while leaving minor_heal, which it does, unprepared. Read as a dead slot at
character creation, that looks like the same defect one class over. It is not a defect, it is the
mechanic: test_field_spellbook.js asserts that exact starter loadout and uses minor_heal being known but
uncarried as the fixture for the whole system, calling it "the loadout tension". Knowing more than you
carry is the game, and the grimoire teaches detect_magic, so reading it is how that slot comes alive. The
change to it is reverted. A general assertion is the right instinct and is what raised the question at
all — but one written without reading what the existing tests already claim is a way to enforce your own
guess, and this was one edit from shipping a change that contradicted a documented mechanic. The first
test to fail was the one that had written the rule down.

The two smaller catches were real. The three foci shipped MUTE: the world evaluation flags any
spellbook-typed item with no `teaches`, because reading one prints "you find no spell you can commit to
memory" — an unreadable object a player can still buy. Each teaches what it carries now, which is what
the fiction wanted anyway. And the note explaining them went into the item catalogue as a "_comment_focus"
key, JSON-style; the catalogue is a map the engine WALKS, so that string became a phantom item with no
type, icon or art, which the Art tab's Missing list found and which the Compendium and the Items tab
would have shown to a player. WORLD_DATA looks like JSON and is a JavaScript object literal, and the
lines above it in the same file already use real comments.

So what this file asserts is the property that was actually established rather than the one first
claimed: no caster is locked out — each can cast at least one spell its class grants, and at least one
rite in its loadout is one it knows. Not "every starting spell is castable", which is false by design.

Tests/test_caster_focus.js, against nine sabotaged versions, asserted by CASTING rather than by looking
for a book in the pack: a test that checked for the item would pass on a class carrying a grimoire it
cannot use, and would need rewriting the day a tradition keeps its rites somewhere new.

Designs/character-skills.html §10c records the axis, the rejected alternative, and all three corrections.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Four comments written during the skills pass collapsed "spell school" into "school of magic" and said
the Concoction branch hangs off the skill "and not off a school of magic". That is the wrong half of the
distinction, and it is the exact framing this codebase has already undone once.

observedMagicSchools lists EVERY school of magic a world has — not every spell school — and its own
comment records why: a school is a property of MAGIC rather than of spells, so a school worked as a
CRAFT belongs on that tab as much as one that is cast, and listing only spell schools was a leftover of
the spell framing Designs/reagents-and-concoctions.html exists to undo. Concoction is on the Schools tab
with type "earthen", derived from the recipes that declare it, and the README row for that document
states the point outright: the ritual is the whole justification for calling it a school of magic with no
spell anywhere in it.

So the line is between MAGIC and SPELLS, not between a craft and a school. Concoction is a school; it is
not a spell school. It stays out of SPELL_SCHOOL_STATS, no spell may be filed under it, and no caster
class may be built on it — because a concoction is compounded from reagents and carried as an object
rather than recited, and the brewing check reads the SKILL's own stat without ever consulting a school.

Nothing mechanical changes here and no assertion moved, which is worth saying plainly: the tests were
already testing the right thing. They assert absence from SPELL_SCHOOL_STATS, that no spell claims the
school, and that the Alchemist is not a caster — all of which remain true and all of which are about
spells. Only the prose was wrong, in the skill catalogue's own comment, the test's header and one
assertion label, Designs/character-skills.html §10b, and its README row. A comment that describes a
decision wrongly is worse than no comment, because it is read as the decision.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Two fixes, because the leak and the fragility are different failures and closing only the first would
leave the next caller free to reopen it.

syncWorldFromStorage now re-applies world.imported after rebuilding the world from another window's
snapshot. It is the same line the restore, the import, the save editor and the tab viewer already carried,
and it was the only rebuild site without one; serializeWorld does not carry the flag inside the world, so
rebuildWorldFromSnapshot could not restore it unasked. That single omission is the whole of BUG-094: two
windows on one origin, either of them saving, and the flag went undefined, the next save wrote it false,
and the next load merged the fourteen-room built-in world into a twelve-room Verengrad save for good.

backfillWorldFromBuiltIn now also asks identity positively, comparing the world's name against the
built-in reference it already builds, so a world that has lost the flag entirely is refused anyway. A
boolean that five separate callers must each remember to re-apply is a guard waiting for a sixth, and the
sixth had already been written.

uid looked like the better test and it is wrong, which is worth writing down because this entry's own
leaning proposed it. The World constructor mints a fresh uid on every construction - buildWorld() answered
epvuzzl and then e11nrz1e on consecutive calls, while the saved built-in world carries e3imasu and
WORLD_DATA carries none - so a uid names the instance a world was built from rather than which world it
is, and refusing on it would have turned the backfill off for the built-in world's own saves. Name
comparison fails closed instead: a renamed built-in world stops receiving new content, which costs a save
some rooms, where the other direction costs a world its identity and cannot be undone.

The tests drive the path rather than the predicate, since the predicate was never the broken part - an
assertion that the guard refuses an imported world passes against the broken build. The suite now runs the
real sync over a same-game snapshot, asserts the world still knows what it is, and hands that same world
to the backfill to confirm it is still refused. Reverting the sync line fails the path assertion alone,
which is the second fix visibly covering a regression of the first; removing the identity check fails the
two that name village_square; over-tightening to refuse the built-in world fails four, including the
assertions that already existed to catch the backfill being switched off for the saves it serves.

Claude19's save is not repaired by this and still holds twenty-six rooms; it will simply take on no more.
Alicia Scoutblade and Alicia6 are safe to open again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Darren made a fresh Verengrad save while the entry was being filed and it came out clean, which disproved
the first reading: that the guard fails for every world not imported from a file. It does not. Reading the
whole library shows the split runs on the flag rather than on the world - Claude18, Claude20 and Moloch
carry imported true and are clean, Claude19 carries false and holds twenty-six rooms, and the flag on
Claude19 was true in its 27 August export. It was not missing. It was lost.

Six places rebuild the world from a snapshot and five set the flag on the very next line. The restore, the
import, the save editor and the tab viewer all do it. syncWorldFromStorage does not, and serializeWorld
never carried imported either, so rebuildWorldFromSnapshot could not restore it if it wanted to. The
sequence needs no mistake by anybody: two windows on one origin, which the app supports, either window
saves and fires the ping, the other rebuilds its world and loses the flag, its next save writes false, and
the next load merges the built-in world in for good.

It is the same function and the same two-window arrangement as BUG-072, which is the part worth sitting
with. That fix scoped the sync so it would stop adopting a stranger's world, and the flag loss survives it
untouched, because for Claude19 the sync was doing its job correctly on its own game. The guard that was
tightened and the value being dropped are eight lines apart.

Two saves are armed and recorded as such: Alicia Scoutblade and Alicia6 both carry imported false on a
twelve-room Verengrad and are clean only because nothing has loaded them since the built-in world grew.
They are not counter-examples, they are the same bug with the trigger unpulled, and loading either
contaminates it.

The leaning is now two fixes rather than one. A single line in the sync stops the leak. Ceasing to depend
on a boolean five callers must remember to re-apply is the one that matters, since the sixth caller has
already been written; world.uid is present on every authored world and absent from the built-in one. And a
test has to drive the path rather than the predicate, because asserting the guard refuses an imported
world passes against the broken build - that was never the broken part.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

The entry recorded the room count and the mechanism but left the two questions anybody meeting this will
ask. What is in there is the starter world by name across nineteen collections - the rooms from
village_square to barrow_chamber, the seven built-in classes standing beside Verengrad's own Bladeward,
three races, twelve beings from the gatekeeper to the skeleton king, three quests, four lore entries, and
the iron sword and health potions. The newest built-in systems came with them, the guards faction and the
fenlung ailment and four reagents and two recipes, which is the clock on when the flag was lost.

And it cannot reach the story, which is worth measuring rather than assuming. No exit joins the two worlds
in either direction, the fourteen foreign rooms form their own sealed twenty-five-exit island, every being
standing in a Verengrad room is Verengrad's, and the single foreign encounter is where-scoped to five
rooms nobody can walk to. That matches the documented promise that a backfilled room arrives unlinked. The
injury is to the data: a save carrying another game inside it, wrong denominators everywhere, and a DM
opening it shown twenty-six rooms for a twelve-room world.

Also recorded is a caution about the diff itself, because the method overstates. The child's toy boat
appears as an extra record and is Verengrad's own, recovered in play on 8 September; the vault's stored
world.json is simply older than the world the save carries. The rooms, classes, races, beings and quests
are unambiguous by name, and a few item rows are not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Resuming Claude19 in Verengrad showed a completion chip of 32% against the 72% session 10 ended on, with
nothing unlearned in between. The denominator had grown: a twelve-room world whose save now holds
twenty-six, the extra fourteen being The Lost Realms' starter world entire - village_square, inn_room,
blacksmith, barrow_chamber and the rest - with the item catalogue up from about forty to eighty-seven and
quest beats from twelve to twenty-two. It is in the exported file, not merely in the session, and the 27
August export of the same character shows twelve rooms and the protecting flag set, so this happened in
the last fortnight.

backfillWorldFromBuiltIn states the stake itself: merging the built-in's rooms and quests into somebody's
own realm would be vandalism rather than an update. Its guard then tests w.imported, which is provenance -
how the world arrived - where the question is identity. Verengrad answers no to being the built-in world
on every signal available, carrying its own uid and a different name, and answers yes on the only one
consulted, because a world made in the World Builder or served from the vault library was never imported
from a file. The guard protects the worlds that arrived the single way it thought to name.

Two things make it worse than a wrong comparison. The flag lives only on the snapshot and serializeWorld
does not carry it, so the world object has no memory of being somebody's own realm and any path that
rebuilds it outside a restore loses the protection permanently. And the damage cannot heal: once the
foreign records are in the save they are what the additive-only rule calls already present, so the very
property that makes the backfill safe is what stops it reversing.

Filed open rather than fixed. The leak wants closing first - the leaning is to ask identity positively,
since world.uid is present on every authored world and absent from the built-in one - and un-merging is
data surgery on a save that would only invite the next load to redo it. The grade taken the same day
stands: the evaluation plan is a static file of Verengrad objectives, so foreign rooms add no objectives.

Worth stating for whoever meets it next, because it reads as loss rather than growth: a completion
percentage that falls while nothing has been forgotten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

Six sessions of coverage had landed on top of a figure measured on 27 August, so the 41/106 in the notes
header had become the least true thing in the file. Re-measured against a fresh export: 68 of 106, or
68 of the 104 a single run can reach, two beats belonging to quest forks nobody can walk both arms of.
Rooms 12/12, monsters 4/4, beats 10/12, lore 30/48, items 12/30.

manifest.json is deliberately untouched, which reverses the instruction the notes carried. Its expected
figure of 41 describes replaying the captured 48-turn script, which still ends where it ended, at level 7
in the flooded transept; it was never a statement about the live character, and the file's own comment
says every figure there was measured rather than estimated precisely so a later drop means something.
Editing it to 68 would have made a manifest about scripts assert something about a save.

The item column is what the re-grade turned up. Every one of the thirty item objectives asserts
inventoryHas, so a title reading Acquire is graded as still carrying, and those come apart the moment a
run does anything with what it picked up. The sharp case is one this ledger already celebrated: handing
three Tide-Cult Tokens to Ys in a single exchange is the authored solution, took two sessions to reach,
and is the subject of BUG-060 - and it permanently un-earns Acquire Tide-Cult Token, because the tokens
are Ys's now. The Widow's-Thread Vine is the same shape without the drama, a consumable that BUG-067's
fix correctly destroys on use. Filed as BUG-093, open, and not fixed in the session that found it: the
remedy touches the plan vocabulary, the player record and the compiler at once, and it would move every
historical grade in the repository, which is a decision about the instrument rather than a fix to slip in
beside a playthrough.

It is the mirror of BUG-062 and the same harm from the other side - that one was a denominator counting
what no run could satisfy, this is a numerator losing what a run did - and it lands hardest on the runs
worth grading well, since a player who hoards everything scores above one who spends it as written.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NkepP2Tw3ugr2Fnpo5W3T3

An NPC card could name the folklore somebody knew and nothing read the field. The tab authored the
stories, the Beings tab said who carried them, and a world could hold forty tales that no character
in it would ever mention. This closes that: the Game Master is shown, every turn, the tales the
people standing in this room can tell, and the player earns one by approaching the topic in
conversation — the same road every other NPC-driven hook and beat is unlocked by.

The dossier departs from the Lore Hooks section beside it in exactly one way, and the departure is
the point. Hooks list the whole world's worth, because a hook can be researched from an archive a
continent away. A tale cannot: it is earned from its teller, and a teller who is not here is telling
nothing, so a tale nobody present knows must not appear at all — otherwise a model that remembered a
story from an earlier scene pays it out in a room where nobody knows it. A locked tale carries its
full text, because the GM has to be able to tell the story the turn it is earned, under the standing
warning that it is a secret until then. An unlocked one stays listed rather than dropping out the way
a spent hook does: asking again about a story you have already heard is the commonest thing anybody
does with one, and a hook drops out because by then the player HAS the fact.

The unlock rides `loreUnlock`, the field the five subject kinds already use, with "tale" as a sixth
kind. One contract, one at-most-one-per-turn rule, one place for the model to look, at a cost of one
word in an enum — a second field would have been a second thing to obey the same rule about. The
apply path is separate, and had to be: a tale is not a subject with a hidden half. Its text is the
whole record, so there is no `lore` to flip and no compendiumTypeContext entry to flip it through. It
goes through setFolkloreUnlockedState, the same writer the DM's own tick uses, so the two roads into
the player's Compendium cannot come to pay differently or deduplicate differently. A title nobody
here can tell, or one the model invented, unlocks nothing and is written to the log rather than
dropped in silence — a GM that narrates a story and pays out nothing is the silent toll rule 13e
exists to end, arriving through a different door.

The section is in `live` and rule 13f is in `stable`, which is the split's own test rather than its
topic: who is standing in this room can differ between two consecutive turns and the rule about
tales cannot.

Tests/test_folklore_told.js pins both halves, and every assertion in it was checked against a
deliberately broken build — including the two that were added because the first pass of the battery
survived them: removing the already-heard guard is caught by the story pane announcing a tale as
newly heard a second time (the payment is refused by discoverLore whatever happens, so XP could not
catch it), and dropping "tale" from the response contract's kind enum is caught by reading the
contract line itself, since a model told to set a kind its own schema forbids picks one of the five
instead and nothing else fails.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Both of these failed on the skills-and-classes pass and neither is about that pass. They are fixtures
that had grown a dependency on what the built-in world happens to contain, which is a dependency a test
about a PARSER and a test about CLASS CREATION should not have.

test_gm_new_items.js asked the Game Master to create a class called Cleric and asserted it came back as
CREATED. That held until the built-in world gained a Cleric of its own, after which the same request
correctly reported it as UPDATED — the engine behaving exactly as designed, and the assertion failing on
content. The class is a Hierophant now, which is nobody's built-in class, and the property under test is
unchanged: a class the world does not have is created, and the item its loadout names is seeded with it.
The check that the name was free is asked BEFORE the call, where it means something.

test_language_ai.js is the one worth reading twice. Its fixture answers the lexicon generator the way a
model does, inventing a word for each English one as `zh${w.slice(0, 4)}ok` — so any two words in the bag
sharing four leading letters minted the SAME invented word, and the generator rightly refused the second
as a batch collision, two English words rendering as one thing being the ambiguity it exists to prevent.
The bag is built from the game's own prose with the built-in skills among its declared sources, so adding
a skill called Animal Handling beside one called Steady Hands, and Stealth beside Steady, cost this test
two words and failed an assertion about the PARSER. The invented word is built from the whole word now,
which is unique by construction; a first attempt appending the index refused all sixty instead of two,
because a stored word has to be letters a renderer can draw and a digit is not.

And the tolerance went with it. The assertion allowed four losses, which is how a fixture that had
already started minting duplicates went on passing until one more pushed it to five. It is exact now:
two refusals are deliberate — the word handed back as itself, and the one colliding with a word the
tongue already has — and every other line must land.

The lesson both share is the one about coupling rather than the one about content. A fixture that draws
its inputs from the live catalogue is a fixture that changes when the game does, and the failure surfaces
somewhere with no visible connection to the edit: nothing about "add ten skills" suggests a lexicon
parser. Neither test was wrong about its property, and both would have gone on being right while failing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The catalogue had twenty-two skills of which four were composites. It now has thirty-two with ten at
tier 2 or above, three new playable classes, and a tier 3 that did not exist before. The list is the
cheap half of this; what follows is the part worth keeping.

THE NEW GROUND. Five tier-1 domains open to every class — Intimidation, Animal Handling, Appraisal,
Theology, Stonelore — each checked one at a time against the existing list, because the catalogue states
a rule about itself that is easy to break: proficiency here is level + 1 with no per-domain notion, so a
narrower duplicate grants the same +2 over strictly less and taking it is a PENALTY. Intimidation is not
Persuasion (pressure is not charm, and a world where both are one skill cannot fail at one and succeed at
the other); Appraisal is not Arcana (what a thing is worth is not what it does, and this game prices
everything in copper); Animal Handling is not Tracking; Theology is not Arcana either.

Five composites above them, written to §07's strict-capstone rule rather than as bigger numbers: each
REQUIRES its parents, levels them up on acquisition, and grants an ability neither parent has. Venomcraft
and Apothecary are the Concoction branch the pass was asked for; Beast Lore, Divine Rites and Command
finish the chains the new tier-1s start.

TIER 3 EXISTS NOW, and a test said so rather than a plan. Venomcraft and Apothecary are built on
Concoction, which is itself tier 2 — filed as tier 2 they made a skill its own parent's equal, which
draws the tree flat and prices a two-deep climb as one rung. An assertion that every skill outranks what
it is built on caught it. The engine needed nothing: pointCost already defaults to the tier and training
time to (tier − 1) days, which is the sign the field was always meant to be read as a ladder.

AND THE TEST FOR "COVERS NEW GROUND" WAS WRITTEN WRONG FIRST, in this repo's oldest way. It flagged any
two skills sharing a stat, a DC, a tier and a prerequisite set as near-twins, and duly reported Persuasion
≈ Intimidation and Tracking ≈ Theology — pairs that share a die and nothing else. It was measuring the
dice rather than the domain. What replaced it is the thing that actually prevents a duplicate: every
skill added here names another skill in its own description and says how it differs. You cannot write
that sentence without first checking whether the ground is taken, and the next author reads it before
adding the eleventh.

THE CLASSES. Cleric and Druid fill in records the engine already anticipated — both were in
CLASS_STARTING_SPELLS and the caster list without being playable. The Alchemist is the one with a trap in
it, and it is the trap this codebase keeps meeting: a change that plays perfectly while quietly making an
earlier decision a lie. Concoction was removed from SPELL_SCHOOL_STATS deliberately, because earth magic
is compounded from reagents and carried as an object rather than recited — so a class built on it must
NOT be a spellcaster. One entry in CLASS_STARTING_SPELLS would have handed it a grimoire, a Spellbook
slot and a mana bar it casts nothing with, and nothing anywhere would have reported it. It has no
starting spells, it is absent from the caster list, and its stat line is built around CON because that is
what its craft actually rolls. Concoction itself stays classes: [] — the Alchemist is built ON the skill
rather than handed a monopoly of it, which is what keeps Spellcasting the app's one hard gate.

The Alchemist therefore BEGINS knowing a tier-2 skill, which looks like a bug and is not: inherent grants
are not point-buys and do not consult prerequisites. That is what inherent means, and the class starts
where a point-buyer would have to climb.

WORLD_DATA.version is NOT bumped, and the test asserts it. Both skills and classes are in WORLD_BACKFILL,
so every existing save gains all of this on its next load; moving the version to announce new content is
the mistake that once refused every save in existence to deliver two ailments.

Tests/test_skill_class_expansion.js, against fifteen sabotaged versions. Beyond the two above it pins the
prerequisite graph itself — no dangling parent, no cycle, and no skill built on something that outranks
it — which are all silent failures: a dangling prerequisite is not a crash, it is a skill nobody can ever
acquire.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

# Conflicts:
#	Designs/README.md

A built-in skill — INT, open to every class, no prerequisite — that unlocks a Translate attempt on any
written thing in a language the reader cannot fully read. One try per book per character level, against
a difficulty that falls the more of that tongue they have already learned.

What it buys is a READING, not fluency, and everything else here follows from that. A language is
learned a word at a time, from books, stones and people; that is where the four display states come from
and it is what makes a primer or a Rosetta Stone worth finding at all. A skill that handed over a
language would switch every one of those off the moment somebody took it, and nothing would report the
loss — the game would still play, the pages would still render, and the system would simply stop
mattering. So a success is recorded against the BOOK. player.languages is never written to, not the
script flag and not one word, and a second book in the same tongue is as foreign as it ever was.

The three alternatives are written into the design doc as rejected rather than left unsaid, because each
is the obvious thing to ask for next. Teaching the words on a success lets a player grind checks to
flatten any lexicon and retires every authored teaching source. Blanket fluency is the cheapest to build
and ends the system. Gating learning behind the skill is a hard gate like Spellcasting and invalidates
language content for every character who did not take it, in worlds already authored.

The difficulty reads the lexicon so that learning and puzzling pull the same way rather than competing —
why study if you can roll? — and it is counted over the words the language actually HAS an entry for,
since a word nobody translated falls through as English and is not something the reader is failing to
read. Knowing the alphabet helps again but not as much: being able to sound a word out is most of where a
cognate is spotted and none of where its sense is.

Three rules came out of building it. One attempt per book per level, pass or fail, because otherwise the
check is not a check but a wait — the skill-book learning check already works this way for this reason;
a page once worked out stays worked out, since remembering one page teaches no words. A failure gives
nothing and a near miss gives nothing either: half a translation is not half a page, it is a wrong page,
and handing one over would be the engine inventing text for a book the author wrote. And the control not
being drawn is NOT the gate — the passage block lives in the message log and survives a reload, so a
control drawn once stays clickable; the action re-checks the skill itself, which is the rule the vault
already states about vaultIsAdmin. Sabotaging that gate passed every other assertion in the new test
until the one that calls the action directly existed.

A worked-out page draws as a pair labelled "Your reading" rather than Translation, because that is what
it is. The top half renders normally rather than forced, so a word learned since shows as English there
and the two halves drift together as the tongue is genuinely learned.

The spoken half of the ask is not built and cannot be yet, which is recorded rather than skipped: the
engine has no representation of a spoken foreign line. Speech reaches the player as narration the model
wrote, and the rule this whole system rests on is that the engine renders what the player cannot read and
the model never sees the plaintext. Giving speech that shape — the GM emitting a line as language-tagged
DATA the engine substitutes, exactly as it substitutes a page — is P4 work, after which this skill
extends to it in one place.

Tests/test_foreign_languages_skill.js, against fifteen sabotaged versions. player.translatedPages and
player.translateAttempts are new fields on the player and carry their backfill lines in the restore and
in the imported-character path, beside the ones that already do.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The same conflict as the last merge and resolved the same way: both sides added a paragraph to the
Culture section of the Designs/README.md table, mine to the culture.html row and theirs to
dialects-and-languages.html. Cleanly separable, so both are kept.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

A Folklore field on every NPC card in Editor › Beings › NPCs: chips for the tales this person knows, a
picker offering the ones they do not, and + Add. The same shape as the Factions field two sections
above it, through the same chrome, because the two are the same kind of question about a being.

STORED AS IDS. A tale is a record on the Culture › Folklore tab that the DM may retitle, rewrite or
reprice at any moment. A being carrying the words would go on telling last week's version for the rest
of the save; one carrying the name would lose the link on the first rename. This is the third time this
rule has been written down in a week — a religion's races, a religion's regions, and now this — and the
corollary is the same each time: an id whose tale no longer exists is KEPT and drawn as a broken chip,
never dropped, because a tale deleted today may be restored tomorrow and a reader who cannot see the
dangling reference cannot tell a removed tale from a person nobody gave one to.

The chip names the KIND beside the title. "The Bell Below" says nothing about whether this person is
repeating a myth, a warning or a piece of gossip, and the kind is the whole of what Folklore's four
types are for. The picker groups by it too — a flat list of forty titles is a list nobody reads to the
end of — and a kind an imported world brought with it keeps its own heading rather than being folded
into Myths, which is the rule the tab itself already follows.

NPCS ONLY. The field is for the conversation half, where a story reaches a player because somebody
tells it, and a monster or an animal has no conversation to tell one in. Drawn on a card that could
never use it, the section would be a control that looks ready and does nothing. A talking monster is a
real case and the comment says which line to move when one turns up; it is a line, not a rewrite.

Nothing reads the field yet. It is the half that makes a tale reachable at all — until now a world could
write forty stories and no character in it knew any of them.

Tests/test_npc_folklore.js is new and covers the picker, the id contract, the dangling chip, the
NPCs-only rule, the three empty states and the save round trip, verified against eight sabotages. Two of
those crashed the file rather than failing a check — the dangling-id guard throws while rendering when
removed, and an unbackfilled list throws on .join — so both reads go through helpers now that report the
property instead of dying on it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

An item's `abilities` array has exactly one reader in the engine. equippedAbilityGrants() walks
player.equippedItems and skips the storage places via isWornSlot, so a grant is read only while the item
sits in a slot on the doll. The editor card nevertheless drew "Grants (equipped)", with its "+ Ability"
button, on all sixteen item types — inviting a DM to give a healing potion a +2 to Stealth while
equipped, listing it back on the card afterwards, and never applying it anywhere, because a potion
cannot be equipped. The card asserted a mechanic the engine has no path to reach.

The gate is itemEquipmentSlots(), which is the question the engine itself asks, rather than a check on
the item's type. A type check is wrong in both directions and it is worth writing down why, because it
is the obvious fix and it would have quietly made things worse. Only weapon, armor and staff INFER a
slot from their type; every other wearable reaches one through an authored equipmentSlots. The built-in
items that most want a grant are exactly those — the Ancient Crown, the Sapphire Pendant, the
Barrowking's Signet and the Stolen Locket are all type "misc" — so gating on an equippable-type list
would have taken the field away from the four items in the catalogue it exists for while leaving it on
swords. It fails the other way too: an item may carry type "consumable" AND an explicit equipmentSlots,
and its grants are live while it is worn, so a type gate would hide a working effect. Asking the same
question as the reader is the only way the card cannot disagree with the engine.

Grants already authored onto something unwearable now disappear from the card along with the section.
That is a decision rather than an oversight: they are unreachable data that nothing in the game will
ever read, this is a test world, and building a second explaining state for a case that only arises
from the bug being removed would cost more than the case is worth.

Tests/test_item_grants_wearable.js drives every type in ITEM_TYPE_IDS and every card the catalogue
renders. Three sabotages were run against it — removing the gate, gating on an equippable-type list, and
excluding consumables alone — and each is caught by its own assertion naming what moved, with the
type-gate failure listing the crown and the pendant by name. A fourth, replacing the isWornSlot filter
with a length check, passed against all of them, so §6 pins the reason it passed: no item resolves to a
storage slot today, the two questions merely coincide, and the assertion tells whoever changes that the
filter has become load-bearing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

A book in a fully traced tongue rendered as blank pages: the title drew, the punctuation drew, and every
letter took up its space and painted nothing. The cause is one expression in bookPassageHTML:

    lines.map(x => `<p>${languageTextHTML(x, langId, o).replace(/\n/g, '<br>')}</p>`)

languageTextHTML returns HTML. Prose survives a newline-to-<br> pass over HTML; a traced glyph does not.
The tracer pretty-prints its path data across several lines, so every newline INSIDE a `d="…"` became a
literal <br> in the attribute. Chrome rejected each path — Expected path command, "M 609.26 143.85<br>
A 0.96 0.9…" — and the letter drew nothing at all. The break is put between the rendered segments now,
which is where it was always meant to go, and the feature it exists for is unchanged.

Stored path data has its whitespace collapsed as well. That is lossless, path data being
whitespace-insensitive, and it does two things: it makes the stored record unable to arm this class of
bug again, and because the normalizer runs on every read of a script it REPAIRS the letters in worlds
traced before this, on their next load. Nobody has to re-trace anything.

What the hunt cost is the part worth keeping. The data was right, the normalizer was right, the save
round trip was right, the CSS was right, and the same letters drew perfectly on the language card —
because the card renders the same markup and does not do this. Four correct layers were searched, a
genuine but unrelated defect was found and fixed on the way (the substituted viewBox, two commits back),
and a wrong diagnosis was handed to the author with it. What ended it was one line in the browser
console. The lesson is not "read the console first"; it is that TWO SURFACES DISAGREEING ABOUT ONE
RECORD is itself the finding. The card worked and the story did not, and that pair alone ruled out every
layer the two share — the data, the normalizer, the save, the renderer. It was the only evidence that
mattered and it was there in the first screenshot.

And the test for this very nearly became evidence for a bug it does not catch. The two fixes above are
redundant by design, so with the storage cleanup in place the ORIGINAL BROKEN RENDERER passed the new
test. Only a sabotage run said so. test_passage_glyph_linebreaks.js now writes a wrapped `d` straight
onto a script, past the normalizer, so the renderer is asserted with the cleanup taken out of the way and
each fix fails on its own. Its fixture wraps its path data on purpose, which is a note to every future
fixture here: written on one line, as every existing one is, no assertion in that file can fail however
the renderer is broken.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Reported from the table as a question: "I just need to re-generate the SVG glyphs? There isn't a button
for that yet." There was not, and the shape of the hole is worth recording. The Trace button traces only
what is MISSING — which is right, and is the difference between a retry costing four calls and paying for
the whole alphabet again — so with every letter in there was nothing missing and the button went dead.
Re-tracing therefore meant opening each of twenty-six letters and pressing Clear on it. That is not a
workflow, it is a forfeit, and it fell hardest on the first alphabet anybody traces, which is the one most
likely to be worth throwing away.

So the button now has three states and is never dead where there is a sheet: Generate with nothing traced,
Trace the rest with a partial alphabet, and Trace again with a complete one. The third re-traces all of
them and says so in its confirmation, plainly, because it is the one press in the app that spends money on
letters that already exist.

A re-trace drops the old letters before it starts, and that is the decision in this change rather than a
detail. Kept, they would draw a page half in the new alphabet and half in the old while the run went on —
and a letter whose new trace FAILED would silently keep its previous version, so a run reported as
complete would be a mixture that nothing on screen could tell from a clean one. Dropped, a failed letter
is missing, the alphabet is incomplete, and the sheet goes back to drawing the language, which is the
honest state and the one the rest of this feature already maintains.

Clear the traces is the companion, for when the answer is not "again" but "back to the sheet". It asks
first — those letters were a paid call each — and takes the failure list with them, because a grid marking
cells red for a run that has been thrown away describes a state nobody is in.

Ten sabotaged versions, each caught by a distinct named assertion. One of them is a note to whoever writes
the next test here: sabotaging the confirmation made an assertion THROW rather than fail, because
normalizeLanguageScript omits `traced` entirely once it empties and the assertion dereferenced it. A crash
is a red test that names a line of the fixture; what belongs on screen is the property that broke, so it
reads through the map now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

One conflict, in the Designs/README.md table: both sides added a paragraph to the Culture section's
rows, mine to the culture.html row and theirs to dialects-and-languages.html. Cleanly separable, so
both are kept.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Two fields on a tale — `xp` and `unlocked` — and a tick that copies it into the save's own
discovered-lore list, where it reads on Compendium › Lore beside everything the character has learned
in play. With the tale's own picture, which needed a change of its own: loreThumbImage infers a subject
from the entry's text and borrows that thing's portrait, because the lore the Game Master uncovers in
play is always about something else. A tale has a picture painted from itself, so an entry that carries
one now wins over the inference — otherwise a card about the story shows a portrait of whoever the
story happens to mention.

DELIBERATELY NOT THE LORE TRIPLE. A room or an item carries lore / loreKey / loreUnlocked: a hidden
fact behind a thing that also has a public description. A tale has no public half — its text is the
whole record, and there is nothing left to show a player who has not earned it. Reusing those names
would have entered every tale into every roster that scans for a lore hook (the Lore tab's groups, the
evaluation's reachability pass, the GM's per-room hook dossier) as a subject whose `lore` is empty,
which is exactly the shape those readers treat as authored-but-unwritten.

THE DM'S TICK PAYS THE XP, where the identical-looking tick on a lore hook does not, and the departure
is the point. A hook's does not pay because a hook has a paying path of its own: the Game Master
unlocks it mid-turn and awards it there. Folklore has no such path — nothing in the engine reads a tale
yet — so a tick that did not pay would leave the XP box beside it authored, priced, and unable to ever
do anything. That is the control-that-looks-ready-and-silently-does-nothing this file keeps paying for,
one step upstream: pricing a thing that can never pay. It pays once, by discoverLore's own refusal of a
repeated id rather than by a flag of our own — a DM who locks and unlocks to bank it again is editing
their own save, which the Save Editor already allows, and a `paid` flag would be world data that
travelled to the next player already spent.

A tale with no text cannot be granted at all. The checkbox is disabled, and the writer refuses
independently, because `disabled` stops a mouse and nothing else: an entry with a title and nothing
under it reads on the player's Lore tab as a discovery that failed to load.

The roster may PRICE a tale and may never GRANT one. `unlocked` is absent from the field patch on
purpose — a model writing tales would otherwise be deciding what the character has already read, and
handing out the XP for it — and the directive says so in as many words. The price is asked for on every
tale it writes, on the absolute scale the races and rooms already use, with the usual warning that an
omitted figure is not "free" but the flat default. The roster line shows each tale's current price, by
the rule the item, being and race rosters already follow: a field the model may write has to be one it
can read, or "raise the cheap ones" is an instruction it has to guess at.

Tests/test_folklore_editor.js grows a section for all of it, verified against nineteen sabotages. One
of them found a gap rather than a defect: the "a textless tale cannot be unlocked" assertion was
reading the disabled attribute alone, which is the courtesy — the guarantee is in the writer, and it
was untested until the sabotage removed it and nothing failed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Every other authored record in the editor has the sparkle on its Description and Detailed Description --
factions, races, dungeons, ailments, entities all reach runTypeDescriptionRequest -- and the school card
had two bare textareas. A school is the record that most wants one: nothing in the engine reads its
prose, so the prose IS the school, and a DM who has just set a kind and an origin has already told the
GM most of what it needs.

WHAT THE GM IS TOLD MATTERS MORE HERE THAN FOR THE OTHER KINDS, and it is why this is a registry entry
rather than two buttons. A school is what its spells DO. Asked to describe "Evocation, arcane, from
study" with nothing else, a model writes about somebody else's Evocation -- the one it already knows --
and the result reads plausibly while describing magic this world does not have. So the spells filed
under the school travel with the request by name, and a craft school says that its magic is brewed from
ingredients rather than recited, because those two schools want completely different prose. A school
nothing declares yet says so outright: an omitted line reads to a model as "no spells worth mentioning",
which is a different claim from "none exist".

The roster is derived and the record is authored, so a school can be on the tab with nothing behind it --
which is the normal state of one nobody has written about, and exactly the school most in need of a
description. `find` therefore MINTS the record, as every field edit on the card already does. Minting one
on a failed call costs nothing: the row is already drawn, and an empty record changes nothing.

The shared row calls its setter as (element, id, key), which is not setMagicSchoolField's shape, so an
adapter bridges them -- and the adapter is a GATE rather than a forward. setMagicSchoolField('name')
renames the school on every spell that declares it, and the key reaching the adapter comes out of an
onchange attribute in generated markup. Forwarded blind, a mistyped or copy-pasted key would turn a
description box into a rename of the whole school, silently, on blur. The two keys the row can
legitimately carry are named and anything else is dropped.

Two assertions in the school test changed rather than being deleted: they pinned the four fields and the
two descriptions as all writing straight through, and the descriptions now take the shared route. The
property they defend -- the field is reachable and lands in the record -- is unchanged, so they assert
the new route and the record write separately.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Reported from the table: a book in a fully traced tongue rendered as blank pages. The title drew, the
punctuation drew, and between them every letter took up its space and painted nothing — no glyph, no
empty box, no warning, in the story and on the language card alike.

The cause is one line of normalizeTracedGlyphs and the reasoning behind that line is the part worth
keeping. It checked the stored viewBox against a regex and, where it did not match, substituted the
app's own 0 0 100 100, arguing in its own comment that a substituted box breaks one glyph where a
refusal would break the alphabet. That is backwards, and the geometry says why: a traced letter's
contours are in the TRACER's space, two hundred units or a thousand across, so a hundred-unit window
around them does not show a small letter, it shows the patch of empty space between two strokes. The
substitution does not degrade the letter. It deletes it, while storing it, reporting it stored, and
drawing it on every page for ever.

So a box that cannot be read now refuses the letter. Dropped, it renders as lang-missing — a visible
empty box that says the true thing, this letter is not there — and an author can see which one failed
and re-trace it. A fallback that cannot be seen is worse than a refusal that can.

The regex was also stricter than SVG, which is what fired it. It demanded whitespace-separated plain
decimals, so `0,0,1024,1024` — a viewBox every browser accepts and vectorizers emit — took the
substitution path. The box is read in SVG's own grammar now (whitespace and/or commas, signs,
exponents), normalised to one spelling so a record has one form however it arrived, and a box with no
area is refused for the same reason an unreadable one is: zero width scales every coordinate to the
same nothing.

It was found in a BROWSER and could not have been found anywhere else. Every assertion over that
markup passed, because the markup was right — well-formed contours, a correct mask, a unique id,
fill: currentColor resolving to a visible colour — and the engine answered correctly at every step it
was asked about. What settled it was rendering a passage in headless Chromium and measuring the ink's
painted box, which came back as nothing inside a box of the wrong size. That is the second defect this
system has produced that no assertion could reach; the first was the word spacing, and both were a bug
in no function.

One existing assertion had to be reversed rather than worked around, and it is the sharpest thing in
this commit. test_glyph_trace_trial.js pinned the fallback — "an unreadable viewBox falls back rather
than being carried, it would break every letter, not one" — which is the substitution's own argument
restated as a guarantee. A test that pins a defect stands guard over it, so the old wording is quoted
in the comment where the new assertion sits.

Tests/test_traced_glyph_view.js covers both properties against six sabotaged versions, the first two
being the two halves of this bug. It asserts the headline the way the failure happened: a comma-spelled
viewBox traced into a whole alphabet and read as a book, where the glyph on the page has to carry the
box its contours were drawn in.

Worlds already traced are not repaired by this: the substituted box overwrote the real one, so those
letters have to be re-traced. They will now either draw or show as empty boxes, which is the difference
between a bug and a chore.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Corrected from the last change, which put the button on the Character › Inventory cards. It belongs in
the popup dialogs and nowhere else: a grid of cards is for reading, and a row of small buttons that each
spend a turn is not what a pack should be.

Moving it made the interesting problem visible. One builder draws EVERY item popup — the Compendium's
reference view, the editor's, the map detail, an NPC's equipment dialog, a thing lying on a dungeon
floor, and the player's own pack — so a flag read off the ITEM would have put a turn-spending button in
all of them. It is opt-in per call site instead, and exactly two openers pass it: the sidebar's Inventory
block and the Character sheet's Inventory tab, both of which resolve from player.inventory. The room's
Items block deliberately does not — that item is not the player's yet, and Loot is the action there.

It joins the row the popup already has for its contextual actions, beside Loot and the out-of-reach note,
rather than inventing a place to stand.

The popup is also SHUT before the command goes. The turn is about to spend the thing the card describes,
and a card left standing over a drained phial is a card that now lies, with a button on it offering to
drink it again. Closed through ITEM_POPUP_IDS, the list that exists precisely so a caller need not know
which of the several popups an item was opened in.

One existing assertion broke and was right to be looked at rather than edited past. test_loot_button
pinned the Inventory opener's call TEXT verbatim, so passing it an unrelated option failed a test whose
claim — that the Inventory click passes no LOOT flag — was still perfectly true. Rewritten to check what
it says. The first rewrite then searched the whole function for the word "loot" and matched the comment
introducing the function BELOW it: prose about the flag, read as the flag, which is a mistake this repo
has made before. It matches the call now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Two faults in yesterday's funnel, both reported from the screen.

REAGENTS HAD NO CHECKBOX. The pack's options came from inventoryHoldings(), which is the pack and the
trove; the tab ALSO draws reagent rows synthesised from player.reagentStock, because a reagent is not an
item and is not in one. So the Reagents section was on screen with no way to filter it. The predicate
was right the whole time -- a reagent row files under its own kind and no equipment slot, and there is a
test saying so -- it was simply never offered the value, which is why the test passed. Omitting a value
is worse than offering a spare one: a spare is visibly useless, while a missing one leaves its cards up
with every box in the group unticked, and "select none, then tick the one I want" appears to be broken.

The synthesis is now a function of its own that the sections builder and the funnel both read, so they
cannot disagree about what the tab holds. Every other surface derives its options from the list it
filters -- the Compendium's does so deliberately, and was written that way in the same change -- so this
one was the exception by accident rather than by argument.

THE COMPENDIUM'S FUNNEL CENTRED ITSELF. #compendium-filter-row lays out space-between with "Reveal all"
at the right, so a third child is neither first nor last and is pushed to the middle of the bar. The
Items toolbar carries a comment about exactly this, ending "the pair has to be ONE flex child or the
facet button would drift into the middle of the bar" -- read while writing the change and then not
applied to the row it describes. The name box and the funnel are now one .items-filter-row, as they are
on the other two tabs, and the assertion pins the pairing on both rows rather than on one.

Neither fault is visible from the code alone, so both are pinned by behaviour: that "reagent" is among
the kinds the menu lists and that unticking it takes the section off the tab, and that each row pairs
its filter with its funnel ahead of the action on its right.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Both sides added a funnel to the shared facet selector lists: main a Quests one, this branch the
Inventory and Compendium pair. The conflict is textual rather than a disagreement -- the lists are
additive by design, which is the point of joining them instead of copying the block -- so the
resolution is the union of the three, in the order each side placed its own.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Filtering a list of things by what they ARE is the same question wherever the list is, and it was asked
in one place only. A player with forty things in a pack could search by name and nothing else; the
Compendium's Items tab could do the same and no more. Both now carry the funnel the Editor's Items tab
has had, beside their own name box.

It is ONE control on three tabs rather than three that resemble each other. The Lore, Art and Folklore
filters are the same job re-implemented three times over and their own comments say so, which is the
precedent worth not following again: what differs between surfaces is named in ITEM_FACET_SURFACES --
the list being filtered, the groups worth offering, the id prefix the controls wear, and what to
repaint -- and everything else is shared. The CSS follows the rule its own comment already states and
joins the selector lists rather than copying the block.

THE PLAYER-FACING TWO OFFER TYPE AND EQUIPMENT SLOT ONLY. Portrait and Icon are an authoring queue: "no
portrait yet" is a job on a DM's list, and beside a player's own sword it reads as a fault in the sword.
The editor keeps all four because there it is exactly the question being asked.

Each surface gets its own record of what is switched off. Sharing one would mean unticking "weapon" in
the editor emptied the player's pack of weapons, with nothing on that screen to say why -- three tabs
showing three different lists cannot want one answer.

Three things here are quiet when they go wrong, and each has an assertion naming it. An unknown surface
falls back to the editor's deliberately, so a DROPPED surface argument does not throw: it filters the
wrong tab's list and reads as the funnel doing nothing. The live version of that mistake was already in
the file -- `list.filter(itemMatchesFacets)`, a bare reference, which now hands the predicate the row's
INDEX as its surface -- ten lines above a comment warning about precisely that trap with the card
builders. It is fixed, and so is the same bare reference in the facet test, which would otherwise have
proved the fallback works rather than that the tab does.

A Compendium entry is a discovery record, not a catalogue item: it carries a name, a type and a
description, and nothing about equipment slots. Read directly it reports every entry as fitting no slot
-- a filter quietly answering a question it cannot see -- so an entry is resolved back to its item by
name, the same bridge its portrait already crosses. The entry's own type wins, because that is what the
card shows and a filter disagreeing with its own tab is worse than no filter; and an entry whose item
cannot be found still files under that type rather than dropping out, since renamed, deleted and
invented-in-play are all ordinary and losing them would hide things the player genuinely found.

The pack's empty state had two nothings and now has three. A funnel that matches nothing leaves the
same blank screen as an empty pack, and "Your Pack Is Empty" over a pack holding a hidden sword is how
a filter is read as lost gear.

The Compendium's filter row is shared by every subtab, so the funnel is hidden on the rest the way the
Magic inner-tab bar already is -- left visible it offers to filter Places by equipment slot.

Four assertions in the existing facet test changed rather than being deleted: they pinned the generated
handlers, and the handlers now name their surface instead of leaning on the default. That is the point
of the change, so they pin the surface too.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Asked for without new circuitry for consuming, and there is none: the engine has no consumeItem and
this does not become one. What a consumable DOES is adjudicated by the Game Master from its description
— the shipped Health Potion says "Restores 30 HP" and carries no mechanical field at all — and an
authored consumeEffect reaches the model as a per-turn note naming the status to apply. So the button
types what the player would have typed and submits it through handleSend, which is the pattern the
direction buttons, the dice roller and voice input already use.

That is the property worth having rather than a detail of the implementation. The button and a typed
line are the SAME path, so whatever consuming means today or later they cannot disagree — and if a
consumable ever grows a local route in handleSend the way `prepare` and `brew` did, this follows it
there with no edit, because it goes through the same front door. It also inherits the lock: while the
input is disabled the GM is mid-turn, and a button that ignored that would queue turns the player never
chose to take.

Offered exactly where canCarryConsumeEffect says a thing can be consumed — the engine's own answer to
that question, already deciding which items may carry a consumeEffect at all. A second, narrower rule
here would be a second opinion about the same question, and the two would disagree the first time
either moved. The one thing added on top is that a prepared MEASURE is excluded: it is brewed with
rather than swallowed, and is a count on the player rather than a thing in a bag.

The verb is a presentation map and nothing reads it, which is why it may be hand-written where a roster
may not — a potion is drunk, a ration eaten, a salve applied, and an unmapped form falls through to
"Use", which is never wrong, only plain. A test walks the taxonomy's own consumable vocabulary against
it so a form word added there cannot quietly start producing "Use the Poultice".

Rendering the real pack rather than a fixture found a data gap the verb logic merely exposed: the
Health Potion showed "USE", because it declares no subtypes at all and a bare `consumable` type says
only that the thing is spent. The fix is the data — it and the Mug of Ale now say which they are —
rather than reading "potion" out of the NAME, which is the trap inferNaturalItemType documents at
length. A name is prose where a subtype is curated vocabulary.

One assertion in the new test was worthless as written and is fixed: it checked that a reagent measure
offers no Consume button using a row typed `reagent`, which the type gate already excludes, so it
passed with the guard deleted. It now asserts the shape the guard actually exists for — a measure whose
row carries a consumable type.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Reported from the table: a DM asked the item bar for a book with a fable in it and got a book with a
title, a description and a price, and an empty Passage. The obvious cause was real. The item roster runs
to a couple of hundred lines, carries a paragraph on skill books and another on spellbooks, and never
mentioned that `passage` exists or that it is the only field the engine can read a page out of. A model
cannot fill in a field it has never heard of, so it did what the contract asked and wrote a book ABOUT a
fable.

Fixing that alone would have changed nothing on screen, and that is the half worth writing down.
applyItemSpec — the writer every item the Game Master authors goes through — never named `passage`, so it
dropped it on arrival, along with `language`, `teachesScript`, `teachesWords` and `bilingual`, and
returned `created` regardless. Its own comment eight fields higher states the rule it was breaking: the
function is explicitly field-by-field, so a field it does not name is discarded without a word. The
directive would have produced a model dutifully writing a fable into a field that was thrown away, under
a success message.

The lesson is the roster rule read from the other end: a field has more than one write path, and a test
that pins it on one proves nothing about the other. Tests/test_book_passage.js guards this exact property
on makeItem — name the field or an authored page is lost — and passed throughout, because a book built
inline kept its page perfectly. The two paths disagreed for as long as the Passage field has existed and
nothing anywhere could report it. The new Tests/test_book_passage_gm.js therefore drives the roster
itself rather than reading its source, captures the directive off the wire so the interpolations have
run, and asserts the two write paths agree.

Three smaller decisions came with it. An over-long passage is refused rather than trimmed, as the editor
already refuses one — half a fable reads as a fable the model botched — but it costs only its own field
and not the book, and the refusal is reported beside the created item, since "created" over a book with
blank pages is the failure this whole change is about. A language the world does not have is not stored
and takes the three lessons with it, on the reasoning that already makes setItemLanguage clear them when
a book is retagged to English: a card claiming six taught words over a tongue that is not there is the
card lying. And the tongue clause reaches the model only when the world actually has a language, with the
list interpolated from allLanguages() rather than written out — four fields naming a tongue that does not
exist are four ways to author a book that teaches nothing, and a roster pasted into a prompt is stale the
moment somebody adds to it.

Fourteen sabotaged versions were run against the new test and each is caught by its own named assertion,
the first two being the two halves of the original defect. Two of the failures were the fixture's own:
ITEM_CATALOG is a `let` that buildWorld rebinds, so a captured reference read the catalogue of a world
two fixtures ago; and the end-to-end block gave its book the same title as an earlier one, which
applyItemSpec correctly resolved to that entry by name, so it read a copy of a record that was never
created. One assertion was also passing vacuously — a book that was never opened is not consumed either —
and now depends on the read having happened.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The Journal's quest panel has carried a questline filter for some time: a player following three
threads at once can put two of them away and read the third without scrolling past them. The editor's
Quests tab, which draws the same threads at greater length — every beat, discovered or not, with its
triggers, its XP and coin fields and its needs-alive rosters — had nothing, so a DM writing the fourth
beat of one quest read the other two in full on the way down to it every time.

This adds the funnel filter to the editor tab. The chrome is the facet menu the Items, Lore, Art and
Folklore tabs already use rather than the Journal's sticky left panel, because the editor tabs are
uniform in this and a second idiom on one of them is a thing to learn rather than a thing to
recognise; the content is the Journal control's — a checkbox per questline, an all/none head, and a
Show all.

Two things it deliberately does not copy from the Journal. It offers every quest in the world rather
than only those with a discovered beat: the player's filter is over what they have found and the
author's is over what there is, and a DM filtering down to the thread they are drafting would
otherwise not find it in the menu until the player had stumbled into it. And the hidden set is not
persisted, for the reason the other four funnels are not — it can empty the tab completely, and a
filter that survives a reload reads as lost data rather than as a filter.

The set records what is HIDDEN rather than what is shown, which is the same choice journalHiddenQuests
made and for the same reason: a quest the GM writes through the request bar while the menu is shut has
to default to visible, and an inclusion list would swallow it silently. For the mirror of that, the
menu is built from world.quests rather than from what is on screen — a menu built from the visible set
loses the checkbox that would undo the filter the moment you use it — and renderQuests sweeps ids that
no longer name a quest, so deleting a hidden thread does not leave the badge counting it forever.
showQuestInEditor unhides its target before scrolling to it, because every caller of it is a jump from
somewhere else in the editor and arriving at a blank tab would read as a broken link.

Emptying the tab needed a third empty state. The two that existed say there are no quests and say the
search matched nothing; neither is true when the world is full and the filter is shut, and offering
"add a quest" to someone who has just unticked all of them is an answer to a question they did not
ask.

Tests/test_quest_filter.js pins the parts that are claims rather than markup: that the options come
from the world and not from the rendered set, that the hidden set is the off side, that
showQuestInEditor unhides, and that the stale sweep runs. Each was sabotaged first — building the menu
from visible quests, dropping the unhide, and copying the Journal's discovered-only rule — and each
break is caught by its own assertion naming what moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The Concoctions tab shipped with a picture slot and no way to fill it. It has the two controls every
other Compendium card carries now: the portrait row under the thumbnail — view full size, upload,
regenerate, each gated the way the Spellbooks card gates its own — and the collapsible DM-only Prompt
editor with its Override World Art Style box beside the GM sparkle.

Almost none of that was new code. compendiumTypeContext already resolves a recipe under the category
'concoctions', having needed it for the Art tab, so the shared setter, the shared painter and the
shared prompt editor all work on a recipe unchanged; what was missing was passing that category. The
context resolves against worldRecipeList rather than allRecipes, which is deliberate and is why a
world with no recipes map of its own gets the cards and no editing controls: painting writes onto the
record, and the fallback's records are the engine's shared constant, so one world's picture would
otherwise appear in every world.

The sparkle was the real find. Five branches of that resolver name a `suggestPrompt` of their own —
encounters, spells, reagents, concoctions and skills — each pointing at a directive that knows
something the generic writer cannot ask about: which beings an encounter involves, that a skill is a
practice rather than an object, that a concoction's picture is the WORKING and not the tin the finished
item already has a picture of. Only the Art tab's batch sweep ever consulted the hook.
compendiumSuggestPrompt did not, so the button a person actually presses used the generic directive
while the better writer sat one field away, unreached. It consults it first now, which fixes the same
gap on four other categories that were never the point of this change.

Two smaller things followed. The Prompt placeholder's noun came off a ternary chain whose fallback was
"item", so the one field that exists to say what the picture is OF would have described a recipe to its
author as an item type; it is a table now, the same fix the Magic empty-state needed two commits ago
and for the identical reason. And the shipped recipes carry no image and no prompt — checked rather
than assumed, after a test assertion written on the assumption that they did — which is what makes the
Prompt field load-bearing rather than decorative here: regenerate has nothing to paint from until it
is written, and will write one itself if asked.

The test for the sparkle is worth noting because its first version was not a test. It asserted that
the branch's text appeared in the source and that it appeared before the generic directive was built,
and a sabotage that left both true while making the branch dead at runtime passed it cleanly. It calls
the function now, with the recipe's own writer and gmFetch both stubbed to record, so "the hook is
used" and "the generic directive is never built" are each observed rather than inferred from the shape
of the file.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

main was red and I put it there. The previous push ran the suite through a pipe to `tail`, which exits
0 whatever the runner did, so the `&&` guarding the push saw success over a failing test. Checked by
exit code from here.

What it was failing on is worth more than the mistake. Two sessions built the player-facing reagent card
at the same time. Both landed a `buildReagentDetailHTML`, forty thousand lines apart, so git merged them
without a textual conflict — and JavaScript keeps the LAST function declaration, so the other session's
won every call and mine was dead code from the moment it merged. The popup opened and looked subtly
wrong rather than broken, which is the worst way for a duplicate to present: nothing throws, nothing
logs, and the only symptom is field labels you did not write.

Only the tests caught it, and only because they asserted the WORDING rather than that a popup appeared.
An assertion that had checked "the popup is non-empty" would have passed against the wrong builder.

Resolved to one builder — the surviving one, which was already wired to the Compendium — with the two
things mine had folded in behind an `actionable` flag: the have-against-need count on each ingredient,
and the Prepare another button. The Compendium passes nothing and stays a reference view, which is the
right split rather than a compromise: it says what a reagent IS, and facts about one character's bag do
not belong in it. The counts read through ingredientTally, the same source the Prepare button and
prepareReagent both use, so the three cannot disagree about whether a preparation can be made.

The test now also asserts there is exactly one such builder in the file, which is the property that was
actually violated and the one no per-behaviour assertion can see.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Reported from play: clicking the Knitbone Meal in Character › Inventory did nothing at all — no popup,
no error, no sign anything had been clicked.

The Reagents section of that tab is SYNTHESISED from player.reagentStock, because a measure of ground
bone is a count on the character rather than an entry in any bag. So inventoryHoldings() has never heard
of those rows. The click handler looked the clicked name up there, found nothing, and returned in
silence. It is the predictable cost of drawing a card that looks like an item card for something that
is not an item, and the answer is to give the tier its own popup rather than to make the card look less
like a card.

The row now carries its reagent id into the DOM and the handler resolves that first, before the item
lookup it would otherwise fall through to.

What it opens is NOT the item popup with a reagent poured into it. An item popup states a type, a worth
and a weight, and a reagent has none of the three — reusing it would answer three questions wrongly to
avoid writing a fourth builder. Nor is it showReagentDef, which jumps to the Editor's Reagents tab: that
is the DM's surface, and a player clicking something in their own pack should not land in a world
editor. It answers what a player actually wants of a measure they are carrying — what it is, how many
they hold, what it was made from (with what is in the pack beside each, so "can I make another?" needs
no second screen), what it is used in, and how it is made — and it carries a Prepare another button, so
a reference card they cannot act on does not send them back to the pack to find one.

It also keeps the two numbers apart that the editor card keeps apart: Held is the stock, One preparation
makes is the rate.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Regenerated from Tools/gen-progress-report.js after fetching complete git
history — the working checkout had been a shallow clone, so the report was
built from a truncated log (3665 commits) rather than the true one (3731,
1079 files). Re-running the generator against the full history picks up the
missing days and lines-of-code count with no change to the tool itself.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ML2hheRm9nHSbhdGAumu53

Compendium › Magic gained Concoctions and Reagents beside Items, Spells and Spellbooks. Both take the
shared filter box and the DM's Reveal All unchanged, because those are controls on the view rather
than anything a tab owns — the only work they needed was to honour them, which each renderer does the
way the Spells and Spellbooks ones already did.

The Concoctions tab lists RECIPES rather than brewed flasks, and that follows the reagents document's
own argument rather than breaking it. A concoction carries `magic` among its subtypes and deliberately
not in its flag, so itemCompendiumCategory files a flask under Items the moment the player holds one;
listing flasks here again would be exactly the second home that section refuses. The working has no
card anywhere else, so the recipe is what the tab is for — its DC, its hours, what it consumes held
against what the character is actually carrying, what it yields, and the `preparation` prose, which is
the longest and best-written field on a recipe and until now reached no player-facing surface at all.

What counts as discovered differs between the two tabs, and the difference is the engine's rather than
a preference. A reagent is genuinely per-entry: knowsReagent is a real predicate over the character —
an explicit learn, or a reagent this world has put no class gate on — and holding a prepared measure
counts as well, since a pouch already in the pack is not something to be told you have not found. A
recipe has no per-recipe knowledge to read at all: brewConcoction refuses on the skill and nothing
else. So the Concoctions tab turns over together when the working is learned, which is unlike Spells
and is stated in the code, the test and the document, because read as a bug it would look like one. An
untrained character genuinely cannot perform any of these, and a compendium implying otherwise would
be describing a capability they do not have.

Two lists collapsed into one on the way through. The inner-tab roster was spelled out as the literal
['items', 'spells', 'spellbooks'] in three places — the switcher's guard, its active-class loop, and
the same loop again in renderCompendium — which is three lists to keep in step and the shape every
stale roster in this file began as; a tab present in one and missing from another is a button that
highlights and never renders. And the empty-state builder branched `kind === 'spells' ? … : …`,
answering "spellbooks" for every kind that was not spells, which was correct while there were two and
quietly wrong the moment there were four. Both are tables now.

Each card's name opens a read-only detail body, so the "View details" affordance every row carries is
not dead on two tabs out of five. The resolver is inner-tab aware in both directions, and the test for
that had to be taught the one case that matters: the branches are ordered and each returns once
entered, so with either tab open one of them always claims the question and an unguarded branch is
invisible. Only from the Items tab does a missing guard get to answer — opening a reagent popup for an
item that happens to share its name — which is the assertion that finally caught it.

test_item_size_display failed on this and was right to, in a way now seen three times in this file: it
sliced compendiumDetailBodyFor by a fixed 6000 characters, and two added branches pushed the literals
it inspects past the window, so it failed while the property it guards was untouched. Bounded by the
end of the function now. Its own fixture check is what made that loud rather than a silent pass on an
empty slice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Reported from play: a character holding one comfrey root typed "prepare the comfrey root into knitbone
meal" and got narration. The command matched only the REAGENT — the thing that does not exist yet — so
the more natural of the two phrasings, naming what the player is actually holding, was the one that
failed. Worse, it failed silently into the story rather than saying anything, because the handleSend
route deliberately only takes a line when the resolver names something real.

Three forms work now. The product, as before ("prepare knitbone meal"). The INGREDIENT, resolving to
what it is prepared into ("prepare comfrey root"). And both ends of the transformation with an article
in front, which is the sentence that was actually typed. A leading the/a/an/some/my is stripped, and an
"X into Y" is split with the right-hand side tried first — the product is the more specific of the two,
since a root may feed several preparations where a preparation is one thing.

The ingredient mapping is the one the Prepare button on an item card already computes, so the two routes
cannot come to different conclusions about what a root turns into.

Ambiguity still asks rather than guessing, now on either side of the mapping: a root two preparations
want names both and waits, because a wrong guess spends the root and the hours on a working nobody asked
for. And a real item nothing uses gets a sentence about that item — "nothing you know how to prepare is
made from Iron Sword" — rather than "you know nothing called that" about a thing the player is visibly
holding, which reads as the game being broken. A line naming nothing at all still falls through to the
Game Master untouched, which is what keeps "prepare an ambush" a story turn.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The one-letter trial settled what a traced letter is; this is that twenty-six times, on the language
card where an author is already working. The Alphabet section carries a Trace button: one press, one
confirmation, and every letter the sheet covers is cut, sent to the Glyph AI slot and stored. A cell
shows a ring while its own letter is in flight, and clicking a letter afterwards opens the traced SVG
in the same box that has always held path data, with a picture of the letter beside it. The picture is
the half that catches what reading path data cannot — a letter upside down, a letter that is its
neighbour, a counter filled in — and it costs one column, stacking under the box on a narrow card.

Everything in the runner is about what it costs. Twenty-six paid calls is the most any single control
in this app spends, so it asks once rather than per letter, which is the dialog this exists to avoid;
it runs four at a time, because twenty-six at once is how a rate limit turns into twenty-six charged
failures and one at a time is twenty-six round trips end to end; it writes each letter as it lands,
because a run this long is one somebody closes partway and a letter already paid for should still be
there; and a second press traces only what is missing, so a run that lost four letters costs four
calls to finish rather than the whole alphabet again.

The rule the rest of it hangs off is that the script kind moves when all twenty-six are in and not
before. languageGlyphHTML asks `kind === 'sheet'` first, so flipping to 'svg' with four letters
missing does not leave four blanks on the card — it leaves them blank on every page ever written in
that tongue. The sheet goes on drawing the language until the alphabet is complete and is kept
afterwards, so clearing a letter drops back to it rather than leaving a hole; with no sheet behind it
there is nothing to drop back to, and the cleared letter renders as a visible gap, which is what a
hand-drawn alphabet does and the honest answer rather than a silent one.

That rule is also the defect this change made and the test found before the button was ever pressed.
storeLanguageTracedGlyph handed normalizeLanguageScript a blank kind and asked it to work one out,
whose rule is "any glyph at all means svg" — so the first letter of a twenty-six-letter run flipped
the language off its sheet, and the completion announcement, which only fires when the kind actually
moves, was swallowed with it. The kind is kept rather than recomputed now, and the new
Tests/test_language_alphabet_trace.js pins it from both ends: a partial run leaves 'sheet' and a
complete one moves.

Twelve sabotaged versions were run against that file and each is caught by its own named assertion.
One of them was the test's own fault and worth recording: the concurrency ceiling was written as
peak <= LANG_TRACE_CONCURRENCY, so widening the limiter to 26 turned the run into the burst the
assertion exists to prevent and it still passed — it was asking whether the code agreed with itself.
What a provider cares about is an absolute number of sockets, so that is what is written down now.

The vault's full-reply console log is behind VAULT_DEBUG now, as its own comment said it had to be
before this landed: twenty-six replies at eight kilobytes each is two hundred kilobytes of console per
press. That figure also corrects the design doc, which promised a weight saving over the base64 sheet
— a traced alphabet is roughly two hundred kilobytes of path data, the same order as the sheet it
replaces. The crispness and the per-letter repair are real; the weight saving is not, until somebody
turns down output.curves.line_fit_tolerance and measures again.

Designs/dialects-and-languages.html closes its last open decision by building it, and §9 gains the
playtesting note the desk cannot settle: whether a traced alphabet still reads as one alphabet, given
that a trace is only as coherent as the sheet it came from and crisp outlines sharpen the differences
along with everything else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The reply for one letter is about nine kilobytes and that reads as a lot for a diamond on a stem. The
comfortable explanation is that a reply is mostly document — header, metadata, fills — and that the
glyph kept out of it is a fraction of the bytes. Measured on a reply shaped like a real one, the glyph
is about 93% of it. The coordinates ARE the file. A traced letter costs roughly what its reply costs,
and an alphabet of twenty-six is a couple of hundred kilobytes rather than a couple of dozen.

So the report gives both figures and the panel gives the one that matters, in kilobytes, beside the
contour count. A letter whose price is only ever quoted as "bytes of SVG in the reply" is one whose
real price nobody finds until a world file is large.

The lever, if it is wanted, is the provider's own output.curves.line_fit_tolerance — 0.001 to 1.0,
default 0.1, higher fitting longer segments through the same edge and emitting fewer points. It is NOT
sent: the request is deliberately still the one that was checked by hand on their page, and the last
three regressions all came from preferring a parameter over that. The figure on the panel is what would
say whether raising it costs anything visible.

Also brought the trial test's header up to date. It still described five panels, an <img> of the
provider's document, and two open questions that have both been answered at the table — a comment
describing what a file used to guard is worse than none, because it is read as what it guards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Yes — "Measures made" is a quantity of the reagent, but it is the quantity one PREPARATION produces,
not the quantity the character is holding. The card carries both and they are different things: the
rate is a property of the world, authored and saved with it, the same for every character who ever
plays there; the stock is "On hand" below it, a count on the player, deliberately not in the world
because world.reagents travels with a published world and a stock stored there would ship somebody
else's larder. They sit adjacent so the difference reads, since showing only one is how "how much
grave-salt do I have?" gets answered with a production rate.

It was read-only, which was inconsistent the moment the concoction's batch one tier up stopped being.
The rule those cards follow was never "write only prose" — it is that no card field may author a
dangling REF, which is why yields (an item id) and reagents (records) go through the GM box and its
validator. A count refers to nothing. So Measures made is a number box now, clamped between 1 and 99
with the input corrected to match: a preparation that makes nothing is not a preparation, and a box
left reading 0 over a record that says 1 is a card lying about what it saved.

The design note this came with is worth keeping, because it is the clearest statement of why this craft
exists. The multiplication at both tiers — one crust into three measures, one working into three salves
— is not a balance patch bolted on to rescue a weak system. It is the argument FOR earth magic and the
thing it has that a spell does not: a spell converts mana into an effect at a fixed rate every time,
where a preparation CONCENTRATES, turning a common thing that was merely lying about into a potent
thing there is more of than you started with, and spending labour rather than power to do it. That
density is what the hours buy. It also says where the two multipliers belong: the reagent's yields is
the first concentration (raw matter into measures) and the recipe's batch is the second (measures into
doses), and neither costs more hours or a harder check — the same rule twice, that this craft charges
upstream and everything after the gathering is the payoff.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Reported from a live tab: the DM pressed + Add, the Logs showed a complete faith — name, deity, a page
of description, its worship, its references and an insignia prompt — and the box said "The GM changed
nothing". It had changed nothing only because this client dropped it.

One slip caused it. The model put "remove" INSIDE "religions" and emitted one closing brace too few.
The shared salvage then does exactly what it is built to do: extractJsonObject tries each `{` in the
text and returns the first that parses, so the unbalanced outer object fails, the one after
`"religions":` succeeds, and the envelope is stripped. What reached the roster was the records at the
top level with no `religions` key, and the old reader had no branch for that — nothing applied, and
`_dmAddRandom` reported the empty result as the GM having changed nothing, which blames the model for a
client-side drop. Reproduced against the exact reply before changing anything.

The same mis-nesting with the brace PRESENT is the louder half of the same defect: `remove` sits among
the religions, gets applied as a spec, and founds a religion called "remove". A junk record dropped into
a world in silence is worse than a refusal.

Both are answered by one reader rather than by teaching the shared parser to auto-close an unbalanced
object. That would have fixed it for every roster at once, and it is the wrong trade: it changes the
behaviour of every GM call in the game, and a brace added to a reply truncated mid-field turns a visible
failure into a plausible wrong answer. religionsFromGmChunk reads three shapes — the envelope the
directive asks for, one bare record, and the records at the top level — and lifts `remove` out of all of
them by NAME, so it is never a faith whatever a model puts in it and is still honoured as a removal list
wherever it was nested. A reply carrying nothing readable now returns an error naming that, with the raw
text logged, instead of an empty success.

The directive also says where `remove` goes, since that is the slip that started this. The salvage is
the net; the wording is the thing meant to stop the fall.

Five other rosters — factions, races, ailments, item types and folklore — read `chunk.<key>` the same
way and would drop the same reply identically. Not changed here on the back of one report; recorded in
the doc's playtesting notes so the next person to meet it recognises it rather than re-diagnosing it.

Tests/test_religions.js §20 covers all of it, verified against eight sabotages. Three of those found
gaps in the assertions rather than in the code: two guards were passing for the wrong reason (`remove`
was being skipped for not looking like a record rather than by name, and an empty envelope was being
recognised by a sibling key rather than by itself), and one regression crashed the file on `.join` of
undefined instead of failing a named check.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The letter rendered as nothing. The cause was the previous commit moving the contours and the mask into
the shared sprite — one <symbol> per letter in the `.lang-defs` svg, which is absolutely positioned at
zero by zero with overflow hidden — and reaching them from a <use> in a different <svg>. A mask defined
in there and referenced across documents is something browsers disagree about, and it cannot be
reproduced from a session container, so the diagnosis was already two guesses deep.

The form that demonstrably draws is the one that was on screen two commits ago and confirmed correct at
the table: the paths and the mask in the SAME <svg> as the glyph. So that is what a traced letter is
now — tracedGlyphSVG builds it, and both the page and the trial go through it. No sprite, no <use>,
nothing reached across documents. Mask ids are numbered rather than named after the letter, because a
page sets the same letter many times and two live glyphs sharing an id means the second takes the
first's holes.

The cost is real and is worth stating rather than discovering: a page of traced text repeats the path
data per letter where the sprite ships it once. That is a size problem with a known fix to try later,
which is a better thing to have than a rendering problem with a guess. Hand-drawn letters are untouched
— still one path in the app's own box, still stroked at their authored weight, still through the
sprite — and the sprite now skips traced letters rather than emitting a symbol nothing will use.

And the reply is printed on the server console in full, which is what should have happened several
commits ago. Every wrong turn taken with this document has been a guess about its shape made from a
summary of it; a trace is one call and a few tens of kilobytes, so the cheapest way to stop guessing is
to put the thing itself where a person can read it. Ungated while this is the one-letter trial — the
twenty-six-letter pass has to put it behind VAULT_DEBUG before it lands, or an alphabet floods the
console with half a megabyte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Three conflicts, all additive. origin/main added a religions entry to CARD_PORTRAIT_KINDS where this
branch added folklore; added the Religions insignia paragraphs to Designs/culture.html where this branch
rewrote the Folklore ones; and added a religions fixture to Tests/test_card_generate_prompt.js where
this branch added a folklore one. Both sides kept in each.

One clause in the incoming Religions entry went stale on contact — it said Folklore could stop at two
fields, which was true until this branch gave a tale a picture — so it now says what actually
distinguishes them: a tale's four fields are all about the tale, while a faith's two reference lists
point at rosters the world already has.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Three attempts were made to reduce a trace to the single path string script.glyphs[ch] holds, and each
lost the letter differently: dropping white paths filled the counters in, joining the contours under an
imposed even-odd erased everything that overlapped, and joining under the paths' own rule left a shape
that was not the letter either. The pattern in those three is the finding, and it was pointed out
rather than deduced — this provider does one thing and does it correctly, and the app was accommodating
its answer as though a general model had produced it and errors were to be expected. Every operation
performed on a correct result is a chance to make it wrong.

So there is no flattening left in the file. script.traced[ch] holds { view, ink[], cuts[] }: the
contours in the order the tracer wrote them, each with its own winding rule, in the box it drew them in.
Nothing is rescaled, re-wound or joined, and a <use> scales the symbol to whatever size the text is set
at, so the coordinates never have to become the app's. It sits beside `glyphs` rather than inside it,
which means no migration, no save touched, and a path editor that goes on editing a string — the only
thing it can edit, a traced letter having no single path to put in a textarea.

Two departures survive and both are forced by what a glyph is. The page is not part of a letter. And a
counter cut by painting over the ink cannot stay painted once the ink takes currentColor, so it travels
as a cut and is emitted as a mask — the identical operation, expressed without naming a colour. There
is no paint flag: a traced letter is filled because being made of outlines is what filled means here,
and a setting could only be a way to get it wrong.

The trial's result panel is now drawn by languageGlyphSpriteHTML and languageGlyphHTML, the story's own
two functions, around a stand-in language. "Is this what the page will look like" had been asked three
times and answered wrongly twice; it is not a question any more, because the panel is not a preview of
the renderer, it is the renderer. Four panels went with the questions they settled — the provider's
document, the two paint rules, and the flattened form — leaving what went up and what comes back.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The Folklore cards gain the portrait column every card of this family has — a picture with ⬆ and ♻ over
it, a Generate / Upload pair while there is none — and a collapsible Portrait section holding the prompt
it is painted from, with the art-style override and the ✨ beside it. All three buttons go through the
shared CARD_PORTRAIT_KINDS driver rather than carrying their own copies; four tabs each kept a private
fifteen-line handler until that existed, and three of them were only found wrong when somebody noticed
the fourth behaved differently.

A tale takes the image/prompt pair and not the portrait/portraitPrompt a faction or a race uses. Which
of the two names a record picks decides which shared helpers can read it at all, so it takes the one the
square-framed cards already share.

THE PICTURE IS OF THE STORY, NEVER OF THE STORYTELLING, and that is the only real decision here. A book,
a scroll, an open page, a fireside, a bard, a hooded elder with children at their feet — every one of
those is a picture of folklore in general rather than of this tale, and they come out identical for
every tale in the world, which is exactly the picture a card does not need. Both directives forbid them
by name. It is the same decision the reagent's prompt makes one tier down: a reagent's picture is what
the root became, not the root.

Folklore gets its own prompt writer rather than the shared compendium one, for the reason the spell,
reagent and concoction directives each give: the generic writer works from a name and a description, and
a tale has neither. It has a name and a STORY, and the story is the only place a picture can come from,
so handing the model the text is the whole point. The one clause that took thought is the belief: three
of the four kinds are narratives and that one is a rule people live by, so it is the kind with no scene
in it — both directives say it still has one, and to paint what it says being done or the object it
warns about. A prompt directive that forgets that produces nothing for a quarter of the tab.

THE REQUEST BAR NOW WRITES THE PICTURE TOO. The roster's directive asks for a "prompt" alongside the
text, drawn out of the text it has just written, and the roster then paints from it — so one press of
Apply leaves a card with a story and a picture rather than a card and a chore. Three guards around that,
each of which is a way to make it worse than not doing it:

The paint is best-effort and cannot lose the writing. The tales are applied and saved before it runs,
and a failed picture is reported as a note rather than raised — painting is a second provider that may
be absent, keyless or rate-limited, and a throw there would answer a successful authoring run with an
error, whereupon the DM presses Apply again and the Game Master writes the tale a second time.

Only tales this reply touched, only those with a prompt and no picture. Repainting one the DM already
has is a spend nobody authorised, and painting one the model gave no prompt for would paint from a
guess.

An empty prompt never wipes one. The roster's field patch takes "prompt" only when it is non-empty,
because a model returning "prompt": "" while changing a name would otherwise lose a line the DM had
tuned — and quietly, since the picture stays on the card and ♻ then repaints from a derived fallback.
The roster also marks which tales already have a prompt and tells the model to leave those alone unless
it is rewriting the text.

Verified in Chromium with only the two providers stubbed: typed an instruction, pressed Apply, and the
card came back with the myth under its heading, the picture painted from the prompt the model wrote, the
Portrait section holding that prompt, and the output line reporting both halves. The tests gain two
sabotages for the new guards — the empty-prompt check removed, and the paint left uncaught — each caught
by a named assertion and each applied to text_adventure.html directly to confirm it fails there. The
second of those needed the assertion reading it made defensive first: it took the file down with a
TypeError instead of reporting, and a crash is evidence of something but not an assertion naming what.

test_card_generate_prompt.js failed on the new registry entry and named exactly what it wanted — a
fixture it could address folklore by — which is that guard working: every kind in CARD_PORTRAIT_KINDS
must declare a prompt field, a GM writer and a derived fallback, or it paints a picture and leaves the
prompt box empty.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Reported from a real editor and visible in one glance: a concoction card showing "×2 ember_stone"
beside a properly drawn "×1 Grave-Salt". Before the tiers were separated a recipe's `reagents` map held
ITEM ids, because a reagent WAS an item. After the split it holds reagent-record ids, and every world
written before that day still names the old ones.

Nothing in the load path noticed. normalizeRecipes coerces shapes and never looks at what a ref points
AT, so the recipe survives intact and is permanently unbrewable: reagentTally resolves the ref to
nothing, reports the working short by its full count for ever, and the chip draws as a dangling ref with
the raw id showing. A player could gather, prepare and stand at the bench and never be told why the
working would not go.

The repointing is decidable and does not guess. A ref that is not a reagent but IS an item, and that
exactly one reagent is prepared from, can only have meant that reagent — ember_stone is the stone Ember
Grist is ground from and there is nothing else it could be. Where two reagents share an ingredient the
answer is genuinely ambiguous, so it is left exactly as it is and the evaluator's working-unmakeable
finding reports it to a person, which is where a judgement belongs. Guessing there would rewrite a
working into one the author never wrote, and do it quietly.

It runs in both places a world is assembled, and only after both maps exist because it reads one against
the other: the World constructor, and again on the restore path, which bypasses that constructor and is
exactly how a pre-split recipe arrives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Two things, one of which turns out to be a correction to how this was written down rather than to what
it does.

The mechanic already worked as intended: neither the hours nor the DC move with the batch or the scale.
What was wrong was the argument attached to it. The comment and the design doc called scaling a gamble
— "fast and risky against slow and safe" — which frames a fixed brewing cost as a trade the player
makes. It is not a trade, it is the shape of the craft. The expensive part of earth magic is upstream:
finding the root, and the hours of grinding and drying that turn it into measures. By the time anything
reaches the bench that price is already paid, so the working is one session and one check whatever the
mortar holds, and a bigger batch is the reward for having done the gathering. The whole thing leans
toward doing the work up front, which is what a craft built on preparation should do. The honest
asterisk is kept rather than buried: one roll governs the lot, so scaling does not make failure more
likely but does make it cost more when it comes — a consequence of the check being fixed rather than a
second price.

The batch had no way into the editor. It was a read-only Details row that hid itself at 1, which is
exactly backwards: a recipe making one dose is precisely the one the evaluator has just told the DM to
raise, and hiding the row there left that finding with no lever on screen. Makes is a number box now,
drawn always, clamped between 1 and 99 with the input corrected to match — leaving 0 on screen over a
record that says 1 is a card lying about what it saved.

That it is editable at all is a reading of the rule rather than an exception to it. A concoction card
wrote only prose so that no card field could author a dangling REF: `yields` names an item and
`reagents` name records, and both need the validator the GM box goes through. A batch refers to nothing.

The kvRows renderer grew a third element saying a value is already markup, opt-in per row and false
everywhere else — a renderer that stopped escaping by default would be one authored recipe name away
from putting unescaped text in the page.

One assertion in the new test was worthless when written and is worth recording. It checked that the
Makes row is drawn at a batch of 1 by rendering the fixture, whose batch is 3 — so it passed against an
implementation that hid the row at exactly the value the claim is about. It sets the batch to 1 first
now, and fails when the row is hidden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Religions was added to Art › Missing in the last commit and to Art › Review only by half: the cells
were built and the group that draws them was not, so `religionCells` was a binding nothing read and a
faith's insignia appeared on neither screen. That is now a group, beside Factions, because the two are
the same kind of picture — an emblem standing for a body of people rather than a portrait of one.

A cell has to open onto something. compendiumDetailBodyFor had no religions branch, so every cell in
that group would have been a button that did nothing at all — the failure the Missing tab disables its
controls to avoid, arriving through the other door. The branch uses the light shared body (title,
insignia, description) plus the fields that make a religion one: its deity, its worship, and the
peoples and places that keep it.

Those last two are rendered as NAMES here, not ids. Everywhere else in this feature the id is the thing
that matters, because it is what gets written back; this is the one surface where nobody writes
anything, and "cairnfolk, drell" reads as debug output. An id the world no longer has still shows,
marked, for the same reason the editor's pickers keep it — a reader who cannot see the dangling
reference cannot tell a deleted people from one that was never named.

generateImageForReligion now refreshes the gallery after storing, like generateImageForItem. A
religion's insignia is the one picture here that can be painted with nobody looking at the card that
owns it: autoGenerateReligionPortraits runs in the background after a GM "+ Add", and the DM is free to
walk over to Review and watch the cells fill while it works.

Tests/test_art_review_gallery.js grows a Religions section — the group, a painted cell, a placeholder
for an unpainted faith, the popup resolving by name, the names-not-ids rule, the marked dangling
reference, and the refresh call — verified against nine sabotages. Two of those are the defects this
commit fixes, so the block is mostly there to hold the cells and the group together.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Asked whether the good-looking panel is what the story will draw, the honest answer was no and the
useful answer is a fifth picture. The pane drew four views of what the provider returned and none of
what could be kept — and the obvious reading of a panel that looks right is that the letter is ready.

A glyph is one path string in one viewBox under one winding rule. So the letter is now also drawn that
way, flattened, beside the others, with a line underneath saying whether the flattening changed it.

Flattening turns out to be nearly free, which corrects the previous commit rather than confirming it.
That commit concluded the join "cannot be done by reading the paths", on the evidence of an even-odd
join erasing the letter. The error was narrower than that: the join is fine, CHOOSING the rule is not.
Where every ink path agrees — including agreeing by saying nothing, which is nonzero — joining under
that rule draws exactly what drawing them separately draws, because the provider's stacking cuts its
shapes out of each other rather than overlapping them. Paths that disagree cannot be joined at all,
which is reported rather than resolved by picking one.

What genuinely cannot be stored is a counter the provider cut by PAINTING OVER the ink rather than by
carrying a contour inside it. The pane expresses that as a mask; a single `d` has nowhere to put it. The
first real letter has exactly one, so it stores with a filled diamond where the drawn one has a hole,
and the panel says so in words instead of leaving it to be found in a page of text later.

Also trimmed the dialog's prose, which had grown into an essay. Captions are captions again — Inverted
Cell, Provider Version, Stored Glyph — and the note says what the button costs and what it does, with
the reasoning left in the comments and the design doc where it was already written.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The craft was strictly dominated by shopping, and the arithmetic is the shape every crafting system
fails into. One Knitbone Salve wanted two measures of meal and one of salt: a preparation, a third of
a preparation and the four-hour working — about nine in-world hours and two ingredients, with a 25%
chance for a good CON build of losing all of it on the roll — to restore about 18 HP, while a Health
Potion on the same shelf restored 30 for a copper more. A player who learned the craft was worse off
than one who walked into a shop.

Two fields close it and they multiply. `batch` is the recipe's: how many doses ONE working makes,
independent of the ingredient counts, because the labour is the same whether the mortar holds enough
for one dose or four. Scale is the player's: how many times over the working runs in one sitting,
spending N times the reagents for N times the doses, written either way round as "brew 3 knitbone
salve" or "knitbone salve x3".

Two things deliberately do not scale, and they are what make scaling a decision rather than a free
win. The hours are a session at the bench and a bigger mortar is still one session, and there is one
roll for the whole lot. So brewing three at once costs four hours and stakes everything on a single
d20, where brewing three times over costs twelve hours and gets three independent rolls — fast and
risky against slow and safe. Scale the hours as well and nobody would ever scale, because it would be
strictly worse than repeating the working; roll per dose and everybody always would, because the risk
would vanish.

The evaluator had never looked at the craft at all. world.recipes and world.reagents were invisible to
the pass — it knew `concoction` only as a type to keep out of an opening kit — so the one question a
crafting system has to answer for a world went unasked, and the shipped world failed it in silence. Two
kinds now: working-destroys-value, the GM's because the Concoctions roster really can write `batch`,
and working-unmakeable, the DM's because the missing link may be a reagent, an ingredient, the product
or the skill, and those live in three different editors.

The first version of that check would have sat silent through the very defect it was written for, and
that is the part worth carrying forward. It compared a working against its own INPUTS: by that measure
the salve was healthy — 5c of ingredients for a 14c product — and it was still pointless. So the
trigger is the SUBSTITUTE, and the argument is about what each costs to obtain rather than about
effects: a shop item costs coin, and a crafted one costs coin and hours and the preparations behind its
reagents and the chance of losing the lot, so a crafted thing priced like a bought thing is
under-priced. That is decidable where the effects are not — "restores about 18 HP" is prose, exactly as
the Health Potion's own "Restores 30 HP" is, because this game adjudicates consumables through the GM
rather than through a field.

Two narrownesses keep it from becoming noise. A rival must be within three times the dose's value,
because a world's legendary elixir is not the alternative to a starter salve and a check that always
fires is one a DM learns to skip. And a world with nothing comparable to buy is not judged at all: the
claim is comparative, and with nothing to compare against there is no claim to make.

Two existing tests failed on the batch and were right to. Both hardcoded a quantity of one where they
meant "what the working makes", so each now reads it off the recipe — an assertion about the brew
reaching the pack should not also be a claim about one recipe's balance. The remedy-coverage test
caught every hand-written figure the two new kinds moved: the finding and card totals, the severity
split, the actor table and the roster count, six numbers across two documents that nothing else checks.

What none of this settles is whether the grind is worth the reward. The pass proves a working is not
pointless, not that nine hours feels worth three salves, and supply decides as much as yield does —
until foraging exists, ingredients arrive only by loot and shops. Both are playtesting notes now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The Religions card grows a picture column, the three buttons every other card with a portrait carries,
and a Prompts › Portrait section with the ✨ that asks the GM to write the prompt. All of it rides the
shared machinery — runCardPortraitPaint, runCardPortraitUpload, compendiumSuggestPrompt — so this card
cannot come to behave differently from the Races and Factions cards beside it.

The interesting part is what the picture IS. Not a portrait of a god: the faith's sign, on the surface
its own worship uses. That surface is the half that carries the world — two faiths with the same
crescent are two different religions if one is embroidered in gold thread behind a cathedral altar and
the other is daubed in ash on a scraped hide a nomad band unrolls where it halts. A model asked for "a
religious structure" with nothing else to go on draws a cathedral, for every faith, every time.

So the record gains a `worship` field: where and how the faith is kept. Not `temple`, because "where"
is not always a building, and a field called temple makes every author answer a question half of them
should refuse — the nomads have no roof, the proscribed faith meets where it will not be found, the
river cult has a bend in the river. It is a good world-data field on its own and it is also the only
record of the material the insignia sits on, which is what the prompt is built from. A faith that has
not written its worship down gets the other branch: infer the place and the material from what this
faith is, and do not default to a temple.

Four fields are new on the record — worship, portrait, portraitPrompt, ignoreArtStyle — and all four
are named in normalizeReligion, which is the trap this codebase has already paid for one level down.
That function rebuilds each record from named keys and runs on every load and every import, so a field
it does not list is not lost on some edge case: it is gone on the next reload, silently, with the card
redrawing from the unchanged object in the meantime so it reads as having saved. The test asserts all
four through a save-and-reload rather than on the normalizer, because that is where a DM would meet it.

The GM directive asks for both new fields. A religion it creates arrives with its worship written, its
insignia prompt written from that worship, and the picture painting in the background, so the DM's
first sight of a + Add result is a finished card rather than one with two empty boxes. The roster line
shows worship too: a field the GM may write has to be one it can read, or "move them indoors" is an
instruction it has to guess at.

Religions is also a group on Editor › Art › Missing now, which is the piece that gets forgotten. The
comments around ART_MISSING_GROUPS record the same omission being found late for races and then again
for factions, and each time the symptom was identical — the card could paint one at a time while
Generate All walked straight past them. Adding it took a list entry, a bucket, a render line and a
gallery row, because renderArt builds its section shells off that registry.

Five existing tests failed on this and each was right to: the art-refresh test derives its renderer map
from artMissingLists and named the unmapped bucket (renderReligions had no reRenderArtIfActive call),
the all-done message test wanted a word for it, the kind-filter test pins the group list, the pulse
test's bounded regex spans the orderedKeys literal and now has room for another decade of kinds, and
the generate-prompt test demands a fixture for every CARD_PORTRAIT_KINDS entry. One of them failed on
prose instead: test_equipment_slot bans the word "interchangeable" from anything that ships to a model,
strips `//` comments before looking, and found it in a new `/** */` block. Reworded rather than widening
the strip — the guard is worth more than my sentence.

Tests/test_religions.js grows five sections, verified against thirty-four sabotages. One of them
exposed a test that crashed where it should have failed: removing the per-faith try/catch from the
background painter let the rejection escape, and the unguarded await took the whole file down with a
message about the test rather than about the property. It is caught and named now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Asked what the app was doing to the returned SVG, the answer was: four things. Paths were dropped for
being white, the rest were concatenated into one, a winding rule was imposed on the join, and the ink
was recoloured. Only the last of those is a rendering decision. The other three are guesses about a
document that is already correct, and each was wrong in its own way — dropping white filled the
counters in, and the join plus the imposed rule ERASED THE LETTER. Four contours under even-odd
cancelled one another and left only the shape that happened to overlap nothing.

That is worth more than the bug it caused. Whether even-odd or nonzero is right for a set of contours
is a property of how the provider stacked its shapes, not something a reader of the paths can decide —
so the previous commit's confident "even-odd answers both at once" was reasoning where evidence was
available, and the evidence said no.

Every path is now drawn, in the provider's order, carrying its own declared winding rule. Nothing is
concatenated and no rule is invented. Two departures remain and both are forced by what a glyph is: the
white page is not drawn, because a glyph is ink on nothing; and a white shape that is NOT the page is a
counter the provider cut by painting over the ink, which is the one operation that cannot survive
recolouring, so it becomes a mask — the same cut stated without reference to what colour the ink ends
up. The pane says all of that on itself, since an author looking at three pictures is entitled to know
which parts of the difference are the provider's and which are the app's.

The untouched bytes sit beside the two paint rules as the control, now at both scales rather than one
big picture against two small ones. They were always untouched — an <img> of the reply, rebuilt from
nothing, which is also the only safe way to show third-party SVG — but the panel said "as the provider
drew it", which is not the same claim as "nothing was done to this". It says so now, and names what it
still carries that the others deliberately do not: its own colours and its own page.

The combined path survives as the storage question and is explicitly not what the pane draws.
script.glyphs[ch] is one string per letter so the join has to happen somewhere, and this run established
that it cannot be done by reading the paths. Either the rule comes from the provider, or a traced
alphabet needs a richer record than one `d`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The second run, with the crop and the framing fixed, returned five paths: three ink, two white, one ink
path carrying two subpaths, and no fill-rule declared anywhere. Both of the ways a counter can arrive
were in that single reply, which is why fixing one of them last time did not fix the diamond.

A counter carried as a SUBPATH of the ink fills solid under SVG's default nonzero rule when the two
contours wind the same way. A counter drawn as a WHITE SHAPE over the ink disappears when white paths
are dropped as paper, and takes the hole with it. The foot of this letter was made both ways at once,
so it came out solid in the app while the provider's own render showed it open — from geometry that was
byte for byte the same.

Concatenating every path of the letter into one `d` and declaring even-odd answers both: a contour
inside another cuts it, whichever way either winds and whatever colour it was drawn in. Only the page
itself is left out, told from a counter by span — the page reaches both edges of the viewBox where a
counter sits well inside one, and the report says how many paths were combined and how many white ones
were kept as counters, so a sheet where that guess goes wrong announces itself rather than quietly
losing a stroke. The provider's own default shape stacking cuts its shapes out of each other rather
than overlapping them, which is what makes even-odd safe here rather than merely convenient.

That this is also the shape script.glyphs[ch] stores — one path string per letter — is less a
coincidence than a sign the storage shape was right to begin with. It does mean a traced alphabet needs
its winding rule recorded beside `paint`, or stored under an even-odd assumption every traced glyph
shares; the design note now says so.

The same run exposed a smaller thing: the stroked comparison was rigged in the house rule's favour. A
weight of 9 means 9% of a 100-unit glyph box, and a trace comes back in a 1024-unit one, so the panel
was drawing a hairline — and a hairline outline looks rather elegant, which is the opposite of what that
panel exists to show. Scaled to the box it is the fat double-walled figure the argument predicts. A
comparison that flatters the option you are arguing against is worse than no comparison.

And no prompt reaches this provider, which the manual run also had none of. Every other generation in
the app is driven by one, so `prompt` is the field most likely to be added here by reflex; a test now
forces one into the params and asserts it appears in neither the body nor the URL.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Four things were wrong between the trial's request and the one that was checked by hand on the
provider's own converter page, and the same letter came back clean there and coarse here. Each is fixed
by removing a difference rather than by adding a preference.

THE SVG VERSION WAS NEVER SENT. The request named no `output.svg.version`, so the provider applied
whatever its server currently defaults to, where the manual run was checked at SVG 1.1. The version is
not cosmetic — 1.1 and Tiny 1.2 do not permit the same features — and a default nobody sends is a
default that can move. It is declared now, and it is the version that was verified.

TWO PARAMETERS WERE OURS AND NOBODY ELSE'S. `processing.max_colors: 2` was reasoning about
anti-aliased edges rather than evidence, and the `output.size.*` box was already known not to do what it
was added for: the previous trial established it sets the drawn SIZE and not the coordinate space, so it
bought nothing while its preserve_inset fit squared a 170x204 cell up and moved its origin to -17. Both
are gone. The manual run is the only ground truth reachable from here, so the request is now that run.

THE CROP DRIFTED. Cells were cut at floor(w/cols) stepped along by the column index, where the renderer
slices the same sheet in per cent — so on a 1024-square sheet six across and five down, the last column
and row were cut three pixels from where the page draws them, and every cell after the first was
progressively out. Cut on exact proportional boundaries now, which is what languageGlyphHTML does.

AND THE LETTER WENT UP SMALL. A model asked to keep a margin inside each cell keeps a generous one: the
first real sheet drew its letters small and off-centre, so most of what reached the tracer was paper and
it had a few hundred ink pixels to find contours in where it could have had a few hundred thousand. The
cell is now trimmed to its own ink, padded square so nothing is stretched, and drawn at 1024 — a
magnification of roughly ten times on a real cell. That also makes the cut robust to a grid starting a
few pixels off, to an outer margin on the sheet, and to a letter drawn off-centre, since all three stop
mattering once the letter is re-centred on itself.

The one case trimming cannot survive is a crop that already clipped the letter, because a trimmed
fragment looks like a confident, well-framed, wrong letterform and nothing downstream can tell. So ink
touching the edge of its cell is measured and reported in words on the pane.

TRIMMING PER LETTER IS RIGHT FOR A TRIAL AND WRONG FOR AN ALPHABET, written down where it happens: the
question here is what one letterform traces like, so filling the frame with it is the help wanted, but
across a set it would destroy the metrics — an 'o' and an 'l' trimmed to their own ink and scaled to the
same box come out the same height. The twenty-six-letter version has to measure one box across the whole
sheet and cut every cell to it.

Separately, and visible in the first trial's own screenshot: the diamond came back open in the
provider's render and solid in ours, from identical geometry. A traced letter's counters arrive as extra
SUBPATHS of the ink path and whether they read as holes depends entirely on the winding rule — and the
rebuild copied `d` alone, letting fill-rule default to nonzero and filling every counter in. It travels
with the geometry now, and the report names it and counts subpaths, so a solid counter can be diagnosed
from the text rather than from two pictures.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Culture › Folklore's request bar shipped disabled under the house rule that a card is the Game Master's
only when the roster it names can actually make the edit. dmEditFolklore is that roster, so the bar
opens — and it closes the loop the tab was built with a hole in: a DM could write a tale by hand and
could not ask for one.

WHAT MAKES THIS DIRECTIVE DIFFERENT FROM EVERY OTHER AUTHORING ROSTER. The others reference a vocabulary
the world already holds — Religions hands the model race ids and region ids and tells it to use those
and nothing else. Folklore's vocabulary is not a list of things to pick from, it is four ways of
speaking, and the model has to be taught them. A myth explains, a belief is held, a fable instructs, a
legend remembers. Asked for "a tale about the moor" with four bare names and no meanings, a model writes
the same short story whatever `type` it puts on it — and because the tab groups by kind, the result is
four identical things under four headings, which is a failure a DM sees immediately and cannot fix from
the card. So the directive carries each kind's id, its label AND the sentence the New menu already shows
the author, plus a line saying where the four differ from each other (a legend and a myth are both told
as true; one has a named person in it) and an instruction to choose rather than default when the ask
names no kind.

Interpolated from FOLKLORE_TYPES, never restated. That is the equipment-slot rule, and this is the case
where breaking it is worst: the "one of …" line listing permitted values is built from the same array, so
a hand-copied explanation block would leave a fifth kind ALLOWED and UNEXPLAINED in the same request —
the model told it may use `saga` and never told what one is. The test injects a fifth kind and checks it
arrives with its sentence, the way test_spell_school_stats.js injects a non-WIS school for the same
reason, and the sabotage that hand-writes the block proves both halves of that.

The apply path is applyFolkloreSpec, which merges an existing tale in place under its own key rather than
minting a second beside it — the same duplicate the dialog's own save guards against, arriving by the
other road. A kind outside the four is KEPT and reported back to the DM as a note: kept because that is
what the import path does and two readings of one field is how they come to differ, reported because the
model was given the four and an answer outside them is something a DM should hear rather than discover as
a fifth heading. dmEditFolklore returns rosterOutcome from every exit, and its signature is now in
test_roster_outcomes.js's list so it cannot acquire a bare one.

Verified end to end in Chromium with only the transport stubbed: typed an instruction, pressed Apply,
and the GM's belief landed under a BELIEFS heading with its paragraph break intact, the output line
naming what was created and the box cleared. Everything between the button and world.folklore was the
real code.

Designs/culture.html gains §7, and the entry it replaces is worth reading: it said Folklore was exempt
from the playtesting-notes rule because "nothing in the engine reads a tale and the Game Master is never
shown one, so a single session can observe precisely nothing". That was true and stopped being true the
day this box opened — the model does not read a tale in play but it writes one under a directive, which
is the part somebody can sit down and watch, and it is the same argument Reagents and Religions are
already documented under. The notes are mostly one question asked four ways, because the vocabulary is
the thing a desk cannot settle. One stale claim in the Religions markup goes too: its comment said
Folklore had no roster and stayed shut.

Folklore takes four of the five pieces a P2 needs and skips + Add, which Religions has: "invent a tale
whole" must choose a kind before it can write anything, and which kind a random tale should be is a
question that driver has no way to ask.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Vectorizer.AI bills in its own credits, one per successful vectorization, so it fits the path Tripo
already laid down: a real number of units times a published rate, computed in pricing.js and nowhere
else. What did not fit was the rate. There was one global CREDIT_USD, worth a hundredth of a dollar
because that is Tripo's published figure — and a Vectorizer credit is a fifth of a dollar, twenty times
that. A vectorize priced through the shared constant would have read $0.01 on the Usage tab and read as
a fact, which is precisely the failure the Fable note in that file describes for the token table: an
inherited rate is indistinguishable from a real one once it is on screen.

So the rate is per provider, and there is no default. A provider absent from the map is UNPRICED and
shows a blank cost, the same answer this file already gives a model with no published rate; the
provider is now part of the arithmetic rather than context around it, and computeCreditCost refuses a
call that does not name one. Two tests called it the old way and were asserting the multiplication
through a rate that happened to be global; both now name Tripo, and one of them — the row billing in
both credits and tokens — has to CONSTRUCT its provider, because no shipped provider bills both ways
and the pairing it was asserting cannot occur.

Counting the credits needed the executor to look at something it never had: the response headers. A
descriptor may now declare how it is billed, and the vectorizer one declares two ways to arrive at the
figure in order of what each is worth. A header, if the reply carries one, is what the provider SAYS it
charged and wins outright. Failing that, their published billing unit of one credit per successful
vectorization applies — which is the weaker answer, since a reply reporting 2 would be right where it
is wrong. The exact header name could not be established (their docs host answers 403 through the
egress proxy, and the searchable record names X-Receipt and X-Image-Token without settling this one),
so the plausible spellings are all read rather than one being bet on; adding the real one later is a
string in an array.

Test mode is recorded as costing nothing, because the Glyph AI mode picker tells the player test mode
is free and the ledger has to agree with the screen. Zero rather than null, deliberately: the request
happened and it cost nothing, which is a different statement from "the provider made no claim". Preview
is NOT exempted — whether they bill it could not be established either, and over-reporting is the safe
direction, since an operator who sees a figure slightly high goes and looks and one who sees it low
does not.

The Usage tab's lede is hand-written prose carrying an argument, so it cannot be generated from the
table — which is the case CLAUDE.md says to check the claim instead. It now names both credit-billing
providers with their rates, says the rate follows the account's subscription tier rather than being
fixed by the service, and a test reads the figure out of pricing.js and asserts the page quotes it. A
rate corrected in one place and not the other would otherwise leave the page quoting something the
vault does not charge, with nothing to notice.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Brewing is settled entirely by the engine and never reaches the model, so nothing in the world can
prevent one: a character can work a four-hour ritual standing in a blizzard, waist-deep in a flooded
crypt, or in the middle of a fight. The engine is exactly right about the arithmetic — the stock, the
roll, the clock — and completely blind to the scene, and whether you can work HERE is a fiction
question, which is the one thing local resolution cannot see.

The entry records the bound the answer has to respect rather than picking a mechanic: not so deep a
burden that the craft becomes an errand in finding somewhere acceptable to stand, and not so free that
a working costs nothing but its reagents. Worth stating because this craft already pays a recurring
cost — the reagents and the hours, spent whether the working takes or not — so a place gate is a second
cost on top of an existing one, which is the strongest argument for making it narrow.

It also records what the engine can already see, because that turned out to be more than it looks:
combatActive answers whether a fight is on, roomIsIndoors is exact rather than inferred since world-gen
is told in capitals to set an interior boolean on every room, and currentWeather gives a room's region
its live sky. And the two things it cannot. There is no fire — camp in this engine is a rest MODE, an
eight-hour block with a recovery tier, not a persistent object, so whether a fire is burning here is
state nothing holds and nothing could answer. And weather has no severity: a condition carries `wet`
and a temperature shift and nothing else, so a blizzard is not distinguishable from snow unless a world
authors the difference, and weather can be switched off world-wide besides.

Three shapes are weighed. Routing every working through the model costs a request each time and
reintroduces the disagreement local resolution was built to avoid — and it breaks the ordering, because
brewConcoction spends the reagents before it rolls and a veto arriving after the spend is not a veto,
it is a bug. The leaning is narrow: refuse where the answer is categorical, let a recipe declare what it
needs, and ask the model only when the engine has a reason to doubt, so a character brewing at an inn
table calls nothing while the blizzard is still caught. That rests on a precedent §11 K found for a
different problem — applyRest place-gates camping and downgrades rather than refusing, telling the
player why, which is what a refusal that costs nothing and explains itself looks like in this codebase.

The narration half is separable, cheaper, and probably first: a working already leaves four to six hours
of clock behind it that the GM was never told the reason for. What blocks the half with teeth is that a
fire has to become a thing in the world first — its own small system serving cooking, warmth and light
as much as brewing, and built outside this craft for the reason §04 gives about foraging.

No code changes. The engine brew button stays exactly as it is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Letter "a" of Tundari, a 170x204 cell, 11 Sep 2026. Both questions the trial was built to ask are
answered, and the interesting one is answered in a shape that a glance would have called success.

The reply carried width="100.000" height="100.000" exactly as asked, and a viewBox of
-17.00 0.00 204.00 204.00 — the cell's own units, squared up by preserve_inset and centred, since
(204 - 170) / 2 = 17. Those are two different things. Width and height are the presentation size; the
viewBox is the coordinate space, and a stored `d` lives only in the second one. So the trial's report
now states that comparison as a line of its own rather than printing both numbers and leaving a reader
to know SVG well enough to notice they disagree.

This removes the blocker rather than confirming it. Nothing needs rescaling and no path data needs
parsing: the answer is to store the viewBox beside the path and emit it on the glyph's own <symbol>,
which languageGlyphSpriteHTML currently hard-codes to 0 0 100 100. Exact, lossless and additive — a
parallel views map, absent meaning the old box, so every alphabet already authored renders unchanged.

The other question settled itself on screen. The filled rule reproduced the letter and the stroked rule
drew the same shape visibly heavier, because it runs a nine-unit stroke around a contour that is
already the right shape and every edge gains the weight twice. Reported from the table as "the stroke
is a little too thick", which is the predicted hollow-blob finding in its mildest form — and that
mildness is itself the finding, because it means a traced alphabet stored without a paint field would
look plausible enough to ship and be wrong in every letter.

One thing the trial got wrong about itself. Its coordinate-range line read "-61.2 … 196.67", which
against a viewBox starting at -17 reads as a shape escaping its own box, and is nothing of the kind:
the path uses relative commands, so those numbers are deltas rather than positions and a range over
them is not an extent. The line is withdrawn when a relative path is seen rather than printing a figure
that means nothing. That reply is now a fixture in the test, including the part that matters most — a
width of 100 beside a viewBox that is not the box has to be reported as NOT honoured.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

The glyph dialog gains a third tab. It traces ONE letter through the Glyph AI slot, writes nothing to
the world, and exists to answer the two questions that decide whether the rest is worth building —
neither of which any amount of design answers.

The first is whether vectorizer's `output.size.*` family really lands a trace in the app's own
0 0 100 100 glyph box. If it does, the rescaling this design called the hard part is a request
parameter; if it does not, it is parsing path data and rewriting coordinates and arc flags. The
descriptor now carries the four fields and the client sends them when a caller names a box, so the
untested path is one a caller opts into rather than one every trace takes. It cannot be settled from a
session container — vectorizer.ai is unreachable through the egress proxy there — so the trial reports
the viewBox it actually got, the ink coordinate range beside the box that was asked for, and whether
anything arrived carrying a transform, which is the finding that would sink the whole idea.

The second is whether a traced letterform is worth keeping, and that is a judgement no assertion makes.
So the pane draws the same paths under BOTH paint rules, at 84px and again at text size, beside the
cell and beside the trace as the provider drew it. The house rule strokes a centreline and a trace is a
filled outline; one of those pictures is a letter and the other is a hollow double-walled blob, and
which is which is the decision this feeds.

Three things the building taught, each written where it happened. The cell is INVERTED before it goes
up: a keyed sheet is white ink on a transparent ground, the alpha channel is the drawing, and sent as
it stands a tracer sees either nothing or everything depending on what it does with alpha — while the
cell looks perfectly fine in the pane either way. The provider's SVG is never put into the page: it is
third-party active content, so the document is only ever shown as an <img>, where a browser runs
nothing, and every path drawn as markup is rebuilt from `d` strings that already passed the charset
normalizeLanguageScript applies. And the trial rides the sheet dialog's own retirement token rather
than one of its own, because two tokens mean Cancel retires one and a reply from the other still lands.

The trial has no Accept and must never grow one by accident, which the test asserts as its first
property: a pane that quietly replaced an alphabet would take every page written in that tongue with
it. Tests/test_glyph_trace_trial.js pins that, the inversion, the injection boundary, the retirement
token and the two-rule comparison, and each was confirmed by breaking the implementation and watching a
distinct assertion name the break. Its own arithmetic was wrong first time — six columns read as six
rows — which is why the fixture sheet is deliberately not square.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

brewConcoction was written in phase 2, covered by four test files, and called by nothing. The check,
the grades, the reagent spend and the hours all worked, and no control in the app reached any of them,
so the craft stopped one tier short of its own product — a player could prepare reagents forever and
never make a concoction out of them.

The route is the preparation's twin one tier up: a Brew button on a reagent's pack card, for the
working that reagent feeds when there is exactly one and the character has the skill, and `brew
<concoction>` resolved locally and gated so "brew some tea" and "brew trouble" stay the Game Master's
turns. Its banner is the fourth caller of animateRestNotice rather than a fourth copy of it, gold
rather than the preparation's green because the two acts differ exactly where it matters: preparing is
labour that always works, and a working can spoil. A spoiled one still gets a banner, in red, because
Decision J says failure costs the reagents and the time — the hours are real and the clock has to show
them. A refusal never does: nothing was spent, and a bar sweeping over a working that never started is
a lie about the clock.

The second change corrects something said earlier in this work. The shipped concoctions were called
inert and they are not. potencyMult has been written onto every brewed item since phase 2 and read by
nothing, so a Potent salve was mechanically identical to a Workable one — but it cannot simply be
applied either, because this game adjudicates what a consumable does from its DESCRIPTION. The shipped
Health Potion says "Restores 30 HP" and carries no mechanical field at all, and consumeEffect only
moves the six attributes for a duration, which is right for a plant and wrong for a salve that closes a
wound. A concoction is therefore exactly as mechanical as every other consumable here, and the
multiplier has to reach the model as prose or it reaches nobody. Each grade carries a note — its
multiplier said in words — appended to the brewed item's description, and the baseline grade carries
none, because "Worked workable: the normal strength" costs a line and says nothing.

The third is that the Game Master had never been told any of this existed. Every tab, command, banner
and roster built for this system went in while the model's briefing said nothing whatever about
reagents, concoctions or brewing — the word does not appear in buildSystemPromptParts — so a player
typing "I brew a salve" got pure narration over machinery sitting right there, and a character holding
four measures of ground bone was, as far as the model knew, holding nothing.

Which half goes where is the decision that fails invisibly. The rules cannot differ between two
consecutive turns, so they are a numbered rule in `stable`; the measures change with a single
preparation, so they are a line in `live`. The other way round and nothing on screen changes: the
prompt stays correct, the game plays the same, and the cached prefix stops matching on every turn of
every session. Topic is not the test, and these two are the same topic. What the GM is told it may NOT
do is the load-bearing half — never move a measure, never decide a working took, never hand over a
brewed concoction — because it would do all three helpfully, a player asking for something they cannot
have reading as a fault a good GM fixes. What it is handed is the two ends: ingredients are ordinary
items arriving the ordinary ways, and using a finished concoction is its adjudication from the
description, exactly as a potion is.

The playthrough-capture guard fired on the new route and was right to: it counts the echo sites in
handleSend and asks for a capture beside each, and only its hardcoded total needed moving, which is
the arrangement working rather than a test to edit past.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Reported: clicking + New showed no menu. It was opening correctly — display block, a 190x128 rect, four
rows in it — and painting nowhere, because the wrap sat inside a .npc-tool-group. That class sets
overflow: hidden to clip its segmented buttons to their rounded frame, and an absolutely positioned
drop-down inside one is clipped to nothing.

This is the failure mode that is invisible to every check short of looking. The element has a size and
reports as visible; a DOM query finds it; the menu is in the roster and closes on a click away. What
says it is elementFromPoint at the menu's own rect: before the fix it answered the card list BEHIND the
menu (art-section-head, "Myths (1)"), and after it answers the Myth row. Measured in Chromium both ways
before and after, rather than inferred from the markup.

The CSS block this wrap now joins carries the whole explanation three lines above the rule, written when
the Items facet menu hit it: "The wrap is its own tool group rather than sitting INSIDE one:
.npc-tool-group sets overflow:hidden to clip its segmented buttons to the rounded frame, which also
clips this absolutely-positioned drop-down to nothing." That comment was read while adding the folklore
facet wrap to the selector directly beneath it, and the New menu was nested in a tool group anyway.

So the fix is the one that comment prescribes — its own wrap beside the Export/Import group, taking the
frame from the shared facet-wrap rule rather than declaring a second copy of it. Two related omissions
from the same edit go with it: #cul-folklore-facet-btn was missing from the three rules that give a
funnel button its padding, its block-level svg and its active tint, so the folklore funnel was a bare
glyph where every other one is a framed control; and the New button gains the same active tint while its
menu is open.

Tests/test_menu_exclusive.js gains the guard, asked of EVERY drop-down rather than of one tab's. The Art
tab already carried a hand-written version of this check for its own funnel, which is what makes a
general one worth writing: the trap was known, documented and tested for in one place, and the next
menu walked into it anyway. The sweep finds all fourteen wraps in the markup by the shape they share — a
-wrap id holding a button with aria-haspopup — and walks the tags before each one in reverse, counting
closes against opens, to find its open ancestors. Comments are stripped first, since prose in one can
name a tag it does not open. Run against the markup as it shipped, it fails naming cul-folklore-new-wrap
and what to do about it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Two corrections to the open decision added yesterday, both found by reading the code the note is about
rather than the note.

The blocker is wrong. §4 named rescaling as the hard part — a trace arrives in the cell's pixel space
and normalizeLanguageScript wants a fixed 0 0 100 100 box, which reads as parsing path data and
rewriting coordinates and arc flags. It is probably a request parameter instead: vectorizer takes
output.size.width, output.size.height, output.size.unit and output.size.aspect_ratio, so asking for
100x100 unitless with preserve_inset should emit in the glyph box directly. Unverified, since the
service is unreachable from here, and one call settles it.

What actually blocks it is that the two path forms are opposites, which is the same finding §4 already
records from the other direction. The house glyph is a stroked centreline — fill:none, stroke:
currentColor, stroke-width: var(--lg-weight) — and that rule was fought for: "a glyph is a stroke, and
a stroke encloses nothing", after a first attempt filled the path and rendered half an alphabet as
nothing. A vectorizer returns the other representation entirely: filled outline contours, the boundary
of the ink rather than its spine. Kept as it arrives, every traced letter is drawn as a nine-unit
stroke run around the outline — a hollow, double-walled blob, from valid data and correct markup, which
is exactly the failure that section says no assertion over markup can find. So the conversion needs a
paint field on the script and a second CSS rule which is precisely the fill rule recorded there as
wrong. Both are right; the field is which. It costs script.weight, which goes inert once the weight is
baked into an outline, and with it that section's answer to "these read as one set".

And the benefit was overstated. The note claimed the house form themes through currentColor where a
sheet does not. A sheet does: .lang-g-sheet paints background-color: currentColor through the mask, and
§4 records that as measured in Chromium rather than assumed. What tracing actually buys is three
narrower things — crispness at size, weight in the save, and per-letter repair — and the note now says
those instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Designs/dialects-and-languages.html §4 already recorded that tracing a generated glyph sheet into the
house `svg` form is possible now that a Glyph AI slot exists, and why the last step is the hard one.
It recorded it as prose, which is the wrong shape for it. The folder marks an unresolved call with an
Open tag inside a decision block, and Designs/current-status.html counts those mechanically — so a
parked idea written as a paragraph is invisible to the one page whose job is to say what is
outstanding. It would have been rediscovered rather than picked up, which is precisely the failure the
decision convention exists to prevent.

Moved into §7 as an eleventh decision with its leaning attached. The lede there said all ten were
settled, which was true of the rev. 1 draft's ten and is no longer true of the section, so it now says
which ten it means and that a later one is open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Re-generate opened a window that showed nothing. The sheet was still on the language and the text said
so, but saying is not showing: the author had come to judge a replacement and the thing being replaced
was not in front of them.

A re-generation is a COMPARISON. The question is never "is this good" but "is this better than the one
I have", and a reference that needs the window closed to look at is not a reference at all. So the
current alphabet is drawn in the dialog now, and in every state of it - under the waiting grid, under
an error, and under a drawn sheet - because the moment it is most needed is the one where there is
finally something to weigh it against, which is exactly the moment it used to be least available.

On opening it IS the subject, so it gets the picture and the specimen row both; there is nothing else
in the box to mistake it for. Everywhere else it is an aside beneath the thing being judged: a rule, a
label, and the specimen alone. Below rather than beside, because this dialog is 760px wide for the
reason its own CSS comment gives - one six-across grid needs that much - and two side by side would
shrink both past the point where an off-by-one cell can be seen, which is the whole thing the author is
looking for. The specimen rather than a second picture for the reason the result is already shown
twice: the letter row is the half a raw picture cannot show, so it is the half worth comparing, and it
costs one line instead of another 300px image. Measured in a browser at 1280x720, the fullest state is
590px and fits.

Two things about it are load-bearing rather than presentational, and both guard the same failure. It
carries its label on EVERY appearance, and it is never written into the dialog's result slot. Accept
writes what was drawn. Seeding the stored sheet there is the tempting way to implement "show the
current sheet" - it would put the picture on screen in one line - and it would also enable Accept over
a picture of the alphabet the language already had, then rewrite the language with itself while
announcing a new alphabet and telling the author to go and check the specimen. The test sabotages that
implementation by name, and asserts the dialog holds no drawn script while the picture is up.

An assertion from the previous commit had to change rather than be deleted: it read "the existing sheet
image is not passed off as a fresh result", which was then the same thing as not showing it at all. The
property it was defending is still the right one, so it is now three assertions - the picture is shown,
it is labelled as the one the language HAS, and Accept stays dead beside it - which is the same
guarantee stated in terms of what the dialog looks like rather than what it omits.

Designs/dialects-and-languages.html 5 records the reasoning and the seeded-result trap.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

The Religions request box is open. It shipped disabled under the house rule that a card is the Game
Master's only when the roster it names can actually make the edit, and the point of that rule is that
the roster comes first — so requestReligionEdit and dmEditReligions were written, and the box was
enabled in the same change rather than ahead of it. Languages and Folklore are untouched: they have
records and no roster, which is exactly the state the rule says is not enough.

The tab also gains a "+ Add" beside its "+ New", on the shared RANDOM_ADD_KINDS driver every other tab
uses. They are different acts and the toolbar now says so: + New opens the founding dialog and asks the
DM for the four decisions together, + Add asks the GM to invent one whole from this world's theme, tone
and prologue. The GM button keeps the -add-btn id because the shared registry addresses it by that id,
so the dialog is the button that was renamed.

The one thing this roster does that no other roster does is refuse an invented reference. A religion's
races and regions are ids into rosters the world already has, and a model handed "who keeps this faith?"
will answer "the Elves" in a world that has none. So the directive carries both id vocabularies in full,
and the applier drops anything not in them and names the drop back to the DM. That looks like it
contradicts normalizeReligion, which KEEPS a dangling id rather than pruning it, and the distinction is
the whole of it: normalization is protecting an author's existing data, where a race deleted today may
be restored tomorrow and a silent prune turns a recoverable mistake into an unrecoverable one; a GM
reply is a new claim, made against a roster it was shown in full, and is checked against that roster.
The two meet where an edit returns a whole list containing an id the record already carried — that one
passes, because the invented-id check must not become the prune the normalizer refuses to do. A
reference written as a display name resolves to its id rather than being refused: the roster shows the
model both, so answering in the name is a mistyped key, not a misunderstood world.

Dropping a reference silently was the tempting version and is the worse one. The religion is still
created, so the box would say "created The Sunken Choir" over a faith kept by nobody, with a picker
showing nothing and no reason on screen — which reads as a bug in the Races tab. The rejects therefore
ride back through errors and are shown beside the success.

dmEditReligions returns rosterOutcome from every exit, and is the first roster written after that
contract existed rather than retro-fitted to it; test_roster_outcomes.js now scans it too, so it cannot
acquire a bare exit later. Tests/test_religions.js grows five sections for the roster, verified against
twenty-one sabotages of the implementation. Tests/test_editor_add_random.js gains Religions as its
sixteenth registered tab.

One assertion in test_culture_editor_tab.js was wrong before it was right: "+ Add sits left of Export"
was anchored on the bare id, and the comment explaining the two buttons named that id, so the offset it
compared was the comment's. It passed with + Add moved to the far end of the toolbar. It is anchored on
the attribute now, and the comment says not to write the id into it.

Designs/culture.html reaches Rev. 4 and gains §6, its first playtesting-notes section. The Game Master
does not read a religion in play yet, so the notes are about the authoring directive alone — the same
case Reagents is the precedent for. The most informative thing to watch is whether "dropped <id>" ever
appears at all; the most expensive is whether an edit that adds one people returns the whole list or
only the addition, because the field is replaced and the short answer silently un-worships everyone else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The AI-Generation panel gains a tenth slot. Glyph takes a raster picture and returns an SVG, and it is
a slot of its own rather than a mode of Image AI for the reason 3D and Language are: what comes back is
not a picture. An SVG is the drawing behind one — paths rather than pixels, scaling without resampling,
taking its ink from currentColor — and the app's house alphabet form, one path per letter in
script.glyphs, is made of exactly that material. A provider offered in the Image slot would be offered
for every job it cannot do.

Vectorizer.AI fills it as a descriptor rather than as a hand-written function, unlike video, 3D and
world generation, because it is one request with one answer: post the image, receive the drawing. No
job id, no poll, no second host to fetch the artefact from. That is the line the descriptor engine
draws and this provider is on the near side of it — but reaching it meant teaching the engine three
things, each properly the descriptor vocabulary's business rather than this provider's.

A FORM BODY. Every provider before this one spoke JSON; vectorizer takes ordinary HTML form fields,
spelled with dots (output.file_format) that look like paths and are each one flat key. bodyFormat
declares it, so nothing else changed shape. A form body has to be flat, and both the schema and the
executor refuse a nested one rather than sending String(value) as "[object Object]" and having it
blamed on the field.

AN IMAGE IN ONE FLAT FIELD. The engine already carried a source image, but only as inline parts
prepended to a JSON array — Gemini's shape. imageInput.base64Field names one body field holding the
bare base64 instead. The prefix is stripped, and that is the defect worth naming: left on, the field is
populated, the request is well-formed, and the provider refuses it for a reason that identifies
nothing. It is written in last so it lands last in the form, which is what keeps the call log readable
— redactBody caps a field at 600 characters, and an inline image in front of `mode` would push every
diagnostic parameter out of the entry.

ONE SECRET FOR AN HTTP BASIC PAIR. Their API issues an API ID and an API Secret, which is two fields
for one credential, and two fields is what an operator pastes into the wrong boxes. The new `basic`
auth style takes either form of the same thing: a string with a colon is an id:secret pair and is
encoded, one without is already the encoded blob and is sent as it stands, and a leading "Basic " is
stripped first for the person who pasted a whole header. Telling them apart is decidable rather than a
guess, because base64's alphabet has no colon.

Two smaller decisions came out of building it. A glyph result is handed back inline and never written
to the media store: the store serves same-origin under the content type it recorded, and SVG is active
content, so an <svg> opened at its own URL would run the script inside it with the vault's origin
around it — its admin session, its token. Nothing is lost, because the store exists to keep art that
would otherwise be a CDN link or a megabyte in every save, and a traced glyph is a few kilobytes of
text the client wants to read. And the provider is vault-only, the second after World Labs, for their
shared reason and one of its own: the service is unreachable from here so its CORS answer could not be
established, and its credential is an account login rather than a scoped key. The slot is still listed
in Direct mode and refuses in a sentence naming the remedy, because an empty dropdown with no
explanation is the failure test_slot_parity.js was written about.

Writing the tests turned up a defect older than any of this. supportsImageInput and imageInput did not
require each other, so a custom descriptor could claim the flag with no wiring, validate, take the
gallery slot, and then generate from the prompt alone with the source portrait silently dropped — a
call that succeeds and ignores what it was asked about. They are now halves of one claim. An
assertion in test_descriptor_schema.js was also asserting the wrong thing: it named `basic` as an
unknown auth style and went on passing on the one-character ref beside it, so it survived the style
becoming real. Split in two.

The contract is the published Python SDK's (mitchbregs/vectorizer-ai), not a guess: vectorizer.ai is
unreachable from the environment these sessions run in, so nothing is exercised against the live
service. What is exercised, through an injected fetch, is every request the vault makes and every way
it declines to make one.

Designs/dialects-and-languages.html §4 records what is deliberately NOT built: promoting a generated
glyph sheet to the house form by tracing its cells. The last step is the hard one — normalizeLanguageScript
takes one path's `d` per letter inside a fixed 0 0 100 100 viewBox, and rescaling a trace into that box
means parsing path data and rewriting coordinates, arc flags and all. Getting it wrong replaces an
author's alphabet with twenty-six shapes at the wrong size, and with it every page written in that
tongue. It wants its own design pass and its own tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FVSQ32VR1ib63VY82N2PHY

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Opening the glyph-sheet dialog asked the image provider at once, whichever button opened it. For a
language with no sheet that is right and stays: there is nothing to look at, nothing to lose, and a
window that sits empty until a second press has spent a click showing the author a button they have
already pressed. For a language that HAS one it was wrong, and expensively so.

The card's button reads Re-generate there, and an author pressing it is almost never asking for a
first attempt sight unseen - "again, but straighter" is the whole of what somebody re-generating wants
to say, which means the one attempt the dialog fired on the way in was precisely the attempt they
opened the window to edit the prompt for. So it was thrown away before they had read it, and a second
was paid for. The token that retires a stale reply is no answer: the request is on the wire the moment
the window appears, and retiring a reply is not unbilling a call. Cancel is no answer either, for the
same reason, and reopening throws the prompt edit away with the dialog.

So opening now draws only when there is no sheet yet, and on the re-generate path the dialog's own
Generate is the only thing that asks. The two cases are the same question asked of different states,
not an inconsistency: what differs is whether there is already an alphabet to compare an attempt
against, and that is exactly what decides whether an unasked-for attempt is useful or wasteful.

Two things came with it. The idle pane was previously a flicker on the way to the waiting grid and is
now the first thing a re-generating author sees, so it says the alphabet on the language is untouched
until Accept - "nothing drawn yet" alone, on a language that plainly has a sheet, reads as though
opening had discarded it. And the card button's tooltip promised a generation it no longer starts, so
it now says the window does not draw on opening; the no-sheet wording is unchanged.

The no-generation path leans on switchGlyphDialogTab repainting the pane, which it already did. Without
that the window would open showing the LAST language's sheet, still sitting in the pane from before -
and Accept looks safe to press next to a picture. Removing that repaint is a distinct failure with a
distinct assertion behind it.

The dialog's own test grew a section for the re-generate path and asserts both halves against the same
language, the only difference being whether a sheet is on it: a fix applied in the wrong direction -
never generating on open - passes half of it and fails the other half. Five sections after Accept had
been relying on opening to start a run, and now press Generate themselves when opening did not; that
helper presses only when nothing went out, so those sections still prove a request exists to be
retired rather than quietly sending a second one.

Designs/dialects-and-languages.html 5 records the split and why the token does not cover it.

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015izWsvj4gzyxMjL6FV2qyK

Editor › World › Culture › Folklore shipped as furniture and said so in its own markup: "Nothing is
stored under world.folklore, so every authoring control on this tab is disabled rather than wired to a
handler that would quietly answer not yet." This is the record it was waiting for. A tale is a name, a
body of text, and a kind — and the kind is the only thing that distinguishes one tale from another,
since nothing in the engine reads any of it yet. The tab groups by kind and a funnel filter narrows by
it, the same pair of controls the Art, Items and Lore tabs carry.

THE KIND IS PICKED ON THE MENU, BEFORE THE DIALOG OPENS, rather than in a select inside it. That is a
claim about what these four are: a myth explains, a belief is held, a fable instructs, a legend
remembers — four different sorts of statement rather than four values of a field. Choosing first is what
lets the dialog's own prompt say something useful about what to write, instead of offering one blank box
under a heading that could mean any of them. The menu is interpolated from FOLKLORE_TYPES rather than
written into the panel, so a fifth kind cannot reach the grouping and the filter while the one control
that can create one goes on offering four — the equipment-slot lesson, which this repo has paid for
twice.

Two fields and not the four the design doc proposed. Where a tale is told and by whom, what it teaches,
and how much of it is true are all fields nothing reads, and a form of five boxes whose last three change
nothing is a form people fill in once. They stay in Designs/culture.html §2 as the proposal they were.

A kind an imported world brought with it is KEPT and drawn under its own heading rather than being folded
into one of ours. The only way to get one is to import a world that authored it, and rewriting somebody's
`saga` as a myth is a silent edit to their data that nothing downstream would ever report — so the
normalizer lowercases the type and stores it, and the grouping puts the four this world knows first and
anything else after them, alphabetically.

Three things about the implementation that a reader would otherwise have to rediscover. The card's
headings are SIBLINGS of the cards rather than wrappers around them, which reads worse in the markup and
is load-bearing: initEntityCardToggles takes only a <details> whose parentElement is the registered view,
so a section div per kind would leave every card one level too deep and silently untracked — the DM opens
a card, the next redraw rebuilds the tab from a set that never heard of it, and it shuts under their
hands. Saving an edit KEEPS the tale's id rather than re-slugging from the name, or a rename files the
tale under a second key and leaves the first standing beside it. And the tale's text renders with
white-space: pre-wrap, because it is prose with paragraphs in it — the same trap the reagent's
preparation fell into last week when it was folded into a plain field.

world.folklore is named in the World constructor, in serializeWorld, in rebuildWorldFromSnapshot and in
WORLD_BACKFILL; the two drop-downs each have a row in ONE_AT_A_TIME_MENUS; the view is registered in
EDITOR_CARD_VIEWS; and folklore has an entry in EDITOR_IO, so Export and Import are the same two buttons
every other card tab has rather than two more disabled ones whose stated reason had just stopped being
true. Its Export honours BOTH filters, unlike every adapter above it, which have only a name box to
honour: a DM who has narrowed to Legends and pressed Export has said which tales they mean.

Tests/test_folklore_editor.js is the new test, with three sabotages — the save re-slugging instead of
keeping the id, the reload path dropping folklore, and the normalizer validating an imported kind against
our four — each caught by a distinct named assertion and each also applied to text_adventure.html
directly to confirm it fails there. It also pins the direct-child property by measuring each card's div
depth in the rendered view, which is the only way to check from here what the toggle listener checks at
runtime.

test_culture_editor_tab.js moves Folklore to its LIVE list beside Languages, exactly as its own header
predicted: "the first one that goes live fails a build and asks whether the record it writes to exists
yet". Two of its mechanics needed correcting rather than working around. It slices each panel up to the
start of the next one, so a comment placed BETWEEN two panels ran the previous panel's slice into this
one and asserted Beliefs held controls that belong to Folklore — the comment moved inside the panel, and
writing that boundary out verbatim in the comment cut this panel's own slice short, which is how it was
found. And it scanned the switcher's whole body, prose included, for renderer names, so the word
"renders" in a comment read as a call to a missing function and failed twice over working code while the
comment was reworded around it; it strips comments first now, because a sentence about dispatching is not
a dispatch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The Culture tab's Religions panel had a lede describing a record nobody could author. It has the record
now: world.religions, holding a name, a deity, a description, and two lists of ids — the races that keep
the faith and the regions it is kept in.

The two id lists are the part worth explaining. They are ids into rosters this world already has, never
names, for the reason the region files already give for `climate` and §5 of the languages document gives
for a language naming its speakers by race: a race renamed on the Races tab would otherwise stop being a
worshipper, silently, while the card went on listing a people that no longer exists under that spelling.
The corollary is the half that is easy to get backwards — an id that stops resolving is KEPT and shown as
missing rather than pruned. A race deleted today may be a race restored tomorrow; this codebase has a Save
Editor and an undo-by-reimport habit, and a normalizer that swallowed the dangling reference would turn a
recoverable mistake into an unrecoverable one, with nothing on screen saying it had happened. The picker
therefore lists a missing id first, marked, and selected, so simply opening it does not drop it.

The regions picker reads world.regions.list rather than world.regions. The regions record is a map object
carrying its own geometry — seed, viewBox, outline — with the places underneath, so a picker built from
its entries offers "outline" as somewhere to worship, which reads as a bug in the regions editor rather
than as a wrong accessor here. worldRegionList() exists to make that mistake unavailable.

+ New opens a dialog rather than dropping a blank card into the view. Four of the five fields are
decisions that want making together, and a blank card asks for none of them; the dialog asks for all of
them at once and refuses a nameless faith in the dialog, while what was typed is still on screen, because
an "unnamed religion" left in the world is a record the author has to go and find. Both multi-selects are
written through one handler that reads the select's whole selection rather than the option that changed —
a writer that only ever added would make ctrl-click-to-deselect impossible, and the symptom is not an
error but an id that comes back on the next render looking like a failed save. That handler deliberately
does not re-render: redrawing the card under a picker somebody is mid-way through using closes the
<details> and drops the focus out of the list, and the only thing that would change is a count in the head.

world.religions is named in all three places — the World constructor, the serializeWorld allowlist and
rebuildWorldFromSnapshot — and has a WORLD_BACKFILL entry so a save written before the tab existed still
receives the built-in records rather than needing the world version moved. The GM request box stays
disabled, on this tab and on Languages both: the house rule is that a card is the Game Master's only when
the roster it names can actually make the edit, and there is no authoring roster for either yet.

Beliefs is gone, folded into Folklore. An omen, a taboo or a superstition is a tale worn down to its
moral, and keeping the two apart made an author answer "is this a story or a belief?" before they could
write either down — a question with no consequence anywhere in the engine. The Folklore lede says so in
its own words, so the distinction is recorded rather than lost, and nothing was ever stored under
world.beliefs for the removal to strand. Removing a tab fails the same way adding one does, so the test
asserts the removal in both directions rather than merely dropping the name from its lists: a name left in
CULTURE_INNER_TABS with no button throws in the render loop and takes the whole strip down, and a button
left in the markup with no name in the list can never be given .active and reads as a dead control.

Tests/test_religions.js is new and covers the model, the pickers, the dialog and the round trip; it was
checked against twenty-seven sabotages of the implementation, each caught by a distinct named assertion.
Tests/test_culture_editor_tab.js moves from six tabs to five and gains a Religions counterpart to the
Languages "genuinely live" section, including the assertion that a live tab is DRAWN when selected —
without the dispatch the view keeps whatever it last held, which looks like a roster rather than a stale
one. The Escape-dismissal comment's two hand-written dialog counts were already ten dialogs out of date
and are corrected, with a line saying they are indicative and unchecked.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The prior page was generated from a shallow checkout, so its commit log and
stats undercounted the project's actual history. Regenerated from a full
clone (git fetch --unshallow) via Tools/gen-progress-report.js: 3,665
commits across 74 days, June 30 through September 11.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0128obVCQc4EATbUXZCyuajS

The Beings editor could author everything about a placed NPC and could not remove one. The only
removal in reach was the item catalogue's, which is a different act entirely — it deletes the
definition and every placement of it — so a DM wanting one gatekeeper gone had no button that meant
that. This adds Remove to the bottom right of the entity card footer, beside Update, wearing
.item-remove-btn's own look rather than a copy of it: it is the same button doing the same kind of
thing, and a parallel rule is how two of them drift apart.

The trap it is written around is that storage is not presence. World.entitiesInRoom scans EVERY room's
array and matches `ent.location`, deliberately, so that a routine can move somebody by reassigning one
field — and storage never moves with them. A gatekeeper defined in the gatehouse and standing in the
square lives in the gatehouse's array with a location pointing at the square. A removal that filtered
the square's array would find nobody there, change nothing, and report success. despawnEncounters
already walks every room for exactly this reason. So entityStorageRoom answers which array actually
holds a being, the confirmation names where it is STANDING because that is the room on the card, and
the splice happens in the other one. The test's fixture is deliberately a being whose two rooms
disagree: run it against one standing where it is stored and the wrong implementation passes.

What the dialog says is the part the DM decides on, and one sentence of it was worth the digging.
makeEntity COPIES out of ENTITY_CATALOG rather than referencing it, so a placed being carries no
back-pointer at all — there is no ref to check. Matching by name is what is left, and the answer
matters: a being the catalogue defines can be placed again and the dialog says so, while one it does
not define exists only here and removing it is the last of it. A DM who assumes every removal is
undoable by re-placing from the catalogue would be wrong about roughly half of them. Off-screen is
reported as its own state rather than as a missing room, and a being in a live fight gets a warning,
because combat holds enemy NAMES rather than references and would be left holding one with nobody
behind it.

It is on all three being tabs rather than on NPCs alone, which is worth saying plainly since the ask
named that tab. They are one card builder — the file's own comment calls Monsters "identical look and
behavior to NPCs" — and Fauna and the Art tab draw the same cards again. Gating the button on
`type === 'npc'` would be an extra condition producing an asymmetry nobody could justify from the
outside, so all four rosters redraw after a removal too: a being gone from one tab and still on the
next reads as a removal that did not take.

Two defects in the test, both found by sabotaging it. A stray scaffold line left an un-awaited removal
whose promise resolved after the assertions that read its result, so every one of them measured the
world before the change. And the unknown-uid assertion checked only that no dialog opened, which a
crash satisfies just as well as a guard does — dropping the guard makes `ent.name` throw before
appConfirm is reached. It now asserts the call returns quietly AND opens nothing, which tells the two
apart. ENTITY_CATALOG is reached through a getter for a related reason: buildWorld reassigns it rather
than filling it, so a reference captured at definition time points at the empty object it started as.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Two authoring fields, added together because they are the same shape and because together they answer
a question neither would have answered alone. The region detail panel gains a Races field above its
map — chips, a select of the races not yet named, an Add button — and a race card gains Languages,
built the same way, whose select is the list World › Culture › Languages authors with English at the
head of it. Both are drawn from the select/Add/chips classes the item card's Teaches section already
uses, rather than a parallel set, because two controls that do the same thing should not have to be
learned twice.

English needed a decision. A book names its tongue with an EMPTY value — the option reads "English —
as every book already is" — because a book has one language and absence can honestly mean the ordinary
one. A race speaks several, so absence there cannot mean English without also meaning that nothing was
said about it, and the two are worth telling apart: an unstated people is not the same as one the
author has placed in the common tongue. So the common tongue gets a reserved id. A world that authors
its own record slugging to `english` simply replaces it — the reserved id is a fallback label, never a
claim on the name, and the select drops the duplicate rather than offering two Englishes one of which
does nothing.

Both fields go through normalizers that REBUILD their record from named keys, which is the trap this
codebase has already paid for on this exact object: normalizeRace returns a fresh literal and lost
`loreXp` that way, set on the card and shown on the card and silently back to the default after a
reload. So the first thing the test asserts of each is that the normalizer names it, before anything
about the setters. A generated region is born with the field present and empty, which is the rule its
brief already follows — no reader should have to cope with a region that predates it.

A chip whose id the world no longer defines is kept and marked rather than dropped. Silently
discarding it would hide that a race or a language was deleted out from under the things that named
it, and the ✕ is how a DM clears one deliberately.

The region field draws nothing at all in a world with no races. That is the climate picker's own rule
two lines above it in the same panel, followed rather than reinvented — a select with nothing in it is
a control that can only disappoint. The race field is the opposite and always draws, because English
is always an option, and that asymmetry is the same one the book's Tongue section makes from the other
side: it hides itself in a world with no languages, since choosing English for a book changes nothing.

Neither field reaches the system prompt. This is authoring surface, and wiring it into the per-turn
dossier is a separate decision with a token cost that should be argued where prompt weight is argued
about rather than smuggled in beside a UI change.

Designs/dialects-and-languages.html needed the note, because it had settled that a language belongs to
a region and this reaches that answer by a different road: a region gets its tongues through the
peoples who live in it. That composition is the better one for the reason the entry itself gives — a
language belongs where it is spoken, and what speaks one is a people rather than a place, so two
peoples in one valley with a tongue each survives it where a flat list flattens them. But the entry
also warned against six cultural markers bolted on one at a time, and two have now been bolted on one
at a time; the region culture dialog it wants should absorb these rather than sit beside them, and it
now has to reckon with markers that attach at different hops.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

"Animal Part" could not be an id, and it turned out it did not need to be. Four surfaces were printing
the raw type ID and none was printing the label the taxonomy has carried on every entry since it was
written: the Item Editor's type dropdown, the tag on a card's head, the card's Details row, and the
room popup. Nobody had noticed, because every built-in id happens to be a serviceable English word —
misc was the only one that read oddly, and it read oddly for exactly this reason. Printing the id was
reading the wrong field, and it only became visible when a type wanted a two-word name.

The world type editor already accepts [a-z0-9_] for an id and already collects a label beside it, so a
DM's own type could always have carried digits and underscores into those four places. There was never
an id spelling that would have made this right. itemTypeLabel renders the label and falls back to a
title-cased id for the types with no taxonomy row at all — the icon map still offers potion, scroll,
gem and tool, which old saves carry — because a blank where a word should be is worse than an imperfect
word. The dropdown's option VALUE stays the id, since that is what lands in it.type; only the text moved.

With that done the type is ordinary. animalpart, labelled Animal Part, is what is cut, drawn or rendered
OUT of a creature — bone, hide, horn, venom, gland — and the Spider Gland is one. The trap it avoids is
still live and one letter away: `animal` means a creature kept or carried as a thing and shelves under
Fauna, so a jar of cured venom typed that way files beside the spider it came out of, which is why the
directive warns off that specific mistake by name rather than only stating the right answer. The three
inferable types are now exactly the three kinds of thing earth magic is compounded from, which is not a
coincidence — a reagent's kind is a statement about where the raw thing came from, and so is each of them.

Three tests failed on the label change, all for the same reason and in the same shape: they witnessed an
item's type by matching its raw id, so `armor` and `weapon` stopped matching once the card said Armor and
Weapon. None of their claims changed — one is about a dialog carrying the card's own fields, one about
the natural type surviving enchantment, one about where the type chip sits in a row — so each now reads
the expected string from itemTypeLabel rather than spelling it out. A hand-written capitalisation in a
test is a second copy of the taxonomy, which is the thing this codebase keeps paying for in other shapes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Two gaps, and they were different shapes.

AILMENTS had the whole pipeline and no list. A sickness is a record in world.ailments carrying `image`
and `prompt`; its editor card has had the three portrait buttons all along, CARD_PORTRAIT_KINDS knows
how to paint one, and compendiumTypeContext has had an 'ailments' branch since that card's sparkle was
fixed. What was missing was the entry in artMissingLists — so an ailment's art could be generated one
card at a time and never by Generate All, and the Art tab's ✓ line claimed a finished world over
sicknesses that had no pictures at all. Factions sat in precisely that gap before them, and the comment
this one sits beside says so in its own words.

REAGENTS were the opposite: on the Missing tab and absent from the Review gallery. Since the tiers were
separated a reagent is a record rather than an item, so it stopped riding the Items cells — and the two
tabs came to disagree about what this world contains, which is the thing nearly every comment in that
renderer is written against. A reagent's picture is the PREPARED MATERIAL, and the ingredient it came
out of is an item with a cell of its own, so both belong on the page: they are two pictures of two
different things, not one duplicated.

What a new gallery group actually costs is the popup. compendiumDetailBodyFor resolves a cell's body BY
CATEGORY and returns null for a category it has no branch for, so the cell renders, hovers, clicks and
opens NOTHING, silently — which is what a Races cell did before its branch was written and a Classes
cell before its. Both branches are here, and the sabotage in the test removes them to prove the cells
would go on looking perfectly healthy without them.

The reagent's preparation and the ailment's detailed description each get their OWN labelled field
rather than being folded into the description with a blank line between. That was the first draft, and
looking at the rendered body is what showed it: buildCompendiumEntryDetail escapes plain text into a
.room-popup-field, which has no white-space: pre-wrap, so two paragraphs collapse into one run-on and
the transformation reads as another sentence about the material — when the transformation is the whole
reason a reagent is a reagent rather than the root it was ground from. compendiumExtraField draws the
second one in the same shape, and returns nothing for an empty value so a caller can append it blind.

The ✓ "nothing left to create" sentence gains "ailment". It stays hand-written: test_art_factions.js
already derives the bucket list from artMissingLists and fails naming any bucket with no word in that
sentence, which is the claim-checking pattern working — an interpolated sentence was tried first and
would have cost eight tests their assertions to buy nothing the guard does not already give. Four other
registry-completeness guards failed on this change and each named exactly what it wanted: a renderer for
the bucket, a word for the message, a thirteenth key in ART_MISSING_GROUPS, a fixture that fills every
bucket. That is the suite doing the job it was built for, so all four are updated rather than worked
around.

Tests/test_art_reagents_ailments.js is the new test, with three sabotages: the popup branches removed
(a cell that opens nothing), artMissingLists returning an empty ailments bucket (the historical factions
shape — the comment beside it says "the batch simply never asked"), and currentArtCards dropping the
descriptors while the section still draws, which is the subtle one: everything looks right and Generate
All walks past every card in it. Each is caught by a distinct named assertion, and all three were also
applied to text_adventure.html directly to confirm they fail there. The first draft of the popup
sabotage cut compendiumTypeContext's own 'reagents' branch instead — it matches earlier in the file —
and reported itself as applied, so the test now checks it removed the two it meant and left that one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

The button refused behind a vault, in a sentence explaining that the vault had no route for a text call
to a provider other than the Game Master's own. That was honest and it was no use to anybody actually
running a vault, which is how this app is meant to be run: the OpenAI key lives on the server there, the
client holds none, and a transport pointed at api.openai.com can only answer "no OpenAI key". The whole
feature was absent for the deployment it was built for.

So there is a route now. /vault/text is code rather than a descriptor, for the same reason video and 3D
are code: the descriptor vocabulary is built around media responses — base64 payloads, poll loops,
urlIfNoKey — and a chat completion is none of those. It sits behind the same token gate as every other
proxy, checks an allow-list of the providers it will run before it looks at anything else, reads the key
from the store and never from the request, builds its URL from a host table in providers.js rather than
from anything a client said, and tallies the call on the same ledger as every other generation. A
lexicon was otherwise the one AI request in the app that cost nothing on the page whose job is saying
what things cost. It is logged the way the other code routes are — as the kind of request it is, not by
its words — because the call log is redacted everywhere else and there is no reason for this one to
differ.

The client side is a dispatch rather than a branch in the button. generateTextWithProvider resolves the
provider and the model from the Language slot's own settings — Settings › Language AI, the Lexicon model
row — and then routes by mode, which is the part a caller must not have to know. Deliberately not
gmFetch, and the reason is worth stating: that is the Game Master's transport and the Game Master's
provider, so a lexicon sent down it would be answered by whatever model is running the game rather than
by the one the player chose. It would look, on the card, exactly like the right answer.

Tests/test_language_ai.js gains a vault-mode run of the whole button — the client holding no key at all,
which is the state a vault actually puts it in — asserting the request goes to the vault's own route,
names the provider filling the Language slot, carries that slot's Lexicon model, and that nothing
key-shaped leaves the browser. Server/test/test_run_text.js covers the route. Fifteen sabotaged
versions, each caught by a distinct assertion; two survived the first battery and both were about the
SSRF boundary, which is the property in this change that matters most. One was a sabotage that changed
nothing — it read a url the tests never passed — and the fix was to assert the real property, that a url
handed in with the request is ignored, since the edit which "helpfully" honours one looks like a
convenience and hands a client the power to name where the vault sends its key. The other was the host
pin, which catches nothing today because the url is a constant; it is pinned from the source instead,
ahead of the fetch, because the day the url stops being constant is the day it matters and a pin added
after that day is a pin added after the bug.

PRIVACY.md was read against this and needs no change. Its list of third parties already says model
providers "receive prompts and return text or images", and OpenAI in the Language slot is a configured
provider receiving a prompt and returning text; the call log's sixty in-memory entries are unchanged,
and this route puts less in one than the document claims rather than more.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The same argument that moved Comfrey Root to plant applies to the salt scraped off a barrow wall, and
with more force: minerals are one of the three kinds of thing earth magic is compounded from, so
leaving them in the catch-all puts a large and growing share of the craft in the drawer labelled
everything else. Barrow Crust and Ember-Stone are minerals now, and so is anything the GM authors with
a dug-up kind word.

It catalogues under Items rather than taking a compendium tab, which is the precedent contraption set:
a distinct kind of thing does not automatically want a screen, and plants and animals have tabs because
a player STUDIES those in a room, which is not true of a lump of ore. What it does take is a shelf in
the pack beside Materials — a type with no inventory group falls to Other, which is where a thing goes
to be lost — and a default icon, because that map is what fills the Item Editor's type dropdown and
contraption went years without one, offered to the Game Master and unreachable by the DM. The test
names all four places a type has to exist, so the next one added cannot go missing in three of them.

With two inferable types the order became a question, and it must never be one in practice: a test
walks both vocabularies and fails if any word is claimed by both, so INGREDIENT_NATURAL_TYPES is a
tiebreak that never fires rather than a silent positional rule. The type's own name counts as a kind
word beside its form vocabulary, because that is the word an author actually writes — both shipped
minerals say "mineral", where a form facet lists what kinds of a type there are and would not sensibly
name the type itself.

An animal by-product still infers nothing, and that is a decision rather than an omission. The taxonomy
has no type for one and the nearest is a trap, since "animal" means a creature kept as a thing and
would shelve a jar of cured venom under Fauna beside the spider. A byproduct type beside mineral is the
honest fix and is left as a decision rather than something to infer a way into.

One test outside this system was argued with rather than satisfied. test_equipment_slot holds that a
prompt asking for "subtypes" is minting catalog items, and minting items means saying where they can be
worn — the rule that caught the Region Builder authoring gear nobody could equip. Its one exemption was
flora, and the ingredient directive had been riding it by ACCIDENT, because its kind line happened to
contain the word "plant". Rewording that line to "something that grows" dropped it out, which is the
useful part: the exemption was resting on a word rather than on a reason. It is NEVER_WORN now and
carries both reasons, since a plant and an ingredient are alike in having no slot to offer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Reported from the editor: Comfrey Root shipped as type "misc" subtyped ["ingredient", "herb"], so a
growing thing sat on the Items tab and was absent from Flora — the one place a player studies plants,
and the one foraging will read when foraging exists. The type and the subtype answer different
questions and both were being asked the second one. What it IS versus what it is FOR: an ingredient is
a use, not a kind of thing, so a root is a plant that happens to be an ingredient exactly as a
spellbook is a book. Re-typing it changes nothing about the craft, because everything there filters by
subtype.

The GM authors ingredients through the same applier, so a line in the directive would not have been
enough — a rule the prompt states and the code does not check holds until the model has a busy day.
ingredientNaturalType reads the kind word beside "ingredient" and types it plant, at the choke point
that already forces the subtype, and only ever as a promotion out of misc. A type the author actually
chose is left alone: misc is what applyItemSpec defaults an unstated type to, so it cannot be told from
a deliberate one, but promoting a herb out of Miscellany is right under either reading, where
overriding a consumable would change which mechanical fields the item may carry.

Its vocabulary is the taxonomy's own. The plant type declares its form facet — tree, herb, root,
fungus, bark, sap — so a word added there teaches the inference and the prompt at once, and the
directive interpolates the same list the applier reads rather than restating it. Two prompts once wrote
the item-type union by hand and both omitted "treasure"; this is the same trap one field over.

One guard was tried and removed, and it is the part worth carrying forward. The first version skipped
any word that also leads another type, reasoning that a subtype meaning two things is not evidence of
either — and it threw out "herb", the one word the reported item carried, because "herb" also leads the
consumable form facet. Bark, root, sap and fruit are all edible too: ambiguity is the normal state of
these words, so the narrowness has to come from the caller instead, and it does.

Nothing but plant is inferred. A mineral and an animal by-product are both misc, and a by-product must
not be typed "animal" — in this taxonomy that means a creature kept or carried as a thing, so a jar of
cured venom typed that way shelves under Fauna beside the spider it was cut out of. The directive's
first draft told the GM to do exactly that, and now warns off the mistake by name.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Generating in place was wrong for this one thing, and the reason is what the picture IS. A portrait that
comes back badly is a portrait, and painting another costs a click. A glyph sheet that comes back badly
replaces the alphabet of a language, and with it every page anybody has written in that tongue — the
sample sentence on the card, every passage in every book tagged with it, the specimen an author has been
tuning for an hour. So the Languages tab's Generate opens a window now: the sheet on one tab, the prompt
that produced it on the other, and Cancel, Generate and Accept beneath, of which only the last writes.

The prompt tab is editable because "again, but straighter" is the whole of what an author wants to say
after seeing the first attempt, and until now the only way to say it was to edit the language's
description and hope. Reset puts back the app's own wording, recomputed for the language as it stands
rather than remembered from when the window opened — the description is what the prompt is built from,
so "the original" has to mean the app's answer now, not its answer ten minutes ago.

Three things about the window are load-bearing rather than decoration. The waiting state is the shape
being drawn — a grid of the right number of columns, one cell per letter, with a wave running across it
— which says what is coming where a spinner says only wait. The result is shown twice: the picture as it
came back, where a stray label or a seventh column is plain to see, and beneath it the alphabet sliced
out of that picture and drawn the way the game will draw it, in the text colour through the mask, which
is the half a picture cannot show. A sheet off by one cell looks perfect in the image and renders every
letter as its neighbour. And Generate stays live while an attempt is running, superseding it, because an
author who has just rewritten the prompt should not have to wait out an attempt they have already
decided against — and the alternative, cancelling and reopening, throws the edit away with the dialog.

What Cancel promises is not what it looks like, and the code says so where somebody will read it. There
is no abort signal threaded through the provider layer, so a request already on the wire may well
finish; OpenAI's own transport does take one, which is worth forwarding since it is the only provider
this slot offers, but that is a courtesy of one provider rather than a rule. The guarantee is that the
reply is dropped: every attempt carries a token, the token is retired on cancel and on the next
Generate, and an attempt whose token is stale writes nothing at all — not to the dialog, not to the
world, not even a line in the Logs. That last clause is the one worth having. The failure that matters
is not a wasted request; it is a late reply overwriting the sheet the author has since accepted, or a
cancelled generation reported as a success in a log that then disagrees with the screen they were
looking at.

Tests/test_glyph_sheet_dialog.js drives the real handlers against a transport held open, which is the
only way to ask what happens to a reply that lands after Cancel — and it can choose which await the run
is retired during, because a run decodes its picture twice and the fake Image counts them. Sixteen
sabotaged versions, each caught by a distinct assertion. Four survived the first battery and every one
was the test's own fault: a canvas double returning the same bytes for every run, so no assertion about
which of two attempts won could ever fail; two guards that could not be told apart because the test
always retired the run at the same await; and an Accept that was never called with nothing to accept.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

`WORLD_DATA.version` was documented as something to bump "whenever the built-in world data changes in a
way that should invalidate old saved games", and the trouble with that sentence is that it reads as
"whenever you change the world". Two sicknesses added to the built-in world moved it from 1.0.0 to
1.1.0, and every save on that world stopped resuming — at both doors, the login screen's Continue and
every row of the Load Save menu. Nothing was deleted; they simply could not be opened.

Not one of those saves would have failed. A save carries its own world, every reader of a world map in
this file is guarded, and a 1.0.0 save rebuilt under that build ran every path the change had added:
the world came back with fourteen rooms and no ailments, the player rehydrated without the field, the
new diagnosis code answered over an empty set, and the character sheet drew. The gate had refused a
hundred good saves to deliver two ailments that would have hurt nobody.

So the version is a break line now, and it moves only when a change would make an existing save
genuinely fail — a mechanic removed or reshaped such that a save written before it cannot be resumed
without crashing or lying. It goes back to 1.0.0, because adding two ailments was not that. The gate
is ordered rather than an equality test, which also stops it stranding a save from a LATER build: a
player who opened an older copy of the file used to lose the save, when the worst case is a field this
build ignores.

The other half is what makes not bumping safe rather than merely cheap. A save that predates a piece of
the built-in world now gets it on load. backfillWorldFromBuiltIn copies every record the built-in world
has and the save does not, by id, out of a freshly built world so that what lands is the normalized
shape a new game would hold rather than the raw literal. The world is meant to be living: a returning
player should find the sicknesses, rooms and quests that have appeared while they were away, and be
told so in a line, because content that appears with no explanation reads as a bug.

It is additive only and never overwrites, and that is not caution but the only honest answer available.
"Already in the save" covers three different things it cannot tell apart: a record the player changed by
playing, a record the DM edited in the Save Editor, and a record that simply matches. Overwriting would
be right for the third and would destroy the first two. Two consequences are documented rather than
fixed — a built-in record deleted from a save on purpose comes back, since nothing records deletions,
and a new built-in room arrives unlinked, since the exits that would reach it live on a room the save
owns. Scalars are left alone for the same reason: rewriting the prologue is a change to what the save
has, not an addition to it.

Two things fell out of building it. Reading the built-in world means running the World constructor,
which assigns the ITEM_CATALOG and ENTITY_CATALOG globals as a side effect — left repointed, every
ref-resolution after a restore answers for the built-in world instead of the save's, silently and a long
way from the cause. And the growth has to be announced after the message log is rebuilt, because the
restore replaces that log wholesale and a line written before it is thrown away by the restore that
produced it.

The Load Save menu also said only "Could not load that save", which was the entire message a player got
when the gate refused one, while the Continue button beside it named the cause in a sentence. Two doors
onto the same refusal, one of them mute, and the mute one is the door somebody uses when they already
suspect that particular save. There is one definition of the refusal now — snapshotRefusalReason — read
by the resume gate, by the login screen's continue state and by that menu, so the three cannot reach
different conclusions about one save in different words or in none.

Tests/test_world_backfill.js asserts the headline the way the failure actually happened: content is
added to the built-in world after the save is written, and the save must still be resumable and must
now have it — nothing about the version, which is the field that lied. Seventeen sabotaged versions,
each caught by a distinct assertion; three survived the first battery and each was the test's fault, the
worst being that every assertion called the merge itself and none checked that the restore ever did,
which is the perfectly-built-and-unreachable shape this repository keeps rediscovering.

One thing the suite caught that I would not have: the comment on WORLD_DATA has to be whole-line //
comments, because that literal is read as data by the world-adopt path and by two item tests, which
strip exactly that and choke on a block comment.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The document said diagnosis was not built, which was true for a day. §7C keeps its leaning, because
the leaning was right about the shape and useful about what it left out: the check earns the course,
and "or Herbalism" was dropped on the way, since Field Medicine is the skill whose own description
says it treats ailments and two skills answering one question is a second ladder to keep in step. What
the entry now records beneath that is the half the leaning called unwritten — the DC ladder, and why
it runs the opposite way to flora's — together with two decisions the shape did not anticipate: no
authored DC override, because a field with no editor row and no line in the directive is surface a
world cannot reach, which is exactly how this document ended up with lore no player could unlock; and
a route that is not the skill at all, because Field Medicine is tier 2 behind Herbalism and a feature
only trained characters can reach is the same defect wearing a different hat.

The playtesting section needed the sharper fix. It was written yesterday and opened on its own best
finding — that no world in this repository defined a single ailment, so every clause of the system was
shipped, reachable and unobservable. Shipping two sicknesses into the built-in world falsified that in
its most prominent sentence, twenty-four hours after it was written, which is a decent argument for
how fast a status claim rots. The callout now records what it said and why it mattered, and says what
replaced it. Five new notes cover diagnosis, and the most informative of them is not about the check:
it is whether a Game Master ever reaches for `diagnoseAilment` on behalf of a character who cannot
roll one, because if it does not, an untrained player carries a card reading Unplaced for the rest of
the game and nothing in the world ever answers it.

One note pointed at the wrong decision letter — the tension it names, a mechanic offered as an example
in a field whose own sentence rules mechanics out, bears on cure (§7D) and not on diagnosis.

The status index moves the ailments row back to §04. It spent one day under §03 with diagnosis named
as its outstanding phase and that phase is now built, so the counts go back: twenty-four built in
part, fifteen shipped with growth ideas only, still totalling the fifty-two the page claims. A page
that moves a row twice in two days is working rather than thrashing, and the footer says so.

CLAUDE.md gains the sharper version of a trap it already records. A field on a record INSIDE a
collection is worse than a field on the player: normalizePlayerAilments rebuilds every entry from
named keys and runs on every read, so anything it does not name is lost on the next turn rather than
on the next reload.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Ailments could be caught and cured but never understood. `detailedDescription` — "its course, its
stages, how a healer would know it" — was authored, required of the Game Master's own ailment roster,
and read by nobody: it reached neither the GM's dossier nor any player surface, because there was no
player surface at all. A sufferer saw the condition labels the toll emits, "feverish" among the rest,
and nothing that named the disease or said how long they had been carrying it. The authoring roster
has been telling models for weeks that "the player earns this by examining or by skill"; that sentence
described code which did not exist, and now it does not have to.

The shape is borrowed whole from the item identity gates, for the reason ailment effects are the item
effect model: a second vocabulary for "roll your skill against this thing to learn more about it"
would be two ladders to keep in step, and this codebase has already paid for that once, with a sensed
read priced at 1 on one ladder and 0 on the other. Three differences are deliberate. The subject is
always present, so there is no reachability gate and no scene for the GM to judge — which is why this
is a button on the character sheet rather than a directive, costing no prompt tokens and impossible
for a model to miss by failing to recognise "what have I caught?" as an attempt to examine oneself.
There is no middle tier, because there is no halfway answer to what a fever is. And nothing is hidden
but the course: the name and the plain description stay visible, since hiding them wants an
apparentName concept ailments do not have and a Game Master forbidden from saying "marsh fever" aloud.

The DC ladder was the open half of the decision and it runs the OPPOSITE way to flora's. A plant's
identifyDC rises with its value because a rare herb is a rare thing to have seen; a disease is not
rarer for being worse, it is louder. Six points off a body is florid, with signs enough to tell it
from everything else. The hard ones are the quiet ones, where two illnesses look alike and only the
course separates them, which is what differential diagnosis is actually hard at. So severity buys the
DC down from a base of 14, floored at 8, and an ailment whose toll is words alone — a real authoring
choice, since narrativeEffect is the half the directive calls more important — lands one above the
base by falling out of the formula rather than by being special-cased. No authored override: it would
be a field with no editor row and no line in the directive, which is how this codebase ends up with
lore nobody can unlock. A world wanting a harder diagnosis authors a subtler toll.

Field Medicine is tier 2 behind Herbalism, so most characters will never have it, and a feature only
they can reach is the unearnable-by-construction shape this repository keeps rediscovering. Hence
`diagnoseAilment`, the direct route: a physician who examines them, a herbalist who has seen it
before, a plague-ward's ledger. It is to the button what identifyItem is to identifyFlora, it is
applied after inflict so one turn can both give a sickness and name it, and its spec says in as many
words that the player's own reasoning does not run through the Game Master.

The course is gated in the dossier exactly as a lore hook's lore is gated, and for the identical
reason: a model shown hidden text with no legitimate way to award it narrates it for free. The
undiagnosed branch says so out loud rather than staying silent, because silence reads as "there is
nothing more" and invites a Game Master to invent a course of its own.

Both new record fields go through normalizePlayerAilments, which REBUILDS each entry rather than
patching it and runs on every read — so a field left out of it is lost not on reload but on the very
next turn. That is the player-side twin of serializeWorld's "Named here or it does not exist", the
allowlist that cost this codebase its ailments once, and it has an assertion of its own.

Finally, the world has sicknesses. No world in this repository defined one, so every clause of the
system was shipped, reachable and unobservable — the finding that opens the playtesting notes. Fenlung
is the moor breathing back; the Bogiron Taint is the price the narrative's own "Aldric's Wrong Ore"
thread has always said the forge's iron exacts on whoever carries it, asserted for a long time with
nothing in the engine able to express it. Their difficulties sit deliberately far apart so the ladder
is legible from one session: the florid moor sickness places at 12, the taint that costs a single
point of DEX and has no name anybody has agreed on at 14. Both are held to the directive's three hard
rules for narrativeEffect by assertion, because the built-in world is bound by them too.

Two tests failed on this and both were right to. The borne-dossier slice in test_narrative_effect was
bounded by a character count that the new gate pushed the line past, so it failed while its property
held — a slice length is a fact about today's file, not about the property, and it is now bounded by
the end of the IIFE. And test_lore_type_filter builds a world whose lore lands in four known groups;
the Bogiron Taint carries lore, so a fifth appeared and every count went off by one, which is the
drift its own fixture assertion warns about.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

The Schools cards shipped with five fields and all five were world-building: nothing in the engine read
any of them. A school's one mechanical fact — the attribute its spells are cast with — stayed where it
was, in SPELL_SCHOOL_STATS, an engine table that names the divine schools in code identically for every
world. That is the wrong shape for a game whose classes, skills, spells, races and factions are all
world-authored: a setting whose magic runs on tides or ancestors could only inherit a taxonomy written
for somebody else's world. A school record now carries a governing attribute, and spellGoverningStat
asks the world first, the engine table second, and the Spellcasting skill's own stat last.

An empty stat means inherit, which is what every school starts as and what nearly all should stay, so a
world that says nothing is unaffected. The shared constant is never written through: editing it would
re-point Restoration in every world at once in a change serializeWorld would save nowhere. One function
was the whole cost of the override, because spellcastingAttackProfile, the spell popup, the Spellbook
card, the combat block, the GM dossier and this tab's own roster all already asked it — which is the
argument for a chokepoint, made by a change that would otherwise have been five edits that could come
to disagree.

The GM's spell-authoring directive is the one place that did not follow for free. It TELLS the model
which schools cast off what, and the model files new spells by it; built from SPELL_SCHOOL_STATS it
would state the engine's answer for a school the world had just re-pointed. It now interpolates
magicSchoolStatRoster(), which merges the two with the world's entry REPLACING the engine's row rather
than joining it — two contradictory sentences in one directive being worse than the stale one. Same
house rule that cost the equipment-slot roster twice.

THE CARD HAS TO SAY WHICH FIELDS ARE WHICH, and that is the half of this worth arguing about. Five
fields that do nothing sitting beside one that decides how well every spell in the school is cast, with
nothing to tell them apart, is a DM either treating a live control as flavour or treating flavour as
live — and both are worse than the field not existing. So the attribute's label carries a mechanical
flag and says in the hint exactly what it changes and what "Inherit" would give instead; the other four
sit under a World-building divider that states that the engine does not read them, at the moment. The
Details row names which of the four possible sources the attribute actually came from, since "from the
spell school table, or the Spellcasting skill" is now wrong for any school the DM has re-pointed — and
wrong in the direction that matters, telling them the engine decided something they decided.

It is a select rather than a text box with a datalist, unlike type and origin, and the setter validates
against STAT_KEYS on top of that. The six attributes are the engine's vocabulary and not the world's,
and a seventh reaches effectiveStat(), which does not throw for an attribute that is not there — it
answers 0, and the whole school casts off a −5 with nothing anywhere reporting it.

A CRAFT school is refused the field and its card says why rather than omitting the control. Earth magic
is worked through a skill, and brewConcoction reads that skill's own stat through skillAbilityMod
without ever consulting a school, so a stat set there would be a control flagged mechanical that changed
nothing — the exact failure the flag exists to prevent. Shown, not offered, exactly as the name is.

test_magic_school_records.js gains a fifth sabotage: spellGoverningStat stops consulting the record.
That is the worst shape this could take — the select works, the value saves, the card promises it is
live, and the spells cast off the engine's answer regardless — so the sabotage asserts both that the
spells do not move AND that the DM's choice still shows as saved, which is what would make it silent.
It also pins that clearing the field inherits again rather than falling to a default, that a value which
is not an attribute is refused rather than stored, and that the roster names an overridden school once.
Designs/spells-and-scrolls.html §IX records the override and why the engine table is overridden rather
than retired: emptying it would re-point the divine schools in every existing world on the next load,
and a world that has never opened this tab has not asked for that.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Found by putting the card on screen. `.item-desc-edit` is a flex ROW — the textarea beside its word
count — so the button row and the hint line, added as further children of it, became a third and a
fourth column: the textarea collapsed to a one-character strip and the whole panel read as a rendering
fault. Both rows move outside that box.

Every assertion over this markup passed, because the markup was right. It is the same lesson the glyph
stroke and the sheet slice each taught in their turn, and the third time in this feature that the only
way to find the fault was to look at it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Reported from the editor, and it is the same wall as last time moved one tier down. A reagent names
ingredient ITEMS and applyReagentSpec refuses a ref the catalogue cannot answer, which is right — a
reagent naming nothing is a preparation nobody can make — but it left the GM unable to do the obvious
thing. Asked to author reagents for a world's concoctions it could invent the reagent and then be
refused for the root it is ground from, with no way to supply the root.

Both boxes may now author the ingredient items too, applied ahead of everything else: items, then
reagents, then recipes, the three tiers bottom up so each may name what the one before it wrote. The
order is the whole of it. Applied the other way round every reagent in the batch is refused for
wanting the item sitting three lines further down the same response, and the DM is told the GM changed
nothing over a reply that contained the entire answer. The test creates the reagent rather than
editing a fixture that already had the right ingredient map, because only a reagent that has to be
created can tell the two orders apart — the first version of that assertion passed against the
sabotage it was written to catch.

Two bounds on the new permission. An item authored from these boxes is an ingredient by construction,
so the subtype is forced onto the applied record; without it the item is authored perfectly and is
invisible to the picker, the pack shelf and the Prepare button. It is forced on the RESULT and never
injected into the spec, because applyItemSpec replaces subtypes whenever a spec carries any, so a
spec-side injection would wipe what an existing ingredient already declared the first time the GM
edited one rather than created one. And the item a recipe YIELDS is still off limits: a concoction is
a finished thing the Items tab makes, so the dangling-yield refusal stands as it was.

The tab now says when ingredients are outstanding, because the state this was reported in is the
DEFAULT one for an existing world: world.reagents seeds from REAGENT_CATALOG for any save predating
the map, so four reagents arrive in a world that has never held a comfrey root and every chip on the
tab draws red. One red chip per card was thought to be signal enough. It is not — four broken cards
read as four faults rather than one with one answer — so a notice above them names each outstanding
ingredient and the reagent that wants it. Its button writes the instruction into the GM box instead of
sending it: what it would author is world content, and the DM should read it before it runs.

Two stale prompts came out with it, both the tier split's wake. The Reagents + Add button had been
re-pointed at the record roster and kept asking for an item's fields, so it authored a record whose
subtypes and price the applier dropped without a word and reported "Added" over them. And the item
roster still carried a reagents branch describing a reagent as an item subtyped "reagent" —
unreachable from any tab since the split, and the most misleading kind of dead code, because it reads
as the current answer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

# Conflicts:
#	Designs/README.md

A Language slot in the AI-Generation panel, with OpenAI as its only entry, and the reason it is a slot
arrived from a direction the design document did not anticipate. §7 imagined a Languages slot as an
escape hatch, should a model specialised in constructed languages turn out to exist. What actually
justifies it is that the slot has two halves and they are different APIs of one account: an image
generation for the glyph sheet and a text completion for the lexicon. No other provider in the
registry can do both, so declaring the slot for one of them would put a name in the dropdown that half
the tab cannot use. It carries two model rows for the same reason, one per half, and it is the only
slot in the panel that does. The older argument still holds and is now the second rather than the
first: an alphabet chart is a technical grid on a ground chosen so it can be keyed, and a picture
nobody would ever want the world's art style on does not belong on the dropdown that governs it. The
glyph-sheet button goes there now instead of to Image AI.

The slot is declared on both sides — the client registry, the vault descriptor and the shared slot
vocabulary — because in Vault mode the server catalog governs slots, and one declared on the client
alone is stripped from every provider and renders an empty dropdown. That is the failure the `weather`
slot already made once and whose comment records it; test_slot_parity.js caught this one before it
could be made twice.

Beneath the lexicon box there is now a Generate of its own. It asks that provider to invent a word for
each of the sixty commonest words in the game's own prose that this tongue has no word for yet. A
dictionary is only worth having for words a player will actually meet, and that is a question the game
can answer about itself: every skill, spell, reagent and weather condition it ships with is described
in prose, and so is every room, item and being an author has written. The sources are a declared list
rather than a sweep, built-ins first so a three-room world still produces something worth translating,
then this world's own, which is where a world about ships gets a dictionary about ships. Stopwords are
dropped, and that is a design decision rather than tidying: unfiltered, the commonest words in any
English text are forty articles and no nouns, and §2's fall-through means an untranslated word renders
as English — so a tongue whose `the` is foreign while its `gate` is English is the feature backwards.

Nothing the author wrote is overwritten. Their word is a decision and the model's is a suggestion, and
a button that quietly rewrites a dictionary is one nobody presses twice. Four other things are refused
and counted rather than stored: a word handed back as itself, a word colliding with one already in the
tongue, a word colliding with another in the same batch — two English words rendering as one thing on
the page makes the tongue ambiguous exactly where a player is trying to work it out — and a pair a
world file could not carry, which goes through the same guard an import does. That last one is not
hypothetical: it was found by the twenty-first sabotage, which gave the reply a parser of its own and
revealed that the merge was writing whatever it was handed straight onto the record. A key like
"1. slate" stored that way survives the session and is dropped on the next load, and a loss that only
shows up after a reload is the worst shape of loss this file has.

The bag excludes what the tongue already has, which is what makes the button pressable twice: the
second press asks for the next sixty rather than a reshuffle of the first. On a dialect the inherited
half counts too, or the valley would restate the capital word for word and stop tracking it. And the
existing words go into the prompt as a style reference, because a language whose first sixty words are
Vashaari and whose next sixty are Elvish is two languages in one record and nothing downstream would
report it.

The text call is deliberately not routed through gmFetch. That is the Game Master's transport and the
Game Master's provider, and a lexicon request sent down it would be answered by whatever model is
running the game rather than by the one the player chose in Settings. Which is also the one place this
does not reach: the vault runs a provider's image descriptor and proxies the GM's own text calls, and
has no route for a text call to a third provider — so behind a vault the button says that in a
sentence rather than failing. The alphabet button beside it works there; that one is an ordinary image
generation.

Tests/test_language_ai.js runs the whole handler against a stubbed reply as well as testing the pieces,
because a generator that built its own parser, or asked for words the language already had, or stored
the reply without merging it, would pass every assertion about the pieces alone. Twenty-one sabotaged
versions, each caught by a distinct assertion; two survived the first battery and both were the test's
fault — a registry with one entry in it makes every wiring look correct, and a leniently parsed reply
grows the dictionary whether or not the keys are usable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

The playtesting-notes convention asks for the claims a desk cannot settle, which in this codebase
almost always means how a model behaves under a rule nothing enforces. Ailments has an unusual number
of those, because the system's central decision is that contraction and cure are prose the Game Master
judges rather than conditions the engine evaluates. Every clause holding that judgement in shape is a
sentence, and a sentence is exactly the thing a model can follow once and then stop following.

The section opens on something found while writing it: no world in this repository defines a single
ailment. The catalogue costs an empty world nothing, which is the guard working, and it also means the
whole system has never been in front of the Game Master with anything in it. So the authoring notes
come first, not because they matter more but because nothing else can be observed until somebody sits
down with the tab. That also bounds what the first session can ask for — the play notes want two or
three sicknesses a character can plausibly meet, and a world with one nobody can catch tests nothing.

Two notes are worth naming here because they are the ones a reader would not predict. The first is
that half of what can go wrong leaves no mark on the story: an ailment name outside the catalogue is
refused, but the refusal goes to the DM log rather than back to the Game Master, so the model is never
told it failed and the narration stands while the character sheet does not. That observation cannot be
made by reading the transcript, which is unusual for one of these sections and is said outright in the
closing note. The second is the borne duration. The live line reports "borne 12d" every turn and
nothing in the engine reads it, progression being unbuilt and the stamp existing to make it possible
later. Both answers are findings: a Game Master that invents a course from the number says progression
has a demand behind it, and one that ignores it entirely says the figure is costing tokens in every
turn of every session for nothing.

The status index needed two corrections that this pass made unavoidable. Its ailments row read zero
open decisions where the document has two, and it sat under §04 — "built and have no phase
outstanding" — on a document whose own badge row says diagnosis is not built. Currency and Doors, both
carrying one unbuilt phase, are filed under §03, so the row was in the wrong section by the page's own
criterion. Moved, reshaped to that table's four columns, and the counts brought along: twenty-five
built in part, fourteen shipped with growth ideas only, which still totals the fifty-two the page
claims. The §06 convention exists to catch exactly this kind of drift and the page had made it itself.

Recorded while checking what diagnosis would have to read: detailedDescription is authored, required
of the GM roster, and today reaches nobody. The dossier sends name, description, CAUGHT BY, CURED BY
and toll; the skill gate is unwired. So §7C is not only an unbuilt gate but an unbuilt gate over a
field with no reader, which is now stated in the index row rather than left to be rediscovered.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

# Conflicts:
#	Designs/README.md

A Generate button beside Upload on the glyph-sheet row. It sends the prompt §5 of the design document
already carried, to the configured Image AI, and stores the result as this language's sheet without
touching a word of the record. It is a different road from "ask the Game Master", which returns a
language — name, speakers, sample, lexicon — and is still P4; this one only draws.

Most of the prompt is the file format written out in sentences rather than style direction, and that
is the argument for building it in rather than leaving it to a text box: an image model will happily
return a beautiful alphabet on parchment with the letters labelled, and every one of those details
makes the file unusable. What the author supplies is the single paragraph a model cannot guess — what
the script is LIKE — and that is the language's own description, already on the card above the button.
The row says so, and says so louder when there is no description yet, because an unbriefed model
returns twenty-six unrelated shapes and that is the one fault nothing here can check. Every count in
the prompt is interpolated from LANGUAGE_LETTERS: a roster hand-copied into a prompt goes stale the
moment the roster moves, and this file has paid for that twice.

The part that is not obvious is what happens to the picture. A sheet is used as a CSS mask and a mask
reads alpha, but no image provider returns transparency — they return a picture, and a picture with no
alpha paints every letter as a filled square. So the prompt asks for the one thing that can be keyed
unambiguously, white strokes on a black ground, and the engine turns brightness into alpha as it
stores the file. Three things about that conversion are load-bearing.

Polarity is read off the border ring rather than off the image as a whole. A dense alphabet is mostly
ink, so an average over the whole picture calls the ink the ground and keys the sheet inside out —
every letter a hole in a solid block — where the border is the one part of a glyph sheet guaranteed to
be ground, since every glyph is asked to keep a margin inside its cell. That also means a model
handing back black on white is accepted rather than refused: it has drawn a perfectly good alphabet,
and the measurement run against exactly that case reports a light ground and keys it correctly.

There is a floor and a ceiling with a ramp between them rather than a straight brightness map. A JPEG
on a black ground carries compression haze everywhere, and a straight map turns that haze into a faint
wash in the shape of the cell rather than of the letter; a hard threshold instead of the ramp would
cost the antialiasing that makes a stroke look drawn. And a file that already carries transparency is
left exactly as it is, because keying an existing mask keys the ink and a hand-drawn upload would come
out inside out.

The prompt and the keyer agree about polarity by convention alone and are written far apart in one
file. A disagreement between them is a sheet of solid blocks reached through a correct prompt, a
correct picture and correct markup at every step, so each is asserted against the other rather than
against a literal. The arithmetic is a pure function over the pixel buffer with the canvas kept in a
thin wrapper, so the part with sums in it is testable and a browser without a canvas gives a clear
refusal rather than a sheet of squares. Twelve sabotaged versions, each caught by a distinct
assertion; three of them survived the first battery and each was the test's fault — a fixture too
sparse to make the border and the whole-image average disagree, an output assertion that cannot tell a
hand-typed count from an interpolated one, and a guard whose removal crashed the file instead of
failing a named check.

One thing fixed in passing: the Alphabet hint reported the stored paths even on a language reading
from a sheet, so a card could say "0 of 26 drawn" directly under a head tag reading "26/26 letters",
with every cell of the grid showing a letterform. Two true figures that read as one contradiction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Three conflicts, all of them two features adding to the same list rather than disagreeing about
anything. The item card gained a Tongue section on main while it gained an Ingredient section here, in
the same place and for the same reason — both are fields one kind of item has and no other does — so
the resolution is both, in the order the card draws them. serializeWorld's allowlist and
rebuildWorldFromSnapshot each gained one key from each side (schools, reagents), which is the shape
that allowlist is meant to conflict in: a merge that quietly kept one would lose a map on the next
reload, exactly as the ailments were lost once, and nothing would report it.

A claim in the concoctions doc did not survive the merge and is corrected rather than deleted. It said
the two tabs beside Concoctions ship every write control disabled because neither has a data model —
true when written, and false in both halves now, since Reagents got one here and Schools got one on
main. The paragraph is kept because what it is actually about is why a live GM box is a claim about
what the roster can do, which the schools work does not change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Rev 12 left a question that turned out to be load-bearing: is a reagent already prepared, or is it a
recipe? While a reagent was an item it had to be both, which is why every attempt to give it a
preparation time produced a field with nowhere to put its answer. Prepare a comfrey root and you hold
a comfrey root — either the preparation changes nothing, or the item carries a prepared state, and a
per-instance state is precisely what acquireItem discards when it merges two entries of one name.

Rev 13 records the tier split that answers it and, more importantly, answers the three counts rev 9
refused a world.reagents map on, one at a time. They were good counts and they still cost what they
said they cost; what changed is that the split pays or dissolves each of them. Nothing is double-keyed
because the two tiers are different things with different names — comfrey_root is the item, knitbone_meal
the reagent it grinds into — and the ambiguity rev 9 feared came from the two tiers sharing one name,
which was the actual defect. The three-place serializeWorld registration is simply paid. And two records
cannot disagree about a price because a reagent has none: the ingredient is what is bought, and the
price of the labour is the hours. Section 12.2 is left standing rather than rewritten, marked as
superseded, because the position argued against is part of the reasoning and a doc that quietly deletes
what it used to think teaches the next reader nothing.

What was genuinely lost is named too. A reagent has no weight, no value and no presence in a room, so
it cannot be looted, dropped or sold. That is right for a measure of ground bone and wrong for an
ingot, so the doc says plainly that a craft whose intermediate goods are goods should reach for the
item tier and not copy this one.

Decision L is added and settled, the header and the footer summary follow the tiers, and the playtesting
notes gain five that ask somebody to play rather than to sit at the editor — chiefly whether a player
discovers the middle tier at all when nobody explains it, and whether "prepare" swallows a sentence
the player meant as fiction. The subtype note is rewritten, since the rule it describes moved down a
tier with the field it hangs off.

CLAUDE.md gains the two rules this cost the most time to learn: that a new player field needs a backfill
line in restoreGame, which never runs the constructor, and that the three tiers are three different kinds
of thing — collapsing any two looks reasonable and puts a working one tier off.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The middle tier had no way in. A reagent was a record with a count on the player and nothing that
could raise the count, so the craft read as three tiers on paper and two in a game. This adds the
action that makes it three.

prepareReagent spends the ingredients, advances the game clock by the record's hours, and adds its
yield to the player's stock. It does not roll, and that is the decision rather than an omission: the
check belongs to the brewing, where failing costs the reagents and the time and therefore has teeth.
A second check one tier down would mean a player can fail to grind a bone, which is two failure
points for one product with the cheaper one carrying the same consequence as the expensive one.
Preparation is labour — it costs hours and materials, and it always works. Like every dmEdit roster
it answers from every exit, carrying what was made, what is now held, the hours and the clock span,
because a caller that cannot tell "it worked" from "nothing happened" will eventually report the
second as the first.

Two ways in, both wanted. An ingredient's inventory card carries a Prepare button that names what it
would make, and is disabled naming the ingredient that is missing when it cannot — a disabled button
that says why is worth more here than a hidden one, because the missing ingredient is the whole of
what the player needs to know. And `prepare <reagent>` is typed, resolved locally against reagent
names alone, so `prepare for battle` still falls through to the GM as fiction. The typed route sits
beside the other local commands in handleSend, so it echoes the player's line — and therefore records
a playthrough turn, since a replay that skipped a real action would diverge. test_playthrough_capture
now counts the echoes rather than enumerating them, so the next local command that grows a route is
caught by the same assertion instead of needing it rewritten.

The hours show as the sleep banner's animation with a herbal-green face: the header clock sweeping,
the action box locked, click to skip. It is the third caller of animateRestNotice rather than a third
copy of it — rest and memorization already shared that sweep, and a third use is what proves such a
thing is general rather than two special cases that happen to look alike.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The status pass that finished rev. 7 of the status index found a third way a document goes wrong,
beside the two it already catalogued. A stale badge is a document arguing with itself and a careful
reader catches it; a missing document argues with nothing and is caught only by listing the folder.
The third is a document that agrees with itself perfectly and disagrees with the repository, and all
three instances pointed the same way — understating what had been built. Rev. 7 noted each in its own
row and left the correction for later, on the grounds that a note on the index saying a document is
wrong leaves the document wrong, and the index is not the page a reader of Ailments is holding.

Ailments carried the worst of it. Section 6 was headed "the gap: nobody catches anything yet" over a
body that had been appended to four times recording contraction, earnable lore and curedBy shipping;
decisions A, B and D still leaned toward building fields that had existed for a fortnight; the badge
row promised diagnosis and cure equally unbuilt when only diagnosis is; and the footer said so once
more. The section keeps its anchor and its original prose — what was believed at the time is the part
a later reader cannot reconstruct — but it is now headed as the log it became and says so up front,
and each settled decision keeps its leaning with what actually shipped recorded beneath it. Two of
those leanings were right, which is evidence about how these questions are best reasoned about, and D
is the interesting one: the prose curedBy field did not beat the consumable, the rest-and-time model
and the skill check so much as subsume them, since a sentence can describe any of the three.

The engine had gone stale alongside it, which is the finding worth keeping. A comment beside the
ailment dossier explained that hidden lore was withheld because loreUnlock's kind had no value for a
sickness — true when written, false since kind: "ailment" shipped, and a comment arguing against a
feature that exists is worse than no comment at all. The real reason is the one beings and places
have always had: a hook and its lock live together in Lore Hooks, once, so a locked secret is never
shown anywhere that has forgotten to say it is locked. Rule 13d had gone stale the same way, offering
the Game Master four kinds where the loreUnlock field spec six hundred lines below offered five, so a
model reading the rule had no way to know "ailment" was spellable. The test caught the comment change
because it pinned the old wording verbatim, which is the check working; it now pins the new reason,
the retirement of the old one, and — because a comment claiming a capability reads identically whether
or not the capability exists — the two engine facts that make the new reason true, plus the agreement
between rule and schema. Five sabotages, five distinct failures.

Modding closed with "event bus proposed, not built" for a month after Phase 0 shipped, with Phases 2,
2.5 and 3 landing behind it, thirteen events live and Extensions/BusProbe holding the contract in a
browser. The body of that document is meticulous and current; only the footer was wrong, which is the
lesson recorded in it — a footer is the last thing anybody edits and the first thing a reader
believes. Licensing's header chip said eight decisions open where the document has two, its meta
description said seven, and its own footer had the right answer all along.

Designs/README.md carried the same three claims in the same three rows, and the status index now
records the correction rather than the complaint, at rev. 8.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Answering a question about the sheet road turned up a defect in it that has been there since P1: the
mask was sized to the sheet's own dimensions and positioned by cell offset in source pixels. That is
the obvious arithmetic and it is a different operation from the one wanted. A 64-pixel cell inside a
0.85em box shows the top-left corner of the letter and crops the rest; at body size — the size at
which every page of a world is actually read — the visible window falls inside the cell's own margin
and the glyphs render as nothing at all. Put on screen at 46px the cropping is unmistakable; put on
screen at 12.5px the passage block is simply empty.

It wants `mask-size: cols×100% rows×100%`, which scales the sheet so that one cell is exactly the
element, and a percentage `mask-position` of n/(count−1) — because a percentage position aligns that
share of the image with the same share of the box, so the last cell is at 100% and not at cols×100%.
The sheet's resolution then never enters the arithmetic, which is the property that makes one upload
work at body size, at specimen size and in a heading. The cell-size field the author was being asked
for goes with it: rows come from the letters and the columns, and that was all the shape there ever
was. A field nothing reads is a field an importer fills and expects to work.

The test that should have held this pinned the pixel arithmetic and passed, against a renderer that
drew nothing. It is the house rule about sabotage stated from the other end — it asserted the sum the
implementation happened to compute rather than the property the sum is for, so it was not merely
useless, it was evidence. The replacement asserts that no pixel figure survives in the style at all,
and covers the one-column and one-row sheets that are a division by zero in the obvious formula and
are also the easiest sheets for an author to draw.

A second finding from the same measurement: a JPEG can never work. A mask made from an image reads
its ALPHA — transparent is where the page shows through and opaque is where the ink goes — and a JPEG
has no alpha channel, so every cell of one is opaque and every letter of it paints as a filled square.
It was accepted on the reasonable-sounding grounds that it is a raster like the other three. Offering
a format that can only ever fail is worse than refusing it, so the accepted list is PNG, WebP and GIF,
and the refusal now names the half of the file that matters: the ink opaque, the ground transparent.

§5 of the design doc gains a ready-made prompt for asking an image model for a sheet, most of which is
the file format written out in sentences rather than style direction — an image model will happily
return a beautiful alphabet on parchment with the letters labelled, and each of those details makes
the file unusable. It carries the same caution §7 records about a model drawing an alphabet, and
points an author who wants a road that works today at asking a text model for twenty-six SVG paths
instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Editor › Magic › Schools listed one flat row per school and nothing else. A school was a free-text
string repeated on every spell that belonged to one, and SPELL_SCHOOL_STATS — an engine table, named
in code, identical in every world — was the only thing that had an opinion about what a school WAS. So
"is this divine or arcane" and "what does it draw on" lived in the author's head. Each row is now a
collapsible card like every other editor tab's, carrying a name, a type of magic, an origin, a
description and a detailed description, backed by world.schools. The fields are authorial: nothing in
the engine reads type or origin, and the test asserts that calling a school divine does not re-point
the attribute its spells cast off.

THE ROSTER STAYS DERIVED, which is the decision the rest of this follows from. A school is on the tab
because something DECLARES it — a spell naming it, or a craft skill working it — and that is what the
placeholder tab was built for: nothing goes stale, and a spell authored into a school nobody remembered
appears by itself. The record only describes a row whose existence was decided elsewhere, and the two
are joined by a slug of the name. Two consequences are worth knowing before touching this. Renaming a
school has to move the declarations with it, so a rename rewrites `school` on every spell in the world's
own grimoire and re-keys the record; renaming only the record leaves the old row standing, still named
by its spells, beside a second empty one under the new name, and a DM watches the school apparently
duplicate. And a school whose name belongs to a SKILL — a craft school, which is how earth magic
appears here — is not renameable from this tab at all, because renaming it would rename a skill that
recipes, point-buy and every character who has learned it reference; the card says so rather than
offering an input that silently reverts.

The roster is the union of what is declared and what is authored, so + Add can write a school ahead of
its first spell. A record the derived roster could not show would be a button that looks like it worked
and did nothing, which is the failure this panel's markup was written around. The same reasoning decides
the card's one destructive control: removing a school that spells declare cannot make it go away, so the
button says "Clear fields" there and "Remove" only where nothing will bring the row back.

world.schools is named in the World constructor, in serializeWorld and in rebuildWorldFromSnapshot,
which is the three-places rule; the reload path is the reInstance literal, not the constructor, and that
is where ailments were lost. Type and origin are text inputs backed by a datalist rather than a select:
a fixed list would be this engine telling every world which kinds of magic exist, which is the same
overreach SPELL_SCHOOL_STATS makes and half the reason the tab was asked for. The datalists are rendered
once per tab and not once per card — a datalist is addressed by id, and a card-local copy would put the
same id on the page once per school.

Three controls that were disabled only for the want of the model are live: + Add, Collapse all, Expand
all. The GM request bar stays disabled, and this is the distinction: the record existing is not a dmEdit
roster that shows the model this world's schools and applies what it writes back. Import and Export stay
disabled for a reason of their own. Every one of those tooltips said "coming with world.schools", which
would now be false, so they state their real remaining reason instead — a disabled control whose stated
reason is no longer true is worse than one with no reason at all, and test_school_editor_tab.js now
fails if that string comes back.

Tests/test_magic_school_records.js is the new test. It sabotages the implementation four ways —
serializeWorld dropping `schools`, the roster ignoring authored records, a rename that leaves the spells
behind, and the record minted under its own key — and requires a distinct named assertion to catch each,
with the catching assertion written into the failure message; all four were also applied to
text_adventure.html directly to confirm they fail there. The fourth is a defect this change had and was
found by rendering a card and reading it: minting is a side effect of the first edit to ANY field, so a
record minted under its slug renamed Restoration to "restoration" in front of the DM the moment they
chose a type, and re-sorted the tab underneath them.

test_school_editor_tab.js said in its own header that these assertions were what would say so when
world.schools landed, and §6 now pins which controls went live and which did not. Its filter assertion
moves from the view's raw HTML to the cards' own ids: a card carries hints and placeholders now, one of
which said "Evocation", so a filter that had correctly narrowed to Restoration still "found" Evocation
in the markup. Designs/spells-and-scrolls.html §IX recorded the tab as UI-only with every control
disabled; it now records what shipped, why the roster stayed derived, and that the governing-attribute
half — the field that would actually retire SPELL_SCHOOL_STATS — was deliberately left open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F6KumKkorZ6HTxFo9F6tkk

Fetching before push found the design doc's own status row had moved again — P3
(dialects: a language inheriting a parent's script and most of its dictionary, so a
fluent reader of one stumbles through the other rather than reading either blind or
perfectly) landed between this session's previous two pushes. One line, corrected in
passing rather than expanded into a section, since the mechanism is a refinement on
what the DMG already documents rather than a new player-facing surface.

node Tests/run.js: 840/840 passed.

Merging claude/amazing-feynman-e4dbcx into main landed cleanly with no textual conflict —
different sections of the same three files — but two other sessions had shipped real
functionality in parallel that the merged text was no longer honest about.

A faction's `quests` and `tasks` free-text fields were deleted from the engine (they were
read by nothing) while this session's Factions edit was in flight, so the field table's
untouched `regions, quests, tasks` row now named two fields that do not exist. Removed;
the real mechanism — a faction-bound quest thread, a duty with a payout — is already
covered by the Quests and Duties bullets further down the same section.

Dialects & Languages went from "P0 shipped, the rest proposed" to P1 and P2 both actually
built while this session was writing the opposite. A book's `passage` can now genuinely be
written in a world's own tongue — rendered as glyphs or unlearned-word placeholders to a
reader who hasn't studied it — and another book teaches the script and the words the same
deterministic way any book teaches a skill, no model call involved. All three guides
picked up a concise note; the DMG also gets the `language` / `teachesScript` /
`teachesWords` / `bilingual` item fields, a cheat-sheet row, a glossary entry, and a
corrected design-doc cross-reference. What remains proposed (P4) is the Game Master's own
part — authoring a language on request, or teaching one through conversation.

node Tests/run.js: 839/839 passed.

The Reagents tab stops being a lens over the item catalogue and becomes a tab over world.reagents,
which is what it should have been once the tiers separated. What changes on it is not the layout but
the subject: a card is a record, its Ingredients row names ITEMS with a chip apiece, and the
transformation is the card's centre rather than one field on an item that also happens to be a root.

The concoction cards follow one tier up. Their Reagents row named item ids and now names reagent ids,
so a chip shows that reagent on the Reagents tab rather than opening an item card — a reagent has no
item card and never did once it stopped being an item. The picker offers reagents and refuses both
items and ingredients, because a working draws on prepared measures and one pointed at a root is a
working nobody can do whose chip looks exactly like a working one.

The Concoctions roster may now INVENT reagents in the same reply, which is what a DM asked for after
hitting the wall it exists to remove: a concoction that already exists is exactly the one whose
reagents do not, and being made to pick from a list with nothing suitable in it is how a working ends
up made of the wrong things. The reply carries { recipes, reagents } and the reagents are applied
FIRST — applied after, a recipe naming one is refused for naming something that did not exist a line
earlier. Both rosters share reagentDirectiveRules and applyReagentSpec, so there is one statement of
what a reagent is and one gate into world.reagents; a second copy of either would be wrong the first
time one of them changed, which is the lesson the pasted equipment-slot roster taught twice.

An ingredient keeps a section on its own item card, and it is deliberately not the reagent's. It says
where the thing is GOT and what it is PREPARED INTO — the question a DM actually has when they are
looking at a root — and carries no preparation at all, because an ingredient describing a
transformation is describing something it is not.

The Inventory tab now heads three sections rather than one, and they are three kinds of thing:
Concoctions and Ingredients are items in the pack, while REAGENTS is synthesised from the count on the
player and holds nothing that is in any bag. The tab already merged the pack with player.treasure, so
showing a holding that is not an inventory entry is the arrangement rather than an exception to it.

The Art tab's reagent bucket reads world.reagents instead of the catalogue, which also retires the
exclusion the items bucket needed while reagents were items. What replaced that risk is its mirror:
read off the catalogue, the bucket would list the INGREDIENTS under the reagent heading — a different
tier and a different set of pictures — so the test says that rather than the old double-listing one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The row was written when P1 had just landed and says P0–P1 built, P2–P4 open. Both phases have shipped
since, and the only thing left in that document is the Game Master's part — which is worth naming
rather than counting, because P4 is the one phase of the five that needs a model at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

P3 of the language system. A dialect names a parent, inherits its alphabet and its dictionary, and
overrides part of the dictionary — the whole mechanism, and it cost almost nothing, which is the
argument for §2's split rather than a reward for it. What it buys is one sentence made computable
instead of asserted: a player who learned the capital's tongue reads the valley's at a stumble, every
inherited word reading and every override arriving as a word they cannot place.

The mechanism turned out to rest on a single claim — knowing a word is knowing a pairing. Knowledge
is recorded against the tongue it was learned in and counts for any tongue in the family that spells
the word the same way, so the inherited half of a dialect is free and the overrides are exactly what
trips. The alternative, transferring by language, has two failure modes and both still render: either
the overrides do nothing and the valley reads perfectly, or the inheritance does and it reads not at
all. The pairing rule gives siblings for nothing as well, and two dialects of one tongue being two
different stumbles is most of why a dialect is not simply a second language.

A dialect has no alphabet of its own. It draws with the parent's glyphs under the parent's sprite
ids, so a page of the capital's and a page of the valley's in one story share a sprite — and the
<use> resolves, which it would not if either wrote its own id. The alphabet is learned once, under
whichever of its names the reader met first, and recorded against the owner rather than kept as a
second name for the same fact that would need holding in step for ever. Glyphs already on a record
that later became a dialect are kept and not read; clearing the parent brings them back, so an author
who made a dialect by mistake has not lost an evening's drawing.

One level, settled as decision six, and it needed refusing in two places rather than one. The editor
refuses with a sentence, in both directions, since a language that already has dialects becoming one
is the same chain read from the other end. The resolver refuses again on every read, because a world
file arrives from somewhere else and can carry a chain no editor ever saw — and that is the refusal
that matters, since a wrong answer there is a page that renders oddly while an unguarded one is a
stack overflow that takes the screen with it. It reads at most two links deep, so two languages
naming each other answer with no parent instead of recursing.

The editor's other two decisions are both about not lying. A dialect's lexicon box holds its
overrides alone: show the merged dictionary and the first save flattens forty of the parent's words
onto the child, where they stop tracking it for ever and the next edit to the capital's tongue
reaches every language in the world except its own dialect — with nothing anywhere reporting the
drift. The panel states the split it is deliberately not showing instead. And a dialect gets no grid
of twenty-six, because a grid that accepted edits nothing would ever read is worse than no grid; in
its place is a sentence naming whose letters it borrows and how many of them are drawn.

Tests/test_language_dialects.js was written against seventeen sabotaged versions, each caught by a
distinct assertion. Two smaller things fell out of building it: the specimen on a card was asking the
record for its alphabet rather than the owner, so a dialect would have claimed to have none beside a
head reading 22/26; and `force` — the specimen's way of treating the reader as knowing nothing — had
no exception for a tongue that has a lexicon and no alphabet at all, which is a trade creole by §2
and was being drawn as a row of missing-glyph boxes on the card of a language that has no glyphs by
design.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

Current Status stated counts — seven proposed, eighteen built in part, ten shipped with growth ideas,
four finished — over 39 of the 52 other documents in the folder. Thirteen had never appeared on it,
so every one of those figures was a count of whatever happened to have been read, presented as a count
of the folder. That is the failure this page exists to catch, standing on the page itself.

All thirteen are read and placed. Proposed: llm-scenario-tests, whose nineteen open decisions are what
a proposal at this stage looks like rather than a fault. Built in part: class-paper-doll (slots
shipped, the doll background not), culture (the tab shipped with no data model behind it),
dialects-and-languages (P0–P1 of five), properties (phases 0–1, with beings and registry promotion
outstanding), being-states (the parity fixes, with the enforced-state vocabulary itself outstanding)
and reagents-and-concoctions (the skill, recipes and brewing built, the wider system proposed).
Shipped with growth ideas: ailments, modding, licensing, victory-banners and rest-banners. Finished
outright: merchant-restocking, proposed and built the same day with every leaning in the proposal
taken.

Reading them turned up a third convention beside the two §01 already names, and it is the reason the
lede promises to check the code wherever a status looks doubtful. Three documents have gone stale
against the repository, all in the same direction — understating themselves. Ailments still says
"nobody catches anything yet" in a section written before inflictAilment shipped, and still leans, as
an open decision, toward building the field that now exists. Modding closes with "event bus proposed,
not built" and the bus has three tests and a second extension template behind it. Licensing's header
chip says eight decisions open where the document has two. None of those is the internal contradiction
§06 catalogues: each agrees with itself perfectly and disagrees with the code, and none would have
been caught by counting tags. Each is noted in that document's own row rather than corrected here,
because the fix belongs in the document.

Every count moved with the rows and each was checked against the rows it claims: eight, twenty-four,
fifteen and five, summing to the 52 the header now states. The historical "rev. 5" references
elsewhere on the page are left alone, since they name that pass rather than this one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

P2 of the language system. P1 shipped the cipher — an alphabet, and a reader who either can or cannot
read it — and this is the half that makes a language a language. `world.languages[id].lexicon` maps
English to the tongue's own word, `player.languages[id].words` records which pairings this character
has been told, and `languageTextHTML` now walks a line word by word through `english → lexicon →
script` rather than substituting the whole of it, so one page can carry a shape, a romanisation and a
word in English at once. That is the four display states of Designs/dialects-and-languages.html §3,
and they exist because the alphabet and the words are learned separately: a word you know reads in
English whether or not you can sound the letters out, and a word you do not know in an alphabet you
can read comes back as `ashan` — pronounceable, meaningless, and a thing a player can carry to an NPC
where a glyph blob is not.

A learned word is emitted as plain text with no class of its own, and that is the whole point rather
than an omission. It has to be indistinguishable from a word that was English all along, or the screen
quietly lists which words the author troubled to translate; a class would make that promise a CSS one,
which the next theme rule breaks in silence, and emitting nothing makes it structural. A romanisation
IS marked, because it costs nothing to mark: `ashan` is visibly not an English word whatever it is
wrapped in.

Two of §5's three teaching sources are here, and neither needs a model call. An item carries
`teachesScript` and `teachesWords`; `bilingual` is the Rosetta Stone and carries no word list at all,
because the pairing is the lexicon and a list beside it would be a second copy free to disagree with
the first. Its carving renders forced, so it stays in the world's letters however much the reader has
since learned — a stone is a thing whose text does not change with who is standing in front of it, and
one that dissolved into English once it had done its job would be a stone nobody could look at twice.
The NPC road is `teachWords` and stays in P4 with the rest of the Game Master's part.

The order of two lines in readBook is load-bearing: the page is drawn before the lesson is granted.
Reverse them and a primer that teaches its own alphabet can never be seen written in it, which is the
one image the whole system exists to produce.

P1's accessible name had to be corrected on the way. `role="img"` was right while every word in the
block was a shape and became wrong the moment one of them was not — an atomic role hides its own
subtree, so the words a reader had learned would have stopped being announced at all, and the reader
who most needs to hear the progress would have been the only one who could not. It is a
visually-hidden sentence inside the block now, and it says "partly" when the page is partly readable,
because a note claiming the whole thing is unreadable contradicts the four real words the same screen
reader is about to read out.

The editor grew a dictionary on the language card and a Tongue section on any book's. The dictionary
is one textarea rather than a row per word: a lexicon is not six fields but a hundred pairs, text
round-trips out of whatever the author already uses, and the count underneath is the load-bearing part
of the control — a paste in the wrong shape produces three entries and looks, in a textarea, exactly
like a paste that worked. Separators are generous and refusals are counted with the first offender
quoted. The Tongue section draws only when the world has a language, since a select reading "English"
and nothing else on every book of every world that never opened the tab is the opposite of an opt-in;
retagging a book back to English clears its three lessons with it, because a word list hanging off a
tongue the item no longer names grants nothing while the card goes on saying it teaches six words.

Tests/test_language_lexicon.js was written against fourteen sabotaged versions, each caught by a
distinct assertion. One defect it could not have found was found by rendering the page: a glyph is
drawn inside a 100-unit box with air on each side, so two letters of one word sat further apart than
two words did. The gaps came out backwards, the letters looked spaced, the words ran together, and a
page of shapes read as one unbroken stream rather than as writing. Every assertion over that markup
passed, because the markup was right.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

WIP on the branch, not main: the editor still treats a reagent as an item, so three of its tests fail
by design until the next commit. Everything else is green (835/838).

The three tiers. An INGREDIENT is a real item acquired by play — a dug root, a gland cut from a
corpse, a stone prised out of a burn-scar — bought, looted, one day foraged. A REAGENT is a
transformation of one: bone ground to dust, petals burnt to ash. It is not an item; it is a record in
world.reagents, and how many prepared measures a character holds is a count on the PLAYER. A
CONCOCTION is brewed from reagents and is an item again, which is where the magic ends up.

A reagent is not an item for a mechanical reason rather than an aesthetic one. acquireItem stacks
inventory entries by NAME ALONE and merges by bumping quantity, discarding the incoming item — so a
"prepared" flag on an item would be silently eaten the first time an unprepared one of the same name
arrived. A count on the character has nothing to merge with. The same constraint that put a
concoction's potency grade in its name puts a reagent's stock on the player.

It follows that the stock belongs to the character and not to the world: ITEM_CATALOG and
world.recipes ride serializeWorld and get published, so a stock on the record would mean two
characters in one world sharing a larder and a published world carrying whoever's stock was on hand
at export. Both new player fields — reagentStock and reagentsKnown — therefore need a backfill line in
the restore, because `player` is saved whole but rehydrated with reInstance, which copies the
snapshot's own keys onto the prototype and never runs the constructor. That is the player-side twin of
the three-place rule for world maps, and stats, languages, gallery and factions each carry such a line
already.

world.reagents itself takes the three-place registration: the World constructor, serializeWorld's
allowlist, and rebuildWorldFromSnapshot. Named in fewer, it is authored, saved perfectly and gone on
the next load, which is how this codebase lost its ailments once.

prepareReagent spends the ingredients and the hours and adds the reagent's own `yields` to the stock.
No roll, and that is a choice: the brewing one tier up rolls against a DC and a failure costs the
measures, because that is where the magic is. Grinding a dried root is craft. A second failure surface
between foraging and brewing would make the loop three chances to lose an afternoon rather than one.

The four shipped reagents split in two. Comfrey Root, Ember-Stone and Spider Gland stay as ingredients
and keep their `origin` — where a thing is got is a property of the thing — but lose their
`preparation`, which is now the business of the reagent above them. Grave-Salt moves up a tier, since
it already read as a prepared thing: a new Barrow Crust is what you scrape off the barrow wall, and
cleaning and drying it is the transformation. Knitbone Meal, Ember Grist and Cured Venom are new.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

Current Status claims to be a pass over every design document in the folder and had no row for
factions at all, which is the index's own §06 defect — a document disagreeing with itself — turned on
the index. It goes in §05, finished outright, rather than §04: there is no growth list left. What the
system wants is authored content, which is not a phase, and §08's sixteen playtesting notes, which are
observations a table makes rather than work a session does.

The row says what it is worth an index reader knowing, which is not the feature list: twenty-one
decisions settled and none open, and the unusual part is that the three which sat parked as growth
ideas — sponsorship, decay, rival orders — were all built rather than left. That is the shape §04
exists to describe, arrived at from the other direction.

Marked "added 10 Sep, after rev. 5", using the convention the page already had for a document that
landed after a pass: §04 carries "new to this page" and "added 20 Aug" for the same reason. The header
chip, the §05 opening sentence and the footer prose all move with it, and the historical "rev. 5"
references elsewhere on the page are left alone, since they name that pass rather than this one.

Two inconsistencies in the document the row points at went with it. Its lede still asked "the question
the system has not answered: how is a player supposed to climb it?" — written when that was true and
left standing through every decision that answered it, so the doc's first paragraph contradicted its
own status chips. And its three revision numbers had drifted apart: the eyebrow said 2, the footer said
1, the chip counted 21. Every sibling doc keeps the three in step; this one had been bumped only where
the chip is.

Not done, and worth naming rather than quietly leaving: the index lists 39 of the 52 other documents in
the folder. Thirteen more have never appeared on it. Backfilling those means reading each one and is a
pass of its own, not a side effect of this row.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

Two free-text lists of strings — an author's jotted quest hooks and little jobs — were normalized on
load, kept in the save, written to an export, and drawn as two read-only rows on the Dungeon Master's
card. Grep for another consumer and there was none. They never reached the Game Master, so an order's
own work was invisible to the only thing that could hand it out. That is the exact shape of the defect
this system had already hit twice: a faction's reputation and aggression were authored data with
nowhere to go until the dossier learnt to carry them, and a rank ladder was a screen until the dossier
learnt the same. A field that only the editor reads is a field the world does not have.

Deletion rather than a reader, because both things they gestured at are now really built and neither
is a list of strings. An order's work is a faction-bound quest thread carrying an id the engine unlocks
beats against; its small repeating work is a duty with a payout the engine pays. Re-pointing a
free-text list at ids would have silently redefined data some worlds already carry, which is why the
document refused to simply give them a reader, and once the real answer shipped the field had nothing
left to become.

The text is carried nowhere and the load that drops it says so. Guessing that an author's note belongs
in detailedDescription would mangle their prose, so the removal names what it found — the faction, the
list and the words themselves — in the Dungeon Master's log, with where that kind of thing lives now.
Silence would have been the same defect one step along: a field nobody reads, replaced by a deletion
nobody is told about. It reports the capitalized spellings too, since the normalizer accepted Quests
and Tasks for as long as it accepted the lowercase pair and a world written that way lost exactly the
same text. A world carrying them empty, which is every world written since they existed, says nothing.

The card's Quest hooks row goes with them, and that closes an older half-measure. The row was
relabelled rather than removed when the real Quests section arrived, because the two being one word
apart invited a DM to write a quest into the row and then wonder why no beat of it ever fired.
Relabelling was the smaller answer to that hazard; Quests is now the only thing on the card that says
quest. The Factions directive stops offering the fields in both places it listed them, and the
built-in world's template stops emitting the two empty arrays.

Verified on the real load path rather than only in a fixture: the shipped world's faction comes back
with eighteen keys and neither of these, loading it is silent, and a save doctored to carry both loses
the fields and nothing else — detailedDescription survives, the notice names both lists with their
words, and a re-serialize does not put them back.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX

P1's authoring half, and the first of Culture's six tabs to have anything behind it. A language card
carries a specimen, the fields, a grid of twenty-six letters and a sheet upload; the Game Master's road
in stays shut, because that is P4 and the roster behind it does not exist.

The specimen sits at the top of the card rather than the grid, which is the argument the design document
made before any of this was built: twenty-six shapes in isolation is exactly where an incoherent set
looks fine, because every letter is plausible on its own, and a stroke weight that wanders is obvious in
a second once the same letters are set as a sentence. It is forced to draw in the world's own letters
whatever the DM's character happens to know — they are reviewing an alphabet, not reading a book — and
that force is only ever a request for shapes. Nothing anywhere can ask the renderer for the plaintext.

Three things were decided at the keyboard rather than on the page. The editor writes THROUGH the
normalizer and never onto the record: a glyph path lands in a d="…" attribute and a sheet image in
mask-image: url("…"), and the guards P1 built for a world file arriving from somewhere else would have
been worth little beside an editor that assigned straight to the record. So setLanguageGlyph hands its
candidate to normalizeLanguageScript and keeps what comes back, which means one definition of what a
glyph may be and the same answer for an author as for an import. Every refusal says so out loud, because
a cell that stays blank after a paste reads as a broken editor and a picked file that vanishes reads as a
broken button — and the likeliest cause of the second is an SVG, which is not a raster and cannot be cut
into cells, so it is named rather than left to be guessed. And removing a language names the written
items it turns back into English, since that is the right fallback and a surprising one to meet by
accident.

Not built, and recorded as not built: dropping an image onto a single letter. Per-letter raster is the
sheet's job done twenty-six times and the sheet exists, so a letter takes path data or nothing.

Writing the test found a defect in the same commit's code, which is the argument for writing it that way.
The speakers box splits what an author types into races and orders, and the first draft asked a function
called `allRaces` that does not exist — behind a `typeof` guard, which turned a crash into a wrong answer
where every speaker became an order and no race was ever recognised. It reads worldRaces() now, and the
comment says why a typeof guard around a function that is supposed to be there is worse than no guard.

test_culture_editor_tab.js moves rather than loosens, which is what it was written for: its
disabled-control count carried the note that "the first one that goes live fails a build and asks whether
the record it writes to exists yet". Languages went live and world.languages exists, so the answer is
yes. The five that are still furniture keep the count and the no-handler sweep, unchanged; the live one
gains assertions that its filter, its + New and its shared Export/Import are wired — and that its GM box
is still disabled. Its switcher assertion changes shape for the same reason: "dispatches to no renderer"
was right while all six were placeholders, and the property underneath it was always that a name in the
switcher RESOLVES, since a throw there takes every Culture tab down and not only the one clicked.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VEwTaUAf75q8V1DkQZUknh

It shipped as type "consumable", which was true of what it does and wrong about what it is: a potion
is bought and a concoction is worked. `concoction` is an item type of its own now, with its own forms
— salve, dust, oil, draught — and the note that the form decides delivery, which is the rule §06 of
Designs/reagents-and-concoctions.html already states. That is what gives it a shelf of its own in a
pack, a heading of its own on the Inventory tab, and its own glyph in the Item Editor's dropdown.

It carries "magic" among its SUBTYPES and does not set the `magic` flag, and the difference is the
whole of the arrangement rather than a detail of it. isMagicItem reads the flag, and the flag is what
routes an item to Editor › Magic › Items and onto the Compendium's Magic shelf. Earth magic is magic —
§01's argument is that the origin differs and the magic does not — so it says so where a reader looks.
But it has a tab of its own, and a second home would be two cards for one record. Setting the flag
instead would look identical on the card and put every concoction on the wrong tab, which is why the
test asserts both halves: not a magic item, and a concoction that DOES set the flag lands there, so
the exclusion is real rather than an empty tab.

Retyping moves a thing between rules, and two of those moves mattered. The suite caught the first
within the hour: the evaluation's opening-kit fallback excluded `consumable`, so leaving that type
made a 14c salve and a 22c pouch of dust "the two cheapest purchases" again — dropping the built-in
world's entry budget from 1400c to 36c and silently clearing a warning that the world was too poor to
equip anybody. That is the exact hole test_decision_branches was written to catch, reopened by a
rename, and the rule names `concoction` now. The second was deliberate: CONSUMABLE_EFFECT_TYPES gains
it too, because a concoction is spent in the using and the one item type that exists to DO something
to whoever uses it should be able to say what. test_item_type_staff caught the third — the icon map is
what fills the Item Editor's dropdown, and a taxonomy type missing from it is offered to the GM and
unreachable by the DM, which is how `contraption` sat invisible for years.

Reagents get a pack shelf too, by a different route. A reagent's type is whatever the thing naturally
is — a misc mineral, a plant root, an animal gland — and only its subtype says it is an ingredient, so
the Inventory tab pulls them out by SUBTYPE ahead of its taxonomy walk, the way spellbooks are pulled
out ahead of it. Left to the walk they shelve under Miscellany with the rope and the tinderbox, which
is the one arrangement that makes a brewer's pack unreadable. Concoctions needed nothing there: they
are a type, so the walk finds them and heads them from the taxonomy's own label.

Ten sabotages, each caught by a distinct named assertion. One needed a second pass and it is a
mistake worth recording: the opening-kit assertion searched the whole `cannotBeAKit` block for the
word "concoction" and passed on the COMMENT that explains why concoctions are in the rule, after the
rule itself had lost them. It matches the type test alone now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qy47HUNwW15ma9AtUAci4x

The fork table argues OWNERSHIP — a quest exists whether or not anybody accepts it, a task is a thing
this character agreed to do — and says outright that the difference is not in size. That is still the
right answer to the question it was asked, which was why the two need separate data models, and it is
not the whole answer to why they need separate words. There is a second axis and it turns out to be
the one a player actually uses.

A quest is a narrative backbone: the plot, the big turns, the larger rewards, the spine the story runs
along. A task is a small, one-and-done request from a person or an order — an errand, a watch, a tally
fetched back, a responsibility somebody trusted you with. The scope is inherent in the words and
always was; the table had no reason to say so while it was answering a question about world.quests
versus player.tasks.

The consequential half is that a player may ignore tasks entirely. Somebody who wants only the grand
story can play the whole game and never accept an errand, and that is a complete way to play rather
than a way of missing content. Everything the two systems already do is consistent with that and none
of it was designed for it, which is worth recording: a duty pays XP and standing and deliberately no
coin, a task is a checkbox nobody else reads, and the climb runs on quests precisely so that an
order's story is never locked behind its chores.

It settles one thing in the negative. A single player-facing list of everything the player has been
asked to do, folding faction quests in beside tasks under one word, was raised earlier and is refused:
it would flatten exactly the distinction the player uses to decide what to care about, since the two
lists answer different questions — where is the story, and what do I owe people — and a reader who
wants only the first should not have to filter the second out of it.

Promotion is the one deliberate crossing and is the better for all of this. An errand that turns out
to be bigger stops being an errand rather than becoming quest-shaped, and it lands as a surprise
precisely because the separation is real: a player who has learnt that tasks are small, optional and
one-and-done is the player for whom the tenth courier run turning into a conspiracy actually works.
Flatten the two words and the surprise has nothing to be a surprise against, which is the other half
of rule 10d's PROMOTE RARELY.

And it puts something on the Game Master, in rule 13c beside the rule that lets an order set a duty at
all. A player who declines errands, leaves them untouched in the Journal and steers every conversation
back to the barrow has said what they came for, and setting more work in front of them is arguing with
it. Offer less, not more insistently. That is the asking rule read from the other side: an order asks
when the fiction offers an opening, and a player who is plainly not interested is not an opening.

The Field Guide now says the same thing to the player, which it never did — its Tasks section was all
mechanics and never told them what a task is relative to a quest, still less that nothing in the story
is locked behind one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RrTNHox1QYWFZEzJGwj3WX