PR 64 — User-defined world modes - #64
Conversation
Reviewer's GuideAdds user-defined world modes as immutable, world-local, framing-only configurations, wired into the persistent world API, council sessions, and receipt verification with strong isolation, immutability, and security boundaries, plus tests and docs. Sequence diagram for world.mode.define user mode creationsequenceDiagram
actor Client
participant PersistentWorldAPI
participant UserModeService
participant Geometry
participant WorldStore
Client->>PersistentWorldAPI: handle({operation: world.mode.define, mode_id, label, description, prompt_instruction, region_id})
PersistentWorldAPI->>PersistentWorldAPI: _require_exact_fields(...)
PersistentWorldAPI->>UserModeService: define_mode(mode_id, label, description, prompt_instruction, region_id)
UserModeService->>UserModeService: _payload_from_inputs(...)
UserModeService->>Geometry: region(region_id)
Geometry-->>UserModeService: region validated
UserModeService->>UserModeService: _definition_lock()
UserModeService->>UserModeService: _definition_map()
UserModeService->>WorldStore: inspect(object_ref*)
WorldStore-->>UserModeService: WorldObject*
alt existing definition with same payload
UserModeService-->>PersistentWorldAPI: {created: False, definition_ref, mode, ...}
else no existing definition
UserModeService->>WorldStore: create_object(USER_MODE_OBJECT_TYPE, payload, provenance)
WorldStore-->>UserModeService: WorldObject(definition_ref)
UserModeService->>UserModeService: _mode_from_object(...)
UserModeService-->>PersistentWorldAPI: {created: True, definition_ref, mode, ...}
end
PersistentWorldAPI-->>Client: {status: ok, created, definition_ref, mode, ...}
Sequence diagram for receipt.verify with user mode definition bindingsequenceDiagram
actor Client
participant PersistentWorldAPI
participant WorldStore
participant UserModeService
Client->>PersistentWorldAPI: handle({operation: receipt.verify, receipt_ref})
PersistentWorldAPI->>PersistentWorldAPI: super().handle(request)
PersistentWorldAPI-->>Client: (intermediate response)
Note over PersistentWorldAPI: post-processing in handle
PersistentWorldAPI->>UserModeService: receipt_definition_ref(receipt_ref)
UserModeService->>WorldStore: inspect(receipt_ref)
WorldStore-->>UserModeService: WorldObject(receipt)
UserModeService->>WorldStore: inspect(result_ref)
WorldStore-->>UserModeService: WorldObject(council_session)
alt world_mode is user_defined
UserModeService-->>PersistentWorldAPI: definition_ref
PersistentWorldAPI->>UserModeService: validate_definition_ref(definition_ref)
alt definition valid
UserModeService-->>PersistentWorldAPI: UserWorldMode
PersistentWorldAPI-->>Client: response + {mode_definition_ref: definition_ref}
else definition missing
UserModeService-->>PersistentWorldAPI: UserModeError(user_mode_definition_not_found)
PersistentWorldAPI-->>Client: {status: failed, missing_refs += definition_ref, mode_definition_ref: definition_ref}
else other validation error
UserModeService-->>PersistentWorldAPI: UserModeError(code)
PersistentWorldAPI-->>Client: error(code, message)
end
else no user-defined mode
UserModeService-->>PersistentWorldAPI: None
PersistentWorldAPI-->>Client: original response
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Sorry @EmergentMonk, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f20f084c71
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex review closure — exact head
|
Purpose
Implement the first genuinely unfinished alpha4 roadmap capability after merged PR #63:
The roadmap is stale around adjacent items: explicit recorded
world.movetransitions and LATTICE-backed placement already exist in the post-stable line. This PR therefore implements the remaining missing mode capability rather than duplicating machinery shipped by earlier PRs.Exact base
PR #64 branches from merged PR #63:
No release tag, runtime version, or protocol version is changed by this PR.
Policy
New policy identity:
User mode definitions are immutable content-addressed WorldStore objects:
Mode ids are namespaced:
Built-in mode ids cannot be shadowed or replaced.
Public operations
New operations:
Existing surfaces become aware of the active world's custom registry:
Framing-only boundary
A user-defined mode can supply:
It cannot create or modify geometry.
The operator-supplied semantic fields pass through Secret Scrubbing before persistence. The runtime always appends a fixed guardrail stating that custom framing cannot change evidence, verification, Council phases, vote weight, epistemic privilege, citizenship, Failsafe/Trap/Guardian behavior, credentials, tools, network destinations, game state, mutation authority, or security policy.
Civic boundary
User modes cannot bind to:
This prevents a custom prompt or label from impersonating civic voting or citizenship parole.
A custom mode may bind to another existing region, but region choice alone grants no game, tool, evidence, civic, or mutation authority.
Immutable definitions
An exact repeated definition is idempotent and returns the same content address.
Reusing one
mode_idwith different content fails closed instead of rewriting history.If conflicting immutable definitions for one mode id are encountered, activation fails closed rather than choosing newest-file-wins.
World isolation
Built-in modes remain process-global immutable code.
User-defined modes are world-local data. A request-local
ContextVarexposes only the current API instance's validated mode registry while handling a request, so two WorldStores in one Python process cannot leak custom modes into one another.Persistence and replay
File-backed definitions are reconstructed from validated immutable WorldStore objects after restart.
Council sessions freeze the complete effective user mode, including its exact
definition_ref.receipt.verifytreats that definition as a transitive custom-mode dependency and reports it. Deterministic mock Council replay resolves the same definition under the source-world context and still requires exact session and receipt identity reproduction.Foreign
world.importobjects remain quarantine wrappers and do not auto-admit custom modes.Compatibility correction found by CI
The first full-suite run passed every new custom-mode test but caught one compatibility regression: an ordinary unknown built-in id such as
vogons_onlywas incorrectly routed through theuser:namespace validator, changing the historical error message.The resolver now consults the custom registry only for ids beginning with
user:. All other unknown ids retain the original built-inunknown world modepath. The legacy regression remains unchanged and green.Files
Regression coverage stays in an existing test module so the historical 83-file hardening inventory is preserved.
Review targets
Please attack:
user_world_mode_definitionobjects throughworld.create;Exact-head validation
Current reviewed head:
Validation on that exact head:
The PR is Ready for review and mergeable. No merge or release/tag action is performed by this PR.
Summary by Sourcery
Implement world-local user-defined modes as immutable, framing-only extensions without granting additional civic, evidence, voting, tooling, mutation, or security authority.
New Features:
Bug Fixes:
Enhancements:
Documentation:
Tests: