feat: PKCE auth + CI/CD deploy
All checks were successful
CI/CD — Build & Deploy / Build & Deploy (push) Successful in 1m2s
All checks were successful
CI/CD — Build & Deploy / Build & Deploy (push) Successful in 1m2s
- Frontend: PKCE flow (oauth.ts, AuthCallback code exchange, 401 interceptor) - Backend: token introspection via SuperOAuth (no more JWT secret) - User model: superOauthId (unified) replaces oauthId+provider - Cookies httpOnly session + refresh token - POST /auth/refresh endpoint - Gitea CI workflow (vps-runner pattern) - DB_SYNC env var for initial schema creation
This commit is contained in:
80
archive/ULTRAIMPORTANTNEJAMAISPRIMER.md/Visions1.md
Normal file
80
archive/ULTRAIMPORTANTNEJAMAISPRIMER.md/Visions1.md
Normal file
@@ -0,0 +1,80 @@
|
||||
Cas concrets. Aucun padding.
|
||||
|
||||
---
|
||||
NO HANDOFF — le brain qui sait qui il est
|
||||
|
||||
Lundi 7h. Tu ouvres une session sans rien préparer.
|
||||
Layer 0 charge : KERNEL, BHP schema, règles de collaboration, frozen layer.
|
||||
La todo dit : brainstorm architecture.
|
||||
Le brain répond : "session brainstorm — pas de contexte projet chargé, espace libre."
|
||||
|
||||
Tu fais de l'architecture propre parce qu'il n'y a pas de bruit du sprint de vendredi. Le cold start n'est pas un handicap — c'est ce qui rend la pensée architecturale possible. Un brain qui cold-start bien sur un brainstorm vaut plus qu'un brain qui traîne 400 lignes de workspace RAM d'un sprint de jeu.
|
||||
|
||||
---
|
||||
SEMI — le chirurgien qui n'a besoin que du dossier
|
||||
|
||||
22h. Bug critique en prod sur SuperOAuth. Token refresh qui expire.
|
||||
Layer 0 charge. Layer 1 partiel : position debug × SuperOAuth.
|
||||
Le brain sait que SuperOAuth tourne port 3006, pm2 cluster, Redis dédié.
|
||||
Il ne charge pas le sprint entier, pas le workspace de la semaine.
|
||||
|
||||
Tu as ce qu'il faut en 30 secondes. Tu fixes. Tu fermes.
|
||||
Pas de bruit. Pas de friction. Le bon contexte au bon niveau.
|
||||
|
||||
---
|
||||
SEMI+ — lundi matin sur un sprint vivant
|
||||
|
||||
TetaRdPG Sprint 4. Tu n'as pas de session ouverte depuis 3 jours.
|
||||
Layer 0 + Layer 1 complet : état du sprint, ce qui est livré, ce qui reste, les décisions d'architecture du GDD.
|
||||
Pas besoin de handoff de la dernière session — l'état du projet suffit.
|
||||
|
||||
Tu reprends en 2 minutes. Le brain n'a pas besoin de ta mémoire — il a la sienne.
|
||||
|
||||
---
|
||||
FULL — la continuation chirurgicale
|
||||
|
||||
Hier soir, refacto TypeORM complexe sur OriginsDigital. Session coupée à 23h en plein milieu d'une migration.
|
||||
Ce matin : FULL HANDOFF. Workspace RAM complet — les 3 fichiers en cours, la décision d'hier sur le cascade delete, le message d'erreur non résolu.
|
||||
|
||||
Tu reprends exactement là. Pas de reconstruction. Pas de "où j'en étais déjà ?". Continuité parfaite sur une tâche qui l'exige.
|
||||
|
||||
---
|
||||
Le gradient intelligent dans un sprint
|
||||
|
||||
Lundi matin → SEMI+ reprendre l'état du sprint
|
||||
Lundi soir → FULL continuation directe session d'avant
|
||||
Mardi matin → SEMI+ nouveau jour, état suffit
|
||||
Mercredi, bug → SEMI juste la position debug, rien d'autre
|
||||
Vendredi close → FULL wrap complet, scribe, metabolism
|
||||
|
||||
Tu ne choisis pas toujours FULL parce que tu n'en as pas toujours besoin. Le niveau juste = moins de bruit, plus de vitesse.
|
||||
|
||||
---
|
||||
Multi-agent — le cas qui prouve tout
|
||||
|
||||
Sprint OriginsDigital. Agent A : backend. Agent B : frontend.
|
||||
|
||||
- Layer 0 : identique pour les deux — même identité, même règles
|
||||
- Layer 1 : partagé — même état de sprint, même API contracts
|
||||
- Layer 2 : isolé — Agent A a son workspace backend, Agent B le sien
|
||||
|
||||
Agent B n'a pas besoin du workspace RAM d'Agent A. Il a besoin de savoir ce que l'API expose — c'est Layer 1. Le FULL d'Agent A ne pollue pas Agent B.
|
||||
|
||||
C'est ça le vrai gain : des agents qui partagent l'identité et l'état, mais pas la mémoire de travail.
|
||||
|
||||
---
|
||||
Brain-as-a-Service — la promesse qui tient
|
||||
|
||||
brain new installe Layer 0 sur une machine vierge.
|
||||
Première session d'un utilisateur : NO HANDOFF complet.
|
||||
Pourtant il est productif immédiatement — parce que Layer 0 est solide.
|
||||
|
||||
C'est la promesse qu'on peut vendre : un brain qui cold-start bien est un brain qui scale.
|
||||
Si NO HANDOFF est cassé, brain new ne marche pas. Layer 0 est le produit.
|
||||
|
||||
---
|
||||
⚡ Coach — tu vois ce que ça implique ?
|
||||
|
||||
Layer 0 n'est pas juste de la philosophie. C'est le critère de qualité mesurable du système. Si NO HANDOFF est productif en moins de 2 minutes → Layer 0 est bon. Sinon il est insuffisant.
|
||||
|
||||
C'est un KPI qu'on peut tester.
|
||||
Reference in New Issue
Block a user