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.
Choix menu ••• : NE PAS casser le comportement natif
ObsiGate est le seul hôte à gérer réellement menu via onAction (il déclenche son propre #header-menu-btn) : cette branche est INCHANGÉE. Avec le nouveau JS, un onAction existant garde la main — le menu natif ObsiGate est donc préservé tel quel, et le menu par défaut v0.1.6 ne s'ouvrira que si l'hôte choisit un jour de retourner false pour menu (choix volontairement non fait ici).
Choix avatar
<span id="draco-avatar"> → vrai <button id="draco-avatar" data-act="compte" aria-haspopup="menu" aria-expanded="false">, neutre ✦ conservé sans nom, title="" conservé. L'id est préservé pour que le remplissage existant depuis /api/auth/me (initiale + title depuis display_name/username) continue de fonctionner ; le nouveau JS rafraîchit d'ailleurs l'avatar à chaque ouverture du menu compte, ce qui couvre ce remplissage différé. 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).
Ce qui n'a PAS été changé
Réécriture DRACO_URLS existante (href rendus + réécriture au parsing) : inchangée. Note de résolution : le nouveau JS s'exécute en defer, donc après cette réécriture ; sur un hôte -dev, la dérivation v0.1.6 (étape 2) s'applique avant le href rendu (étape 3), comme le prescrit le contrat — sans cfg.urls explicite ajouté 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 — ObsiGate
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
- `frontend/index.html` (fragment inline ~l.339) — en-tête vendangé v0.1.4 → v0.1.6 ; bouton ••• : `aria-expanded` ajouté ; avatar (voir ci-dessous). RIEN d'autre dans ce fichier.
- `frontend/draco-barre.js` — copie verbatim de `ui/barre-apps/barre-apps.js` (branche commons #1).
- `frontend/draco-barre.css` — copie verbatim de `ui/barre-apps/barre-apps.css` (styles menus •••/compte + avatar bouton).
## Choix menu ••• : NE PAS casser le comportement natif
ObsiGate est le seul hôte à gérer réellement `menu` via `onAction` (il déclenche son propre `#header-menu-btn`) : cette branche est INCHANGÉE. Avec le nouveau JS, un `onAction` existant garde la main — le menu natif ObsiGate est donc préservé tel quel, et le menu par défaut v0.1.6 ne s'ouvrira que si l'hôte choisit un jour de retourner `false` pour `menu` (choix volontairement non fait ici).
## Choix avatar
`<span id="draco-avatar">` → vrai `<button id="draco-avatar" data-act="compte" aria-haspopup="menu" aria-expanded="false">`, neutre `✦` conservé sans nom, `title=""` conservé. L'`id` est préservé pour que le remplissage existant depuis `/api/auth/me` (initiale + `title` depuis `display_name`/`username`) continue de fonctionner ; le nouveau JS rafraîchit d'ailleurs l'avatar à chaque ouverture du menu compte, ce qui couvre ce remplissage différé. 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).
## Ce qui n'a PAS été changé
- Réécriture `DRACO_URLS` existante (href rendus + réécriture au parsing) : inchangée. Note de résolution : le nouveau JS s'exécute en `defer`, donc après cette réécriture ; sur un hôte `-dev`, la dérivation v0.1.6 (étape 2) s'applique avant le href rendu (étape 3), comme le prescrit le contrat — sans `cfg.urls` explicite ajouté ici.
- Menu natif ObsiGate, recherche native, rail, domaine, 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 — ObsiGate
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
frontend/index.html(fragment inline ~l.339) — en-tête vendangé v0.1.4 → v0.1.6 ; bouton ••• :aria-expandedajouté ; avatar (voir ci-dessous). RIEN d'autre dans ce fichier.frontend/draco-barre.js— copie verbatim deui/barre-apps/barre-apps.js(branche commons #1).frontend/draco-barre.css— copie verbatim deui/barre-apps/barre-apps.css(styles menus •••/compte + avatar bouton).Choix menu ••• : NE PAS casser le comportement natif
ObsiGate est le seul hôte à gérer réellement
menuviaonAction(il déclenche son propre#header-menu-btn) : cette branche est INCHANGÉE. Avec le nouveau JS, unonActionexistant garde la main — le menu natif ObsiGate est donc préservé tel quel, et le menu par défaut v0.1.6 ne s'ouvrira que si l'hôte choisit un jour de retournerfalsepourmenu(choix volontairement non fait ici).Choix avatar
<span id="draco-avatar">→ vrai<button id="draco-avatar" data-act="compte" aria-haspopup="menu" aria-expanded="false">, neutre✦conservé sans nom,title=""conservé. L'idest préservé pour que le remplissage existant depuis/api/auth/me(initiale +titledepuisdisplay_name/username) continue de fonctionner ; le nouveau JS rafraîchit d'ailleurs l'avatar à chaque ouverture du menu compte, ce qui couvre ce remplissage différé. 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).Ce qui n'a PAS été changé
DRACO_URLSexistante (href rendus + réécriture au parsing) : inchangée. Note de résolution : le nouveau JS s'exécute endefer, donc après cette réécriture ; sur un hôte-dev, la dérivation v0.1.6 (étape 2) s'applique avant le href rendu (étape 3), comme le prescrit le contrat — sanscfg.urlsexplicite ajouté ici.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.