Source : Projets/dracodev-commons PR #1, branche barre-apps-derivation-dev-v0.1.6 (barre v0.1.6). JS/CSS repris verbatim depuis cette branche, relus sur place — pas de recopie de mémoire. Agent-commun n'utilise pas la barre : non touché. Rien mergé, rien publié, aucune issue fermée, VERSION non bumpée dans cette PR.
Vérifié sur place : l'hôte ne gérait PAS réellement menu — la branche existante n'était qu'un toast placeholder « Menu commun : arrive avec la fédération ». Choix : le placeholder est remplacé par if (act === "menu") { return false; } (commenté), qui demande explicitement le menu par défaut v0.1.6 (Console agent + 4 applications, URL résolues donc dérivées -dev sur un hôte -dev). Supprimer simplement la branche n'aurait pas suffi : avec un onAction existant, le nouveau JS laisse la main à l'hôte sauf retour false. Toutes les autres branches onAction sont inchangées ; le panneau Spark (draco-panneau.js, agent_url) n'est pas touché.
Choix avatar
<span> → vrai <button data-act="compte" aria-haspopup="menu" aria-expanded="false">, initiale préservée (draco_avatar = initiale auth_user ou K, cf. app/main.py) et title="Opérateur Kanbante" conservé dans le HTML servi. Adaptation nécessaire, documentée dans le fragment : ajout de user: "{{ draco_avatar }}" dans DRACO_BAR_CONFIG — sans cfg.user, le nouveau JS dériverait l'initiale du title (« Opérateur Kanbante » → « O »), qui est un libellé de rôle et non un nom. Contrepartie honnête : syncAvatar() (v0.1.6) réécrit aussi le title avec le nom d'affichage, donc l'infobulle devient l'initiale après chargement. Le menu compte affiche l'identité ; Profil/Déconnexion sont relayés mais non gérés par l'hôte (même limite que dans le contrat commons, pas de gestionnaire inventé ici).
node --check OK sur le JS vendangé ; logique de dérivation présente (resolveUrls, isDevHost, og-dev/agent-dev).
Test commons re-exécuté sur les fichiers exacts de la branche #1 : 21 passés, 0 échoué ; 75 assertions, 0 en échec.
Aucun DRACO_BAR_CONFIG.urls ajouté : la config explicite reste prioritaire partout (ordre : explicite > hôte -dev dérivé > href rendu > défaut prod) ; aucun secret dans le code.
Aucune capture, aucun test déployé : la vérification en direct des liens sur les hôtes -dev reste à faire après merge/release, comme le prescrit fusion-trois-apps #60.
# barre-apps v0.1.6 — Kanbante
Source : Projets/dracodev-commons PR #1, branche barre-apps-derivation-dev-v0.1.6 (barre v0.1.6). JS/CSS repris verbatim depuis cette branche, relus sur place — pas de recopie de mémoire. Agent-commun n'utilise pas la barre : non touché. Rien mergé, rien publié, aucune issue fermée, VERSION non bumpée dans cette PR.
## Fichiers changés
- `app/templates/_draco_bar.html` — en-tête vendangé v0.1.4 → v0.1.6 ; bouton ••• : `aria-expanded` ajouté ; avatar ; `cfg.user` ajouté ; branche `menu` remplacée (voir ci-dessous).
- `static/js/draco-barre.js` — copie verbatim de `ui/barre-apps/barre-apps.js` (branche commons #1).
- `static/css/draco-barre.css` — copie verbatim de `ui/barre-apps/barre-apps.css` (styles menus •••/compte + avatar bouton).
## Choix menu •••
Vérifié sur place : l'hôte ne gérait PAS réellement `menu` — la branche existante n'était qu'un toast placeholder « Menu commun : arrive avec la fédération ». Choix : le placeholder est remplacé par `if (act === "menu") { return false; }` (commenté), qui demande explicitement le menu par défaut v0.1.6 (Console agent + 4 applications, URL résolues donc dérivées `-dev` sur un hôte `-dev`). Supprimer simplement la branche n'aurait pas suffi : avec un `onAction` existant, le nouveau JS laisse la main à l'hôte sauf retour `false`. Toutes les autres branches `onAction` sont inchangées ; le panneau Spark (`draco-panneau.js`, `agent_url`) n'est pas touché.
## Choix avatar
`<span>` → vrai `<button data-act="compte" aria-haspopup="menu" aria-expanded="false">`, initiale préservée (`draco_avatar` = initiale `auth_user` ou `K`, cf. `app/main.py`) et `title="Opérateur Kanbante"` conservé dans le HTML servi. Adaptation nécessaire, documentée dans le fragment : ajout de `user: "{{ draco_avatar }}"` dans `DRACO_BAR_CONFIG` — sans `cfg.user`, le nouveau JS dériverait l'initiale du `title` (« Opérateur Kanbante » → « O »), qui est un libellé de rôle et non un nom. Contrepartie honnête : `syncAvatar()` (v0.1.6) réécrit aussi le `title` avec le nom d'affichage, donc l'infobulle devient l'initiale après chargement. Le menu compte affiche l'identité ; Profil/Déconnexion sont relayés mais non gérés par l'hôte (même limite que dans le contrat commons, pas de gestionnaire inventé ici).
## Ce qui n'a PAS été changé
- Onglets, href rendus (`draco_urls` injectés depuis `app.config`), compteurs, domaine, rail, palette, alertes, Spark : inchangés.
- Aucun `DRACO_BAR_CONFIG.urls` ajouté.
## Vérifications (chiffres réels)
- JS vendangé : 491 lignes (ancien : 128), CSS : 193 lignes (ancien : 166) ; diff JS/CSS vs commons v0.1.6 = vide.
- `node --check` OK sur le JS vendangé ; logique de dérivation présente (`resolveUrls`, `isDevHost`, `og-dev`/`agent-dev`).
- Test commons re-exécuté sur les fichiers exacts de la branche #1 : 21 passés, 0 échoué ; 75 assertions, 0 en échec.
- Aucun `DRACO_BAR_CONFIG.urls` ajouté : la config explicite reste prioritaire partout (ordre : explicite > hôte -dev dérivé > href rendu > défaut prod) ; aucun secret dans le code.
- Aucune capture, aucun test déployé : la vérification en direct des liens sur les hôtes -dev reste à faire après merge/release, comme le prescrit fusion-trois-apps #60.
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.
barre-apps v0.1.6 — Kanbante
Source : Projets/dracodev-commons PR #1, branche barre-apps-derivation-dev-v0.1.6 (barre v0.1.6). JS/CSS repris verbatim depuis cette branche, relus sur place — pas de recopie de mémoire. Agent-commun n'utilise pas la barre : non touché. Rien mergé, rien publié, aucune issue fermée, VERSION non bumpée dans cette PR.
Fichiers changés
app/templates/_draco_bar.html— en-tête vendangé v0.1.4 → v0.1.6 ; bouton ••• :aria-expandedajouté ; avatar ;cfg.userajouté ; branchemenuremplacée (voir ci-dessous).static/js/draco-barre.js— copie verbatim deui/barre-apps/barre-apps.js(branche commons #1).static/css/draco-barre.css— copie verbatim deui/barre-apps/barre-apps.css(styles menus •••/compte + avatar bouton).Choix menu •••
Vérifié sur place : l'hôte ne gérait PAS réellement
menu— la branche existante n'était qu'un toast placeholder « Menu commun : arrive avec la fédération ». Choix : le placeholder est remplacé parif (act === "menu") { return false; }(commenté), qui demande explicitement le menu par défaut v0.1.6 (Console agent + 4 applications, URL résolues donc dérivées-devsur un hôte-dev). Supprimer simplement la branche n'aurait pas suffi : avec unonActionexistant, le nouveau JS laisse la main à l'hôte sauf retourfalse. Toutes les autres branchesonActionsont inchangées ; le panneau Spark (draco-panneau.js,agent_url) n'est pas touché.Choix avatar
<span>→ vrai<button data-act="compte" aria-haspopup="menu" aria-expanded="false">, initiale préservée (draco_avatar= initialeauth_userouK, cf.app/main.py) ettitle="Opérateur Kanbante"conservé dans le HTML servi. Adaptation nécessaire, documentée dans le fragment : ajout deuser: "{{ draco_avatar }}"dansDRACO_BAR_CONFIG— sanscfg.user, le nouveau JS dériverait l'initiale dutitle(« Opérateur Kanbante » → « O »), qui est un libellé de rôle et non un nom. Contrepartie honnête :syncAvatar()(v0.1.6) réécrit aussi letitleavec le nom d'affichage, donc l'infobulle devient l'initiale après chargement. Le menu compte affiche l'identité ; Profil/Déconnexion sont relayés mais non gérés par l'hôte (même limite que dans le contrat commons, pas de gestionnaire inventé ici).Ce qui n'a PAS été changé
draco_urlsinjectés depuisapp.config), compteurs, domaine, rail, palette, alertes, Spark : inchangés.DRACO_BAR_CONFIG.urlsajouté.Vérifications (chiffres réels)
node --checkOK sur le JS vendangé ; logique de dérivation présente (resolveUrls,isDevHost,og-dev/agent-dev).DRACO_BAR_CONFIG.urlsajouté : la config explicite reste prioritaire partout (ordre : explicite > hôte -dev dérivé > href rendu > défaut prod) ; aucun secret dans le code.