76 lines
2.3 KiB
Markdown
76 lines
2.3 KiB
Markdown
# Handoff Macchina `.205` - Sorgente Primaria Nuovo Sviluppo
|
|
|
|
## Ruolo della `.205`
|
|
|
|
La `.205` resta la macchina di sviluppo piu avanzata. Deve consolidare il codice, ridurre il rumore locale nel branch di lavoro e pubblicare una baseline leggibile dalla `.200`.
|
|
|
|
## Obiettivo immediato
|
|
|
|
- trasformare il recovery branch in baseline di stabilizzazione
|
|
- continuare fix e nuove funzioni con disciplina Git
|
|
- produrre solo pacchetti di codice e direttive che la `.200` possa validare
|
|
|
|
## Procedura Git minima da eseguire sulla `.205`
|
|
|
|
### 1. Verifica stato locale
|
|
|
|
```bash
|
|
cd ~/netgescon-day0-backup
|
|
git status
|
|
git branch --show-current
|
|
git remote -v
|
|
```
|
|
|
|
### 2. Aggancio al ramo di stabilizzazione
|
|
|
|
```bash
|
|
cd ~/netgescon-day0-backup
|
|
git fetch origin
|
|
git switch recovery/205-from-200-20260701
|
|
git switch -c stabilization/205-zero 2>/dev/null || git switch stabilization/205-zero
|
|
```
|
|
|
|
### 3. Pubblicazione del ramo su Gitea
|
|
|
|
```bash
|
|
cd ~/netgescon-day0-backup
|
|
git push -u origin stabilization/205-zero
|
|
```
|
|
|
|
### 4. Verifica refs remote
|
|
|
|
```bash
|
|
git ls-remote --heads ssh://git@git.netgescon.it:2222/michele/netgescon-day0.git
|
|
```
|
|
|
|
### 5. Regola operativa da questo punto in poi
|
|
|
|
- i nuovi fix stabili vanno su `stabilization/205-zero`
|
|
- `main` non si tocca fino a validazione `.200`
|
|
- se emerge un fix sporco o sperimentale, usare un branch corto dedicato e poi rientrare su `stabilization/205-zero`
|
|
|
|
### 6. Output atteso
|
|
|
|
- branch `stabilization/205-zero` visibile su Gitea
|
|
- `.200` in grado di clonare o tracciare il branch senza ambiguita
|
|
- base sufficiente per distribuire task alle altre macchine dal Centro Stella
|
|
|
|
## Branch di riferimento atteso
|
|
|
|
- sorgente storica: `recovery/205-from-200-20260701`
|
|
- branch da promuovere: `stabilization/205-zero`
|
|
|
|
## Vincoli
|
|
|
|
- niente promozione a `main` prima della validazione `.200`
|
|
- niente distribuzione cieca alle altre macchine
|
|
- separare il piu possibile dati locali, documenti runtime e codice distribuibile
|
|
- non inventare dati o fallback per sbloccare import legacy o schermate
|
|
- se il task non richiede mutazioni DB, evitare qualunque scrittura strutturale sul database
|
|
- fermarsi dopo i comandi richiesti e restituire esito prima di procedere oltre
|
|
|
|
## Output atteso dalla `.205`
|
|
|
|
- baseline pubblicata su Gitea
|
|
- fix documentati
|
|
- indicazione chiara di cio che la `.200` deve verificare per prima |