rpg skill: Things from the Flood lessons (sequel-system rules drift, canon-local fallback, 3-hour act budgets)
This commit is contained in:
slaguru666
@@ -4,4 +4,7 @@
|
||||
- [ForgeRPG project state](forgerpg.md) — P6 + cloud art live on prod; OpenAI AND Gemini art proven e2e everywhere; SD paused (memory pressure)
|
||||
- [Continuum 2026 deploy topology](continuum-deploy.md) — con-app subdomains on VPS 77.68.99.134; Caddy + docker `proxy` net; how to ship + the graphiti-server host-key caveat
|
||||
- [claude-config sync gotchas](claude-config-sync-gotchas.md) — 3-machine fleet; settings.json and memory overwrite rather than merge; GitHub MCP now OAuth remote, no PAT
|
||||
- [VANITY already ships "the Forge"](vanity-forge-exists.md) — stage/map, encounter, hoard, monster, adventure generators already in vanity.mjs; check before building any generator
|
||||
- [VANITY on Foundry (Mac install)](vanity-foundry-install.md) — Mac data path ≠ CLAUDE.md's Linux one; VRPG `dist/` zips are stale, install from the git tree
|
||||
- [codex-ops-kit installer bugs](codex-ops-kit-installer-bugs.md) — its merge deleted Codex's own config state and misfiled root keys; fixed, plus the ≥0.146 profile-file migration
|
||||
- [Clairvoyance MCP needs the app open](clairvoyance-mcp-needs-app.md) — "Failed to connect" is normal when the desktop app is closed; not a broken install
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
name: codex-ops-kit-installer-bugs
|
||||
description: "codex-ops-kit's install script destroyed Codex's own config state and misfiled root keys under a table; both fixed 2026-08-04, plus the profile format migration"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: c4d6262b-e105-4e05-87bf-f2f891e7df82
|
||||
modified: 2026-08-04T22:08:23.936Z
|
||||
---
|
||||
|
||||
`~/codex-ops-kit/scripts/install_codex_kit.sh` merges a managed block into
|
||||
`~/.codex/config.toml`. On 2026-08-04 it had **three** faults, all fixed. Re-read this before
|
||||
touching that script — the failure mode is silent data loss.
|
||||
|
||||
1. **It deleted everything after the managed block.** The merge did
|
||||
`before = text.split(managed_start, 1)[0]` and wrote `before + block`, discarding all content
|
||||
below the block. That is exactly where Codex writes its own `[plugins.*]`, `[projects.*]`,
|
||||
`[marketplaces.*]` and `[mcp_servers.*]` state. A single reinstall took the live config from
|
||||
142 lines / 32 sections to 37 / 2. Fixed: keep `head`, `interior` and `tail`.
|
||||
|
||||
2. **The block's interior had swallowed real state.** Over past runs the `managed_end` marker
|
||||
drifted to line 88, so plugins/projects/marketplaces/`mcp_servers.graphiti` sat *inside* the
|
||||
block. Dropping the interior wholesale therefore also deleted them. Fixed: the interior is
|
||||
**filtered** (strip only keys/sections the kit owns), never discarded — which makes the layout
|
||||
self-heal on the next run.
|
||||
|
||||
3. **Root keys were being filed under a table.** The block was appended at the end, so its bare
|
||||
keys (`model`, `profile`, `web_search`, …) landed below `[sandbox_workspace_write]` and TOML
|
||||
bound them to *that table*. `profile = "balanced"` was therefore never a root selector at all.
|
||||
Fixed: write `preserved_root`, then the block, then `preserved_tables`, so bare keys always
|
||||
precede the first `[table]`.
|
||||
|
||||
**Profile format migration (the reason this surfaced).** Codex ≥ 0.146 refuses
|
||||
`--profile <name>` while `config.toml` holds a legacy `profile = "..."` selector or
|
||||
`[profiles.<name>]` tables. Profiles now live in `~/.codex/<name>.config.toml`. The kit gained
|
||||
`templates/global/profiles/{economy,balanced,deep}.config.toml`, the installer copies them, and
|
||||
`profile`/`profiles.*` stay in the merge's managed lists **purely so old installs get cleaned
|
||||
up**. Live values preserved: economy `gpt-5.4-mini`/low, balanced `gpt-5.5`/medium, deep
|
||||
`gpt-5.4`/high — note **deep's model is weaker than balanced's**, which looks like stale config
|
||||
worth revisiting.
|
||||
|
||||
**Also:** `config.toml` has three writers — Codex itself, **Clairvoyance** ("do not edit the
|
||||
[clairvoyance] section manually"), and this kit. That is why duplicate `model` keys appeared.
|
||||
Root model is now `gpt-5.6-sol`, set once.
|
||||
|
||||
**Two separate faults blocked Codex entirely that day:** the profile format above, *and* CLI
|
||||
0.142.3 being too old for its configured model (`400: The 'gpt-5.6-sol' model requires a newer
|
||||
version of Codex`). `npm install -g @openai/codex` → 0.146.0 fixed the second.
|
||||
|
||||
**Why:** CLAUDE.md says to edit kit templates rather than live files, which is right — but the
|
||||
installer applying them was itself destructive, so "just re-run install.sh" was unsafe advice.
|
||||
|
||||
**How to apply:** always diff `~/.codex/config.toml` section counts before and after running the
|
||||
installer. Its own backups land in `~/.codex/backups/<stamp>/`. Related:
|
||||
[[claude-config-sync-gotchas]].
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: vanity-forge-exists
|
||||
description: "VANITY's vanity.mjs already ships a full generator suite (stage/map, encounter, hoard, monster, NPC, hero, adventure) — check it before building any VANITY generator"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: c4d6262b-e105-4e05-87bf-f2f891e7df82
|
||||
modified: 2026-08-04T21:53:20.458Z
|
||||
---
|
||||
|
||||
Before writing **any** generator for VANITY, read `systems/vanity/vanity.mjs`. It already
|
||||
contains "the Forge", and it is far bigger than the compendia suggest:
|
||||
|
||||
| Function | Line | Does |
|
||||
|---|---|---|
|
||||
| `forgeStage()` | 2714 | **Map + scene generator.** Types `barrow · cave · fen · village · forest`, sizes; layout → `stageWalls` → `stageSVG` → raster/upload → `Scene.create`; optional `populate` + `heat` |
|
||||
| `forgeEncounter()` | 2875 | Monster pool by type, heat composition (`skirmish · fight · battle · nightmare` via `HEAT_BUILDS`), situation/terrain/complication tables, **2d6 Reaction mood roll**, ambush, auto-hoard, GM-whispered card |
|
||||
| `forgeHoard()` | 1958 | Hoard tiers `pocket · cache · chest · vault · kingly`, relic chance in richer tiers |
|
||||
| `forgeMonster` / `forgeFace` / `forgeHero` | 1796 / 1866 / 1633 | Actor generation |
|
||||
| `forgeAdventure()` | 3113 | Chains stage + encounter + hoard |
|
||||
| `carouse()` / `stageVainCrown()` | 2916 / 3259 | §27 carousing; builds the shipped adventure |
|
||||
|
||||
The `vanity-stage/*.png` files shipped with The Vain Crown were produced by `forgeStage` — that
|
||||
is what the directory name means. It is VANITY-native and already correct on Foundry v14.
|
||||
|
||||
Two constraints on reusing it:
|
||||
|
||||
- Everything uses `Math.random` (`vanity.mjs:1548`) and creates Foundry documents directly, so
|
||||
it is **not seed-reproducible** and not callable outside Foundry. Any tool wanting determinism
|
||||
must either extract the data tables or make the Forge injectable.
|
||||
- None of it is a public API — no `game.vanity.forge*` surface — so an external module would be
|
||||
reaching into system internals.
|
||||
|
||||
**Why:** it is invisible from the compendium list, and the obvious move (build a generator) means
|
||||
writing a fourth duplicate of code that already works. This finding shrank the DELVE design from
|
||||
"build generators" to "sequence the existing ones" — see [[vanity-delve-design]].
|
||||
|
||||
**How to apply:** grep `vanity.mjs` for `function forge` first. Related:
|
||||
[[vanity-foundry-install]].
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
name: vanity-foundry-install
|
||||
description: "VANITY on Foundry — Mac data path differs from the Linux one in CLAUDE.md, and foundry/dist/*.zip in VRPG is stale; install from the git tree"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: c4d6262b-e105-4e05-87bf-f2f891e7df82
|
||||
modified: 2026-08-04T21:29:22.480Z
|
||||
---
|
||||
|
||||
VANITY runs on Foundry VTT as a **system** (`vanity`), not a world. Two repos carry it and
|
||||
`VRPG/sync.sh` publishes one to the other, so they stay in lockstep at the same version:
|
||||
|
||||
- **`slaguru666/VRPG`** (private) — rules drafts, rulebook, art, plus `foundry/vanity/`
|
||||
(the system), `foundry/worlds/the-vain-crown/` (the ready-made world) and
|
||||
`foundry/vanity-stage/` (generated battlemap PNGs the scenes point at).
|
||||
- **`slaguru666/Vanity`** (public) — the published runtime system only, installable by manifest:
|
||||
`https://raw.githubusercontent.com/slaguru666/Vanity/main/system.json`
|
||||
|
||||
Two traps, both hit on 2026-08-04 installing v0.10.3 on the MacBook Air:
|
||||
|
||||
1. **`foundry/dist/vanity.zip` and `vrpg-foundry-full.zip` are stale.** `INSTALL-REMOTE.md`
|
||||
describes them as v0.9.0 and the zip really does contain v0.9.0, while the git tree was at
|
||||
v0.10.3. The zips are not rebuilt on release — **install from the git tree, not `dist/`**,
|
||||
whenever "latest" matters.
|
||||
|
||||
2. **The Mac data path is not the one in CLAUDE.md.** That file records
|
||||
`~/FoundryVTT/Data/...`, which is the Linux/MINI-S layout. On this Mac Foundry uses
|
||||
`~/Library/Application Support/FoundryVTT/Data/` (confirmed via `Config/options.json`
|
||||
→ `dataPath`). `~/FoundryVTT` does not exist here.
|
||||
|
||||
Three things must land, and the world alone is not enough:
|
||||
|
||||
Data/systems/vanity/ the system
|
||||
Data/worlds/the-vain-crown/ the world
|
||||
Data/vanity-stage/ battlemap PNGs
|
||||
|
||||
Scene backgrounds are stored as paths **relative to `Data/`** (e.g.
|
||||
`vanity-stage/the-salt-throat-1783978801989.png`), so `vanity-stage/` must sit at the `Data/`
|
||||
root or every map renders blank.
|
||||
|
||||
**Why:** the zips look like the official artefact and the CLAUDE.md path looks authoritative;
|
||||
both quietly give you a stale or broken install.
|
||||
|
||||
**How to apply:** clone VRPG, `rsync` those three directories into the Mac data dir, restart
|
||||
Foundry. Verify by reading the LevelDB with the app's bundled `classic-level` — `grep`/`strings`
|
||||
cannot see inside, values are Snappy-compressed. Always read from a **copy**: opening a pack
|
||||
read-write compacts it and dirties the working tree.
|
||||
|
||||
## Map/scene modules on this Mac (2026-08-04)
|
||||
|
||||
`mapwright` v0.5.0 installed from its GitHub release — `compatibility.maximum: "14"`, so it runs
|
||||
on Foundry 14.365. It is the live map generator; `quick-battlemap-builder` and
|
||||
`scifi-deckplan-generator` are its superseded predecessors.
|
||||
|
||||
`quick-battlemap-builder` v0.3.0 was also installed on request, but **it cannot work on v14 as
|
||||
shipped**, for two independent reasons:
|
||||
|
||||
1. `compatibility.maximum: "13"` — Foundry 14 refuses to enable it outright.
|
||||
2. Even if that is bumped, `quick-battlemap-builder.mjs:395` does
|
||||
`sceneData.background = { src }`, the v13 pattern. In v14 the background moved to the scene's
|
||||
default **Level**, so generated scenes come out **blank**. The real fix is to mirror
|
||||
mapwright's `applyBackground()` (`module/lib/scene.mjs:107`,
|
||||
`scene.updateEmbeddedDocuments("Level", [{_id, background:{src,color}}])`).
|
||||
|
||||
Its `FilePicker` use is already v14-safe (line 1424 falls back through
|
||||
`foundry.applications?.apps?.FilePicker?.implementation`), so that is *not* a blocker — only the
|
||||
background write and the manifest ceiling are.
|
||||
|
||||
Related: [[claude-config-sync-gotchas]], [[tims-rpg-games]].
|
||||
Reference in New Issue
Block a user