docs(sdk): contrat commandes/menus apres reload — handler manquant = erreur retryable jamais no-op silencieux, feedback skipped/failed host-owned, pas de contributes.commands separe, reload sans refresh auto par le plugin — #336 (docs only, aucun push)

docs/commands-and-feedback.md

@@ -25,9 +25,10 @@ manifest contribution -> command id -> registered command handler -> optional ta
   not by a fake task.
 - Feedback objects must be stable enough for agents and programmatic callers to
   parse, and their messages must be readable by humans.
-- The current human menu-click UI does not guarantee display of a command
-  handler return value. When a human must see feedback from a menu action, open
-  or focus a plugin layout/window from the handler with
+- The human menu-click UI presents minimal host-owned feedback for `skipped`
+  and `failed` results. It intentionally does not expose the raw result payload.
+  For successful actions and richer status, open or focus a plugin layout/window
+  from the handler with
   `ctx.services.windows.open({ layoutType, state })`.
 
 ## Preconditions
@@ -78,9 +79,9 @@ Use the same `status` vocabulary consistently:
 
 Visible surfaces are intentionally distinct:
 
-- Command return value: immediate feedback for programmatic callers, agents and
-  future host surfaces. It is not a guaranteed visible UI surface for current
-  human menu clicks.
+- Command return value: immediate feedback for programmatic callers and agents.
+  The human menu host maps `skipped` and `failed` results to concise feedback;
+  plugin-specific fields and messages are not displayed verbatim.
 - Plugin layout/window: the normative visible feedback surface for menu actions
   that need to show status, results or next steps to a human. The layout must be
   declared in `idea-plugin.json` and registered during activation.

docs/manifest.md

@@ -243,7 +243,9 @@ public id used by both `ctx.layouts.register({ type, component })` and
 
 Contribution ids are part of the runtime contract:
 
-- commands can only register ids declared by `contributes.menuItems[*].command`;
+- there is no separate `contributes.commands` collection; commands can only
+  register ids declared by `contributes.menuItems[*].command` or
+  `contributes.slashCommands[*].command`;
 - layouts can only register `type` values declared by `contributes.layouts`;
 - `services.windows.open({ layoutType })` only accepts a layout type declared by
   the calling plugin.

docs/menus.md

@@ -41,9 +41,11 @@ export function activate(ctx: ActivateContext): void {
 
 ## Rules
 
-- A command can only be registered if at least one manifest menu item declares
-  that exact `command` id.
-- Missing command handlers are a no-op when the user clicks the menu item.
+- There is no separate `contributes.commands` collection. A command can only be
+  registered if at least one manifest `menuItems[].command` or
+  `slashCommands[].command` entry declares that exact id.
+- A missing command handler is surfaced by the host as a retryable reload error;
+  menu clicks must never fail silently.
 - A handler owns precondition checks and feedback. See
   [Commands And Feedback](commands-and-feedback.md).
 - Menu item `when` expressions are evaluated by the host; unsupported or false

docs/project-plugin-assignments.md

@@ -150,6 +150,8 @@ These actions solve different problems:
 - Reload the plugin after rebuilding or replacing its installed package. Reload
   refreshes the plugin manifest, runtime bundle, contributions, and packaged
   skill Markdown. It does not change project activation or agent assignments.
+  Plugins do not call a contribution-refresh API themselves: rebuild or replace
+  the installed package, then use the host reload action.
 - Relaunch the agent after enabling or disabling a project plugin, changing its
   skill/tool assignments, or manually editing `.ideai/project-plugins.json`.
   Agent capabilities are resolved into a launch-time snapshot, so an already