refactor(container)!: rename destroyUser to destroyUserData - #50
Merged
Conversation
It erases what a user has STORED, never the user - accounts live in the auth service and never in the engine. Clean rename, no deprecated alias: the only consumer is agentage/memory, which picks it up at its 1.3.0 relock.
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.
Owner naming correction, landing before the 1.3.0 release so the wrong name never reaches npm.
VaultContainer.destroyUser->VaultContainer.destroyUserData. It erases what a user has stored - every vault they own in this root, tombstones included. It does not destroy the user: accounts live in the auth service and never in the engine. The old name read like account deletion, which is a different operation owned by a different system.No deprecated alias
Deliberate. The only consumer is
agentage/memory, which picks the rename up at its 1.3.0 relock - so an alias would exist purely to be removed, and the whole point is that the wrong name stops spreading. Anyone outside the estate on 1.2.0 stays on 1.2.0 until they choose to move.Cross-repo note:
agentage/memory's host lifecycle wrapper gets the matching rename (deleteUser->deleteUserData) in that same relock commit, for consistency with the/account/dataroute.Sweep
Not just the identifier - the prose said "account erasure" in five places, which is exactly the claim the rename exists to stop making:
src/container/vault-container.tsVaultContainermethod + its doc comment ("erases what ONE user has STORED... not the user - accounts live in the auth service"), theRoutedContainernote, and the implementation commenttest/container/admin-verbs.test.tsdescribeblock, 8 call sites, and the file headerREADME.mdRoutedContainerparagraphsmoke:distnever named this verb, so it is unchanged. No other file in the repo referenced it - adestroyUsergrep acrosssrc,test,README.mdandpackage.jsoncomes back empty.Verified
npm run verifygreen: type-check, lint, format:check, 273 tests (26 files), coverage 97.4 / 88.2 / 98.3 / 99.0 against 70 floors, build,dist smoke ok.Branched off
master, independent of #49 (authors()) - the two touch different files and can merge in either order.