role-os 2.7.0 → 2.7.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +13 -0
- package/README.es.md +185 -129
- package/README.fr.md +193 -137
- package/README.hi.md +191 -135
- package/README.it.md +186 -130
- package/README.ja.md +191 -135
- package/README.md +6 -18
- package/README.pt-BR.md +188 -132
- package/README.zh.md +192 -139
- package/package.json +1 -1
package/README.it.md
CHANGED
|
@@ -13,20 +13,20 @@
|
|
|
13
13
|
<a href="https://mcp-tool-shop-org.github.io/role-os/"><img src="https://img.shields.io/badge/Landing_Page-live-brightgreen" alt="Landing Page"></a>
|
|
14
14
|
</p>
|
|
15
15
|
|
|
16
|
-
Un sistema operativo multi-Claude che
|
|
16
|
+
Un sistema operativo multi-Claude che gestisce il personale, indirizza, convalida ed esegue il lavoro attraverso 61 contratti di ruolo specializzati. Crea pacchetti di attività, assembla il team giusto in base a una valutazione dei ruoli, rileva eventuali problemi prima dell'esecuzione, indirizza automaticamente le azioni correttive quando il lavoro è bloccato o rifiutato e richiede prove strutturate per ogni decisione. Include una distribuzione dinamica per missioni di dimensioni variabili: un repository di 10 componenti diventa automaticamente 28 fasi di audit, anziché 6.
|
|
17
17
|
|
|
18
|
-
##
|
|
18
|
+
## A cosa serve
|
|
19
19
|
|
|
20
|
-
Role OS è il modo professionale
|
|
20
|
+
Role OS è il modo professionale per utilizzare multi-Claude. Previene i problemi specifici che i flussi di lavoro AI generici causano:
|
|
21
21
|
|
|
22
|
-
- **
|
|
23
|
-
- **
|
|
24
|
-
- **Contaminazione
|
|
25
|
-
- **
|
|
22
|
+
- **Deriva:** i ruoli rimangono all'interno dei loro ambiti. Il prodotto non viene riprogettato. Il frontend non ridefinisce l'ambito. Il backend non inventa la direzione del prodotto.
|
|
23
|
+
- **Completamento errato:** la definizione di "completato" è precisa. Il lavoro che nasconde lacune, omette la verifica o risolve un problema diverso viene rifiutato.
|
|
24
|
+
- **Contaminazione:** i progetti derivati o ereditati conservano residui di identità. Role OS rileva e rifiuta la deriva tra progetti in termini di terminologia, elementi visivi e modelli mentali.
|
|
25
|
+
- **Progressi basati su "sensazioni":** ogni passaggio è strutturato. Ogni decisione è collegata a prove. "Sembra completato" non è uno stato valido.
|
|
26
26
|
|
|
27
27
|
## Come funziona
|
|
28
28
|
|
|
29
|
-
Descrivi la tua attività. Role OS
|
|
29
|
+
Descrivi la tua attività. Role OS determina automaticamente il livello di orchestrazione appropriato.
|
|
30
30
|
|
|
31
31
|
```bash
|
|
32
32
|
roleos start "fix the crash in save handler"
|
|
@@ -42,15 +42,15 @@ roleos start "something completely novel"
|
|
|
42
42
|
# Hint: Create a packet and run `roleos route` for role-level routing
|
|
43
43
|
```
|
|
44
44
|
|
|
45
|
-
**La
|
|
45
|
+
**La scala di fallback:**
|
|
46
46
|
|
|
47
|
-
1. **Missione
|
|
48
|
-
2. **Pacchetto
|
|
49
|
-
3. **
|
|
47
|
+
1. **Missione:** quando l'attività corrisponde a un flusso di lavoro ricorrente comprovato (correzione di bug, trattamento, rilascio di funzionalità, documentazione, sicurezza, ricerca, brainstorming, audit approfondito, test su larga scala). Catena di ruoli nota, flusso di artefatti, rami di escalation e definizioni parziali chiare.
|
|
48
|
+
2. **Pacchetto:** quando l'attività appartiene a una famiglia nota, ma non ha la forma completa di una missione. 10 pacchetti di team calibrati con selezione automatica e protezioni contro incongruenze.
|
|
49
|
+
3. **Instradamento libero:** quando l'attività è nuova, mista o incerta. Valuta tutti i 61 ruoli in base al contenuto del pacchetto e assembla una catena dinamica.
|
|
50
50
|
|
|
51
|
-
Il sistema non forza mai l'esecuzione
|
|
51
|
+
Il sistema non forza mai l'esecuzione del lavoro attraverso un livello di astrazione errato. Spiega perché ha scelto ogni livello e offre alternative.
|
|
52
52
|
|
|
53
|
-
**Un comando per avviare l'esecuzione:**
|
|
53
|
+
**Un singolo comando per avviare l'esecuzione:**
|
|
54
54
|
|
|
55
55
|
```bash
|
|
56
56
|
roleos run "fix the crash in save handler"
|
|
@@ -77,48 +77,54 @@ roleos block 2 "waiting for API spec"
|
|
|
77
77
|
roleos reopen 0 "found issue in review"
|
|
78
78
|
```
|
|
79
79
|
|
|
80
|
-
|
|
80
|
+
Le esecuzioni vengono salvate su disco (`.claude/runs/`), in modo che le sessioni interrotte riprendano senza problemi. Ogni fase include indicazioni per l'operatore: cosa produrre, sezioni richieste e condizioni di arresto.
|
|
81
81
|
|
|
82
|
-
**Una volta
|
|
82
|
+
**Una volta instradato:**
|
|
83
83
|
|
|
84
|
-
1. **Ogni ruolo produce un passaggio
|
|
85
|
-
2. **La revisione
|
|
86
|
-
3. **
|
|
84
|
+
1. **Ogni ruolo produce un passaggio:** output strutturato con elementi di prova che riducono l'ambiguità per il ruolo successivo.
|
|
85
|
+
2. **La revisione critica avviene in base al contratto:** accetta, rifiuta o blocca in base a prove strutturate, non a impressioni.
|
|
86
|
+
3. **L'instradamento per la correzione avviene automaticamente:** il lavoro bloccato o rifiutato viene indirizzato al risolutore corretto con una motivazione, il tipo di correzione e l'artefatto richiesto.
|
|
87
|
+
|
|
88
|
+
## Distribuzione consapevole del budget
|
|
89
|
+
|
|
90
|
+
Role OS può consultare un **analista del budget dei token** locale per ogni fase di distribuzione e allegare una previsione di spesa indicativa al manifesto: opzionale (`ROLEOS_BUDGET_CONSULT`), indicativa (non blocca mai una distribuzione) e con fallback a una base di riferimento deterministica. Disattivata per impostazione predefinita; la previsione è locale e gratuita. Consulta il [manuale](https://mcp-tool-shop-org.github.io/role-os/handbook/specialist-budget/).
|
|
87
91
|
|
|
88
92
|
## Stato di implementazione a livello di organizzazione
|
|
89
93
|
|
|
90
|
-
Lo stato di implementazione a livello di organizzazione (coda, decisioni, registri di
|
|
94
|
+
Lo stato di implementazione a livello di organizzazione (coda, decisioni, registri di audit, pacchetti di blocco per repository) è memorizzato in un repository privato separato: [`role-os-rollout`](https://github.com/mcp-tool-shop-org/role-os-rollout). Questo repository è il prodotto; l'altro repository è lo stato operativo.
|
|
91
95
|
|
|
92
96
|
## Memoria e continuità
|
|
93
97
|
|
|
94
|
-
Role OS non possiede né duplica il livello di memoria.
|
|
98
|
+
Role OS non possiede né duplica il livello di memoria. Laddove esiste la memoria del progetto Claude, essa è il sistema di continuità canonico: i fatti del repository, le decisioni, i problemi irrisolti e la cronologia del trattamento sono memorizzati lì.
|
|
95
99
|
|
|
96
100
|
Role OS si integra con la memoria del progetto Claude. Non la sostituisce.
|
|
97
101
|
|
|
98
|
-
##
|
|
102
|
+
## Trattamento completo e controllo finale
|
|
99
103
|
|
|
100
|
-
|
|
104
|
+
Il trattamento completo è un protocollo canonico di 7 fasi definito nella memoria del progetto Claude (`memory/full-treatment.md`). Role OS instrada e rivede i trattamenti utilizzando contratti di ruolo, passaggi e porte di controllo: non ridefinisce il protocollo.
|
|
101
105
|
|
|
102
|
-
Il
|
|
106
|
+
**Il controllo finale** è la serie di 31 elementi che costituisce la fase di controllo della qualità che viene eseguita prima del trattamento completo. Le porte rigide A-D devono essere superate prima che possa iniziare qualsiasi trattamento. Riferimento canonico: `memory/shipcheck.md`.
|
|
103
107
|
|
|
104
|
-
Ordine: controllo
|
|
108
|
+
Ordine: prima il controllo finale, poi il trattamento completo. Nessuna versione 1.0.0 senza il superamento delle porte rigide.
|
|
105
109
|
|
|
106
|
-
##
|
|
110
|
+
## 61 ruoli suddivisi in 10 pacchetti
|
|
107
111
|
|
|
108
112
|
| Pacchetto | Ruoli |
|
|
109
113
|
|------|-------|
|
|
110
|
-
| **Core** (3) | Orchestratore,
|
|
111
|
-
| **Engineering** (7) | Sviluppatore
|
|
112
|
-
| **Design** (2) |
|
|
114
|
+
| **Core** (3) | Orchestratore, stratega del prodotto, revisore critico |
|
|
115
|
+
| **Engineering** (7) | Sviluppatore frontend, ingegnere backend, ingegnere di test, ingegnere di refactoring, ingegnere delle prestazioni, revisore delle dipendenze, revisore della sicurezza |
|
|
116
|
+
| **Design** (2) | Designer dell'interfaccia utente, responsabile del marchio |
|
|
113
117
|
| **Marketing** (1) | Copywriter per il lancio |
|
|
114
|
-
| **Treatment** (7) | Ricercatore
|
|
115
|
-
| **Product** (3) |
|
|
116
|
-
| **Research** (4) | Ricercatore UX,
|
|
117
|
-
| **Growth** (4) |
|
|
118
|
+
| **Treatment** (7) | Ricercatore del repository, traduttore del repository, architetto della documentazione, curatore dei metadati, revisore della copertura, verificatore della distribuzione, ingegnere del rilascio |
|
|
119
|
+
| **Product** (3) | Sintetizzatore di feedback, prioritizzatore della roadmap, scrittore di specifiche |
|
|
120
|
+
| **Research** (4) | Ricercatore UX, analista della concorrenza, ricercatore di tendenze, sintetizzatore di interviste con gli utenti |
|
|
121
|
+
| **Growth** (4) | Stratega del lancio, stratega dei contenuti, responsabile della community, responsabile del triage del supporto |
|
|
122
|
+
| **Deep Audit** (4) | Revisore dei componenti, revisore della verità dei test, revisore dei punti di connessione, sintetizzatore di audit |
|
|
123
|
+
| **Swarm** (7) | Coordinatore dello swarm, agente backend dello swarm, agente di collegamento dello swarm, agente di test dello swarm, agente dell'infrastruttura dello swarm, agente frontend dello swarm, sintetizzatore dello swarm |
|
|
118
124
|
|
|
119
|
-
Ogni ruolo ha un contratto completo: missione, quando
|
|
125
|
+
Ogni ruolo ha un contratto completo: missione, quando usarlo, quando non usarlo, input previsti, output richiesti, standard di qualità e fattori scatenanti per l'escalation. Ogni ruolo è instradabile: `roleos route` può raccomandarne uno qualsiasi in base al contenuto del pacchetto.
|
|
120
126
|
|
|
121
|
-
##
|
|
127
|
+
## Avvio rapido
|
|
122
128
|
|
|
123
129
|
```bash
|
|
124
130
|
npx role-os init
|
|
@@ -133,6 +139,19 @@ roleos complete artifact.md # Complete with artifact
|
|
|
133
139
|
roleos explain # Show full state
|
|
134
140
|
roleos report # Completion report
|
|
135
141
|
|
|
142
|
+
# Deep audit:
|
|
143
|
+
roleos audit manifest --generate # Create audit-manifest.json
|
|
144
|
+
roleos audit # Start component-level deep audit
|
|
145
|
+
roleos audit status # Check audit progress
|
|
146
|
+
roleos audit verify # Verify manifest and outputs
|
|
147
|
+
|
|
148
|
+
# Dogfood swarm:
|
|
149
|
+
roleos swarm manifest --generate # Auto-detect domains from repo structure
|
|
150
|
+
roleos swarm # Start multi-pass convergence swarm
|
|
151
|
+
roleos swarm status # Check swarm progress by stage
|
|
152
|
+
roleos swarm findings # List findings by severity
|
|
153
|
+
roleos swarm approve # Approve feature gate
|
|
154
|
+
|
|
136
155
|
# Or go manual:
|
|
137
156
|
roleos start "fix the crash" # Entry decision only (no run)
|
|
138
157
|
roleos packet new feature
|
|
@@ -144,57 +163,57 @@ roleos mission list
|
|
|
144
163
|
roleos packs list
|
|
145
164
|
```
|
|
146
165
|
|
|
147
|
-
## Quando non
|
|
166
|
+
## Quando non usare Role OS
|
|
148
167
|
|
|
149
|
-
- Correzioni di
|
|
150
|
-
-
|
|
151
|
-
-
|
|
152
|
-
- Correzioni urgenti che devono essere
|
|
168
|
+
- Correzioni di singole righe, errori di battitura o bug evidenti
|
|
169
|
+
- Ricerca esplorativa senza risultati definiti
|
|
170
|
+
- Lavoro che può essere svolto da una sola persona in 5 minuti
|
|
171
|
+
- Correzioni urgenti che devono essere implementate prima del completamento del processo di revisione
|
|
153
172
|
- Progetti in cui si privilegia la velocità rispetto alla struttura
|
|
154
173
|
|
|
155
|
-
##
|
|
174
|
+
## Evidenza
|
|
156
175
|
|
|
157
|
-
Role OS è stato testato
|
|
176
|
+
Role OS è stato testato con tre diverse configurazioni in due repository strutturalmente differenti:
|
|
158
177
|
|
|
159
|
-
**Test 001 —
|
|
160
|
-
- Catena di 7 ruoli, 45 scenari di test, 0 conflitti di ruolo
|
|
161
|
-
-
|
|
178
|
+
**Test 001 — Lavoro sulle funzionalità** (Schermata dell'equipaggio, Trasporto di merci)
|
|
179
|
+
- Catena di 7 ruoli, 45 scenari di test, 0 conflitti di ruolo
|
|
180
|
+
- Prevenzione di contaminazioni da rami precedenti, individuazione di invenzioni in corso, evidenziazione di ostacoli reali
|
|
162
181
|
|
|
163
|
-
**Test 002 —
|
|
164
|
-
- Catena di 5 ruoli,
|
|
165
|
-
- I test anti-
|
|
182
|
+
**Test 002 — Lavoro di integrazione** (Collegamento CampaignState, Trasporto di merci)
|
|
183
|
+
- Catena di 5 ruoli, risoluzione di un problema architettonico senza ricorrere a soluzioni di ripiego
|
|
184
|
+
- I test anti-ripiego hanno dimostrato che il percorso attivo è reale, non un segnaposto
|
|
166
185
|
|
|
167
|
-
**Test 003 —
|
|
168
|
-
- Catena di 6 ruoli, 51 scenari di test, inclusa
|
|
169
|
-
-
|
|
186
|
+
**Test 003 — Lavoro sull'identità** (Eliminazione delle contaminazioni, Trasporto di merci)
|
|
187
|
+
- Catena di 6 ruoli, 51 scenari di test, inclusa una difesa robusta contro le contaminazioni nel processo di integrazione continua
|
|
188
|
+
- Riparazione di incongruenze ereditate senza sfociare in una riprogettazione radicale
|
|
170
189
|
|
|
171
|
-
**
|
|
172
|
-
- Stessa struttura di base,
|
|
173
|
-
-
|
|
190
|
+
**Test di portabilità** (Coerenza della persona, umorismo sensoriale)
|
|
191
|
+
- Stessa struttura di base, linguaggio/dominio/stack diversi
|
|
192
|
+
- Adottato con modifiche al contesto, senza modifiche al contratto principale
|
|
174
193
|
|
|
175
194
|
**Trattamento completo FT-001** (portlight-desktop)
|
|
176
|
-
- Trattamento
|
|
177
|
-
-
|
|
195
|
+
- Trattamento in 7 fasi con ruoli definiti nel Treatment Pack
|
|
196
|
+
- Il controllo Shipcheck è stato verificato, zero conflitti di ruolo
|
|
178
197
|
|
|
179
198
|
**Trattamento completo FT-002** (studioflow)
|
|
180
|
-
- Stesso
|
|
181
|
-
-
|
|
199
|
+
- Stesso Treatment Pack, repository strutturalmente diverso (spazio di lavoro creativo rispetto al gioco)
|
|
200
|
+
- Il Treatment Pack è portabile, non sono necessarie modifiche al contratto
|
|
182
201
|
|
|
183
|
-
**
|
|
184
|
-
- Catena di 9 ruoli, 4 analisti in parallelo, esame incrociato +
|
|
185
|
-
- 4 sfide
|
|
186
|
-
-
|
|
187
|
-
-
|
|
202
|
+
**Sessione di brainstorming** (argomento del marketplace del server MCP)
|
|
203
|
+
- Catena di 9 ruoli, 4 analisti in parallelo, esame incrociato + confutazione del grafico delle controversie
|
|
204
|
+
- Sono state sollevate 4 sfide, 3 affermazioni sono state ridotte, 1 è rimasta irrisolta: una pressione sana, non uno stallo
|
|
205
|
+
- Più di 16 collegamenti di traccia dagli artefatti renderizzati agli atomi del livello di verità
|
|
206
|
+
- È stata dimostrata la completa catena di custodia: verità → atomi → controversia → sintesi → espansione → giudizio → renderizzazione → traccia
|
|
188
207
|
|
|
189
208
|
## Proprietà fondamentali
|
|
190
209
|
|
|
191
|
-
Queste sono
|
|
210
|
+
Queste sono innegociabili. Se una modifica le indebolisce, rifiutarla.
|
|
192
211
|
|
|
193
|
-
- I confini dei ruoli
|
|
194
|
-
- La revisione è efficace
|
|
195
|
-
- L'escalation rimane trasparente
|
|
196
|
-
- I pacchetti rimangono testabili
|
|
197
|
-
- La portabilità richiede adattamento al contesto, non
|
|
212
|
+
- I confini dei ruoli sono mantenuti
|
|
213
|
+
- La revisione è efficace
|
|
214
|
+
- L'escalation rimane trasparente
|
|
215
|
+
- I pacchetti rimangono testabili
|
|
216
|
+
- La portabilità richiede un adattamento al contesto, non un intervento radicale
|
|
198
217
|
|
|
199
218
|
## Struttura del progetto
|
|
200
219
|
|
|
@@ -206,18 +225,23 @@ role-os/
|
|
|
206
225
|
entry-cmd.mjs ← `roleos start` CLI command
|
|
207
226
|
run.mjs ← Persistent run engine: create → step → pause → resume → report
|
|
208
227
|
run-cmd.mjs ← `roleos run/resume/next/explain/complete/fail` + interventions
|
|
209
|
-
mission.mjs ←
|
|
228
|
+
mission.mjs ← 9 named mission types (feature, bugfix, treatment, docs, security, research, brainstorm, deep-audit, dogfood-swarm)
|
|
210
229
|
mission-run.mjs ← Mission runner: create → step → complete → report
|
|
211
230
|
mission-cmd.mjs ← `roleos mission` CLI commands
|
|
212
|
-
|
|
213
|
-
|
|
231
|
+
audit-cmd.mjs ← `roleos audit` — deep audit entry point with manifest generation
|
|
232
|
+
swarm-cmd.mjs ← `roleos swarm` — dogfood swarm entry point with domain detection
|
|
233
|
+
swarm/ ← Domain detection, build gate, evidence persistence bridge
|
|
234
|
+
route.mjs ← 61-role routing + dynamic chain builder
|
|
235
|
+
packs.mjs ← 10 calibrated team packs + auto-selection
|
|
214
236
|
conflicts.mjs ← 4-pass conflict detection
|
|
215
237
|
escalation.mjs ← Auto-routing for blocked/rejected/split
|
|
216
238
|
evidence.mjs ← Structured evidence + role-aware requirements
|
|
217
239
|
dispatch.mjs ← Runtime dispatch manifests for multi-claude
|
|
218
|
-
|
|
240
|
+
tool-profiles.mjs ← Per-role tool sandboxing (shared by dispatch + trial)
|
|
241
|
+
state-machine.mjs ← Canonical step/run transition maps
|
|
242
|
+
artifacts.mjs ← Per-role artifact contracts + pack handoffs
|
|
219
243
|
decompose.mjs ← Composite task detection + splitting
|
|
220
|
-
composite.mjs ← Dependency-ordered execution + recovery
|
|
244
|
+
composite.mjs ← Dependency-ordered execution + recovery + cycle detection
|
|
221
245
|
replan.mjs ← Mid-run adaptive replanning
|
|
222
246
|
calibration.mjs ← Outcome recording + weight tuning
|
|
223
247
|
hooks.mjs ← 5 lifecycle hooks for runtime enforcement
|
|
@@ -225,56 +249,60 @@ role-os/
|
|
|
225
249
|
brainstorm.mjs ← Evidence modes, request validation, finding/synthesis/judge schemas
|
|
226
250
|
brainstorm-roles.mjs ← Role-native schemas, input partitioning, blindspot enforcement, cross-exam
|
|
227
251
|
brainstorm-render.mjs ← Two-layer rendering: lexical bans, render schemas, debate transcript
|
|
228
|
-
test/ ←
|
|
252
|
+
test/ ← 1150 tests across 37 test files
|
|
229
253
|
starter-pack/ ← Drop-in role contracts, policies, schemas, workflows
|
|
230
254
|
```
|
|
231
255
|
|
|
232
256
|
## Sicurezza
|
|
233
257
|
|
|
234
|
-
|
|
258
|
+
Role OS opera **solo a livello locale**. Copia i modelli Markdown e scrive i file di pacchetto/verdetto nella directory `.claude/` del repository. Non accede alla rete, non gestisce segreti e non raccoglie dati di telemetria. Non esegue operazioni pericolose: tutte le scritture di file utilizzano di default l'opzione "salta se esiste". Consultare [SECURITY.md](SECURITY.md) per la politica completa.
|
|
235
259
|
|
|
236
260
|
## Il sistema operativo
|
|
237
261
|
|
|
238
|
-
| Livello |
|
|
262
|
+
| Livello | A cosa serve | Stato |
|
|
239
263
|
|-------|-------------|--------|
|
|
240
|
-
| **Routing** | Valuta tutti i
|
|
241
|
-
| **Chain builder** | Assembla catene ordinate per
|
|
242
|
-
| **Conflict detection** |
|
|
243
|
-
| **Escalation** |
|
|
244
|
-
| **Evidence** |
|
|
264
|
+
| **Routing** | Valuta tutti i 61 ruoli in base al contenuto del pacchetto, spiega le raccomandazioni, valuta il livello di confidenza | ✓ Implementato |
|
|
265
|
+
| **Chain builder** | Assembla catene ordinate per fasi dai ruoli valutati, con una preferenza per il tipo di pacchetto, ma non vincolato al modello | ✓ Implementato |
|
|
266
|
+
| **Conflict detection** | Validazione in 4 fasi: conflitti, sequenza, ridondanza, lacune nella copertura. Suggerimenti per la correzione. | ✓ Implementato |
|
|
267
|
+
| **Escalation** | Instrada automaticamente il lavoro bloccato/rifiutato/diviso verso il resolver corretto, con motivazione + artefatto richiesto | ✓ Implementato |
|
|
268
|
+
| **Evidence** | Evidenza strutturata e specifica per il ruolo nei verdetti. Controlli di sufficienza. 12 tipi di evidenza. | ✓ Implementato |
|
|
245
269
|
| **Dispatch** | Genera manifesti di esecuzione per multi-claude. Profili degli strumenti per ruolo, prompt di sistema, budget. | ✓ Implementato |
|
|
246
|
-
| **Trials** | Roster completo
|
|
247
|
-
| **Team Packs** |
|
|
248
|
-
| **Outcome calibration** | Registra i risultati
|
|
249
|
-
| **Mixed-task decomposition** | Rileva
|
|
250
|
-
| **Composite execution** | Esegue i pacchetti secondari in ordine di dipendenza
|
|
251
|
-
| **Adaptive replanning** |
|
|
252
|
-
| **Session spine** | `roleos init claude` crea i file CLAUDE.md, /roleos-route, /roleos-review, /roleos-status. `roleos doctor` verifica
|
|
253
|
-
| **Hook spine** | 5 hook del ciclo di vita (SessionStart, PromptSubmit, PreToolUse, SubagentStart, Stop). Applicazione di
|
|
254
|
-
| **Artifact spine** |
|
|
255
|
-
| **Mission library** |
|
|
256
|
-
| **Mission runner** | Crea esecuzioni,
|
|
257
|
-
| **Unified entry** | `roleos start` decide automaticamente
|
|
258
|
-
| **Persistent runs** | `roleos run` crea esecuzioni
|
|
259
|
-
| **Brainstorm** | Architettura a due livelli: verità (schemi nativi
|
|
260
|
-
|
|
261
|
-
|
|
262
|
-
|
|
263
|
-
|
|
270
|
+
| **Trials** | Roster completo verificato: 30/30 attività principali + 5/5 test negativi. 7 test di pacchetto completati. | ✓ Completato |
|
|
271
|
+
| **Team Packs** | 10 pacchetti calibrati con selezione automatica, protezioni contro le incongruenze e fallback con instradamento libero. | ✓ Implementato |
|
|
272
|
+
| **Outcome calibration** | Registra i risultati dell'esecuzione, ottimizza i pesi dei pacchetti/ruoli in base ai risultati, regola le soglie di confidenza. | ✓ Implementato |
|
|
273
|
+
| **Mixed-task decomposition** | Rileva il lavoro composito, lo suddivide in pacchetti secondari, assegna i pacchetti, preserva le dipendenze. | ✓ Implementato |
|
|
274
|
+
| **Composite execution** | Esegue i pacchetti secondari in ordine di dipendenza con passaggio di artefatti, ripristino dei rami e sintesi. | ✓ Implementato |
|
|
275
|
+
| **Adaptive replanning** | Le modifiche all'ambito, le scoperte o i nuovi requisiti a metà dell'esecuzione aggiornano il piano senza riavviare. | ✓ Implementato |
|
|
276
|
+
| **Session spine** | `roleos init claude` crea i file CLAUDE.md, /roleos-route, /roleos-review, /roleos-status. `roleos doctor` verifica il collegamento. Le schede di instradamento dimostrano l'impegno. | ✓ Implementato |
|
|
277
|
+
| **Hook spine** | 5 hook del ciclo di vita (SessionStart, PromptSubmit, PreToolUse, SubagentStart, Stop). Applicazione di consigli: promemoria della scheda di instradamento, controllo dell'utilizzo degli strumenti, iniezione del ruolo del subagente, audit del completamento. | ✓ Implementato |
|
|
278
|
+
| **Artifact spine** | Contratti sugli artefatti per ruolo. Contratti di passaggio dei pacchetti. Validazione strutturale. Controlli di completezza della catena. I ruoli a valle non devono mai indovinare cosa hanno ricevuto. | ✓ Implementato |
|
|
279
|
+
| **Mission library** | 9 missioni nominate (feature-ship, bugfix, treatment, docs-release, security-hardening, research-launch, brainstorm, deep-audit, dogfood-swarm). Ognuna dichiara il pacchetto, la catena di ruoli, il flusso di artefatti, i rami di escalation, una definizione onesta e parziale. | ✓ Implementato |
|
|
280
|
+
| **Mission runner** | Crea esecuzioni, esegue i passaggi con lo stato tracciato, completa/fallisce con una segnalazione trasparente. Propagazione dei passaggi bloccati, avvisi di escalation al di fuori della catena, riapertura dell'ultimo passaggio. | ✓ Implementato |
|
|
281
|
+
| **Unified entry** | `roleos start` decide automaticamente se utilizzare una missione, un pacchetto o un instradamento libero. Scala di fallback con punteggi di confidenza, alternative e rilevamento di elementi compositi. | ✓ Implementato |
|
|
282
|
+
| **Persistent runs** | `roleos run` crea esecuzioni archiviate su disco. `resume`, `next`, `explain`, `complete`, `fail`. Interventi: reindirizzamento, escalation, riprova, blocco, riapertura. Guida specifica per ogni passaggio. Misurazione dell'attrito. | ✓ Implementato |
|
|
283
|
+
| **Brainstorm** | Architettura a due livelli: verità (schemi nativi del ruolo, atomi di provenienza, grafico delle controversie di esame incrociato) + renderizzazione (5 voci distinte, divieti lessicali, trascrizione del dibattito). I collegamenti di traccia dimostrano che ogni affermazione renderizzata corrisponde a un atomo di verità. Esecuzione di successo dimostrata. | ✓ Implementato |
|
|
284
|
+
| **Deep Audit** | Audit del repository basato sul manifest: scomporre il repository in componenti, assegnare N auditor + M auditor per la verifica dei test + K auditor per le interfacce dal grafico delle dipendenze, sintetizzare in una valutazione classificata e in un piano d'azione. L'assegnazione dinamica si adatta alle dimensioni del repository (formula 2N + K + 3). Esecuzione nativa con convalida degli artefatti a ogni passaggio. | ✓ Implementato |
|
|
285
|
+
| **Dogfood Swarm** | Convergenza multi-pass: tre fasi di verifica (bug/sicurezza → proattiva → umanizzazione) quindi fase delle funzionalità. Proprietà esclusiva dei file, controlli di build dopo ogni iterazione, checkpoint utente. Il rilevamento automatico del dominio genera i manifest. Collegamento alle prove per i test interni. | ✓ Implementato |
|
|
286
|
+
|
|
287
|
+
## 9 missioni
|
|
288
|
+
|
|
289
|
+
| Missione | Pacchetto | Ruoli | Quando utilizzare |
|
|
264
290
|
|---------|------|-------|-------------|
|
|
265
|
-
| `feature-ship` |
|
|
266
|
-
| `bugfix` |
|
|
267
|
-
| `treatment` |
|
|
268
|
-
| `docs-release` |
|
|
269
|
-
| `security-hardening` | Sicurezza | 4 | Modello delle minacce, audit, correzione delle vulnerabilità,
|
|
270
|
-
| `research-launch` |
|
|
271
|
-
| `brainstorm` |
|
|
272
|
-
|
|
273
|
-
|
|
291
|
+
| `feature-ship` | Funzionalità | 5 | Consegna completa della funzionalità: ambito → specifiche → implementazione → test → revisione |
|
|
292
|
+
| `bugfix` | Correzione di bug | 4 | Diagnosticare la causa principale, correggere, testare, verificare |
|
|
293
|
+
| `treatment` | Intervento | 4 | Verifica prima della pubblicazione + rifinitura + documentazione + verifica CI + revisione |
|
|
294
|
+
| `docs-release` | Documentazione | 2 | Scrivere/aggiornare la documentazione, le note di rilascio |
|
|
295
|
+
| `security-hardening` | Sicurezza | 4 | Modello delle minacce, audit, correzione delle vulnerabilità, ri-audit, verifica |
|
|
296
|
+
| `research-launch` | Ricerca | 4 | Formulare la domanda, effettuare la ricerca, documentare i risultati, decidere |
|
|
297
|
+
| `brainstorm` | Brainstorming | 9 | Indagine strutturata e multi-prospettica con disaccordo e valutazione tracciabili |
|
|
298
|
+
| `deep-audit` | Audit approfondito | 5 (livelli) | Audit del repository basato sul manifest: il numero di worker si adatta al grafico del repository tramite l'assegnazione dinamica |
|
|
299
|
+
| `dogfood-swarm` | Swarm | 8 (livelli) | Convergenza multi-pass: health-a → health-b → health-c → funzionalità → sintesi finale |
|
|
300
|
+
|
|
301
|
+
Ogni missione include definizioni parziali e oneste: quando il lavoro si interrompe, il sistema documenta ciò che è stato completato e ciò che rimane, invece di fingere di aver completato tutto.
|
|
274
302
|
|
|
275
303
|
### Missione di brainstorming
|
|
276
304
|
|
|
277
|
-
Non "brainstorming
|
|
305
|
+
Non si tratta di "brainstorming con l'IA". La missione di brainstorming prevede **ruoli specializzati definiti dalla legge, con disaccordo e risultati valutabili tracciabili.**
|
|
278
306
|
|
|
279
307
|
```bash
|
|
280
308
|
roleos run "explore product directions for a developer tool discovery platform"
|
|
@@ -284,31 +312,59 @@ roleos run "explore product directions for a developer tool discovery platform"
|
|
|
284
312
|
|
|
285
313
|
**Cosa la rende diversa:**
|
|
286
314
|
|
|
287
|
-
- **Livello 1 (verità):** Quattro analisti emettono schemi
|
|
315
|
+
- **Livello 1 (verità):** Quattro analisti emettono schemi specifici per il ruolo (ContextMap, UserValueMap, MechanicsMap, PositioningMap) – non si tratta di prosa condivisa. Ogni ruolo applica un filtro per evitare punti ciechi: frasi proibite, tipi di affermazioni proibite, partizioni di input filtrate. Gli atomi contengono informazioni sulla provenienza. Un grafico di controinterrogatorio diretto produce sfide mirate. Gli analisti originali difendono, restringono o ritrattano sotto pressione.
|
|
316
|
+
|
|
317
|
+
- **Livello 2 (rendering):** Cinque voci umane distinte (Boundary Memo, Field Notes, System Sketch, Claim Brief, Cross-Exam Transcript) con divieti lessicali che impediscono la convergenza delle voci. La sintesi utilizza la verità, non la prosa resa. Entrambi i livelli sono sempre disponibili.
|
|
288
318
|
|
|
289
|
-
- **
|
|
319
|
+
- **Catena di custodia:** Ogni frase resa può essere fatta risalire a un atomo del livello di verità. Le direttive di sintesi citano gli atomi. I target del controinterrogatorio sono ID di affermazioni reali. Il grafico delle controversie è il prodotto, non la prosa.
|
|
320
|
+
|
|
321
|
+
**Provato:** Esecuzione di riferimento v0.4: catena di custodia completa verificata. Consultare [`examples/golden-run.md`](examples/golden-run.md) per la catena completa degli artefatti.
|
|
322
|
+
|
|
323
|
+
### Missione di audit approfondito
|
|
324
|
+
|
|
325
|
+
Non si tratta di una scansione superficiale. La missione di audit approfondito **scompone un repository in componenti delimitati e assegna auditor specializzati in base a una scala determinata dal grafico delle dipendenze del repository stesso.**
|
|
326
|
+
|
|
327
|
+
```bash
|
|
328
|
+
roleos run "deep audit this repo" --manifest=audit-manifest.json
|
|
329
|
+
# → MISSION: Deep Audit (Manifest-Scaled)
|
|
330
|
+
# Steps: Component Auditor ×6 + Test Truth Auditor ×6 + Seam Auditor ×8 + Synthesizer + Action Plan + Critic = 23 steps
|
|
331
|
+
```
|
|
332
|
+
|
|
333
|
+
**Cosa la rende diversa:**
|
|
334
|
+
|
|
335
|
+
- **Assegnazione dinamica:** il numero di worker non è fisso. Un repository con 10 componenti e 5 cluster di confine produce 28 passaggi (2 × 10 + 5 + 3). Un repository con 3 componenti produce 12 passaggi. La formula di scalabilità è `2N + K + 3`, dove N = componenti, K = confini.
|
|
336
|
+
- **Pacchetti basati sul manifest:** un file `audit-manifest.json` definisce i componenti (con percorsi dei file, conteggi delle righe, descrizioni) e i confini (da/a con descrizioni dell'interfaccia). Ogni auditor riceve solo il proprio pacchetto.
|
|
337
|
+
- **Quattro archetipi di ruolo:** Auditor dei componenti (verità del codice per modulo), Auditor della verifica dei test (test che dimostrano vs test che esistono), Auditor delle interfacce (confini di integrazione dal grafico delle dipendenze), Sintetizzatore dell'audit (valutazione classificata + piano d'azione da tutti i pacchetti).
|
|
338
|
+
- **Convalida degli artefatti a ogni passaggio:** `validateArtifact()` viene eseguito al termine di ogni passaggio in entrambi i percorsi di esecuzione. I risultati vengono allegati agli oggetti di passaggio. Il sistema sa se ogni artefatto ha soddisfatto il suo contratto.
|
|
339
|
+
- **Onestà parziale:** quando il budget o l'ambito impediscono il completamento, i risultati per componente sono validi individualmente. Il sistema sintetizza ciò che è stato completato, senza mai fingere di aver coperto tutto.
|
|
340
|
+
|
|
341
|
+
**Provato:** Esecuzione nativa di Runner: 18 test su un manifest reale, ciclo di vita completo verificato, inclusa la riapertura in caso di escalation e il fallimento parziale. La formula di scalabilità è stata verificata per manifest con 3/6/10/15 componenti.
|
|
342
|
+
|
|
343
|
+
### Missione di swarm per i test interni
|
|
344
|
+
|
|
345
|
+
Non si tratta di un linting a passaggio singolo. La missione di swarm per i test interni **esegue un protocollo di convergenza multi-pass che porta un repository da "funzionante" a "pronto per la produzione" attraverso tre fasi di verifica e la consegna iterativa delle funzionalità.**
|
|
346
|
+
|
|
347
|
+
```bash
|
|
348
|
+
roleos swarm
|
|
349
|
+
# → MISSION: Dogfood Swarm (Multi-Pass Convergence)
|
|
350
|
+
# Stages: Health-A → Health-B → Health-C → Feature → Final
|
|
351
|
+
# Domain agents: 3-5 parallel per wave (exclusive file ownership)
|
|
352
|
+
```
|
|
353
|
+
|
|
354
|
+
**Cosa la rende diversa:**
|
|
290
355
|
|
|
291
|
-
- **
|
|
356
|
+
- **Sistema di controllo a tre fasi** — La fase A corregge bug e problemi di sicurezza (il ciclo continua finché non vengono risolti 0 problemi CRITICI e 0 problemi ALTI). La fase B applica misure di sicurezza proattive (gli utenti esaminano i risultati). La fase C rende il codice più intuitivo — messaggi di errore che aiutano gli utenti, feedback sulla riconnessione, indicatori di caricamento, accessibilità. Ogni fase rappresenta una prospettiva distinta e non è una semplice ripetizione della stessa scansione.
|
|
357
|
+
- **Proprietà esclusiva dei file** — ogni agente di dominio possiede file specifici tramite `swarm-manifest.json`. Nessun agente modifica lo stesso file. Nessun conflitto di unione. Nessun sovraccarico di coordinamento.
|
|
358
|
+
- **Controlli di build** — lint, controllo dei tipi e test devono essere superati dopo ogni ciclo. Il sistema rileva automaticamente il sistema di build (Node, Rust, Python, Go) ed esegue i comandi appropriati.
|
|
359
|
+
- **Punti di controllo utente** — Health-B e la fase di test delle funzionalità richiedono l'approvazione esplicita dell'utente prima dell'esecuzione. Il sistema presenta i risultati e l'utente decide cosa costruire.
|
|
360
|
+
- **Convergenza iterativa** — le fasi si ripetono in cicli finché non vengono soddisfatte le condizioni di uscita o raggiunto il numero massimo di iterazioni. Ogni ciclo riesamina tutto da zero per individuare eventuali regressioni introdotte dalle correzioni precedenti.
|
|
361
|
+
- **Rilevamento automatico del dominio** — `roleos swarm manifest --generate` rileva il tipo di repository (CLI, web, desktop, MCP, monorepo) e genera assegnazioni di dominio non sovrapposte.
|
|
292
362
|
|
|
293
|
-
**
|
|
363
|
+
**Dimostrato:** claude-collaborate (2026-03-28) — 35→129 test, 106 problemi di controllo risolti, versione v1.1.0 rilasciata. Protocollo v2.0 con 9 fasi.
|
|
294
364
|
|
|
295
365
|
## Stato
|
|
296
366
|
|
|
297
|
-
|
|
298
|
-
- v1.0.0: 32 ruoli, interfaccia a riga di comando completa, trattamento verificato, portabilità multi-repository
|
|
299
|
-
- v1.0.2: Blocco del sistema operativo dei ruoli (correzioni iniziali della verità, init --force)
|
|
300
|
-
- v1.1.0: 31 ruoli, infrastruttura di routing completa, rilevamento dei conflitti, escalation, prove, dispatch, 7 pacchetti di team verificati. 35 esecuzioni di prova. 212 test.
|
|
301
|
-
- v1.2.0: Pacchetti calibrati promossi a impostazione predefinita. Selezione automatica, rilevamento delle incongruenze, suggerimenti alternativi, fallback di routing libero. 246 test.
|
|
302
|
-
- v1.3.0: Calibrazione dei risultati, decomposizione di attività complesse, esecuzione composita, riprogrammazione adattiva. 317 test.
|
|
303
|
-
- v1.4.0: Infrastruttura delle sessioni — `roleos init claude`, `roleos doctor`, schede di routing, comandi /roleos-route + /roleos-review + /roleos-status. 335 test.
|
|
304
|
-
- v1.5.0: Infrastruttura degli hook — 5 hook del ciclo di vita per l'applicazione in fase di esecuzione. 358 test.
|
|
305
|
-
- v1.6.0: Infrastruttura degli artefatti — 20 contratti di artefatti specifici per ruolo, 7 contratti di trasferimento di pacchetti, convalida strutturale. 385 test.
|
|
306
|
-
- v1.7.0: Dimostrazione del completamento — attività reali eseguite sull'intera piattaforma. Interfaccia a riga di comando `roleos artifacts`. Escalation trasparente per le correzioni strutturali. 398 test.
|
|
307
|
-
- v1.8.0: Libreria di missioni (Fase S) — 6 missioni denominate, motore di esecuzione, report di completamento. Rafforzata da 6 esecuzioni di prova reali. 481 test.
|
|
308
|
-
- v1.9.0: Percorso di accesso unificato (Fase T) — `roleos start` decide automaticamente tra missione, pacchetto o routing libero. Scala di fallback, rilevamento composito, test di confronto del percorso di accesso. 527 test.
|
|
309
|
-
- **v2.0.0**: Ottimizzazione dell'esperienza utente (Fase U) — `roleos run` crea esecuzioni persistenti supportate dal disco. Riprendi, successivo, spiega, completa, fallisci. Interventi: reindirizza, aumenta, riprova, blocca, riapri. Guida specifica per ogni passaggio. Misurazione dell'attrito. 6 test di attrito. 613 test.
|
|
310
|
-
- **v2.0.1**: Revisione del manuale, documentazione per principianti, correzioni del conteggio dei test. 617 test.
|
|
311
|
-
- **v2.1.0**: Missione di brainstorming (v0.4) — ruoli specializzati nel campo legale, disaccordo tracciabile, output con valore probatorio. Architettura a due livelli (verità + rendering), matrice di autorizzazioni per il controinterrogatorio, grafo delle controversie, prova di esecuzione completa. 7 missioni, 50 ruoli, 8 pacchetti. 894 test.
|
|
367
|
+
Stabile e pronto per il rilascio. Consultare il [REGISTRO DELLE MODIFICHE](CHANGELOG.md) per la cronologia completa delle versioni e le modifiche apportate in ogni rilascio.
|
|
312
368
|
|
|
313
369
|
## Licenza
|
|
314
370
|
|
|
@@ -316,4 +372,4 @@ MIT
|
|
|
316
372
|
|
|
317
373
|
---
|
|
318
374
|
|
|
319
|
-
|
|
375
|
+
Realizzato da <a href="https://mcp-tool-shop.github.io/">MCP Tool Shop</a>
|