I did not want someone to hesitate over menu cleanup because it might erase program files. Removing a Northstar plugin first removes its current-project registration. That is useful only if the next initialization respects the decision instead of bringing the same button back, so removal also needs a remembered dismissal.
State the removal scope in the confirmation
The UI confirmation says that the plugin leaves the list while the original work program is retained. changePlugin implements remove by filtering that programId from preferences. The function contains no call deleting code or notebooks from the program library. A button's registration and a file's lifetime are deliberately different.
The word delete is too broad on its own. Hiding a menu item, disabling use, deleting a definition and deleting results carry different recovery costs. I implemented the narrow change needed for menu cleanup and described that scope explicitly. Retention of the original definition at this boundary must not be inflated into a complete-system backup or a guarantee that every unrelated storage path is protected.
Without a dismissal marker, initialization overrides the user
Some built-in capabilities are registered automatically during startup. Removing only the preference would let the next discovery treat it as a new entry and add it again. After remove, pluginAction records the identifier in dismissedTaskPlugins. Automatic register checks that list and returns registered=False without restoring the entry.
This marker does not condemn the program as broken. It records a choice not to use its menu entry in this project. Mixing a removal preference with a failure state would make later diagnosis confusing. A separate preference lets automatic connection respect the decision without rewriting execution history. Stable program identity also matters: it keeps the marker connected to the capability the user actually dismissed.
Allow an explicit choice to add it again
Automatic discovery and deliberate registration are treated differently. An explicit register call clears the dismissal marker and connects the definition to current preferences. An existing test blocks automatic registration first, then verifies restoration through create with the same programId. Removal is not an irreversible blacklist that makes recovery unnecessarily difficult.
It is also not a recycle bin containing every former preference. A new registration can use default enabled and pinned values; I do not promise restoration of the old pin. Restoring archived settings and connecting a definition with fresh defaults are separate contracts. The synthetic example makes its unpinned restoration default visible in generated records rather than implying a fuller recovery mechanism than it implements.
Explain retained definitions alongside active-work interruption
Removal clears the currently selected entry. A following branch requests runner.cancel when an active program matches the profile and program identity. Retaining the definition therefore does not mean that an in-flight task continues unaffected. Definition retention and interruption of an active run operate on separate state.
A cancellation request also does not reverse an action already completed externally. Publication or upload requires checking the original outcome and record. This content task disabled or removed no real work. It describes the control boundary visible in source, while the linked example returns an intent value instead of performing live cancellation. Keeping those facts separate is part of explaining removal honestly.
Preservation tests compare material outside preferences
An existing task-plugins test serializes program data before remove and compares it afterward. Plugin-creation tests separately check that dismissal blocks automatic registration and is cleared by explicit registration. Together they support distinct explanations of definition preservation and respect for a user's preference.
This task did not rerun those original tests or inspect an entire user store. The independent synthetic module actually tests unchanged definition copies, dismissal, automatic blocking and explicit restoration. It includes no authentication, file cleanup or original-UI verification. A small unit-test result is evidence of its particular state contract, not a certificate covering every possible deletion path in the application.
A growing manager should show the scope of reversibility
As capabilities grow, people need to tidy unused entries more often. Linking every cleanup to file deletion makes management expensive; hiding without remembering the choice lets initialization undo it. Separating definition, registration and dismissal explains which material remains and which connection disappears.
I see this small distinction as part of the long-term usability of a company-specific manager. Decide what must remain recoverable, then align confirmation text and API receipts with that scope. The linked example exposes the judgment through inspectable in-memory transitions. It does not eliminate the integration work required for real persistence and authorization, and is not presented as a complete operational manager.