Fusion #145 — adoption de l'amorçage conditionnée, et #144 (part Kanbante)
Version 0.46.5 (série 0.46.x, base main 0.46.4 revérifiée avant clonage). La PR #87 (0.47.0, métadonnées des jetons) n'est pas touchée ; le numéro en 0.46.x reste valide qu'elle fusionne avant ou après. Aucune fusion — à fusionner sur l'ordre de Bruno.
Sur une instance fraîche, le premier visiteur du pont /auth/draco adoptait le compte administrateur d'amorçage (« liaison au premier passage » de resolve_draco_user()) — prouvé par l'audit « compte partout » : « dan », simple user, est devenu l'admin local d'une instance neuve.
Le correctif (app/accounts.py, app/main.py)
L'adoption de l'amorçage (unique compte, admin actif, sans liaison) n'a désormais lieu que si :
(a) le sub entrant est « administrateur » pour kanbante au registre des rôles du Hub — le pont consultait déjà le registre (HUB-19) avant la résolution ; il transmet maintenant le rôle à resolve_draco_user(..., role_hub=...). Repli propre : Hub muet / rôle inconnu / rôle moindre → pas d'adoption ;
(b) ou l'adoption est initiée depuis une session native déjà authentifiée (liaison explicite par l'utilisateur connecté : pont avec session native ouverte, ou connexion native doublement connectée — mécanismes existants, désormais documentés comme la voie (b), drapeau liaison_session_native sur la résolution directe).
Tout autre sub inconnu reçoit le parcours JIT ordinaire : compte membre propre, jamais l'amorçage. La correspondance existante (cas de production : amorçage déjà lié) résout inchangée. /api/search, qui ne consulte pas le registre, ne peut plus adopter l'amorçage du tout. Documentation mise à jour : docs/correspondance-draco.md.
L'échec du formulaire local ne rend plus le seul « Identifiants incorrects. » : identifiant sans compte local → le message le dit et suggère « Se connecter avec ObsiGate (SSO) » (le bouton déjà présent sur l'écran, libellé inchangé) ; mauvais mot de passe sur un compte local → même renvoi au SSO. Un compte créé au Hub n'a pas de mot de passe local (il vit chez ObsiGate) : l'impasse muette disparaît.
Tests
Nouveau tests/test_amorcage_pont.py — instance réellement fraîche par test (base SQLite temporaire : seul le compte d'amorçage, sans liaison) : (i) sub simple utilisateur → JIT membre propre, amorçage intact non lié ; (ii) sub administrateur au registre → adoption ; (ii-bis) Hub muet → pas d'adoption ; (iii) liaison existante → résolution inchangée ; (iv) session native authentifiée → liaison explicite (pont + résolution directe) ; échecs de formulaire #144. Le test historique d'amorçage de tests/test_draco_correspondance.py simule désormais le rôle « administrateur » du registre ; docstring de tests/test_draco_sso.py aligné.
Périmètre ciblé (pont + correspondance + rôles + SSO + auth) : 49 réussis en relance complète — une première passe avait vu 1 échec httpx.InvalidURL (fonds d'environnement de la VM : variables proxy/no_proxy, connu), non reproduit à la relance ni en exécution isolée. Suite complète comparée à l'arbre vierge dans le rapport du chantier.
Chevauchement signalé
La PR #88 ouverte (HUB-21, réglages du Hub) touche aussi VERSION, CHANGELOG.md et app/main.py : conflits de fusion possibles sur ces trois fichiers si elle fusionne d'abord — aucun fichier métier en commun (elle ajoute app/hub_reglages.py, _header.html, la recherche ; ici : app/accounts.py, le pont et le login de app/main.py, la documentation et les tests).
## Fusion #145 — adoption de l'amorçage conditionnée, et #144 (part Kanbante)
Version **0.46.5** (série 0.46.x, base `main` 0.46.4 revérifiée avant clonage). La PR #87 (0.47.0, métadonnées des jetons) n'est **pas touchée** ; le numéro en 0.46.x reste valide qu'elle fusionne avant ou après. **Aucune fusion** — à fusionner sur l'ordre de Bruno.
### #145 — le trou
Sur une instance fraîche, le premier visiteur du pont `/auth/draco` adoptait le compte administrateur d'amorçage (« liaison au premier passage » de `resolve_draco_user()`) — prouvé par l'audit « compte partout » : « dan », simple `user`, est devenu l'admin local d'une instance neuve.
### Le correctif (`app/accounts.py`, `app/main.py`)
L'adoption de l'amorçage (unique compte, admin actif, sans liaison) n'a désormais lieu que si :
- **(a)** le `sub` entrant est **« administrateur » pour kanbante au registre des rôles du Hub** — le pont consultait déjà le registre (HUB-19) avant la résolution ; il transmet maintenant le rôle à `resolve_draco_user(..., role_hub=...)`. Repli propre : Hub muet / rôle inconnu / rôle moindre → **pas d'adoption** ;
- **(b)** ou l'adoption est initiée depuis une **session native déjà authentifiée** (liaison explicite par l'utilisateur connecté : pont avec session native ouverte, ou connexion native doublement connectée — mécanismes existants, désormais documentés comme la voie (b), drapeau `liaison_session_native` sur la résolution directe).
Tout autre `sub` inconnu reçoit le parcours JIT ordinaire : compte **membre** propre, jamais l'amorçage. La correspondance existante (cas de production : amorçage déjà lié) résout inchangée. `/api/search`, qui ne consulte pas le registre, ne peut plus adopter l'amorçage du tout. Documentation mise à jour : `docs/correspondance-draco.md`.
### #144 — part Kanbante
L'échec du formulaire local ne rend plus le seul « Identifiants incorrects. » : identifiant sans compte local → le message le dit et suggère « Se connecter avec ObsiGate (SSO) » (le bouton déjà présent sur l'écran, libellé inchangé) ; mauvais mot de passe sur un compte local → même renvoi au SSO. Un compte créé au Hub n'a pas de mot de passe local (il vit chez ObsiGate) : l'impasse muette disparaît.
### Tests
Nouveau `tests/test_amorcage_pont.py` — instance **réellement fraîche** par test (base SQLite temporaire : seul le compte d'amorçage, sans liaison) : (i) `sub` simple utilisateur → JIT membre propre, amorçage intact non lié ; (ii) `sub` administrateur au registre → adoption ; (ii-bis) Hub muet → pas d'adoption ; (iii) liaison existante → résolution inchangée ; (iv) session native authentifiée → liaison explicite (pont + résolution directe) ; échecs de formulaire #144. Le test historique d'amorçage de `tests/test_draco_correspondance.py` simule désormais le rôle « administrateur » du registre ; docstring de `tests/test_draco_sso.py` aligné.
Périmètre ciblé (pont + correspondance + rôles + SSO + auth) : **49 réussis** en relance complète — une première passe avait vu 1 échec `httpx.InvalidURL` (fonds d'environnement de la VM : variables proxy/`no_proxy`, connu), non reproduit à la relance ni en exécution isolée. Suite complète comparée à l'arbre vierge dans le rapport du chantier.
### Chevauchement signalé
La PR #88 ouverte (HUB-21, réglages du Hub) touche aussi `VERSION`, `CHANGELOG.md` et `app/main.py` : conflits de fusion possibles sur ces trois fichiers si elle fusionne d'abord — aucun fichier métier en commun (elle ajoute `app/hub_reglages.py`, `_header.html`, la recherche ; ici : `app/accounts.py`, le pont et le login de `app/main.py`, la documentation et les tests).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fusion #145 — adoption de l'amorçage conditionnée, et #144 (part Kanbante)
Version 0.46.5 (série 0.46.x, base
main0.46.4 revérifiée avant clonage). La PR #87 (0.47.0, métadonnées des jetons) n'est pas touchée ; le numéro en 0.46.x reste valide qu'elle fusionne avant ou après. Aucune fusion — à fusionner sur l'ordre de Bruno.#145 — le trou
Sur une instance fraîche, le premier visiteur du pont
/auth/dracoadoptait le compte administrateur d'amorçage (« liaison au premier passage » deresolve_draco_user()) — prouvé par l'audit « compte partout » : « dan », simpleuser, est devenu l'admin local d'une instance neuve.Le correctif (
app/accounts.py,app/main.py)L'adoption de l'amorçage (unique compte, admin actif, sans liaison) n'a désormais lieu que si :
subentrant est « administrateur » pour kanbante au registre des rôles du Hub — le pont consultait déjà le registre (HUB-19) avant la résolution ; il transmet maintenant le rôle àresolve_draco_user(..., role_hub=...). Repli propre : Hub muet / rôle inconnu / rôle moindre → pas d'adoption ;liaison_session_nativesur la résolution directe).Tout autre
subinconnu reçoit le parcours JIT ordinaire : compte membre propre, jamais l'amorçage. La correspondance existante (cas de production : amorçage déjà lié) résout inchangée./api/search, qui ne consulte pas le registre, ne peut plus adopter l'amorçage du tout. Documentation mise à jour :docs/correspondance-draco.md.#144 — part Kanbante
L'échec du formulaire local ne rend plus le seul « Identifiants incorrects. » : identifiant sans compte local → le message le dit et suggère « Se connecter avec ObsiGate (SSO) » (le bouton déjà présent sur l'écran, libellé inchangé) ; mauvais mot de passe sur un compte local → même renvoi au SSO. Un compte créé au Hub n'a pas de mot de passe local (il vit chez ObsiGate) : l'impasse muette disparaît.
Tests
Nouveau
tests/test_amorcage_pont.py— instance réellement fraîche par test (base SQLite temporaire : seul le compte d'amorçage, sans liaison) : (i)subsimple utilisateur → JIT membre propre, amorçage intact non lié ; (ii)subadministrateur au registre → adoption ; (ii-bis) Hub muet → pas d'adoption ; (iii) liaison existante → résolution inchangée ; (iv) session native authentifiée → liaison explicite (pont + résolution directe) ; échecs de formulaire #144. Le test historique d'amorçage detests/test_draco_correspondance.pysimule désormais le rôle « administrateur » du registre ; docstring detests/test_draco_sso.pyaligné.Périmètre ciblé (pont + correspondance + rôles + SSO + auth) : 49 réussis en relance complète — une première passe avait vu 1 échec
httpx.InvalidURL(fonds d'environnement de la VM : variables proxy/no_proxy, connu), non reproduit à la relance ni en exécution isolée. Suite complète comparée à l'arbre vierge dans le rapport du chantier.Chevauchement signalé
La PR #88 ouverte (HUB-21, réglages du Hub) touche aussi
VERSION,CHANGELOG.mdetapp/main.py: conflits de fusion possibles sur ces trois fichiers si elle fusionne d'abord — aucun fichier métier en commun (elle ajouteapp/hub_reglages.py,_header.html, la recherche ; ici :app/accounts.py, le pont et le login deapp/main.py, la documentation et les tests).