Skip to content

PR 64 — User-defined world modes - #64

Merged
EmergentMonk merged 9 commits into
mainfrom
agent/pr64-user-defined-world-modes
Aug 21, 2026
Merged

PR 64 — User-defined world modes#64
EmergentMonk merged 9 commits into
mainfrom
agent/pr64-user-defined-world-modes

Conversation

@EmergentMonk

@EmergentMonk EmergentMonk commented Aug 21, 2026

Copy link
Copy Markdown
Member

Purpose

Implement the first genuinely unfinished alpha4 roadmap capability after merged PR #63:

2.0-alpha4 — World Modes and Geometry
[ ] user-defined modes

The roadmap is stale around adjacent items: explicit recorded world.move transitions 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:

04f914998afd53305fb5491b31b746b24e108af5

No release tag, runtime version, or protocol version is changed by this PR.

Policy

New policy identity:

nexus-user-world-modes/1

User mode definitions are immutable content-addressed WorldStore objects:

object_type = user_world_mode_definition
schema      = nexus-user-world-mode-definition/1

Mode ids are namespaced:

user:<lowercase-id>

Built-in mode ids cannot be shadowed or replaced.

Public operations

New operations:

world.mode.policy
world.mode.define

Existing surfaces become aware of the active world's custom registry:

world.modes
system.health
actor.chat
council.run
receipt.verify
receipt.replay

Framing-only boundary

A user-defined mode can supply:

  • label;
  • description;
  • prompt instruction;
  • one existing world-region binding.

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.

USER_MODE != PROCEDURAL_AUTHORITY
USER_PROMPT != SYSTEM_POLICY
MODE_REGION != CIVIC_ACCESS
MODE_DEFINITION != EVIDENCE
MODE_POPULARITY != TRUTH
CUSTOM_FRAMING != VOTE_WEIGHT

Civic boundary

User modes cannot bind to:

bureaucratic_vote_room
upside_down

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_id with 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 ContextVar exposes 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.verify treats 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.import objects 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_only was incorrectly routed through the user: 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-in unknown world mode path. The legacy regression remains unchanged and green.

Files

src/nexus_runtime/user_modes.py
src/nexus_runtime/persistent_world_api.py
contracts/user-world-modes.json
docs/USER_MODES.md
tests/test_modes_geometry.py

Regression coverage stays in an existing test module so the historical 83-file hardening inventory is preserved.

Review targets

Please attack:

  1. cross-world mode leakage between API instances;
  2. attempts to shadow a built-in mode;
  3. civic/parole-region impersonation;
  4. prompt text claiming vote, evidence, security, tool, or mutation authority;
  5. secret-shaped mode metadata reaching durable state;
  6. conflicting immutable definitions or cross-process races;
  7. forged user_world_mode_definition objects through world.create;
  8. foreign imported definitions becoming active;
  9. restart reconstruction and corrupt-definition handling;
  10. custom-mode Council replay or receipt verification losing the definition binding;
  11. custom framing changing deterministic vote mechanics;
  12. any accidental geometry or protocol mutation.

Exact-head validation

Current reviewed head:

f20f084c71536105ca309291ce2d7d91521e8187

Validation on that exact head:

  • ✅ README dual-surface contract
  • ✅ Python mock runtime tests — full 895-test suite plus mock Council and Trap structural demos
  • ✅ NEXUS security regression — full Python + Rust + adversarial quick profile
  • ✅ NEXUS adversarial gauntlet
  • ✅ historical NEXUS 2.0 release-candidate hardening against its frozen subject
  • ✅ NEXUS 2.1 extension hardening against merged PR PR 60 — Post-stable extension hardening #60
  • ⏭️ NEXUS 2.1.1 release candidate intentionally skipped because this is post-candidate PR PR 64 — User-defined world modes #64

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:

  • Add world-local user-defined modes with namespaced identifiers, immutable definitions, configurable framing, and existing-region bindings.
  • Expose user-mode policy and definition operations, and integrate custom modes with world listings, health, chat, Council execution, receipt verification, and replay.

Bug Fixes:

  • Preserve the historical unknown built-in mode error path for non-user mode identifiers.

Enhancements:

  • Enforce framing-only semantics, reserved civic/parole regions, secret scrubbing, immutable conflict detection, provenance validation, persistence, restart reconstruction, and cross-world isolation for custom modes.
  • Bind Council sessions and receipt verification to the exact content-addressed custom mode definition.

Documentation:

  • Document the user-defined mode policy, API usage, persistence, replay behavior, and authority boundaries.

Tests:

  • Add regression coverage for custom-mode isolation, persistence, immutability, secret handling, reserved regions, deterministic voting, Council replay, and receipt verification.

@sourcery-ai

sourcery-ai Bot commented Aug 21, 2026

