Espaces privés — `private/<handle>/`¶

Principe : chaque membre de l'équipe a un sanctuaire personnel dans le second cerveau. Ce qui y est écrit ne quitte jamais sa machine. C'est la garantie psychologique qui évite que les gens recréent des systèmes parallèles (Notion perso, Obsidian séparé, Apple Notes) et que tout le monde maintienne quelque chose en double.

Pourquoi¶

Un second cerveau partagé ne fonctionne que si les gens y déposent tout. Mais sans espace privé, il y a toujours des choses qu'on ne veut pas partager : - Impressions sur un collègue, doutes, observations sensibles - Brouillons à moitié formés qu'on n'assume pas encore - Objectifs de carrière personnels - Notes de coaching, développement pro - Réflexions stratégiques controversées en phase exploratoire - Questions qu'on se pose sans vouloir les exposer tout de suite

Sans exutoire → ces contenus migrent vers des outils externes → le second cerveau perd sa valeur de source unique.

Solution : un dossier private/<handle>/ par personne, dans le même repo mais jamais synchronisé avec le remote.

Contrat technique¶

1. `private/` est entièrement gitignored¶

.gitignore contient /private/
Aucun fichier dans private/ ne peut être committé
Un pre-commit hook dans .githooks/pre-commit bloque toute tentative de git add -f private/* (sécurité renforcée)

2. Les Cloud Agents ne lisent jamais `private/`¶

Les règles Cursor (.cursor/rules/private-space.mdc) imposent aux Cloud Agents de sauter private/ entièrement
Les scripts d'ingest, daily-pulse, weekly-digest, lint ne parcourent PAS private/
Même en cas d'accès accidentel, ils ne peuvent pas push vers le remote car gitignored

3. L'IA locale (Cursor IDE) respecte le périmètre de la personne¶

Quand tu travailles dans Cursor, l'IA peut lire/écrire dans ton private/<toi>/
L'IA ne DOIT JAMAIS :
Copier du contenu privé vers une page partagée sans ta demande explicite
Lire le private/<quelqu'un d'autre>/ (même si accessible techniquement sur une machine partagée)
Suggérer de graduer un contenu privé sans que tu le demandes

Workflow de création¶

Pour initialiser ton espace privé (une seule fois, au cloning du repo) :

cd scripts
npm run init-private -- --handle romain

Cela crée la structure standard :

private/romain/
  README.md                   # Mode d'emploi personnalisé
  profil/                     # Profil personnel auto-alimenté (préférences, style, habitudes, vocabulaire)
  inbox/                      # Drop zone pour captures rapides
  journal/                    # Daily notes perso
  thoughts/                   # Réflexions structurées, en cours de formation
  drafts/                     # Brouillons en attente de graduation vers le wiki public
  observations/               # Notes sur les gens/sujets (pas partagées)
  learnings/                  # Apprentissages, lectures, insights
  goals/                      # Objectifs de carrière / perso

Tu peux adapter cette structure — c'est ton espace.

Profil personnel auto-alimenté¶

Le dossier profil/ est une couche vivante de personnalisation : l'IA y lit tes préférences et l'enrichit toute seule au fil des sessions, pour que tu n'aies pas à réexpliquer à chaque fois comment tu travailles.

private/<handle>/profil/
  README.md                   # Index + protocole
  preferences.md              # Format de restitution, ton, défauts de décision, ce que tu aimes/détestes
  style-ecriture.md           # Comment l'IA écrit pour toi (drafts, docs, specs)
  habitudes.md                # Rythme, rituels, contraintes récurrentes, séquencement
  vocabulaire.md              # Termes & raccourcis perso que l'IA doit comprendre

Comment ça s'alimente : le comportement IA est défini par la règle partagée .cursor/rules/profil-personnel.mdc (présente dans chaque clone, valable pour tout utilisateur). L'IA :

lit ton profil quand le contexte s'y prête (rédaction, restitution, arbitrage de format) ;
capture une nouvelle préférence quand elle est durable et généralisable (pas un one-off — typiquement quand tu reformules ≥ 2 fois la même demande, ou que tu dis "note que je préfère X") ;
dit toujours ce qu'elle a modifié, ne supprime jamais en silence, et propose avant d'écrire quand le changement touche ton ton de fond.

Les fichiers sont scaffoldés vides à l'init-private, puis se remplissent au fil de l'eau. Tu peux aussi les éditer à la main quand tu veux.

Versionnement de ton espace privé (optionnel)¶

private/<toi>/ n'est pas versionné par le repo Bricks OS. Tu peux :

Pas de versioning (simple) — juste un backup Time Machine.

Git privé local — initialiser un repo git séparé :

cd private/romain
git init
git remote add origin git@github.com:<toi>/brain-private.git
# Push vers ton propre remote privé personnel (pas Bricks)

Sync cloud perso — déposer dans iCloud Drive / Dropbox / Drive perso (jamais Drive d'entreprise).

Ne jamais pousser vers le remote Bricks ni un remote d'entreprise partagé.

Graduation — passer du privé au public¶

Parfois un brouillon privé mûrit et mérite de rejoindre le wiki partagé. Exemples : - Une réflexion stratégique qui devient une ADR - Une observation sur un concept qui mérite concepts/<truc>.md - Un retour sur un client qui enrichit people/clients/<client>.md

Commande :

cd scripts
npm run graduate -- --from "private/romain/drafts/sso-reflexions.md" --to "concepts/sso.md"

Cela : 1. Extrait le contenu pertinent (assisté IA via prompts/graduate.md) 2. L'intègre dans la destination publique (avec citations si applicable) 3. Ajoute une note dans le fichier privé : > Graduated on YYYY-MM-DD to concepts/sso.md 4. Le fichier privé reste en local (historique de pensée, jamais effacé auto)

L'humain garde le contrôle : le script propose, tu valides.

Règles IA renforcées¶

L'IA qui t'assiste dans Cursor (Agent mode, Ask mode) applique ce contrat : - ✅ Peut lire et écrire dans private/<toi>/ - ✅ Peut proposer une graduation si tu le demandes - ❌ Ne copie jamais de contenu privé vers le wiki public sans npm run graduate - ❌ Ne cite jamais un chemin private/* dans un output destiné à un canal partagé (Slack, PR, etc.) - ❌ Les Cloud Agents (daily-pulse, weekly-digest, lint, ingest) ignorent entièrement private/

Voir .cursor/rules/private-space.mdc pour le détail.

Que peut-on mettre dans son espace privé ?¶

Oui, mets-y sans hésiter : - Tes notes perso de meeting (impressions, ressentis, ce que tu n'as pas osé dire) - Tes brouillons d'ADR avant d'avoir la certitude - Tes observations sur des collègues (positive ou constructive) - Tes objectifs de carrière 3/6/12 mois - Ton journal pro / réflexions hebdomadaires - Tes drafts de messages qu'il faudra envoyer - Tes apprentissages de lectures, podcasts, conférences - Tes questions ouvertes / doutes - Tes notes de coaching ou thérapie pro

Non (cf. policies Bricks) : - Données clients non-anonymisées (restent dans people/clients/ avec confidentiality: restricted) - Informations financières (restent dans resources/chiffres-cles.md restricted) - Infos soumises à NDA tiers (pas dans le repo du tout)

FAQ¶

Q : si je change d'avis et veux partager une note privée ? R : utilise npm run graduate. La note privée reste, une copie va dans le wiki public.

Q : quelqu'un peut-il lire mon private/ sur ma machine ? R : si plusieurs personnes partagent la même machine physique (rare), oui. Sinon non — c'est sur ton disque local.

Q : et si je veux archiver mon private/ en quittant l'entreprise ? R : tu l'emportes. C'est le tien.

Q : l'IA peut-elle me suggérer des graduations ? R : seulement si tu le demandes explicitement via npm run graduate ou une commande équivalente. Elle ne prend jamais l'initiative.

Q : les Cloud Agents peuvent-ils accidentellement lire private/ ? R : non. .cursor/rules/private-space.mdc leur interdit, et techniquement private/ n'est pas dans le clone distant du Cloud Agent (gitignored).

Espaces privés — private/<handle>/¶