fix(writers-room): align settings stage key with renamed places template#265
Merged
Conversation
Commit be90356 renamed writers-room-settings.md → writers-room-places.md but left the stage-config key and two code references pointing at the old name, causing 'Template for writers-room-settings not found' at runtime. Rename the stage-config key + the two server lookups, and add migration 017 to rename the key in existing installs. The broader BIBLE_KIND.SETTING → PLACE rename stays deferred (PLAN.md).
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes the Writers Room settings/world-bible extraction by aligning server-side stage lookups and seeded prompt config with the renamed writers-room-places prompt template.
Changes:
- Updates Writers Room settings extraction stage references from
writers-room-settingstowriters-room-places. - Updates
data.samplestage config to seed the renamed stage key. - Adds migration 018 to rename existing installed stage-config entries.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
server/services/writersRoom/evaluator.js |
Updates the Writers Room settings stage metadata to use the places template key. |
server/lib/bibleExtractor.js |
Maps BIBLE_KIND.SETTING extraction to writers-room-places. |
scripts/migrations/018-rename-writers-room-settings-stage.js |
Adds an installed-data migration for the stage-config key rename. |
data.sample/prompts/stage-config.json |
Seeds fresh installs with the renamed writers-room-places stage key. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
setup-data.js runs before migrations and auto-seeds writers-room-places with sample defaults when an existing install still has the legacy writers-room-settings key. The original migration kept that auto-seeded entry and discarded the legacy one, silently losing any user-customized model/provider/variables on writers-room-settings. Detect the byte-for-byte sample-default case and prefer the legacy entry's value in that path. When the installed writers-room-places differs from the sample default, treat that as a deliberate user edit and respect it (discard the legacy entry, same as before). Co-Authored-By: Claude Opus 4.7 <[email protected]>
Copilot review pointed out that the previous fix only preserved customizations in the stage-config entry. setup-data.js's ensureSampleContent will also auto-seed data/prompts/stages/writers-room-places.md from data.sample, leaving any user-customized writers-room-settings.md orphaned and unused after the stage-key rename. Mirror the same conflict-resolution policy for the .md template: - legacy file exists, …-places.md matches sample default (auto-seeded), legacy differs from sample → preserve legacy content as …-places.md and warn the user that migration 007's intExt / timeOfDay updates need manual merge. - …-places.md differs from sample → user-customized, keep it as-is. - …-places.md missing → promote legacy file directly. - always remove the now-orphan writers-room-settings.md. Run before the stage-config rename so an orphan prompt file is cleaned up even when the stage-key is already on …-places. Co-Authored-By: Claude Opus 4.7 <[email protected]>
…hash Migration 018's prompt-file branch previously treated any difference between the legacy `…-settings.md` and the current sample as a "user customization", then promoted the legacy content over the freshly seeded `…-places.md`. For installs that never ran migration 007, the unmodified legacy file is *expected* to differ from the current sample (which has 007's intExt/timeOfDay fields), so this would silently overwrite the modern template with an older default and require manual re-merge of a migration the user did not customize. Mirror migration 007's approach: embed the pre-rename shipped baseline hash (`7f1f80eb…` — equal to migration 007's OLD_SHIPPED_MD5 for the renamed file, since be90356 only renamed, no content change). When the legacy file hashes to that baseline, treat it as unmodified-default and keep the freshly seeded modern sample. Only diverging hashes count as customizations and trigger the legacy-content preservation branch. Co-Authored-By: Claude Opus 4.7 <[email protected]>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
scripts/migrations/018-rename-writers-room-settings-stage.js:135
- When
writers-room-places.mdis missing, this always promotes the legacy file. For an unmodified legacy prompt, that installs the older pre-rename/pre-007 template instead of the current sample, so users who run migrations without first running setup keep missing the currentintExt/timeOfDayschema. Use the current sample when the legacy file matches the old shipped baseline, and reserve promotion for actually customized legacy content.
// `…-places.md` missing entirely (setup-data didn't run) — promote
// the legacy file in place rather than dropping the user's content.
await writeFile(newPath, legacyContent);
console.log(`📝 ${PROMPTS_STAGES_DIR_REL}/${NEW_PROMPT_FILE}: promoted from legacy ${LEGACY_PROMPT_FILE}`);
…anch The setup-data-skipped branch (where `…-places.md` doesn't exist) was unconditionally promoting the legacy file. For an unmodified pre-rename baseline (a user who never ran migration 007), that installs the older default instead of the current sample — regressing 007's intExt / timeOfDay schema. Apply the same `LEGACY_PROMPT_SHIPPED_MD5` baseline check here too: if the legacy file is the unmodified shipped baseline AND a current sample is available, install the sample. Only promote legacy content when it actually diverges from the baseline (real user customizations) or when no sample is available to fall back to. Co-Authored-By: Claude Opus 4.7 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ServerError: Template for writers-room-settings not foundwas being thrown on every Writers Room settings/world-bible extraction. Commit be90356 (Universe Builder rename) renamedwriters-room-settings.md→writers-room-places.mdbut explicitly deferred the corresponding stage-key + bible-kind rename; the stage-key half is what's biting at runtime.stage-config.jsonkey + two server-side stage-name lookups with the on-disk template (writers-room-places), and add migration 018 to rename the key in users' installeddata/prompts/stage-config.json.BIBLE_KIND.SETTING → BIBLE_KIND.PLACErename stays deferred (PLAN.md:41) — that one touches ~20 files and is a separate change. This PR is the minimal fix to stop the runtime error.Why minimal scope
The commit-message of be90356 spells out the rename was split for reviewability. The internal
BIBLE_KIND.SETTINGenum andseries.settingsfield are unaffected here — only the stage-name string that gets looked up againstdata/prompts/stages/*.mdwas wrong. After this PR,bibleExtractor.jsmapsBIBLE_KIND.SETTING → 'writers-room-places', which is intentionally asymmetric until the deferred follow-up lands.Test plan
cd server && npx vitest run— 5085 passed / 5 skipped, no regressions📝 … renamed writers-room-settings → writers-room-places; idempotent path produced✅ … already on writers-room-places, no changes❌ Route error: Template for writers-room-settings not foundno longer fires when running a Writers Room settings/world-bible extraction