diff --git a/memory/projects/projects-MacMem/MEMORY.md b/memory/projects/projects-MacMem/MEMORY.md index d924980..4dd6cfc 100644 --- a/memory/projects/projects-MacMem/MEMORY.md +++ b/memory/projects/projects-MacMem/MEMORY.md @@ -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 diff --git a/memory/projects/projects-MacMem/codex-ops-kit-installer-bugs.md b/memory/projects/projects-MacMem/codex-ops-kit-installer-bugs.md new file mode 100644 index 0000000..6183105 --- /dev/null +++ b/memory/projects/projects-MacMem/codex-ops-kit-installer-bugs.md @@ -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 ` while `config.toml` holds a legacy `profile = "..."` selector or +`[profiles.]` tables. Profiles now live in `~/.codex/.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//`. Related: +[[claude-config-sync-gotchas]]. diff --git a/memory/projects/projects-MacMem/vanity-forge-exists.md b/memory/projects/projects-MacMem/vanity-forge-exists.md new file mode 100644 index 0000000..71655bb --- /dev/null +++ b/memory/projects/projects-MacMem/vanity-forge-exists.md @@ -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]]. diff --git a/memory/projects/projects-MacMem/vanity-foundry-install.md b/memory/projects/projects-MacMem/vanity-foundry-install.md new file mode 100644 index 0000000..93ef564 --- /dev/null +++ b/memory/projects/projects-MacMem/vanity-foundry-install.md @@ -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]]. diff --git a/skills/rpg/references/lessons.md b/skills/rpg/references/lessons.md index 8e16811..d79488a 100644 --- a/skills/rpg/references/lessons.md +++ b/skills/rpg/references/lessons.md @@ -11,6 +11,33 @@ grows into a duplicate of the skill. Several 2026-07 entries below are already encoded in the references; they stay as worked examples until the next pruning pass. +## 2026-08 — DEAD AIR build (Things from the Flood, 3-hour variant) + +- **A sequel system is a different system — verify the core loop before + writing the crash-course.** Things from the Flood looks like Tales from the + Loop and isn't: **Luck Points are gone**, **Pride is replaced by Shame** + (once per session, automatic success for acting *against* it), **Scars** are + permanent and the second one can remove a teen from play — the "kids can't + die" guarantee is off. Writing the GM Essentials block from memory of the + parent game would have shipped four wrong rules. Check the build numbers too + (Flood: 14 attribute points, 10 skill points, keys ≤3, non-keys ≤1). +- **When lore can't be verified, make the scenario canon-local and say so in a + numbered Design-Intent line.** Anchoring only to what's confirmed published + (Boulder City, the DART Loop, the Gravitron, the Bona Reactor) and inventing + every site, org and NPC means the Mystery drops into any table's version of + the setting with nothing to reconcile — and it stops the writer bluffing + setting detail they haven't got. +- **The 3-hour cut of the house format** (proven shape, not a guess at the + table yet): Intro 15 · Act One 45 · break 5 · Act Two 60 · Act Three 30 · + Epilogue 15 = 2:45 play inside a 3:00 cap, hard rule at **2:00** instead of + 2:45. What gets cut to make it fit is *breadth*, never structure — one split + with two sites, one journey, one set-piece, one room. Act Three keeps its + full 30 minutes; it is the only budget that must not shrink. +- **In a system where PCs can be permanently maimed, announce the stakes of + the set-piece before the first roll.** "Nobody dies here; failure costs + Conditions, and the fifth Condition is permanent" turns a swim into a real + decision instead of a dice formality. + ## 2026-07 — AFTERIMAGE desk playtests (Blade Runner, Continuum 2026) - **Answer the obvious professional move.** Players will always try the