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
-  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,15 @@ 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 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
+  failures follow this path.
 - 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

docs/windows.md

@@ -24,6 +24,13 @@ do not currently guarantee that return value is displayed.
   existing `contributes.layouts` layout.
 - The host validates the plugin is runtime-active and the layout exists before
   opening or focusing the window.
+- The calling plugin package must still be installed, enabled globally and
+  enabled for the focused project. A stale command from a replaced runtime is
+  rejected instead of opening a window under another plugin's identity.
+- `windows.open(...)` rejects its promise when any validation or native-window
+  operation fails. Let that rejection reach the command handler (or catch it,
+  log it and return explicit failed feedback); the IdeA menu host logs the
+  rejection and shows a retryable error to the user.
 - Reopening the same plugin/layout pair focuses the existing window.
 - `state` is JSON-serializable initial window state. The mounted component can
   later call `setState(next)` to update its local host state.
@@ -47,13 +54,14 @@ The returned `label` is a host-owned window identity. Treat it as opaque.
 
 ```ts
 ctx.commands?.registerCommand("hello-plugin.open-dashboard", async () => {
-  const win = await ctx.services?.windows.open({
+  if (!ctx.services) {
+    return { status: "skipped", reason: "ui-service-unavailable", message: "UI service unavailable." };
+  }
+  const win = await ctx.services.windows.open({
     layoutType: "hello-plugin.dashboard",
     state: { source: "menu" }
   });
 
-  return win
-    ? { status: "opened", message: "Opened dashboard.", alreadyOpen: win.alreadyOpen }
-    : { status: "skipped", reason: "ui-service-unavailable", message: "UI service unavailable." };
+  return { status: "opened", message: "Opened dashboard.", alreadyOpen: win.alreadyOpen };
 });
 ```