merge(sdk): fix #336 — contrat docs commandes/menus apres hot reload (erreur retryable, feedback host-owned, contrat manifest/registration, reload sans refresh auto)

# Conflicts:
#	docs/menus.md

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
+- The human menu-click UI presents minimal host-owned feedback for `skipped`
-  handler return value. When a human must see feedback from a menu action, open
+  and `failed` results. It intentionally does not expose the raw result payload.
-  or focus a plugin layout/window from the handler with
+  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
+- Command return value: immediate feedback for programmatic callers and agents.
-  future host surfaces. It is not a guaranteed visible UI surface for current
+  The human menu host maps `skipped` and `failed` results to concise feedback;
-  human menu clicks.
+  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
+- There is no separate `contributes.commands` collection. A command can only be
-  that exact `command` id.
+  registered if at least one manifest `menuItems[].command` or
-- Missing command handlers are a no-op when the user clicks the menu item.
+  `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 registered handler's rejected promise is not swallowed: the host logs the
   plugin id, command id and reason, then presents a retryable error. In
   particular, return/await `services.windows.open(...)` so native-window

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