check-scenarios resolves every skill a scenario NAMES against the catalogue, which is a different question from whether anybody present can roll it. CLEAN GROUND shipped four commits with three clues gated on Track (base 10), Navigate (base 10) and Science (Botany) — base 1, so the 1% floor was the whole of it — and every guard passed, because all three are perfectly real skills. A desk playtest found it by auditing the acts against the sheets the scenario casts. That audit is mechanical, so it belongs in the build. Two tiers. Corpus-wide, some roster agent must reach VIABLE for every skill any scenario names. Per scenario, a document that DECLARES its cast is held to that cast instead, and that is the tier that catches this defect class. The cast is declared rather than inferred, and that is the interesting part. The first version scraped pc_ keys out of the prose and swept up the substitutes named in CLEAN GROUND's player-count scaling — a cast of nine instead of six, which put Sandoval and his Track 35 in scope and made the guard pass the very bug it was written for. A guard that guesses the cast is worse than none, because it reports success. CLEAN GROUND now carries a cast comment and the guard reads it off the raw text, since scenarioText strips HTML comments. Verified load-bearing rather than assumed: re-injecting the original Track tag into the real CLEAN_GROUND.md fails the guard, naming the skill, the base chance and the declared cast. Worth recording that the corpus-wide tier would never have caught it — Lindqvist trains Botany at 40, so it is rollable by the roster and simply not by the six who were cast. The first fixture test passed for that reason and misled me; only the declared-cast tier finds this. VIABLE is 25 and is justified, not picked: it is the commonest base chance in the catalogue, what an untrained agent brings to Spot, Listen or Brawl, so it is the level the game itself treats as worth attempting. Below it a clue is not gated, it is buried. check-scenarios exports its tag parser rather than growing a second copy, behind the invokedDirectly pattern simulate.mjs already uses; a duplicated parser is exactly what this repository's one standing law forbids. update-readme then caught me fairly — it cross-checks the advertised guard list against npm run check — so the guard is registered there too and the README advertises eleven in all three places. No REVIEW_LOG entry: the log is clean at R-260 and is being appended to every few minutes by concurrent work, so the end of that file is the likeliest place to collide. Left for whoever next touches it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
28 lines
1.1 KiB
JSON
28 lines
1.1 KiB
JSON
{
|
|
"name": "ringbrp",
|
|
"version": "0.9.0",
|
|
"description": "The Custodians — a Basic Roleplaying game of crossings, for Foundry VTT",
|
|
"main": "ringbrp.mjs",
|
|
"scripts": {
|
|
"build": "node tools/build-packs.mjs && node tools/update-readme.mjs",
|
|
"icons": "node tools/make-icons.mjs",
|
|
"portraits": "node tools/make-portraits.mjs",
|
|
"bestiary": "node tools/bestiary.mjs",
|
|
"mj": "node tools/mj-queue.mjs",
|
|
"simulate": "node tools/simulate.mjs",
|
|
"check": "bun tools/check-rules.mjs && bun tools/check-kits.mjs && bun tools/check-lang.mjs && bun tools/check-templates.mjs && bun tools/check-behaviour.mjs && bun tools/check-scenarios.mjs && bun tools/check-rollable.mjs && bun tools/check-creatures.mjs && bun tools/check-anatomy.mjs && bun tools/check-lethality.mjs && bun tools/check-bestiary.mjs",
|
|
"test": "bun run check",
|
|
"readme": "bun tools/update-readme.mjs"
|
|
},
|
|
"keywords": [],
|
|
"author": "Tim Evans (slaguru666)",
|
|
"license": "SEE LICENSE.txt",
|
|
"type": "commonjs",
|
|
"dependencies": {
|
|
"classic-level": "^3.0.0"
|
|
},
|
|
"devDependencies": {
|
|
"handlebars": "^4.7.9"
|
|
}
|
|
}
|