Skip to content

feat(manager): put attributes in a world, and show which world a value is in - #213

Merged
stormer78 merged 1 commit into
mainfrom
feat/attributes-in-worlds
Sep 9, 2026
Merged

feat(manager): put attributes in a world, and show which world a value is in#213
stormer78 merged 1 commit into
mainfrom
feat/attributes-in-worlds

Conversation

@stormer78

Copy link
Copy Markdown
Contributor

Closes the half of the worlds feature the pane did not reach, and with it the last piece of the original ask: "is it possible to link attributes together — tie my work email, work number, work name together?"

The wire has carried attributeIds since the specification landed and the core client has always sent it; the editor preserved whatever it loaded and offered no way to change it. So that grouping could only be expressed by building a face — which is a different statement: what is shown together, rather than which part of a life a value belongs to.

What's new

  • The world editor gains Which attributes belong to it?, grouped by the same families the map and the list use.
  • Attribute rows in the list view show dots in each world's colour, with the names on the title.
  • A world card says how many attributes belong to it.

Two decisions

An attribute may belong to several worlds, and nothing implies otherwise. That is the asymmetry with a face and the reason for it: a face belongs to one world because the world is where its colour is read from, and a mobile number is genuinely part of a working life and a home one at once. The agent enforces no exclusivity over attributes, so the screen doesn't either — no checkbox disables itself, and the copy says so before anyone wonders. Asserted, so a later change that adds disabling has to delete a test.

Dots, not named chips. A row already carries a type, a value, a provenance and a status. Four more words per row buries the value under its own metadata. The dots are a reminder that a value is arranged; the editor is where the arrangement is read. worldsOfAttribute returns listing order rather than membership order so two attributes in the same worlds draw their marks in the same sequence — marks that reshuffle between renders read as a change when nothing changed.

Same replace hazard, third time

The editor seeds both membership lists from what it loaded and sends both, because persona/facet/put replaces. A test asserts that adding an attribute does not drop the faces — the failure mode would otherwise be silent and only visible on the next screen.

Verification

extension 485/485 (8 new), tsc -b and npm run build clean.

I also deleted a test I had written with no assertions in it — it passed, and would have passed forever.

…e is in

Closes the half of the worlds feature the pane did not reach. The wire has
carried `attributeIds` since the specification landed and the core client has
always sent it; the editor preserved whatever it loaded and offered no way to
change it. So "tie my work email, work number and workplace together" could
only be expressed by building a face — which is a different statement, about
what is shown together rather than about which part of a life a value belongs
to.

**An attribute may belong to several worlds, and nothing here implies
otherwise.** That is the asymmetry with a face and the reason for it: a face
belongs to one world because the world is where its colour is read from, and
a mobile number is genuinely part of a working life and a home one at once.
The agent enforces no exclusivity over attributes, so neither does the
screen — no checkbox disables itself, and the copy says so before anyone
wonders.

**The picker groups by family**, reusing `groupRows` rather than laying out a
flat column of thirty. One grouping of one pool, defined once: two that
disagree is the defect where a person counts six in one place and five in
another.

**The list view now shows which worlds a value is in**, as dots in the
world's own colour with the names on the title. Dots rather than named chips
because a row already carries a type, a value, a provenance and a status, and
four more words per row buries the value under its own metadata — this is a
reminder that a value is arranged, not the place the arrangement is read.

`worldsOfAttribute` returns worlds in listing order rather than membership
order, so two attributes in the same worlds draw their marks in the same
sequence: a row whose marks reshuffle between renders reads as a change when
nothing changed.

The attribute editor seeds from what was loaded and sends both lists, for the
reason the face list already did — a put replaces, and an editor seeded empty
silently empties a world on an edit that meant to rename it. A test asserts
that adding an attribute does not drop the faces.

extension 485/485, `tsc -b` and `npm run build` clean.

Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
@stormer78
stormer78 merged commit 235baf1 into main Sep 9, 2026
3 checks passed
@stormer78
stormer78 deleted the feat/attributes-in-worlds branch September 9, 2026 07:15
@affinidi-appsecurity-bot

Copy link
Copy Markdown

🛡️ AI Agentic Security Code Review

🔎 A manual security review is recommended before merging. Please contact the Security team for specifics and remediation guidance.

ℹ️ Detailed findings are not published on public repositories; the Security team holds the complete report.

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.

2 participants