GitRust
actualise le readme
EBO <eric@ebii.fr> committé le 2026-09-26 14:33
2dda5a6aa917c832baae51a71de4385679f5ebd5
1 parent(s)
1 fichiers modifiés
+71
-8
M
README.md
+71
-8
@@ -30,7 +30,7 @@ Sans configuration sync : aucun compte, aucune donnée CRM envoyée hors apparei
| 30 | 30 | |
| 31 | 31 | Sync **offline-first** avec un serveur [PicLead](https://github.com/) (piclead-server) : carnet, projets, tâches kanban et comptes-rendus. **L’OCR et le scan ne nécessitent pas Internet.** |
| 32 | 32 | |
| 33 | -**Prérequis serveur :** variable `PICLEAD_API_CLES` (clés API par utilisateur), endpoints `/api/auth/cle`, `/api/sync/status`, `/api/sync/pull` — voir le [plan serveur](../Server/docs/plans/sync_api_mobile_v1.md). | |
| 33 | +**Prérequis serveur :** variable `PICLEAD_API_CLES` (clés API par utilisateur), endpoints `/api/auth/cle`, `/api/sync/status`, `/api/sync/pull`. Le contrat de ces endpoints est figé par les fixtures `Server/contrats/*.json`, rejouées par les tests des trois plateformes. | |
| 34 | 34 | |
| 35 | 35 | **Configuration dans l’app :** Paramètres (engrenage) → URL **HTTPS** du serveur → identifiant + mot de passe → « Obtenir la clé » → retaper le mot de passe pour déchiffrer la clé API (stockée chiffrée sur l’appareil ; le mot de passe n’est jamais conservé). |
| 36 | 36 |
@@ -43,6 +43,26 @@ Sync images carte/photo : [`docs/plans/sync_cartes_visite_v1.md`](docs/plans/syn
| 43 | 43 | |
| 44 | 44 | > **Upgrade schéma v2 :** la migration Room peut réinitialiser les données locales (documenté dans le plan sync). |
| 45 | 45 | |
| 46 | +## Tâches et planification (dépend de la sync) | |
| 47 | + | |
| 48 | +Les projets et leurs tâches arrivent par la sync ; l’écran projet affiche un **kanban** par colonnes de workflow. Il n’y a **pas de diagramme de Gantt sur téléphone** : l’écran retenu est la carte kanban enrichie. | |
| 49 | + | |
| 50 | +Quand le projet a la **planification activée** (réglage web), chaque carte porte : | |
| 51 | + | |
| 52 | +- une **pastille de couleur** d’étiquette — même teinte que sur le web, le hachage étant reproduit à l’identique sur les trois plateformes ; | |
| 53 | +- la **période** « 22/07 → 24/07 », calculée en **jours ouvrés** selon le rythme du projet (5 = lun-ven, 6 = lun-sam, 7 = tous les jours) ; | |
| 54 | +- l’**avancement des sous-tâches** (« 2/5 fait ») ; | |
| 55 | +- un **repère de retard** si la fin dépasse l’échéance du projet ; | |
| 56 | +- la mention **« ↳ regroupée »** si la tâche a une tâche parente. | |
| 57 | + | |
| 58 | +Si le projet n’active pas la planification, aucun de ces repères ne s’affiche — comme sur le web. | |
| 59 | + | |
| 60 | +**Éditable depuis le téléphone :** titre, assigné, **date de début** (saisie en texte ISO `AAAA-MM-JJ` ; une date malformée bloque la validation plutôt que de partir au serveur), **durée** en jours ouvrés, **étiquette** (avec suggestions tirées des tâches du projet) et **cases des sous-tâches**. | |
| 61 | + | |
| 62 | +**Réservé au web :** le diagramme de Gantt, l’édition des **dépendances** et du **regroupement** (transportés et conservés, mais non modifiables ici), ainsi que l’**échéance** et le **rythme** du projet. | |
| 63 | + | |
| 64 | +> **`duree_jours` se compte en jours ouvrés**, pas en jours calendaires. Les projets antérieurs sont neutralisés par `jours_ouvres = 7` ; basculer un projet en rythme 5 allonge visiblement ses tâches en durée calendaire. | |
| 65 | + | |
| 46 | 66 | ## Agenda / calendriers (optionnel, dépend de la sync) |
| 47 | 67 | |
| 48 | 68 | PicLead ne contient **aucun écran agenda** : les rendez-vous et réservations de ressources se consultent et se modifient dans l’**app Agenda système** (calendriers **locaux**, hors-GMS — aucun compte Google requis), via des calendriers dédiés que l’app crée et synchronise avec PicLead. |
@@ -58,7 +78,7 @@ PicLead ne contient **aucun écran agenda** : les rendez-vous et réservations d
| 58 | 78 | - **Oui** → la réservation locale et son événement Agenda sont supprimés. |
| 59 | 79 | - **Non** → rien n’est modifié ; l’arbitrage se fait sur le serveur web (demandes / réclamations restent hors périmètre mobile). |
| 60 | 80 | |
| 61 | -Spec détaillée : [`docs/superpowers/specs/2026-07-22-sync-agenda-rdv-ressources-v2-design.md`](docs/superpowers/specs/2026-07-22-sync-agenda-rdv-ressources-v2-design.md). Plan d’implémentation : [`docs/plans/sync_agenda_rdv_ressources_v2.md`](docs/plans/sync_agenda_rdv_ressources_v2.md). | |
| 81 | +Plan d’implémentation : [`docs/plans/sync_agenda_rdv_ressources_v2.md`](docs/plans/sync_agenda_rdv_ressources_v2.md). La spec de conception correspondante n’est pas versionnée (voir [Documentation locale](#documentation-locale-non-versionnée)). | |
| 62 | 82 | |
| 63 | 83 | > **Room v3 (agenda) :** l’ajout des tables RDV/réservations/indisponibilités passe la base Room en version 3 avec `fallbackToDestructiveMigration` — comme pour l’upgrade v2 ci-dessus, la mise à jour **réinitialise les données locales** (carnet inclus) ; ré-exportez en VCF ou synchronisez avant de mettre à jour l’app si nécessaire. |
| 64 | 84 |
@@ -192,21 +212,43 @@ Distribution : envoyez le fichier `PicLead-<version>-direct-release.apk` tel que
| 192 | 212 | |
| 193 | 213 | ## Build |
| 194 | 214 | |
| 215 | +Quatre variantes : deux saveurs (`fdroid`, `direct`) × deux types (`debug`, `release`). | |
| 216 | +Toutes les commandes se lancent depuis `android/`. | |
| 217 | + | |
| 218 | +| Variante | Commande | APK produit | | |
| 219 | +|---|---|---| | |
| 220 | +| `fdroid` debug | `./gradlew :app:assembleFdroidDebug` | `app/build/outputs/apk/fdroid/debug/PicLead-<version>-fdroid-debug.apk` | | |
| 221 | +| `fdroid` release | `./gradlew :app:assembleFdroidRelease` | `app/build/outputs/apk/fdroid/release/PicLead-<version>-fdroid-release.apk` | | |
| 222 | +| `direct` debug | `./gradlew :app:assembleDirectDebug` | `app/build/outputs/apk/direct/debug/PicLead-<version>-direct-debug.apk` | | |
| 223 | +| `direct` release | `./gradlew :app:assembleDirectRelease` | `app/build/outputs/apk/direct/release/PicLead-<version>-direct-release.apk` | | |
| 224 | + | |
| 225 | +Ajouter `-Ptessdata=full` aux variantes `direct` pour embarquer les modèles `full` | |
| 226 | +au lieu des `fast` (voir « Saveurs de distribution » ci-dessus). La saveur `fdroid` | |
| 227 | +ignore ces propriétés : elle n’embarque rien et n’accède pas au réseau au build. | |
| 228 | + | |
| 195 | 229 | ```bash |
| 196 | 230 | cd android |
| 197 | -./gradlew :app:assembleFdroidDebug | |
| 231 | +./gradlew clean :app:assembleFdroidRelease # build F-Droid reproductible, hors ligne | |
| 198 | 232 | ./gradlew :app:testFdroidDebugUnitTest |
| 199 | 233 | ./gradlew :app:testDirectDebugUnitTest |
| 200 | 234 | ``` |
| 201 | 235 | |
| 202 | -APK debug : `android/app/build/outputs/apk/fdroid/debug/PicLead-<version>-fdroid-debug.apk` | |
| 203 | - | |
| 204 | 236 | Les tests d’absence de modèle vivent dans la source set `app/src/testFdroid/` : la saveur |
| 205 | 237 | `direct` embarque ses traineddata, l’absence n’y est pas reproductible. |
| 206 | 238 | |
| 207 | -##Install | |
| 208 | -adb install -r android/app/build/outputs/apk/debug/app-debug.apk | |
| 239 | +Vérifier qu’un APK `fdroid` est bien vide de modèles (doit afficher `0`) : | |
| 240 | + | |
| 241 | +```bash | |
| 242 | +unzip -l app/build/outputs/apk/fdroid/release/PicLead-*-fdroid-release.apk \ | |
| 243 | + | grep -cE 'traineddata|vosk-model' | |
| 244 | +``` | |
| 209 | 245 | |
| 246 | +## Install | |
| 247 | + | |
| 248 | +```bash | |
| 249 | +adb install -r android/app/build/outputs/apk/fdroid/debug/PicLead-<version>-fdroid-debug.apk | |
| 250 | +adb install -r android/app/build/outputs/apk/direct/release/PicLead-<version>-direct-release.apk | |
| 251 | +``` | |
| 210 | 252 | |
| 211 | 253 | Prérequis : JDK 21, Android SDK (API 35). |
| 212 | 254 |
@@ -219,7 +261,28 @@ Prérequis : JDK 21, Android SDK (API 35).
| 219 | 261 | |
| 220 | 262 | ## Design |
| 221 | 263 | |
| 222 | -UI N&B éditoriale (`design.md`) : coins carrés, hairlines, polices TTF embarquées (Playfair Display, Lora, Manrope — OFL, voir `docs/licenses/OFL-fonts.txt`). Icône : `icon.png`. | |
| 264 | +UI N&B éditoriale (`design.md`) : coins carrés, hairlines, polices TTF embarquées (Playfair Display, Lora, Manrope — sous licence **OFL**). Icône : `icon.png`. | |
| 265 | + | |
| 266 | +> Le texte de la licence OFL est présent en local dans `docs/licenses/OFL-fonts.txt` mais **n’est pas versionné** (cf. ci-dessous). L’OFL impose que sa copie accompagne les polices redistribuées : à corriger avant toute publication du dépôt ou de l’APK. | |
| 267 | + | |
| 268 | +## Documentation locale (non versionnée) | |
| 269 | + | |
| 270 | +Le `.gitignore` racine exclut `docs/plans`, `Server/docs/plans`, `Server/docs/superpowers`, `Client/docs/plans/` et `Client/docs/superpowers/` ; `Client/.gitignore` exclut en plus tout `docs/*`. Une partie de la documentation de travail **n’est donc pas dans le dépôt**, et les liens qui y pointaient ont été retirés de ce README. | |
| 271 | + | |
| 272 | +Présent en local seulement, côté client : | |
| 273 | + | |
| 274 | +| Fichier | Contenu | | |
| 275 | +|---|---| | |
| 276 | +| `docs/publication-fdroid.md` | Procédure de publication F-Droid (recette YAML, checklist) | | |
| 277 | +| `docs/superpowers/specs/2026-07-22-sync-agenda-rdv-ressources-v2-design.md` | Conception de la sync agenda / ressources v2 | | |
| 278 | +| `docs/audit-securite-2026-07-27.md` | Audit de sécurité | | |
| 279 | +| `docs/licenses/OFL-fonts.txt` | Licence des polices embarquées | | |
| 280 | + | |
| 281 | +Les plans du monorepo (`docs/plans/` à la racine, dont les chantiers **modèles OCR téléchargeables** et **planification des tâches**) sont dans le même cas. | |
| 282 | + | |
| 283 | +Seuls les six plans historiques de `Client/docs/plans/` restent suivis : ils avaient été committés avant l’ajout des règles d’exclusion. | |
| 284 | + | |
| 285 | +> Deux points à trancher, hors périmètre de ce README : l’exclusion de `docs/plans` contredit son propre commentaire dans le `.gitignore` (« les plans versionnés restent dans `docs/plans/` ») et la consigne du `CLAUDE.md` (« les plans vivent dans le dépôt, avec le code »). Et la licence OFL devrait être redistribuée avec les polices. | |
| 223 | 286 | |
| 224 | 287 | ## Origine du code |
| 225 | 288 |