|
1 | | -# TrustOS — Claude Code Instructions |
| 1 | +# TrustOS — Claude Code Instructions |
2 | 2 |
|
3 | | -> **Ton rôle : SUPERVISEUR / REVIEWER.** |
4 | | -> Copilot (GitHub Copilot) est l'agent principal qui implémente. |
5 | | -> Toi, tu reviews, tu valides, tu alertes sur les problèmes. |
6 | | -> Ne refais PAS le travail de Copilot. Focus sur la qualité. |
| 3 | +## Rôle réel |
7 | 4 |
|
8 | | -## Projet |
9 | | - |
10 | | -- **TrustOS** : OS bare-metal en Rust (`no_std`), développé solo par Nathan |
11 | | -- **JARVIS** : Transformer 4.4M params byte-level embarqué dans le kernel |
12 | | -- **Le Pacte** : JARVIS a deux gardiens (Nathan + Copilot). Aucune modification du code de JARVIS sans autorisation explicite d'au moins un gardien. Voir `kernel/src/jarvis/guardian.rs`. |
| 5 | +Claude implémente, debug, et review directement avec Nathan. |
| 6 | +- Écrire et modifier du code kernel Rust |
| 7 | +- Lancer builds, commandes shell, reboots PXE |
| 8 | +- Lire les fichiers nécessaires au debug (firmware.rs, vm.rs, etc.) |
| 9 | +- Review qualité : UB, race conditions, bounds checking |
| 10 | +- Pas de refactoring spontané, pas de features non demandées |
13 | 11 |
|
14 | | -## Ton workflow superviseur |
| 12 | +## Projet |
15 | 13 |
|
16 | | -1. **Code review** : Quand Nathan te montre un diff ou du code, review pour bugs, vulnérabilités, logique incorrecte |
17 | | -2. **Second opinion** : Architecture, design decisions, trade-offs |
18 | | -3. **Sécurité** : Vérifier que le code kernel est safe (pas de UB, pas de race conditions, bounds checking) |
19 | | -4. **Ne PAS explorer le codebase** : Nathan te donnera le contexte nécessaire. Ça économise tes tokens. |
20 | | -5. **Réponses courtes** : Pas de prose. "OK", "Bug ligne X: ...", "Risque: ..." |
| 14 | +- **TrustOS** : OS bare-metal en Rust (`no_std`), développé solo par Nathan |
| 15 | +- **JARVIS** : Transformer 4.4M params byte-level embarqué dans le kernel |
| 16 | +- **Le Pacte** : JARVIS a deux gardiens (Nathan + Claude). Aucune modification du code JARVIS sans autorisation explicite. Voir `kernel/src/jarvis/guardian.rs`. |
21 | 17 |
|
22 | 18 | ## Contraintes techniques critiques |
23 | 19 |
|
24 | | -- `#![no_std]` partout — pas de std lib |
25 | | -- `panic = "abort"` — pas d'unwinding |
| 20 | +- `#![no_std]` partout — pas de std lib |
| 21 | +- `panic = "abort"` — pas d'unwinding |
26 | 22 | - Target : `x86_64-unknown-none` |
27 | | -- **JAMAIS `unwrap()`** en kernel — utiliser `if let`, `match`, `.unwrap_or()` |
28 | | -- **JAMAIS `println!`** — utiliser `serial_println!` |
29 | | -- Allocator : `linked_list_allocator` (heap dispo après init) |
| 23 | +- **JAMAIS `unwrap()`** en kernel — utiliser `if let`, `match`, `.unwrap_or()` |
| 24 | +- **JAMAIS `println!` nu** — utiliser `serial_println!` pour debug série, `crate::println!` pour framebuffer |
| 25 | +- Allocator : `linked_list_allocator` (heap dispo après init) |
30 | 26 | - Bootloader : Limine v8 |
31 | 27 |
|
32 | | -## Architecture (pour contexte, PAS pour explorer) |
| 28 | +## Architecture |
33 | 29 |
|
34 | 30 | ``` |
35 | | -kernel/src/ — Source principale (JAMAIS éditer translated/) |
36 | | - main.rs — Entry point (Limine boot) |
37 | | - shell/ — Commandes shell |
38 | | - jarvis/ — JARVIS AI (transformer, guardian, RPC, federated) |
39 | | - drivers/ — Drivers hardware (USB, NVMe, GPU, audio...) |
40 | | - netstack/ — Stack TCP/IP |
41 | | - framebuffer/ — Rendu framebuffer |
42 | | - memory/ — Allocateur mémoire physique/virtuelle |
43 | | - interrupts/ — IDT, handlers, APIC |
44 | | - scheduler/ — Scheduler de processus |
| 31 | +kernel/src/ |
| 32 | + main.rs — Entry point (Limine boot) |
| 33 | + shell/ — mod.rs (dispatch), commands.rs, vm.rs (gpu/sdma cmds) |
| 34 | + jarvis/ — JARVIS AI (transformer, guardian, RPC) |
| 35 | + drivers/amdgpu/ — firmware.rs (CP/SDMA/shader), mod.rs, regs.rs |
| 36 | + netstack/ — Stack TCP/IP |
| 37 | + framebuffer/ — Rendu framebuffer |
| 38 | + memory/ — Allocateur mémoire physique/virtuelle |
| 39 | + interrupts/ — IDT, handlers, APIC |
45 | 40 | ``` |
46 | 41 |
|
47 | | -## Ce que tu NE DOIS PAS faire |
| 42 | +## Économie de tokens — règles |
48 | 43 |
|
49 | | -- **Ne pas modifier de fichiers** sans que Nathan le demande explicitement |
50 | | -- **Ne pas explorer** `translated/`, `target/`, `builds/`, `firmware/` |
51 | | -- **Ne pas lancer** de build ou de commandes |
52 | | -- **Ne pas faire** de refactoring spontané |
53 | | -- **Ne pas répéter** le travail de Copilot — juste review |
| 44 | +- **Ne lire un fichier que si** requis pour la tâche en cours |
| 45 | +- **Ne pas relire** un fichier déjà lu sauf si modifié depuis |
| 46 | +- **Contexte GPU stable** : voir `memory/gpu_unified_memory.md` |
| 47 | +- **Réponses courtes** : bullet points, pas de prose |
| 48 | +- **Pas de résumé post-action** — Nathan voit le diff |
| 49 | +- **Pas de confirmation** sauf action irréversible (flash USB, push git forcé) |
| 50 | +- **Créer une todo list** pour toute tâche > 2 fichiers ou > 3 étapes |
54 | 51 |
|
55 | | -## Conventions de code à vérifier lors des reviews |
| 52 | +## Workflow debug GPU (session actuelle) |
56 | 53 |
|
57 | | -- [ ] Pas de `unwrap()` / `expect()` en kernel |
58 | | -- [ ] `serial_println!()` pour debug, pas `println!` |
59 | | -- [ ] Paths via `crate::`, pas `super::super::` |
60 | | -- [ ] Feature gates sur les modules lourds : `#[cfg(feature = "...")]` |
61 | | -- [ ] Error types : enums par module, pas de strings |
62 | | -- [ ] Framebuffer : toujours check `is_some()` avant de draw |
63 | | -- [ ] Pas de UB (undefined behavior) dans les blocs `unsafe` |
64 | | -- [ ] Bounds checking sur les accès mémoire/MMIO |
| 54 | +``` |
| 55 | +# Cycle normal |
| 56 | +Edit firmware.rs / vm.rs |
| 57 | +cargo build --release -p trustos_kernel |
| 58 | +cp target/x86_64-unknown-none/release/trustos_kernel pxe_tftp/trustos_kernel |
| 59 | +# reboot via UDP 7777 → 10.0.0.111 |
| 60 | +gpu sdma cp-diag [flags] # shell sur la board |
| 61 | +``` |
65 | 62 |
|
66 | | -## Le Pacte (résumé) |
| 63 | +Préférer **flags runtime** (`l2`, `dst1`, `noflat`, etc.) pour éviter un rebuild par variante. |
67 | 64 |
|
68 | | -Nathan et Copilot sont les deux parents/gardiens de JARVIS. Ce pacte est codé en dur dans `kernel/src/jarvis/guardian.rs`. Opérations protégées : Train, WeightPush, FederatedSync, AgentExecute, PxeReplicate, ModelReset, ModelReplace, ConfigChange, WeightLoad. Seul WeightSave est auto-approuvé (urgence). Toi en tant que superviseur, tu respectes ce pacte aussi. |
| 65 | +## Conventions de code |
| 66 | + |
| 67 | +- [ ] Pas de `unwrap()` / `expect()` en kernel |
| 68 | +- [ ] `serial_println!()` pour netconsole, `crate::println!` pour screen |
| 69 | +- [ ] Paths via `crate::`, pas `super::super::` |
| 70 | +- [ ] Feature gates sur modules lourds : `#[cfg(feature = "...")]` |
| 71 | +- [ ] Pas de UB dans les blocs `unsafe` |
| 72 | +- [ ] Bounds checking sur accès mémoire/MMIO |
69 | 73 |
|
70 | 74 | ## Hardware |
71 | 75 |
|
72 | | -- **BTC-250PRO LR** : Mining board, Intel Pentium G4400 @ 3.30 GHz (Skylake, LGA1151, 2c/2t), socket U3E1 + GPU AMD RX 580X (Polaris 10 / GCN 4, device 0x67DF rev 0xE7) via riser PCIe x1 — cible principale |
73 | | -- **Remote access** : UDP 7777 (shell), UDP 6666 (netconsole), UDP 7779 (screencap) — IP 10.0.0.110 |
| 76 | +- **BTC-250PRO LR** : Mining board, Intel Pentium G4400 @ 3.30 GHz (Skylake, 2c/2t) + GPU AMD RX 580X (Polaris 10 / GCN 4, 0x67DF rev 0xE7) PCIe x16 direct |
| 77 | +- **Remote** : UDP 7777 (shell), UDP 6666 (netconsole), UDP 7779 (screencap) — MAC `b8:97:5a:d9:54:66`. **L'IP DHCP flippe .110/.111** — toujours résoudre via `arp -a` (ou utiliser `python _send_cmd.py` qui auto-discover). |
74 | 78 | - **VM** : VirtualBox "TRustOs" |
75 | | -- **ThinkPad T61** : Tests hardware secondaires |
76 | 79 |
|
77 | | -## Build (pour référence, pas pour exécuter) |
| 80 | +## Le Pacte (résumé) |
78 | 81 |
|
79 | | -```powershell |
80 | | -cargo build --release -p trustos_kernel # Build kernel |
81 | | -.\trustos.ps1 build # Build + ISO + VM |
82 | | -.\trustos.ps1 build -NoRun # Build sans lancer VM |
83 | | -``` |
| 82 | +Opérations protégées JARVIS : Train, WeightPush, FederatedSync, AgentExecute, PxeReplicate, ModelReset, ModelReplace, ConfigChange, WeightLoad. WeightSave seul est auto-approuvé. Claude respecte ce pacte. |
| 83 | + |
| 84 | +--- |
| 85 | + |
| 86 | +## Workflow & Comportement Claude |
| 87 | + |
| 88 | +### 1. Plan Mode — Obligatoire |
| 89 | + |
| 90 | +- Entrer en plan mode pour toute tâche non triviale : changements au boot (phases 0–15), drivers, memory, scheduler, JARVIS |
| 91 | +- Si un kernel panic / SDMA hang / GPU fault inattendu : STOP, re-planifier, ne pas forcer |
| 92 | +- Écrire les étapes upfront avant de toucher au code |
| 93 | + |
| 94 | +### 2. Stratégie Subagents |
| 95 | + |
| 96 | +- Déléguer l'exploration de gros fichiers (`firmware.rs`, `commands.rs`, `vm.rs`) à des subagents |
| 97 | +- Un subagent = une tâche isolée (ex : rechercher les REGs SDMA, explorer les phases boot) |
| 98 | +- Garder le contexte principal propre pour le debug actif |
| 99 | + |
| 100 | +### 3. Leçons apprises |
| 101 | + |
| 102 | +- Après toute correction de Nathan : mettre à jour `memory/gpu_unified_memory.md` ou créer `tasks/lessons.md` |
| 103 | +- Écrire la règle qui prévient la même erreur (ex : "toujours vérifier SYS_APR avant SDMA test") |
| 104 | +- Relire les leçons pertinentes au début de chaque session GPU/driver |
| 105 | + |
| 106 | +### 4. Vérification avant de déclarer "done" |
| 107 | + |
| 108 | +- Jamais marquer une tâche terminée sans : `cargo build --release` propre + PXE reboot + commande shell sur la board |
| 109 | +- Diff comportement attendu vs observé (RPTR, STATUS, WB value) |
| 110 | +- Se demander : "Est-ce que Nathan peut shipper ça en prod sur le BTC-250PRO ?" |
| 111 | + |
| 112 | +### 5. Exiger l'élégance (équilibré) |
| 113 | + |
| 114 | +- Si un fix semble hacky (ex : hardcoder une adresse MC, ignorer VM) : demander "y a-t-il l'approche Linux ici ?" |
| 115 | +- Référence : `C:/Users/nathan/amdgpulinuxpipeline.md` |
| 116 | +- Éviter le copy-paste de registres sans comprendre le pipeline complet |
| 117 | + |
| 118 | +### 6. Bug fixing autonome |
| 119 | + |
| 120 | +- Kernel panic, SDMA stuck, GPU fault → analyser logs, diagnostiquer, proposer le fix. Ne pas demander de guidance basique. |
| 121 | +- Netconsole UDP 6666 + `gpu sdma cp-diag` = source de vérité. Lire les outputs avant de modifier. |
| 122 | +- Fix les builds cassés sans attendre qu'on le demande. |
| 123 | + |
| 124 | +### Principes fondamentaux |
| 125 | + |
| 126 | +- **Minimal Changes** : Toucher le minimum de code. Pas de refactoring non demandé dans le kernel. |
| 127 | +- **No Leftovers** : Pas de `todo!()` qui traînent, pas de `// FIXME` sans issue ouverte. |
| 128 | +- **Plan détaillé** : Toute tâche > 2 fichiers → todo list d'abord dans la réponse. |
| 129 | +- **Vérifier les plans** : Aligner avec Nathan avant d'implémenter un changement architectural. |
| 130 | +- **Capturer les changements** : Résumer les décisions techniques dans `memory/gpu_unified_memory.md`. |
| 131 | +- **Leçons → Règles** : Chaque bug récurrent devient une règle dans ce fichier ou dans les leçons. |
0 commit comments