Registre des retours utilisateurs (crash tests, entretiens, Tchap), codifiés et traçables. Sens unique : un retour brut → un finding ici (
AC-R###) → un ticketBACKLOG.md(<- AC-R###) → un scénarioTESTS.md. Les verbatims détaillés et l'identité des testeurs restent hors du repo (notes de recherche privées). Ici : finding anonymisé + source légère.
Légende
- Type : 🐛 bug · 🎛️ UX/friction · ✨ feature · ⚙️ infra · ❓ question/doute
- Sévérité : 🔴 bloquant · 🟠 majeur · 🟡 mineur
- Statut : 🆕 à trier · 📥 backlogué · 🔧 en cours · ✅ traité · ⛔ rejeté
| AC-R035 | ⚙️ | 🟠 | Absorption d'agent-vm dans le bundle : le code est vendored sous vendor/vm/, plus de clone GitHub, plus de shim agent-vm sur le PATH. Installation OpenCode-only (--preinstall=node,gh,chromium,opencode). chrome-devtools MCP géré au niveau projet (pas global VM). | Chantier technique 2026-07-07 | ✅ traité | BACKLOG.md EPIC 7 · TESTS.md S39 |
| ID | Type | Sév | Retour | Source | Statut | Renvoi |
|---|---|---|---|---|---|---|
| AC-R001 | 🐛 | 🔴 | Après ./install.sh, agent-vm reste introuvable dans le même terminal (fonction shell sourcée, non chargée dans le shell parent), même après relance de l'installeur. |
Crash test 2026-07-02, profil dev power user | ✅ traité | BACKLOG.md T-FIX-11 · TESTS.md S15 |
| AC-R002 | 🎛️ | 🟠 | Les messages « ✓ agent-vm cloné / sourcé » laissent croire que la commande est utilisable immédiatement, alors qu'elle ne l'est pas. | Crash test 2026-07-02, profil dev power user | ✅ traité | BACKLOG.md T-FIX-11 |
| AC-R003 | 🎛️ | 🟡 | Chemin ~/Dev/… codé en dur (défauts + README + doc) : convention personnelle qui ne doit pas fuiter dans un installeur distribué. |
Revue interne 2026-07-02 | ✅ traité | BACKLOG.md T-FIX-12 |
| AC-R004 | ⚙️ | 🟠 | Absence de prompt caching (Scaleway ; à confirmer côté Albert API) → coût x~10 sur un usage code-harness. Considéré comme prérequis, surtout gros modèles. | Crash test 2026-07-02, profil dev power user | 🆕 à trier | — |
| AC-R005 | ❓ | 🟡 | Certaines skills ne se déclenchent pas dans OpenCode/Vibe (/skill → l'agent ne fait rien) : question de harness/compatibilité vs Claude Code. |
Crash test 2026-07-02, profil dev power user | 🆕 à trier | — |
| AC-R006 | 🎛️ | 🟠 | Le hint de scaffold (phase_b) affiche un chemin hardcodé ~/albert-code/install.sh au lieu du chemin réel ($SELF_DIR) → copier-coller cassé si le dépôt est cloné ailleurs (ex. ~/Dev/albert-code). Régression de T-FIX-12. |
Dogfood 2026-07-02 | ✅ traité | BACKLOG.md T-FIX-13 · TESTS.md S16 |
| AC-R007 | 🐛 | 🔴 | Après une install fraîche, agent-vm opencode échoue (Base VM not found. Run 'agent-vm setup' first.) : install.sh ne crée pas la VM de base et le message « Prochaines étapes » ne mentionne pas agent-vm setup. Onboarding cassé pour tout nouvel utilisateur. |
Dogfood 2026-07-02 | ✅ traité | BACKLOG.md T-FIX-14 · TESTS.md S17 |
| AC-R008 | ⚙️ | 🟠 | Des notes de validation / sorties de dry-run collées dans le dépôt public fuitent le chemin home absolu personnel (/Users/<name>/…) et le username. Même classe que AC-R003 mais autre vecteur (docs, pas code). Instance neutralisée au pré-vol (note S16), mais rien n'empêche la récidive. |
Pré-vol commit 2026-07-02 | ✅ traité | BACKLOG.md T4.5 · TESTS.md S18 |
| AC-R009 | 🎛️ | 🟡 | L'installeur signale « OpenCode absent du PATH » et suggère un contournement hors-VM (npm i -g opencode-ai). Contraire à la doctrine Albert Code = usage exclusivement via agent-vm (bulle isolée) ; ne pas proposer de bypass de l'isolation. Redondance en prime (« absent du PATH » ×2). |
Dogfood 2026-07-02 | ✅ traité | BACKLOG.md T-FIX-15 |
| AC-R010 | ⚙️ | 🟠 | Ressources VM par défaut d'agent-vm trop justes pour du code (1 CPU / 3 GiB / 10 GiB). En usage réel il faut ~4 CPU / 8 GiB / 30 GiB. agent-vm n'a pas de défaut configurable par env → Albert Code doit fixer une taille adaptée (disque au setup, cpu/mémoire au lancement) sans sur-allouer sur petite machine. |
Dogfood 2026-07-02 | ✅ traité | BACKLOG.md T1.4 · TESTS.md S20 |
| AC-R011 | 🎛️ | 🟡 | context7 est enabled: true en dur dans opencode.template.json alors qu'il exige CONTEXT7_API_KEY → pour un utilisateur sans clé, le MCP échoue (401 / bearer vide) au démarrage dans la VM et s'affiche « cassé ». T1.1 notait « rendre le MCP optionnel/skippable si pas de clé » — pas encore fait. |
Revue config dogfood 2026-07-02 | ✅ traité | BACKLOG.md T1.5 · TESTS.md S28 |
| AC-R012 | 🎛️ | 🟠 | Scaffold dans un repo ayant DÉJÀ un opencode.json : le fichier est conservé (non-destructif) → le provider albert n'est pas ajouté → Albert ne se connecte pas dans la VM, et l'installeur affiche seulement « conservé » sans avertir que le merge n'a pas eu lieu. Footgun silencieux. |
Dogfood 2026-07-02 | ✅ traité | BACKLOG.md T1.6 ⊃ T7.7 · TESTS.md S45 |
| AC-R013 | 🎛️ | 🟠 | Albert Code onboarde « coder dans la VM » mais pas « committer/pusher depuis la VM » : ni l'identité git (user.name/user.email) ni la clé SSH ne sont configurées dans la VM, alors que le README promet « l'agent pousse des PR depuis la VM ». L'agent tombe sur Author identity unknown. Rappel : SSH (auth) ≠ identité de commit. |
Dogfood 2026-07-02 | ✅ traité | BACKLOG.md T1.8, T2-CH2 · TESTS.md S23, S31, S40 |
| AC-R014 | ✨ | 🟠 | Test d'install S28 : l'interface à 3 verbes (install / setup / run) facilite la vie de l'utilisateur : une commande albert-code unique au lieu de mémoriser install.sh + agent-vm setup + agent-vm opencode. |
Test utilisateur S28 2026-07 | ✅ traité | BACKLOG.md T6.1 · TESTS.md S25 |
| AC-R015 | 🎛️ | 🟡 | Manque de pédagogie sur agent-vm : c'est quoi cette « VM bulle isolée » dont tout le monde parle ? Un non-dev ne comprend pas pourquoi on a besoin d'une VM, ni ce que ça fait concrètement. | Test utilisateur S28 2026-07 | ✅ traité | BACKLOG.md T6.2 · TESTS.md S26 |
| AC-R016 | 🎛️ | 🟡 | Choix de profil (beta.gouv / La Suite / IAE / Autre) déroutant pour qui n'est pas familier de cette typologie. Question posée trop tôt, avant toute configuration. La valeur « Autre » donne l'impression d'avoir choisi par défaut. | Test utilisateur S28 2026-07 | ✅ traité | BACKLOG.md T6.3 · TESTS.md S6, S27 |
| AC-R017 | ✨ | 🟠 | Au setup, on aimerait choisir quelles skills et MCP on branche (Y/N). La config ouverte ne donne aucun contexte de ce qu'apporte chaque brique — « est-ce que j'ai besoin de playwright pour mon projet ? » | Test utilisateur S28 2026-07 | ✅ traité | BACKLOG.md T6.4 · TESTS.md S28, S29 |
| AC-R018 | 🎛️ | 🟡 | Bascule FR->EN vers le wizard agent-vm : quand install.sh passe la main à agent-vm setup, le wizard natif d'agent-vm (en anglais) s'affiche sans prévenir. Déroutant pour un public non-tech francophone. |
Dogfood install 2026-07 | ✅ traité | BACKLOG.md T6.5 · TESTS.md S30 |
| AC-R019 | 🐛 | 🔴 | À l'étape auth GitHub, install.sh demande « Email noreply GitHub » avec pour défaut le vrai email de l'utilisateur, qui échoue la validation. Un utilisateur non-tech ne connaît pas son email noreply ni comment le trouver. |
Dogfood install 2026-07 | ✅ traité | BACKLOG.md T6.6 · BACKLOG.md T2-CH2 · TESTS.md S31, S40 |
| AC-R020 | ⚙️ | 🟠 | agent-vm setup installe 4 harnais (Claude Code, OpenCode, Codex, Mistral Vibe). En test réel, l'installeur Mistral Vibe a retourné HTTP 429 (rate limit) et TOUT le setup a échoué, alors qu'Albert Code n'a besoin que d'OpenCode. Un seul installeur qui rate = base non finalisée. Le retry a fonctionné (429 transitoire), mais risque de fiabilité à l'install party (plusieurs testeurs en parallèle). Dépendance upstream agent-vm. |
Dogfood install 2026-07 | 📥 backlogué | BACKLOG.md T6.7 |
| AC-R021 | 🐛 | 🟠 | (a) install avortée sans shim : install.sh a set -e et install_shim est appelé APRÈS la création fragile de la VM de base. Un échec d'agent-vm setup (429) fait sortir l'installeur en erreur AVANT de poser le shim -> install incomplète, aucune commande albert-code. (b) ancien installeur MVP écrivait une fonction shell albert-code() dans ~/.zshrc, qui masque le shim PATH -> le nouveau shim est ignoré. |
Dogfood install 2026-07 | ✅ traité | BACKLOG.md T6.8 · TESTS.md S32 |
| AC-R022 | 🐛 | 🔴 | Le shim albert-code (généré par install_shim) avale les prompts interactifs : il source le script avec 2>/dev/null (avale stderr où confirm()/prompt_* écrivent) puis appelle $name "$@". Résultat : albert-code setup affiche l'entête puis semble figé (questions MCP/skills invisibles, read attend). |
Dogfood install 2026-07 | ✅ traité | BACKLOG.md T6.9 · TESTS.md S33 |
| AC-R023 | 🎛️ | 🟡 | MCP chrome-devtools présent malgré 0 MCP sélectionné : agent-vm le préinstalle au niveau global de la VM. Pas une fuite (MCP local), mais ça casse la transparence « ce que je choisis = ce que j'ai » du public souveraineté. À cadrer avec Sylvain (agent-vm). |
Dogfood install 2026-07 | 📥 backlogué | BACKLOG.md T6.11 |
| AC-R024 | 🐛 | 🟠 | L'agent scaffold un projet react-dsfr (npm install) puis commit SANS .gitignore -> node_modules/ dans la PR : 41659 fichiers, +5,4M lignes. Hygiène cassée + risque sécurité (sans .gitignore, un .env part aussi facilement). |
Dogfood E2E 2026-07 | ✅ traité | BACKLOG.md T6.10 · TESTS.md S34 |
| AC-R025 | 🐛 | 🟠 | install_shim fait « si le fichier shim existe → return 0 » → quand le contenu change (ex. fix exec d'AC-R022), un git pull && ./install.sh ne repose PAS le nouveau shim. Il faut rm manuel. Pas idempotent pour les mises à jour. |
Dogfood hotfix re-test 2026-07 | ✅ traité | BACKLOG.md T6.12 · TESTS.md S36 |
| AC-R026 | 🐛 | 🟡 | Au boot VM (runtime/agent-vm.runtime.sh, sync_skills), la sortie affiche des lignes parasites « name= » (ex. name=datagouv-apis, name=react-dsfr). Bruit de debug, comptage correct mais gène la lisibilité. |
Dogfood hotfix re-test 2026-07 | ✅ traité | BACKLOG.md T6.13 |
| AC-R027 | 🎛️ | 🟡 | Phase B (setup) commence sans aucun repère visuel — pas d'ASCII art, pas de titre d'étape — alors que Phase A en a. L'utilisateur ne sait pas que la config du projet a commencé. | Dogfood setup 2026-07 | ✅ traité | BACKLOG.md T6.12-p |
| AC-R028 | 🎛️ | 🟡 | Context7 MCP coché au setup mais la clé n'est jamais demandée : le MCP apparaît « cassé » au premier lancement (401). L'utilisateur doit l'activer manuellement après coup. | Dogfood setup 2026-07 | ✅ traité | BACKLOG.md T6.12-p |
| AC-R029 | 🎛️ | 🟡 | print_next_steps est long et encombré : instructions VM de base (déjà faite en Phase A), ligne « Parle en français » (banale), et push GitHub (déjà fait plus haut). Trop de texte tuile finale. | Dogfood setup 2026-07 | ✅ traité | BACKLOG.md T6.12-p |
| AC-R030 | 🎛️ | 🟡 | Le statut GitHub (push/PR OK ou non) apparaît après « ✓ Projet configuré. » dans print_next_steps — ordre illogique : un statut AVANT le ✅ final. | Dogfood setup 2026-07 | ✅ traité | BACKLOG.md T6.12-p |
| AC-R031 | 🎛️ | 🟡 | L'ASCII art actuel ne correspond pas au branding. Remplacer par la police figlet "slant" de "Albert Code" (57 colonnes, tient sous 80). | Feedback Leo Guillaume (Tech Lead Albert API) 2026-07 | ✅ traité | BACKLOG.md T6.14 · TESTS.md S38 |
| AC-R032 | 🎛️ | 🟠 | Les étapes silencieuses et longues (clone agent-vm, clone skills) laissent l'utilisateur sans feedback. Ajouter un spinner (frames braille) pendant ces opérations. | Feedback Leo Guillaume (Tech Lead Albert API) 2026-07 | ✅ traité | BACKLOG.md T6.14 · TESTS.md S38 |
| AC-R033 | 🎛️ | 🟡 | L'utilisateur ne sait pas où il en est dans le setup (Phase B) : pas de compteur d'étapes. Afficher [1/4]..[4/4] serait utile. | Feedback Leo Guillaume (Tech Lead Albert API) 2026-07 | ✅ traité | BACKLOG.md T6.14 · TESTS.md S38 |
| AC-R034 | 🎛️ | 🟡 | En fin de setup, aucun récapitulatif des choix (MCP actifs, skills cochées, statut GitHub). Un panneau récap aide à valider avant de lancer. | Feedback Leo Guillaume (Tech Lead Albert API) 2026-07 | ✅ traité | BACKLOG.md T6.14 · TESTS.md S38 |
| AC-R036 | 🎛️ | 🟠 | UX auth GitHub du wizard : après avoir collé le PAT, le wizard redemande quand même « Nom pour les commits » et « Email noreply GitHub » (pré-remplis), alors que le PAT donne tout via l'API. De plus, si l'utilisateur colle par erreur son token à la question o/N (au lieu de répondre o d'abord), le token est silencieusement ignoré sans message clair. | Feedback bêta-testeur 2026-07-07 (Romaric) | ✅ traité | BACKLOG.md T2-CH2 · TESTS.md S40 |
| AC-R038 | 🎛️ | 🟠 | La clé Context7 est demandée dès albert-code install (phase A.4), avant toute explication du MCP et avant même que l'utilisateur ait choisi de le brancher. À déplacer : ne la demander qu'au setup, si l'utilisateur répond Y à « Installer le MCP context7 ». Aggravant découvert à l'analyse : une clé saisie au setup (chemin AC-R028) est persistée dans le ~/.zshenv hôte mais jamais propagée dans ~/.agent-vm/runtime.sh (ensure_vm_runtime n'est appelé qu'en phase A) : la VM garde CONTEXT7_API_KEY=''. | Onboarding alpha Adrien Carpentier 2026-07-21 | ✅ traité | BACKLOG.md T6.15 · TESTS.md S-ctx-1 à S-ctx-4 |
| AC-R039 | 🎛️ | 🟡 | Les questions Y/n du setup (MCP notamment) n'expliquent pas assez chaque option : un libellé court entre parenthèses, pas de vraie phrase. Un testeur demande deux fois « c'est quoi Context7 ? » pendant l'onboarding. Format cible : une ligne d'explication avant chaque question, « Installer Context7 ? Context7 est un MCP qui permet de [...]. Y/n ». | Onboarding alpha Adrien Carpentier 2026-07-21 | ✅ traité | BACKLOG.md T6.16 · TESTS.md S-ctx-5 |
| AC-R040 | 🎛️ | 🟠 | albert-code run dans un dossier jamais setup (pas de opencode.json) — ou avec un opencode.json sans provider albert — ouvre OpenCode sur ses modèles par défaut, Albert absent de /models, sans aucune alerte. 2 bêta-testeurs piégés (dont un power user), longue session de debug à chaque fois. Généralise T1.6 au cas « pas de fichier ». Fix : garde-fou au run (avertit + confirmation avant de lancer sans Albert) + avertissement au setup sur fichier existant sans albert. | Bêta-testeur 2026-07-21 (Julien Bouquillon, dossier pres-gafam) | ✅ traité | BACKLOG.md T7.7 · TESTS.md S44, S45 |
| AC-R041 | 🐛 | 🟠 | albert-code run ouvre l'écran de help d'OpenCode au lieu du TUI quand la VM a une version d'OpenCode trop ancienne (ex 1.2.9) qui ne connaît pas le flag --auto lancé par le moteur VM (vendor/vm/agent-vm.sh:1167). Le runtime valide la présence d'OpenCode mais pas la compatibilité --auto. Source : bêta-testeur Julien Bouquillon, VM betabot2, 2026-07-21. | Bêta-testeur 2026-07-21 (Julien Bouquillon, VM betabot2) | ✅ traité | BACKLOG.md T8.3 · TESTS.md S47 |
| AC-R042 | ⚙️ | 🔴 | Le catalogue de modèles d'Albert API a churné pendant l'été : alias DeepSeek re-versionné (404), Qwen 3.6 retiré du catalogue (404), Mistral Medium 3.5 en panne (502, statut red dans /health/models). Les trois modèles du bundle sont morts simultanément. Comme les id vivent dans l'opencode.json projet, figé au setup, tous les projets déjà configurés sont cassés et le bundle n'a aucun canal pour leur pousser le correctif. | Reprise post-congés 2026-08-26 | ✅ traité (canal de correction livré) : le finding couvrait l'absence de canal pour pousser le correctif de catalogue — albert-code update (T9.3, lib/phases.sh:257-292) EST ce canal, complété par la réparation auto au setup (T9.2, lib/phases.sh:905-911) et le catalogue canonique T9.1. | BACKLOG.md T9.1 · T9.2 · T9.3 · TESTS.md S48, S54-S58 |
| AC-R043 | 🐛 | 🔴 | Albert Code ne peut plus pousser ni ouvrir de PR depuis la VM : le GH_TOKEN du .zshenv de la VM est un jeton périmé qui renvoie 401 (gh auth status : « Failed to log in »), alors que celui de l'hôte est valide. Deux gardes « ne rien faire si la variable existe » se combinent : persist_zshenv sort avec « déjà présente » dès qu'une ligne export GH_TOKEN= existe, et la ligne posée dans le runtime de la VM n'est plus jamais rafraîchie. Le zsh -l du TUI ressource le .zshenv de la VM, dont l'export périmé écrase la valeur fraîche héritée. Conséquence : sur les dernières PR, l'agent s'est arrêté avant le push et un humain a poussé à la main à chaque fois. | Reprise post-congés 2026-08-26 | ✅ traité | BACKLOG.md EPIC 10 · T10.1 (remplacement d'un secret invalid hôte), T10.2 (réécriture systématique du .zshenv de la VM au boot, auto-réparation), T10.3 à T10.5 suivent · T10.11 (corrige la régression de périmètre de ce finding) |
| AC-R044 | 🐛 | 🔴 | La VM projet peut perdre zsh ou opencode après une mise à jour du moteur de VM : symptômes zsh: command not found : opencode / opencode: command not found, ou messages du moteur de VM. La VM projet n'est pas recréée automatiquement sur la base nominée, laissant l'utilisateur sans issue claire. | Bêta-test juillet 2026, cause racine élucidée le 15/07 | ✅ traité | BACKLOG.md T7.8 · TESTS.md S49 |
| AC-R045 | 🎛️ | 🟠 | Sous Linux avec bash, install_shim pose le shim dans ~/.local/bin et écrit l'ajout au PATH dans ~/.zshenv, jamais lu par bash : albert-code: command not found après une installation pourtant réussie, sans message d'aide. | Revue de parcours Linux 2026-09-01 | ✅ traité | README.md Dépannage · BACKLOG.md T5.4 · TESTS.md S67 |
| AC-R046 | 🎛️ | 🟡 | Prérequis Linux non documentés : le README promet que le script installe Lima, ce qui n'est vrai que via Homebrew ; QEMU et l'accès à /dev/kvm, vérifiés par le code, ne sont annoncés nulle part. | Revue de parcours Linux 2026-09-01 | ✅ traité | README.md Prérequis |
| AC-R047 | 🐛 | 🔴 | albert-code run affiche /bin/bash: line 1: opencode: command not found alors qu'OpenCode est installé dans la VM (~/.opencode/bin). Cause racine : Lima v2.2.0 (publiée le 21/07/2026, PR lima-vm/lima#5194) a introduit un champ user.shell et n'utilise plus le shell de connexion du guest pour limactl shell (défaut /bin/bash) : le chsh de vendor/vm/agent-vm.setup.sh:81 est devenu inopérant, et bash non-login ne lit pas ~/.zshenv où le PATH + secrets sont posés. Fenêtre d'impact : toute installation faite depuis le 21/07/2026, brew install lima n'épinglant pas de version (lib/phases.sh:74). Distinct de AC-R044 (binaire absent après clone périmé). | Dogfood 2026-09-01 | ✅ traité | BACKLOG.md T-FIX-16 · TESTS.md S65 |
| AC-R048 | 🎛️ | 🟠 | La clé Context7 est demandée après les quatre questions MCP, et non au moment où l'utilisateur accepte le connecteur. Deux questions s'intercalent (Playwright, Chrome DevTools), alors que la ligne d'explication promet « Clé gratuite (…), demandée juste après si tu acceptes » : la promesse affichée est fausse et l'utilisateur ne rattache plus la demande de clé au connecteur qu'il vient d'accepter. | Onboarding alpha 2026-09-02 | ✅ traité | BACKLOG.md T6.17 · TESTS.md S-ctx-6 |
| AC-R049 | 🎛️ | 🟠 | La saisie du jeton GitHub se fait sur un libellé unique, sans aucune explication : ni ce qu'est ce jeton, ni à quoi il sert, ni où le créer, ni quelles permissions donner, ni la différence entre jeton classique et fine-grained. Aggravant : le libellé mentionne « scope repo », vocabulaire des jetons classiques, alors que la cible du bundle est un jeton fine-grained (T10.3). Le wizard oriente donc vers le mauvais type de jeton. | Onboarding alpha 2026-09-02 | 📥 backlogué | BACKLOG.md T10.10 |
| AC-R050 | 🎛️ | 🟡 | La commande d'installation du README impose l'emplacement du clone sur la machine de l'utilisateur et passe par ./install.sh, alors que le même README documente plus bas albert-code install. Or cette commande n'existe pas encore à ce stade : le shim est posé par l'installation elle-même. Deux points d'entrée contradictoires, dont un qui ne peut pas fonctionner depuis un clone frais. | Onboarding alpha 2026-09-02 | 📥 backlogué | BACKLOG.md T5.5 |
| AC-R051 | ✨ | 🟠 | Le baseURL d'Albert est codé en dur en quatre endroits du dépôt (config/opencode.template.json:8, programme jq de merge du provider et repli par concaténation quand jq est absent dans lib/phases.sh, plus l'appel GET /v1/models du catalogue), ce qui interdit de passer par un intermédiaire compatible OpenAI sans repatcher après chaque setup. Testé par le rapporteur avec un proxy local, OpenCode tourne sur deepseek-v4-flash, appels d'outils inclus. | Issue publique #36, 2026-09-08 (contributeur externe) | 📥 backlogué | BACKLOG.md T1.9 |
- AC-R004 (prompt caching) : à instruire avant tout scaling. Vérifier si Albert API expose du caching sur
chat/completions; sinon, arbitrer l'infra d'inférence. vLLM implémente le caching nativement. Mesure : sur un usage code-harness, le prompt caching réduit drastiquement le volume de tokens traités — ratio mesuré de l'ordre de 250:1 pour un token réutilisé. La confirmation de l'exposition du caching côté Albert API reste à faire (dépendance d'infra, hors bundle). - AC-R005 (harness skills) : investiguer le déclenchement des skills selon le harness (OpenCode / Vibe / Claude Code). Impacte la portabilité du bundle hors Claude Code.
- AC-R006 / AC-R007 : détectés en dogfood (réinstall complète sur machine remise à zéro le 2026-07-02). R007 est bloquant onboarding (le « next step » affiché échoue). Fixes validés par S16 / S17.
- AC-R008 : fuite récurrente de chemin absolu / username dans un dépôt public. L'instance (note S16) a été neutralisée au pré-vol du commit
7f84d9a; le fix durable est un garde-fou CI (T4.5), pas un edit ponctuel — sinon ça reviendra.