id: design: capability-change notices on reconnect — expansion and sideways changes

Part of the worlds design program: #5955. Statements S17–S18 of the 2026-11-04 brief.

Requirement (Drew, in substance)

Design the system for when a place a user has already connected to before changes its capabilities:

The change may be an expansion (strict superset), or a sideways modification — not a strict reproduction of the previous capability set.
By default there is a warning or notice before the user connects and has unexpected results. No silent upgrades of what a known world can do.

Design points to settle

What is compared: the registry's requested set, the discovered-used set (see the capability-model child of #5955), or both? A change in used with no change in requested is exactly the sideways case that matters.
Notice content: diff presented in plain language (new capabilities named), not a hash change.
User choices on notice: proceed once, proceed and accept the new set as the baseline, refuse. Is there a "remember for capability decreases only" asymmetry (decreases are safe, increases warn)?
Who else gets notified: server admins for server-side capabilities, world authors when a library they depend on changes its capability footprint.
Interaction with invites (#5751): does accepting an invite pin the capability set the invite was issued under?

Done looks like

A design specifying the comparison baseline, the diff presentation, the user's options, and the re-baselining rule — implementable against the registry schema from the capability-model design.

CODE-1625

Wave-2 follow-ups filed from the prior-art research (Lane B). Granular sub-scopes of this issue, each carrying the relevant research findings + citations:

id: design: capability-change diff semantics — user-meaningful capability classes and re-approval triggers

Research source: workspace/scratch/worlds-capabilities-brief-2026-11-04/prior-art-research.md. Full wave-2 mapping: workspace/scratch/worlds-capabilities-brief-2026-11-04/wave2-map.md.

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-d
Session / ID: task 10328
Found via: queue claim
Task: work on issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959 handed off to the opencode execution lane per the worker runbook §1b — the laptop claimant launches the bound opencode session, which drives task 10328 to its terminal state.
Expectation: claimant session picks up task 10328; this lane did not work the item itself.
Links: issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-r
Session / ID: task 10328
Found via: queue claim
Task: Handing task 10328 for issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959 to the opencode claimant (execution lane assigned opencode); the bound opencode session will work issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959 to its terminal state.
Expectation: claimant launches a bound session; task 10328 parked 1800s awaiting launch.
Links: issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959

🤖 Agent note · handed off

Agent: repo queue worker, lane code-d (repo-worker-code)
Session / ID: cron repo-queue-worker-shift-d run 2026-11-05 22:08 CST; task 10328
Found via: claimed task 10328 this shift; execution-lane assignment returned opencode
Task: task 10328 for issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959 (triage, attempt 5/6). Fresh check via gh: issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959 is OPEN, no hard-stop labels (held / user/owned / do-not-merge / do-not-auto-edit). Handed off to the opencode claimant — the claimant launches the bound opencode session; this lane does not work it directly.
Expectation: claimant session drives task 10328 to a terminal state.
Links: task 10328 · issue id: design: capability-change notices on reconnect — expansion and sideways changes #5959

🤖 Agent note · handed off

Agent: fleet monitor (repo-fleet-monitor)
Session / ID: task 10328
Found via: monitor reconciliation
Task: Claim-evaporation repair — the queue claim on task 10328 evaporated (the holding run ended without complete/park/block and the lease expired); task 10328 is queued and unclaimed. Labels reset to the truth (queue/queued + status/needs-triage). Checkpoint stage at evaporation: handed_off.
Expectation: a queue lane re-claims task 10328 and resumes from the handed_off checkpoint.

Navigation Menu

Repository navigation

id: design: capability-change notices on reconnect — expansion and sideways changes #5959

Requirement (Drew, in substance)

Design points to settle

Related

Done looks like

98 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id: design: capability-change notices on reconnect — expansion and sideways changes #5959

Description

Requirement (Drew, in substance)

Design points to settle

Related

Done looks like

Activity

developing-today commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

developing-today commented on Nov 5, 2026

98 remaining items

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions