Skip to content

Reproducing a stored session's blob requires pinning IdSource.newGameId #280

Description

@The-Running-Dev

Reproducing a stored session's blob requires pinning IdSource.newGameId

The default mints a fresh crypto.randomUUID() per createGame, so replaying a real
session's action log from scratch can never byte-match its stored blob unless the host
injects an IdSource returning the original gameId. 07-replay.md's oracle never hit this
because fixtures are inputs with no prior identity; a stored session has one. Adventures
builds a second Engine per replay for exactly this.

Found by the first downstream host — see design/90-decisions.md, Found by the first
downstream host — SubZeroDev.Adventures
.

Done when

  • The contract (06-extensibility.md and/or 07-replay.md) states explicitly that
    reproducing a stored session's exact blob from its action log requires an IdSource
    pinned to the original gameId, so a second host doesn't have to rediscover this by
    building its own second Engine.

Agent instructions
  • Authority: this issue, since the bullet no longer lives in design/90-decisions.md's
    open register (Found by the first downstream host).
  • Stop if: the fix turns out to need more than documenting the existing mechanism — e.g. a
    new store operation — surface that rather than assuming docs-only.

Metadata

Metadata

Assignees

No one assigned

    Labels

    openOpen work tracked from the canonical design register

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions