feat(api): record which setting a case came from - #17
Merged
Conversation
A seed identifies a case only together with the generator version and the setting. There is one setting today, so nothing is ambiguous yet — which is exactly why this is cheap now and a migration later. The moment a second setting exists, seed 42 means two different mysteries. Reproducibility is the whole premise of ADR-0004: every eval runs five times because temperature makes one run inconclusive, and that only measures the model if the case underneath is fixed. Without the setting recorded, baselines would silently compare cases that are not the same case, and a stored case would have no way to say which catalog renders it. CaseVeneer carries it too, for the same reason: prose is written for one world, and a cached veneer must not be reused for a different one that happened to share a seed. Nothing else changes. The generator still builds only the manor, and grouping its constants into a `Setting` object is phase 8 work — recorded in the roadmap, along with the glossary entry that gives the term a name in both vocabularies.
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
1 participant
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.
One field, added now because it is five minutes today and a migration later.
The gap
Caserecordsseedandgenerator_version. It does not record which world itwas built from — and today that is fine, because there is exactly one.
The day a second setting exists, seed 42 means two different mysteries. That
breaks something load-bearing rather than cosmetic:
on determinism. Every eval runs five times because temperature makes a single
run inconclusive; that only isolates the model if the case underneath is
fixed.
difference as a model regression.
CaseVeneercarries it for the same reason: prose is written for one world, anda cached veneer must not be reused for another that shares a seed.
What it does not do
It does not build the feature. The generator still knows exactly one world, and
its constants — rooms, cast, means, secrets — stay module-level. Grouping them
into a
Settingobject is phase 8, now written into the roadmap alongside"cenários além da mansão (outros países e épocas)".
Worth restating from the conversation that prompted this: the solver, the
validator and the rules need no change for a second setting. They reason over
ids and never over what a room is. That is why this is one field and not a
refactor.
The test
It asserts a habit rather than catching a bug — there is one setting, so nothing
can be wrong yet. The docstring says so plainly, because a test that looks
tautological deserves an explanation of the failure it is placed there to catch.
openapi.jsonis unchanged:Caseis not on the API surface yet.Closes #5.