registri dei piani in git (AI-OS#309)

Refs gitea:Adriano/AI-OS#310

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.superpowers/sdd/task-10-report.md

@@ -0,0 +1,58 @@
+# Task 10 — Report: badge GUID + modal modifica inline
+
+## Cosa è stato fatto
+
+Sostituito integralmente il blocco `{showTags && (...)}` in `src/layouts/Base.astro` (righe ~76-101) con il
+codice verbatim del brief: badge overlay (nome tag + guid abbreviato + pulsante matita ✎) e modal `#tag-modal`
+con textarea/select per contenuti testuali, upload/rimozione file per contenuti immagine.
+
+## Build e test automatici
+
+- `npm run build` → OK, nessun errore.
+- `npm test` → 13 file di test, 64 test, tutti verdi.
+
+## Verifica funzionale (runtime reale, non solo build statica)
+
+Ho creato un utente admin locale (`super`/`prova1234`, ruolo `admin` — lo script `create-user` accetta solo
+`admin`/`editor`, non `superuser`; `canTags` in Base.astro accetta sia `superuser` sia `admin`, quindi admin è
+sufficiente per attivare i tag).
+
+Avviato il build di produzione (`node dist/server/entry.mjs`, porta 4399) e verificato via `curl`:
+
+1. **Pagina anonima** (nessun cookie): `grep -c 'tag-modal'` sul body → **0**. Overlay assente per utenti non
+   autorizzati, come atteso.
+2. **Login** via POST form a `/login` con header `Origin` (richiesto dal check CSRF di Astro) → 302 + cookie
+   `session` (flag `Secure`, quindi passato manualmente negli header successivi visto che il server gira su http
+   in locale).
+3. **Attivazione tag**: POST `/api/admin/showtags {"on":true}` con cookie di sessione → 200, cookie `showtags=1`
+   impostato.
+4. **Pagina con showtags attivo**: GET `/` con cookie `session` + `showtags=1` → il body contiene:
+   - `tag-modal` (14 occorrenze: markup + CSS + script)
+   - `tag-badge__edit` (classe pulsante matita)
+   - `STYLE_GROUPS` (oggetto opzioni di stile nello script inline)
+   - 111 elementi con `data-tag`
+5. **Ciclo GET→PUT identico a quello del modal**: preso un tag reale dal DOM (`home.hero.title-line-1`):
+   - `GET /api/admin/content/home.hero.title-line-1` → 200, JSON con `{tag, guid, type:"text", value, styleOptions}`
+     — esattamente la forma consumata da `openModal()`.
+   - `PUT` con nuovo `value` → 200, `{ok:true, value:"PERFORMANCE-TEST-EDIT."}`.
+   - Rilettura via GET → valore effettivamente cambiato in DB.
+   - `PUT` di ripristino al valore originale (`"PERFORMANCE."`) → 200, verificato con GET finale che il valore
+     originale è tornato. Nessun dato di produzione lasciato alterato.
+6. Server fermato (`fuser -k 4399/tcp`) a fine verifica.
+
+### Cosa NON è stato verificato
+
+- Non ho un browser headless disponibile in questo ambiente, quindi **non ho eseguito il JS del badge/modal nel
+  DOM reale** (creazione dinamica dei badge posizionati, apertura modal via click, aggiornamento in-place del
+  testo senza reload, upload/rimozione immagine, comportamento dei `<select>` di stile). Ho verificato che lo
+  script sorgente sia presente e sintatticamente corretto (build Astro non fallisce, contiene le funzioni
+  `openModal`/`closeModal`/listener `tm-save`) e che le API che il modal chiama rispondano nel formato atteso
+  (GET/PUT verificati manualmente sopra). Il percorso "clic reale su ✎ → modal si apre → salvo → testo cambia
+  senza reload" resta da confermare in un browser vero.
+- Non ho testato il ramo immagine (`POST`/`DELETE /api/admin/content/[tag]/image`) end-to-end nel modal, solo
+  che gli endpoint esistono da task precedenti.
+
+## Commit
+
+`git commit -m "feat(inline): badge con guid + modal di modifica contenuti in pagina"` su
+`src/layouts/Base.astro`.