[CLI]: rename packmind-cli to packmind

[MaloPromyze]

Renaming packmind-cli → packmind: Summary

Base change (~343 references across ~60 files)

Area	Scope
UI	~34 refs in 23 frontend files — command examples, tooltips, test assertions
Docs	~142 refs in 13 doc files — every guide, the full CLI reference
Skills	~105 refs in 7 default skills — all CLI instructions taught to agents
CLI source	~60 refs in 15 files — main.ts name, consoleLogger prefix, handler usage/error messages
Other	2 refs in packages/types/ (JSDoc comments)

Backward compatibility strategy

1. Install script — rename BINARY_NAME to packmind, add a packmind-cli symlink (Unix) or copy (Windows) post-install
2. npm bin field — expose both packmind and packmind-cli entrypoints
3. Release assets — publish under new names; optionally publish both during a transition period
4. Already-deployed skills — users need a packmind init re-run to refresh skill

All work shall be done & validated on a branch
Update the ci / cd

-> See PR

[cteyton]

Just a thought, current packmind-cli update will be stopped at a given version.

"Already-deployed skills — users need a packmind init re-run to refresh skill"

How should we handle projects where 10 users have not the same of version of the CLI?

[MaloPromyze]

How should we handle projects where 10 users have not the same of version of the CLI?

Fair point. As mentioned for the install script & the npm bin field, we should update the packmind-cli update so that it creates both packmind-cli & packmind executable/ symlink. This will ensure that even if the packmind skills that are outdated and custom user integration keep working. We'll note packmind-cli as deprecated in documentation & remove it completely in the future.

We can also add a check on the cli so that it logs a warning when invoked as packmind-cli (argv[0])

[cteyton]

• We'll have to update the homebrew repo https://github.com/PackmindHub/homebrew-cli to support both packmind-cli and packmind (https://github.com/PackmindHub/homebrew-cli/blob/main/.github/workflows/bump-packmind-formula.yml#L50) with the following approach:

 Use Homebrew's deprecate! mechanism:
 1. Create new `packmind.rb` formula downloading new assets
 2. Update packmind-cli.rb to depends_on "packmind" + deprecate! notice
 3. Existing users' brew upgrade packmind-cli still works, shows migration notice.

[cteyton]

• The released artifacts from the GH workflows will now be named packmind-*.
  I wonder if this is not something confusion, as we could believe it's like the packmind app or platform.

[cteyton]

• For current users who have installed the CLI using the DL script, the packmind-cli update will stop working, since we'll stop fetching the artifacts called packmind-cli-*. If we release now, it means the current packmind-cli users won't be able to use the command update.

Proposal:

• If we don't change the release artifact (previous comment), it will not break. However, if the update script writes into /home/.bin/packmind, users will have both packmind-cli and packmind installed. Maybe the update script could detect if packmind-cli is installed and adapt a particular behavior for this?

[cteyton]

• The fact that we have bin duality is perfect for npm packages installation. But for a script-based install, only one binary is installed. The install.sh does create a symlink, but the updateHandler.ts does not (the one that self-update the CLI).

More info: