Dernier état `.ideai/` du sprint serveur embarqué, séparé du code applicatif conformément aux précédents `f965f64` / `7fbaa8e` / `5ee25d1`. - #68 passé en `qa`, pas en `closed` : mergé dans `develop` (`b30c9c7`) et vert, mais RIEN n'a été cliqué dans l'app réelle. « Mergé » ne veut pas dire « validé » — même distinction que pour #69 et son lot 3. - Carnet de #68 : périmètre livré, réserve « aucune validation live », et la dette identifiée (ordre de `preview_settings` qui verrouille la liste des candidats LAN, warning `missingTrustedProxy` inatteignable). - Mémoire projet : note `sandbox-eperm-bind-false-green-web-server`. Elle capitalise le piège qui s'est refermé DEUX FOIS le 2026-07-16 : les sandboxes de DevBackend et QA refusent `TcpListener::bind`, donc tout `cargo test` sur `web-server`/`app-tauri` y rend un vert qui ne prouve rien. La première fois, ce faux vert masquait un vrai bug produit — un serveur embarqué sur port éphémère rejetait toutes les requêtes API en 403. La règle qui en sort : aucun repli EPERM silencieux, et tout vert sur ces crates doit être produit hors sandbox. - Journal des tâches de fond : complétions enregistrées. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
16 lines
663 B
Markdown
16 lines
663 B
Markdown
---
|
|
id: "13821b24-f566-402e-bc10-02ac6e8a5f7c"
|
|
number: 68
|
|
title: "Ajouter dans l'app desktop, la possibilité d'activer le serveur"
|
|
status: "qa"
|
|
priority: "medium"
|
|
sprint: "028179b1-eaf4-41e9-9c1f-7c37125117e6"
|
|
links: [{"target":"#65","kind":"dependsOn"}]
|
|
agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
|
|
createdBy: {"kind":"user"}
|
|
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
|
createdAt: 1784193318419
|
|
updatedAt: 1784238387151
|
|
version: 7
|
|
---
|
|
J'iamerais que depuis l'app desktop, on puisse quand même embarquer le serveur. Comme ça un utilisateur pourrait continuer son travail en cours en remote |