CtrlK
BlogDocsLog inGet started
Tessl Logo

spec-driven-development/agent-registry

Coordina multipli agenti AI CLI (Kimi, Claude, Gemini, OpenAI, ecc.) che lavorano contemporaneamente sullo stesso progetto e mantiene una memoria collettiva (wiki) di tutte le sessioni passate. Usa questa skill SEMPRE quando lavori in parallelo con altre AI CLI, quando devi salvare lo stato di una sessione condivisa, quando vuoi evitare sovrascritture su file toccati da altri agenti, quando devi chiedere "questo lavoro è già stato fatto? questo bug si è già visto?", o quando l'utente parla di "multi-tap", "registry agenti", "coordination", "lock file", "handoff condiviso", "wiki delle sessioni", "chi sta lavorando su cosa" o "evitare che le AI si pestino i piedi".

72

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

tasks.mdopenspec/changes/archive/2026-07-16-fix-cross-process-coordination/

1. Infrastruttura di test cross-process

  • 1.1 Creare tests/conftest.py con una fixture che isola AGENT_REGISTRY_LOCK_DIR e AGENT_REGISTRY_PATH in tmp_path per ogni test
  • 1.2 Aggiungere a conftest.py un helper che esegue un comando del manager in un processo separato che termina, restituendo exit code e stdout
  • 1.3 Aggiungere un helper che spara N processi simultanei sullo stesso path e raccoglie i loro esiti, per i test di corsa

2. Test rossi: la mutua esclusione (file-locking)

  • 2.1 tests/test_lock_cross_process.py: un secondo agente non può acquisire un lock valido preso da un processo terminato — riproduce il furto del lock
  • 2.2 L'owner conserva il proprio lock dopo il tentativo fallito di un altro agente
  • 2.3 N processi simultanei sullo stesso path: esattamente un vincitore
  • 2.4 Path distinti non interferiscono; l'owner riacquisisce in modo idempotente da un nuovo processo
  • 2.5 Staleness: rilevamento, acquisizione di un lock scaduto con stale_owner, e corsa di N processi su uno stale con un solo vincitore
  • 2.6 Heartbeat: rinnovo owner-only, rifiuto al non-owner, fallimento su lock assente, rinnovo che previene la scadenza
  • 2.7 Release: rilascio owner-only, rifiuto al non-owner con lock intatto, rilascio di lock inesistente senza eccezioni
  • 2.8 Identità del lock: path relativo e assoluto contendono lo stesso lock; file omonimi in progetti diversi no
  • 2.9 Configurazione: AGENT_REGISTRY_LOCK_DIR rispettato e directory creata se assente
  • 2.10 Verificare che 2.1–2.9 falliscano sul codice 0.1.0 e annotare quali passano per il motivo sbagliato

3. Test rossi: il registry (agent-registry)

  • 3.1 tests/test_registry_concurrency.py: N processi registrano N sessioni simultaneamente, tutte devono sopravvivere — riproduce la perdita di registrazioni
  • 3.2 N processi aggiornano simultaneamente sessioni diverse senza perdite
  • 3.3 Il registry resta parsabile durante le scritture concorrenti
  • 3.4 finish rilascia i lock della sessione e lascia intatti quelli altrui
  • 3.5 Estendere tests/test_registry_manager.py: aggiornamento parziale, sessione inesistente non creata implicitamente, escaping di | e a capo anche nelle liste, AGENT_REGISTRY_PATH rispettato
  • 3.6 Verificare che 3.1–3.5 falliscano sul codice 0.1.0

4. Riscrittura di scripts/lock_manager.py

  • 4.1 Aggiungere l'header GENERATED FROM SPEC e risolvere LOCK_DIR a ogni chiamata via AGENT_REGISTRY_LOCK_DIR
  • 4.2 Identità del lock su os.path.realpath, con il path reale scritto dentro il file di lock
  • 4.3 Stato del lock nel contenuto del file (sopravvive al processo) e flock a serializzare la sola sezione critica; rimuovere _OPEN_LOCK_FDS. Il lock file non viene mai cancellato: il rilascio ne azzera il contenuto (revisione in corso d'opera: l'approccio O_EXCL + os.link() previsto in design.md è stato scartato — vedi 4.4)
  • 4.4 Takeover di lock stale dentro la sezione critica, dove due taker sono serializzati dal flock (revisione: la verifica di st_ino/st_mtime_ns prima e dopo NON chiude la finestra, perché unlink agisce sul nome e non sull'inode — non esiste "cancella solo se è ancora quello che ho letto". design.md aggiornato di conseguenza)
  • 4.5 Riacquisizione idempotente dell'owner, con rinnovo della scadenza
  • 4.6 heartbeat e release_lock owner-only, con la verifica dell'owner e l'azione nella stessa sezione critica
  • 4.7 is_locked non cancella più i lock stale: si limita a riportarli
  • 4.8 CLI con exit code significativi e uso stampato senza traceback sugli argomenti mancanti

5. Riscrittura di scripts/registry_manager.py

  • 5.1 Aggiungere l'header GENERATED FROM SPEC e risolvere il path a ogni chiamata
  • 5.2 Introdurre registry.lock dedicato e mai rinominato, con un context manager che tiene flock per l'intera sezione critica
  • 5.3 Portare lettura e scrittura dentro la stessa sezione critica: register_session, update_session, unregister_session, add_handoff_ref
  • 5.4 Scrittura atomica via tempfile + os.replace, con fsync prima del replace
  • 5.5 update_session segnala l'assenza della sessione invece di crearla o tacere
  • 5.6 unregister_session rilascia i lock della sessione, saltando quelli di cui non è owner
  • 5.7 Escaping di | e a capo in ogni cella, incluse quelle derivate da liste
  • 5.8 CLI con exit code significativi
  • 5.9 Blocco di protocollo rigenerato a ogni scrittura fra frontmatter e tabella, con l'avvertenza sui lock advisory
  • 5.10 tests/test_registry_protocol.py: presenza nel registry nuovo, sopravvivenza agli aggiornamenti, parse non alterato, ripristino dopo manomissione
  • 5.11 Allineare templates/registry-template.md al blocco canonico, con un test che impedisca la divergenza fra template e codice

6. Verde e allineamento

  • 6.1 Eseguire l'intera suite: tutti i test dei gruppi 2 e 3 devono passare
  • 6.2 Rimuovere i test in-process della 0.1.0 resi obsoleti, documentando nel commit perché erano ciechi
  • 6.3 Verificare che scripts/webapp/main.py funzioni ancora dopo il cambio di serializzazione
  • 6.4 Aggiornare SKILL.md: path indipendenti dall'installazione, natura advisory dei lock, avvertenza su filesystem sincronizzati/di rete, rimozione del riferimento a references/registry-schema.yaml inesistente
  • 6.5 Eseguire bash scripts/verify.sh: link [@test], ownership dei target e suite tutti verdi
  • 6.6 work-review requisito per requisito con evidenza file:riga

openspec

changes

archive

2026-07-16-fix-cross-process-coordination

README.md

requirements-dev.txt

SKILL.md

SPEC_SETUP.md

tile.json