Lalabase
Tickets, Doku, Zeiterfassung und Kundengespräche an einem Ort, durchsuchbar per KI. Für Softwarefirmen mit Kundenprojekten. Open Source: auf deinem eigenen Server oder in unserer Cloud in Deutschland.
翻譯準備中
尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證正在載入完整 README。 以下為已儲存的摘錄。
Plateforme SaaS de gestion des activités terrain : entreprises, équipes, clients, missions, planification, comptes rendus, devis, factures, achats, stocks et outils techniques spécialisés. État : stabilisation avant commercialisation. Les principaux parcours métier sont opérationnels. La priorité actuelle porte sur la fiabilité en production, les parcours automatisés et l'expérience mobile hors connexion. L'application démarre sur http://localhost:5173. Les migrations de base de données s'appliquent séparément : voir supabase/README.md.檢視完整 README ↗
Plateforme SaaS de gestion des activités terrain : entreprises, équipes, clients, missions, planification, comptes rendus, devis, factures, achats, stocks et outils techniques spécialisés.
État : stabilisation avant commercialisation. Les principaux parcours métier sont opérationnels. La priorité actuelle porte sur la fiabilité en production, les parcours automatisés et l'expérience mobile hors connexion.
npm install
cp .env.example .env.local # PowerShell : Copy-Item .env.example .env.local
# renseigner VITE_SUPABASE_URL et VITE_SUPABASE_PUBLISHABLE_KEY
npm run dev
L'application démarre sur http://localhost:5173.
Les migrations de base de données s'appliquent séparément : voir
supabase/README.md.
| Commande | Rôle |
|---|---|
npm run dev | Serveur de développement |
npm run build | Typecheck puis build de production |
npm run preview | Sert le build de production |
npm run typecheck | TypeScript seul |
npm run lint | ESLint (qualité, accessibilité et règles d'architecture) |
npm run lint:fix | ESLint avec corrections automatiques |
npm run format | Prettier — écriture |
npm run format:check | Prettier — vérification |
npm run test | Tests unitaires et d'intégration |
npm run test:watch | Tests en mode surveillance |
npm run test:coverage | Tests avec couverture |
npm run smoke | Rejoue toutes les requêtes Supabase de l'app contre la vraie base (lecture seule) |
npm run smoke:writes | Idem, plus les écritures, dans une organisation jetable auto-supprimée |
npm run protect:node-modules | Protection OneDrive (voir plus bas) |
Définies dans .env.local, jamais versionné. Modèle : .env.example.
| Variable | Rôle |
|---|---|
VITE_SUPABASE_URL | URL du projet Supabase |
VITE_SUPABASE_PUBLISHABLE_KEY | Clé publique (sb_publishable_… ou clé anon legacy) |
VITE_APP_ENV | development | staging | production |
VITE_APP_VERSION | Identifiant facultatif du déploiement pour le journal d'erreurs |
Elles sont validées par Zod au démarrage : une variable manquante ou mal formée
provoque un échec immédiat et explicite, plutôt qu'un undefined silencieux.
Ne jamais placer
SUPABASE_SERVICE_ROLE_KEYdans ce projet. Cette clé contourne la Row Level Security et n'a sa place que côté serveur. Vite n'expose au navigateur que les variables préfixéesVITE_.
L'application est un frontend statique : vercel.json est versionné, et le seul
travail restant est de renseigner les trois variables obligatoires ci-dessus dans Vercel puis
d'autoriser le domaine dans Supabase Auth.
Procédure complète, réglages Supabase compris :
docs/DEPLOIEMENT-VERCEL.md.
Les migrations ne partent PAS avec le déploiement. Elles s'appliquent séparément par
npx supabase db push --linked, et doivent précéder la mise en ligne du frontend qui en dépend.
Voir ARCHITECTURE.md — couches, frontières appliquées par
ESLint, système modulaire d'outils, isolation des pannes.
Pour ajouter un outil : src/tools/README.md.
npm run test
Vitest + Testing Library, environnement jsdom. Les tests d'amorçage couvrent le mapping des erreurs Supabase, la validation d'environnement, le registry d'outils, l'isolation des pannes et le routing réel (y compris la protection des routes privées).
Playwright vérifie les pages publiques et les premiers parcours applicatifs sur Chrome bureau et sur un téléphone Pixel simulé :
npx playwright install chromium
npm run test:e2e
Les contrôles de types, de qualité, les tests et le build sont également
exécutés automatiquement à chaque pull request et à chaque push sur main.
Le projet est hébergé dans OneDrive avec Files On-Demand actif. Le risque
n'est pas le volume synchronisé — gênant mais bénin — c'est la
déshydratation : OneDrive peut transformer un fichier de node_modules en
placeholder cloud, et Node échoue alors en EIO/ENOENT au milieu d'un build.
npm run protect:node-modules # à relancer après chaque npm install
Ce script épingle node_modules en local (attribut +P), ce qui interdit à
OneDrive de le déshydrater.
Approche écartée — jonction NTFS. Déplacer node_modules hors de OneDrive
via une jonction a été testé et échoue : npm 11 supprime le lien au début de
chaque installation (npm warn reify Removing non-directory … node_modules) et
recrée un dossier réel. La mitigation ne survivait donc pas à npm install.
| Version | |
|---|---|
| React | 19.2.8 |
| TypeScript | 6.0.3 |
| Vite | 8.2.1 |
| Tailwind CSS | 4.3.3 |
| React Router | 8.3.0 |
| Supabase JS | 2.112.2 |
| TanStack Query | 5.101.4 |
| Zod | 4.4.3 |
| Vitest | 4.1.10 |
| ESLint | 9.39.5 |
Deux versions sont délibérément en retrait de latest, pour cause
d'incompatibilité vérifiée sur le registre :
[email protected] exige
typescript <6.1.0. TypeScript 7 casserait le lint type-aware. Vite ne
typecheckant pas, le build n'est pas affecté.[email protected] plafonne à
eslint ^9.Ces deux choix évitent tout --legacy-peer-deps ou overrides.