netgescon-day0/docs/support/WORKFLOW-KB-ORCHESTRATOR-PRODUTTIVO.md

157 lines
3.9 KiB
Markdown
Executable File

# Workflow produttivo KB + orchestrator
## Scopo
Questo file fissa il modo pratico di lavorare sulle macchine client con `.53` come cervello centrale.
La regola e semplice:
1. prima consultazione
2. poi backlog
3. poi implementazione
4. poi ritorno del risultato in `docs/` o nel KB
## Perche questo flusso aumenta la produttivita
Su NetGescon molta parte del lavoro corretto non e partire subito dal codice.
Spesso il flusso giusto e:
1. recuperare il contesto gia esistente
2. capire cosa e gia stato deciso o prototipato
3. evitare di duplicare codice o idee gia presenti
4. scrivere solo il codice nuovo che manca davvero
Questo vale in particolare per:
- anagrafica unica
- import e unita immobiliari
- ticket e operativita
- banca, contabilita e FE
- WABA
- etichette
- integrazioni API e moduli
## Pipeline consigliata
```text
KB search -> briefing locale -> backlog di lavoro -> orchestrator locale -> codice/test -> docs/KB
```
## Regola operativa per ogni nuovo cantiere
### 1. Consultazione iniziale
Fare sempre almeno 2 o 3 query KB prima di aprire un nuovo task.
Esempi:
- `anagrafica unica`
- `ticket operativita`
- `integrazione contabile`
- `WABA webhook`
- `etichette stampa`
### 2. Backlog piccolo e mirato
Non partire con backlog troppo grandi o generici.
Meglio backlog con 3 task iniziali:
1. ricognizione e riepilogo
2. implementazione o riallineamento
3. validazione e documentazione
### 3. Implementazione
Solo dopo la ricognizione KB si passa a:
- modifica codice
- script
- validazione
- commit
### 4. Ritorno della conoscenza
Se esce qualcosa di utile per altri:
- si aggiorna `docs/` se e una regola stabile o un runbook
- si registra nel KB se e una sessione, un fix o una sintesi operativa
## Wrapper operativo disponibile
Per automatizzare la fase `consultazione -> backlog -> orchestrator` usare:
- `scripts/ops/netgescon-orchestrator-kb-run.sh`
Questo script:
- interroga prima il KB con una o piu query
- salva un briefing locale in Markdown
- crea un backlog arricchito con il briefing KB
- lancia poi `agent-orchestrator` sul backlog arricchito
## Esempio pratico NetGescon
```bash
NETGESCON_KB_API_KEY='...' \
scripts/ops/netgescon-orchestrator-kb-run.sh \
--backlog ~/netgescon-orchestrator/netgescon-backlog.md \
--query 'anagrafica unica' \
--query 'ticket operativita' \
--query 'integrazione contabile' \
--mode analyze
```
## Esempio pratico WABA ed etichette
Quando vuoi farmi vedere i progressi su WABA ed etichette, il flusso consigliato e:
1. raccogliere i file o note che hai gia prodotto
2. interrogare il KB con query dedicate
3. creare un backlog breve per distinguere:
- stato attuale
- gap da colmare
- nuovo codice da scrivere
Query iniziali consigliate:
- `WABA webhook`
- `etichette stampa`
- `protocollo etichette`
- `documenti archivio`
## Cosa possiamo fare in concreto da adesso
### Stream A - NetGescon core
- consolidare anagrafica unica e import
- riallineare ticket e operativita
- collegare banca, contabilita e FE in modo piu leggibile e riusabile
### Stream B - WABA
- mappare lo stato attuale del lavoro fatto
- separare integrazione, webhook, code operative e UI
- capire cosa va promosso a modulo o servizio riusabile
### Stream C - Etichette
- censire il codice e la documentazione gia presenti
- distinguere stampa fisica, QR, protocollo e archivio
- trasformare le parti mature in un flusso stabile e riusabile anche su altri progetti
### Stream D - Replicazione macchine
- usare il bootstrap SSHFS + KB + orchestrator sulle altre macchine
- usare `.53` come centro conoscenza e Git
- usare le macchine client come esecutori specializzati per progetto o stream
## Prossimo passo consigliato
Il passo piu produttivo adesso e uno solo:
1. aprire un backlog dedicato `WABA + etichette`
2. far girare il wrapper KB + orchestrator su quel backlog
3. usare il risultato per decidere cosa e gia pronto, cosa va documentato e cosa va implementato davvero