Le fichier ~/.config/<service>/bw-session est redondant depuis l'introduction
du fichier partagé mcp-framework. On n'écrit plus que dans le partagé et on lit
uniquement depuis lui dans refreshSessionEnv et loadAnyBitwardenSession.
EnsureBitwardenSessionEnv tente le fichier service-spécifique en premier
(rétrocompat) puis bascule sur le partagé.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Quand deux MCPs appellaient login, le second appelait bw unlock et générait
un nouveau token, invalidant celui du premier. Deux mécanismes corrigent ça :
1. LoginBitwarden ne relance plus bw unlock si le vault est déjà unlocked
et qu'une session existe (env, fichier service, ou fichier partagé).
2. Le login écrit le token dans ~/.config/mcp-framework/bw-session (partagé)
en plus du fichier service-spécifique. Les autres MCPs lisent ce fichier
en priorité via refreshSessionEnv avant chaque opération Bitwarden.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Quand un MCP appelle login/unlock, le token est écrit dans le fichier de session
mais les autres MCPs conservent leur token obsolète dans l'environnement du processus.
Désormais, bitwardenStore.ensureReady() appelle refreshSessionEnv() qui relit le
fichier avant chaque vérification, ce qui permet à tous les MCPs de rester
opérationnels après une rotation de session.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Le trigger 'on: push: tags: "**"' dans Forgejo déclenche aussi sur les
pushes de branches. Le guard 'if: startsWith(github.ref, refs/tags/)'
assure que le job ne tourne que sur de vrais tags.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
À chaque tag stable, la CI extrait la section [Unreleased], l'utilise
comme notes de release Forgejo, renomme la section avec la version et
la date, puis commite le CHANGELOG.md mis à jour sur main.
Les tags RC utilisent le contenu [Unreleased] pour les notes mais ne
modifient pas le fichier.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Documenter BitwardenLoginHandler, StandardConfigTestHandler et le
comportement opt-in de ManifestCheck dans RunDoctor.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Le handler est spécifique au backend Bitwarden CLI. Le nom "Default"
suggérait à tort qu'il s'applique à tous les MCPs.
Les MCPs sans backend Bitwarden ne définissent pas de hook Login :
autoDisabledCommands masque automatiquement la commande.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- DefaultLoginHandler(binaryName) : handler de login Bitwarden prêt à
l'emploi avec confirmation. Remplace les réimplémentations identiques
dans chaque MCP.
- StandardConfigTestHandler(opts) : handler de config test standard sans
ManifestCheck. Accepte ConfigCheck, OpenStore, ConnectivityCheck et
ExtraChecks.
- ManifestCheck dans RunDoctor devient opt-in : inclus uniquement si
ManifestDir est fourni (artefact de build, pas de contrainte runtime).
- Supprime le handler mort CommandLogin dans bootstrap.Run, désormais
remplacé par l'auto-disable et DefaultLoginHandler.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Commands are now hidden from help and return ErrUnknownCommand when
invoked if their hook is nil (and for version, if Version string is
also empty). No explicit DisabledCommands needed for MCPs that don't
use login/setup/config/etc.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Commands listed in DisabledCommands are excluded from global help output
and return ErrUnknownCommand when invoked or help is requested for them.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When Hooks.Login is nil, Run() now handles the login command directly
using LoginBitwarden with BinaryName as the service name, removing
the need for glue code in each consumer binary.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