Copy link
Copy Markdown

Reviewer's Guide

Adds 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 creation

sequenceDiagram
    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, ...}
Loading

Sequence diagram for receipt.verify with user mode definition binding

sequenceDiagram
    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
Loading

File-Level Changes

Change Details Files
Introduce user-defined world mode definitions and registry, with strict validation, immutability, and world-local isolation.
  • Define user-mode policy constants, schemas, limits, guardrail text, and validation helpers for IDs, text bounds, regions, and definition references.
  • Implement UserModeService to create, validate, list, and resolve user modes from immutable WorldStore objects, enforcing provenance, schema, reserved regions, and one-definition-per-mode-id semantics with idempotent repeats and conflict errors.
  • Add contextvar-based user_mode_context, contextual get/list mode dispatch, and installation into existing modes/api/council modules so user modes are visible only within the active world’s request context.
src/nexus_runtime/user_modes.py
Extend persistent world API with user-mode operations, error handling, and integration into health, verification, and mutation paths.
  • Register world.mode.policy and world.mode.define operations, treating the latter as a persistent mutation and delegating to UserModeService with strict field validation.
  • Instantiate UserModeService in PersistentWorldAPI, wire its errors into the operation handler, and wrap handle() with user_mode_contextual so each request sees the correct world-local mode registry.
  • Block world.create from directly creating user_world_mode_definition objects, and extend system.health and receipt.verify to surface user-mode policy, counts, and to treat mode definition refs as explicit dependencies that must validate or be reported as missing.
src/nexus_runtime/persistent_world_api.py
Document user-defined world modes and define a contract schema for their stored objects.
  • Add USER_MODES.md describing policy identity, definition format, allowed regions, prompt/guardrail boundary, world isolation, persistence/replay rules, and new operations.
  • Introduce contracts/user-world-modes.json capturing the schema/contract for user_world_mode_definition objects (not shown in diff detail).
docs/USER_MODES.md
contracts/user-world-modes.json
Add regression tests covering user-mode creation, immutability, isolation, restart behavior, and Council/receipt integration.
  • Add tests that define a user mode and assert it appears via world.modes, is used by council.run, and is frozen into sessions and receipts with deterministic replay and verification preserving the definition_ref.
  • Test that user modes do not alter Council vote mechanics by comparing analytical and user modes on the same question and members.
  • Test that definitions are immutable, idempotent, secret-scrubbed, and that attempts to shadow built-in modes, bind to civic/parole regions, or forge definitions via world.create fail with the expected error codes.
  • Test that user modes are world-local (no cross-world leakage) and survive file-backed restart with correct geometry binding, using separate NexusAPI instances and a shared world_root directory.
tests/test_modes_geometry.py

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@EmergentMonk
EmergentMonk marked this pull request as ready for review August 21, 2026 02:49

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @EmergentMonk, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread src/nexus_runtime/user_modes.py Outdated
Comment thread src/nexus_runtime/user_modes.py
Comment thread src/nexus_runtime/persistent_world_api.py

Copy link
Copy Markdown
Member Author

Codex review closure — exact head 256940146113d3af87e8ea4e3f659a8742276cdb

All three Codex findings are fixed and their inline threads are resolved.

  • P1 redaction-expansion persistence: scrubbed mode text is re-bounded before any WorldStore write; the regression proves an in-bound 94-character raw label that expands past 96 during redaction is rejected without leaving a poisoned immutable definition, including after restart.
  • P2 civic proceedings resolver: civic_observation now uses the same request-local contextual mode resolver/list as the rest of the runtime; a committed custom-mode Council proceeding can be read with its exact user: source mode.
  • P2 continuity boundary: post-receipt.verify custom-mode dependency enrichment now converts WorldContinuityError and storage failures to structured public errors rather than letting them escape handle().

Regression coverage stays inside the existing 83 Python test-file inventory.

Exact-head validation:

  • ✅ README dual-surface contract
  • ✅ Python mock runtime tests — 898 tests, all green, plus mock Council and Trap structural demos
  • ✅ NEXUS security regression — full Python + Rust + adversarial quick profile
  • ✅ NEXUS adversarial gauntlet
  • ✅ frozen NEXUS 2.0 release-candidate hardening
  • ✅ frozen PR PR 60 — Post-stable extension hardening #60 / NEXUS 2.1 extension hardening
  • ⏭️ NEXUS 2.1.1 candidate intentionally skipped on this post-candidate PR

PR #64 remains open, Ready for review, mergeable, and unmerged. No release/tag action was performed.

@EmergentMonk
EmergentMonk merged commit 24cb0ce into main Aug 21, 2026
8 checks passed
@EmergentMonk
EmergentMonk deleted the agent/pr64-user-defined-world-modes branch August 21, 2026 03:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant