feat(manager): realign a DID's key records from the console - #245
Merged
Merged
Conversation
Drives `vta/webvh/dids/realign-keys/1.0` (specified at trustoverip/dtgwg-trust-tasks-tf#456, served by OpenVTC/verifiable-trust-infrastructure#1466 and dispatched by #1470) from the DIDs pane. ## The dry run is the diagnosis, not a courtesy Nothing on this screen tells an operator whether a DID needs realigning: the answer lives in the agent's key store and the DID's published log, and comparing them is precisely what the task does. So the preview *is* the feature — a consistent DID says so, and one that is not lists every rename before any of them happen. Which is why the action is offered on every DID rather than only where the console thinks it is needed. Deciding that here would mean a second, client-side copy of the comparison, and a copy that disagreed with the agent's would be invisible to the operator. ## A repair is not a destruction `Destructive` was the obvious home — it is already ask-then-confirm, and it already routes a consent refusal to the ceremony instead of a red string. But its voice is deletion throughout: a danger button, "what this would destroy", a danger note. A realign renames records and leaves the key material untouched, and drawing that in red is the lie `manager-theme.css` forbids, where `--w-danger` is one of three colours that mean something. So the shape of the decision stays shared and the voice became a parameter: `nature: "corrective"` asks what would *change* and draws in the accent. No force tick, because there is no refusal to override. A second component would have been a second place for the consent-refusal handling to be forgotten. ## The three outcomes are kept apart `moved` empty with `unmatched` non-empty is **not** "nothing to change" — it is an agent that cannot finish the repair because it holds no key for a method the document publishes. Both have an empty `moved` and the reassuring reading is the wrong one, so the pane says which it is. `dids-realign.render.test.mts` asserts each of the three against the words on screen. ## The snapshot moves more than this task `task-surface.json` is re-synced (vta-sdk 0.35.0 → 0.38.0) and the coverage expectation with it, 204 → 205. The canonical *total* jumps 227 → 235, and only one of those eight is this task: the other seven were always in the SDK and invisible to the old scanner, which matched only string literals while vta-sdk increasingly derives a constant from the generated payload type. The scanner learned to resolve those in the previous commit, so this is not the agent growing seven families — it is a denominator that had been under-counting the gap this number exists to keep reviewable. Nothing is lost in the resync: all 245 tasks in the old snapshot survive. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Completes the chain that started with the rename bug in #243. Drives
vta/webvh/dids/realign-keys/1.0from the DIDs pane.Depends on OpenVTC/verifiable-trust-infrastructure#1470 (the dispatch arm). Merge that first — this snapshot claims the task is in
vta-sdk, and until #1470 lands that is true only on its branch.The dry run is the diagnosis, not a courtesy
Nothing on this screen tells an operator whether a DID needs realigning: the answer lives in the agent's key store and the DID's published log, and comparing them is precisely what the task does. So the preview is the feature — a consistent DID says so, and one that isn't lists every rename before any of them happen.
Which is why the action is offered on every DID rather than only where the console thinks it's needed. Deciding that here would mean a second, client-side copy of the comparison, and a copy that disagreed with the agent's would be invisible to the operator.
A repair is not a destruction
Destructivewas the obvious home — already ask-then-confirm, and it already routes a consent refusal to the ceremony instead of a red string. But its voice is deletion throughout: a danger button, "what this would destroy", a danger note. A realign renames records and leaves key material untouched, and drawing that in red is the liemanager-theme.cssforbids, where--w-dangeris one of three colours that mean something.So the shape of the decision stays shared and the voice became a parameter:
nature: "corrective"asks what would change and draws in the accent. No force tick, because there's no refusal to override. A second component would have been a second place for the consent-refusal handling to be forgotten.The three outcomes are kept apart
movedempty withunmatchednon-empty is not "nothing to change" — it's an agent that cannot finish the repair, because it holds no key for a method the document publishes. Both have an emptymoved, and the reassuring reading is the wrong one. Six rendered tests assert each outcome against the words on screen, including that the repair is never dressed as a destruction.The snapshot moves more than this task
task-surface.jsonre-syncs 0.35.0 → 0.38.0, and the coverage expectation with it, 204 → 205. The canonical total jumps 227 → 235, and only one of those eight is this task.The other seven were always in the SDK and invisible to the old scanner, which matched only string literals while
vta-sdkincreasingly derives a constant from the generated payload type. #244 taught it to resolve those. So this is not the agent growing seven families — it's a denominator that had been under-counting the very gap this number exists to keep reviewable. Nothing is lost in the resync: all 245 tasks in the old snapshot survive.Checks
npm test— 1352 across the workspace, 0 failures.npm run buildclean.The chain, for the record
dtgwg-trust-tasks-tf#456 (spec) → #457 (unblocked its CI) → releases 0.20.5 / 0.19.5 → VTI#1466 (create fix + repair) → VTI#1470 (dispatch) → #244 (scanner) → this.