# 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