89 lines
4.2 KiB
Markdown
89 lines
4.2 KiB
Markdown
# Agent Operating Contract - NetGescon Centro Stella
|
|
|
|
## Scopo
|
|
|
|
Questo file e il contratto operativo minimo per gli agent che lavorano sul progetto NetGescon.
|
|
Vale come regola stabile per `.53`, `.205` e `.200`.
|
|
|
|
## Ordine di lettura obbligatorio
|
|
|
|
Prima di iniziare qualunque task, l'agent deve leggere in quest'ordine:
|
|
|
|
1. `AGENTS.md`
|
|
2. `skill-netgescon/control-tower/CURRENT-205.md` oppure `skill-netgescon/control-tower/CURRENT-200.md` in base alla macchina
|
|
3. i file richiamati nel task corrente
|
|
4. `skill-netgescon/.ai-context.md` come memoria architetturale e roadmap
|
|
|
|
Se uno dei file obbligatori manca o non e leggibile, l'agent deve fermarsi e restituire `BLOCCO_CONTESTO`.
|
|
|
|
## Regole rigide Catasto e Anagrafiche Stabili
|
|
|
|
- E vietato creare fallback dati per riempire la maschera Catasto.
|
|
- E vietato usare query locali di comodo al posto dell'archivio consolidato delle unita immobiliari.
|
|
- Se manca una relazione, una sorgente dati o una conferma strutturale, l'agent deve restituire `BLOCCO_DATI`.
|
|
- Ogni modifica deve proteggere il flusso: `import/prelettura -> matching -> conferma -> aggiornamento unita consolidate -> validazione`.
|
|
- **Relazioni Anagrafiche Legacy**:
|
|
- `id_cond` e il campo unico e tassativo di collegamento tra la tabella `condomin` e la tabella `comproprietari` per associare comproprietari, nudi proprietari ed usufruttuari alla corretta unita immobiliare.
|
|
- `cod_cond` e il codice contabile gestionale di ciascun anno gestione per legare rate ed incassi (`emes_det` e `incassi` in `generale_stabile.mdb`).
|
|
- `cond_inquil` (`'C'` per Condomino/Proprietario e `'I'` per Inquilino) distingue tassativamente la titolarita dei movimenti contabili per ciascuna gestione.
|
|
- Le percentuali di comproprieta e diritti reali (`perc_diritto_reale`, es. 50% / 50%) devono essere tassativamente rispettate e conservate nelle movimentazioni temporali di ciascun anno gestione.
|
|
|
|
## Regole rigide Stabili e Fatture Elettroniche (FE)
|
|
|
|
- L'anagrafica degli Stabili viene alimentata e sincronizzata direttamente dall'archivio consolidato `Stabili.mdb` popolando tassativamente il `codice_fiscale` dello Stabile.
|
|
- Le Fatture Elettroniche (XML/P7M/ZIP) scansionate nelle cartelle di lavoro e di archivio vengono assegnate ed associate agli Stabili con certezza assoluta ed esclusiva tramite il matching del `CessionarioCommittente` con il `codice_fiscale` dello Stabile.
|
|
- È vietata qualsiasi assegnazione arbitraria di Fatture Elettroniche priva di riscontro sul Codice Fiscale / Partita IVA dell'ente condominiale.
|
|
- È vietato lo svuotamento o la cancellazione automatica dei dati degli stabili consolidati (la pipeline di importazione richiede l'opzione esplicita `--reset-temp`).
|
|
|
|
## Regole macchina
|
|
|
|
### `.53`
|
|
|
|
- orchestra il lavoro
|
|
- prepara direttive e task
|
|
- controlla esiti e conformita
|
|
- non sviluppa il core applicativo della `.205`
|
|
|
|
### `.205`
|
|
|
|
- sviluppa il codice
|
|
- pubblica il risultato su Gitea
|
|
- non chiude il task senza branch, commit e test dichiarati
|
|
|
|
### `.200`
|
|
|
|
- valida in modo indipendente
|
|
- non modifica direttamente il branch condiviso
|
|
- restituisce solo esito, differenze, rischi e prima correzione richiesta
|
|
|
|
## Regole Git
|
|
|
|
- Gitea e la sorgente ufficiale di branch e commit del giro di lavoro.
|
|
- `.205` e l'unica macchina che modifica e pubblica il branch condiviso del task corrente.
|
|
- `.200` non deve riscrivere il branch condiviso; puo proporre fix o patch come indicazione, ma non sostituirsi alla `.205`.
|
|
|
|
## Regole API-first
|
|
|
|
- Il canale primario di orchestrazione e via API Control Tower.
|
|
- File locali, note temporanee o cartelle di appoggio non sostituiscono l'esito ufficiale del task.
|
|
- Ogni giro deve lasciare traccia persistente in: task, eventi, branch, commit, test, note e blocchi.
|
|
|
|
## Uscita obbligatoria task
|
|
|
|
Prima di chiudere un task, l'agent deve produrre un esito persistente con almeno:
|
|
|
|
- `TASK_ID`
|
|
- `ESITO_205` oppure `ESITO_200`
|
|
- `REPOSITORY`
|
|
- `BRANCH`
|
|
- `COMMIT`
|
|
- `TEST_ESEGUITI`
|
|
- `BLOCCO_DATI`
|
|
- `NOTE`
|
|
|
|
## Regola di continuita
|
|
|
|
- Le decisioni stabili non devono restare solo in chat.
|
|
- Le regole consolidate vanno promosse in `skill-netgescon/directives/` o nella documentazione permanente.
|
|
- Il task corrente va mantenuto nei file `CURRENT-*` del Control Tower.
|