feat(framework): show installed versions and notify available updates #980

Objective

Make the installed AIDD version visible and notify users when an update is available, while respecting the separate installation and update lifecycles of the CLI, marketplace, and plugins.

Agreed direction

CLI

• Keep CLI version checks autonomous. Reuse the existing self-update check and cache rather than introducing another checker.
• Expose the information through the command-line interface and an interactive menu entry.
• Compare the installed CLI version with the published npm version and provide the appropriate update instruction.

Marketplace startup notice

• A single owning plugin declares a startup hook and ships its dependency-free Node script. The marketplace catalog itself does not execute hooks.
• The script checks whether a newer release of the configured AIDD marketplace/framework source is available. It must work without a globally installed AIDD CLI.
• Reuse AIDD's existing hook translation and host adapters for supported tools. Verify both execution and a user-visible notification; starting a script alone is insufficient.
• The notice means that a newer framework/marketplace release exists. It must not imply that every installed plugin is outdated: marketplace, plugin, and CLI versions are independent.
• Keep the CLI and plugin runtime independently distributable. A shared package or universal checker is not an agreed requirement.

Visible behavior

Once per new conversation, retain the startup greeting and locally resolved framework version:

AI-Driven Development On ⚡ · Framework v · Releases

If the installed framework version cannot be established, display Framework version unknown. Do not substitute the CLI version or a plugin version.

When a newer matching release is known, show a short notice identifying the installed and available versions, with a link or update instruction appropriate to the installation mode. Notifications must not install updates automatically.

Reading the installed version is local. Discovering a newer release requires remote metadata or a previously populated cache; this extends the original local-only scope of this issue. Cache remote checks to avoid a request on every conversation. Network failures must not block startup or be reported as proof that the installation is up to date.

Installation provenance to resolve before implementation

• Establish how the startup script obtains the installed marketplace/framework version and source for native URL-based installs, local marketplace directories, and CLI-translated installs.
• Do not assume that an installed plugin contains the root marketplace manifest or that a CLI registry exists for a native installation.
• Respect the configured source and channel, including local checkouts and pinned versions. The official repository may be the known default, but its latest release is not automatically the correct comparison for every installation.
• Select the owning plugin against existing architecture responsibilities. Keep one canonical startup implementation rather than adding a network checker to every plugin.
• Choose the cache freshness and notification frequency during refinement; avoid duplicate notices from overlapping hooks.

OpenCode integration

The existing bridge approximates SessionStart at plugin/server initialization and discards child-script output. Validate actual session-start events on the targeted OpenCode versions and adapt the bridge and notification presentation as necessary. Documented event availability alone is not runtime proof. Preserve existing memory and telemetry hook behavior.

Acceptance criteria

• CLI version information and update availability are accessible through both an explicit command and the interactive menu, reusing existing self-update behavior.
• A native marketplace installation can run the plugin-owned startup check without the AIDD CLI installed globally.
• The installed framework version and provenance are established for native remote, local-directory, and CLI-translated installations, or are explicitly reported as unknown.
• A new conversation displays the greeting once; after an upgrade, a new conversation resolves the updated installed version.
• Update comparisons use the same component, source, and release channel; a marketplace update notice does not claim all plugins are outdated.
• A known newer release produces a visible notice with an appropriate update path. No update is installed automatically.
• Cached checks avoid a remote request on every startup; unavailable remote information does not block a session or produce a false up-to-date result.
• Each advertised tool has evidence for triggering the check and displaying its result. Include Claude Code, Codex, and OpenCode in the initial verification; explicitly state unsupported or unverified paths.
• OpenCode verification distinguishes server initialization from conversation creation and confirms that existing hooks still work.