fix(persona): never write a value the editor never held, and let a decision reach the copy

[stormer78]

Two bugs reported minutes after #195, both from one gap: neither the pool's value nor the pool's decisions travel with the copy.

1. The editor was blanking values — data loss

Since #194 the pane lists without includeSensitive, so the plaintext of a sensitive attribute is deliberately not in the page. That means an existing one reaches the editor as value: undefined → rawValue returns "" → the field opens blank → and persona/attribute/put is a replace.

So opening a withheld attribute to change its label — or the visibility controls #195 had just put in that same form — wrote an empty string over a value the console had never seen. Silently, and with no way back: there is no attribute/get, no version history, nothing to restore from.

Two mechanisms now, deliberately separate:

• The fetch. On open, an attribute that arrived without its value is asked for — the same one-attribute request Show makes, narrowed by type and matched by id.
• The refusal. Independently of that, a save is refused while the value is neither loaded nor typed. It sends no put at all: "wrote something wrong" and "wrote nothing" are very different outcomes for a value with no way back. The message says which case it is and offers the deliberate route — type the value in yourself.

Every control that edits the field now goes through one writer. One that set raw directly would leave the guard reading a typed value as one nobody typed — which the test caught while this was being written.

2. A decision did not reach the copy

What someone would receive renders claims read from a face or a binding. A claim is a copy and carries no sensitivity: the decision lives on the pool attribute it was materialised from, above the boundary those panels sit below. So a value the holder had just marked show it was masked in one panel and shown in the clear on the card one scroll away — same person, same value, two answers.

decidedSensitivity matches a resolved claim's attributeId back to the pool. An inline claim has no attributeId and no pool ancestor to have decided anything, so the registry answers for it — the right answer for that case rather than a gap in this one.

Rebased onto #196, not merged with it

#196 moved the claim-type table to the agent's served one and threads a registry through these same components. It fixes neither of these — nothing in it touches the put path, and the claims panel still passed no sensitivity — but it rewrote the files. This branch was rebased onto it and the conflicts resolved by keeping both props at every call site, rather than letting a textual merge pick one.

Checks

• 7 new tests. Extension 359 pass, core 562 pass.
• tsc -b clean; npm run build clean, manager.js a single chunk.
• Pinned: opening a withheld attribute fetches its value and the save carries it; a refused fetch blocks the save and writes nothing; typing a value is allowed through; a claim is drawn under the decision made about the attribute behind it; and an inline claim still falls to the registry.

Note for whoever hit this

Values already blanked this way are gone — they have to be re-entered. Worth knowing while reviewing: the window was #194 → this, and it applied to any attribute the registry resolves as sensitivity: high, which includes every unregistered type.

[affinidi-appsecurity-bot]

🛡️ 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.