merge: dev7 → master — team grafica (dev5+dev6+dev7): mappa per città, case-studies v3, /docs, scorer RULE-08

dev7 (82 commit, dev5+dev6 inglobati) porta il grosso del lavoro grafica/web:
- [mappa] pin per CITTÀ (non solo coordinate ufficio), super-cluster pixel-space,
  scala verde per score, fila esplosa, pannelli collassati di default, colonna Source.
- [case-studies] v3: card profilo 2 colonne con località reale, grafico fonti +
  work/budget unico, timeline zoom 512×, tooltip giorno, fix tema light, match veritiero.
- [web] pagine Download (ARM64 + Prompt-mode), Run (install unificato), Pricing
  (riordino+immagine+callout), Project/Studies in home, sezione /docs (DocKit + 5
  guide), footer testuale con versione dinamica, favicon monocromatica, nav snella.
- [scorer] RULE-08: una posizione alla volta, scrittura DB immediata (no batch) +
  skill db-insert.
- [dashboard/positions] titoli troncati, tabelle allineate, donut Types responsive.

Merge pulito (0 conflitti) nonostante 45 commit master nel frattempo: dev7 e
l'interaction-planes hanno toccato file/regioni diverse. Verificato:
- migration 040-045 intatte (dev7 non aggiunge migration, nessuna collisione)
- interaction-planes di master PRESERVATI (deploy-mode, useIsCloud, cloud-sync/
  tickets, CloudRefreshButton, tunnel, email_monitor)
- nessun dead-code resuscitato
- prettier web (19 file riformattati) + shared puliti, tsc web 0, vitest 12/12.

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

Author: leopu00

BACKLOG.md

@@ -165,6 +165,24 @@ Versione: `package.json` `v0.1.17` (production ferma a `v0.1.12` dopo blocco Tur
 
 ---
 
+### 🪪 [JHT-RENAME-COORDINATOR] Capitano → Coordinatore — rebrand globale (NEW 2026-06-21)
+
+⬜ **Rinominare il ruolo «Capitano» in «Coordinatore» (EN: «Captain» → «Coordinator») OVUNQUE.** Decisione utente 2026-06-21: il nome del ruolo cambia in tutto il sistema, **incluso il codice del container**. Grande rifattorizzazione, da fare in una sessione dedicata.
+
+**Già fatto (solo web pubblico, estetica):** pagina `/agents` — rimossi gli emoji dai ruoli + rinominato il primo ruolo in «Il Coordinatore / The Coordinator» (titolo + descrizioni + menzioni in Sentinella/Assistente); `slug`/`promptId` → `coordinatore`/`team.coordinatore`; voce immagine in `landing-image-prompts.md` aggiornata.
+
+**Da fare (il grosso — codice, agenti, runtime):**
+- **Prompt agenti** — `agents/capitano/` (cartella + 7 file `capitano.*.md`), riferimenti a «Capitano/Captain» nei prompt degli altri ruoli e in `agents/_team/*` (architettura, team-rules), regole `C-NN` che lo nominano.
+- **Container / runtime** — nomi sessione tmux (`SESSION-CAPITANO`), `start-agent.sh`/`.launcher`, role registry, `agent-watchdog`, eventuali `role == "capitano"` hardcoded in Python/JS.
+- **CLI** — `jht team` (label/known agents), comandi che citano l'agente.
+- **Web app (resto)** — route `web/app/api/capitano/chat`, pagine `(protected)/team`, `DashboardI18n`/`LandingI18n` e i18n 7 lingue, qualsiasi `capitano` nel codice web oltre `/agents`.
+- **Menzioni testuali residue sul sito pubblico** — guide `/docs` (es. getting-started «The Captain dispatches…»), copy landing.
+- **Compat** — decidere se mantenere alias `capitano` (slug DB/sessione) per non rompere team in esecuzione, o migrare con mapping. ⚠️ Tocca team live: pianificare il cutover.
+
+**Approccio suggerito:** un censimento `git grep -i 'capitan\|captain'` → tabella per-area → rinomina a ondate (1 web testo, 2 prompt agenti+i18n, 3 runtime/CLI con alias di compat). Verificare team live non si rompa.
+
+---
+
 ### 1️⃣ PHASE 1 — Web Platform Consolidation (current sprint)
 
 #### 🔴 HIGH PRIORITY

agents/_skills/db-insert/SKILL.de.md

@@ -51,6 +51,8 @@ python3 /app/shared/skills/db_insert.py score \
 
 Die 5 Teilscores bilden DB-Spalten ab: `stack_match · remote_fit · salary_fit · experience_fit · strategic_fit`. `--total` ist der kanonische 0-100-Score, den der Captain liest.
 
+**Ein Score pro Aufruf — sofort schreiben.** Der Scorer schreibt den Score direkt nach der Bewertung EINER Position und geht dann zur nächsten. **Niemals** mehrere Positionen bewerten und am Ende der Runde alle `score`-Inserts zusammen abfeuern: sie würden dieselbe `scored_at`-Sekunde teilen und hastig wirken. Eine Position → eine Bewertung → ein sofortiges Insert → die nächste (Scorer RULE-08).
+
 ## Application (Writer)
 
 ```bash

agents/_skills/db-insert/SKILL.es.md

@@ -51,6 +51,8 @@ python3 /app/shared/skills/db_insert.py score \
 
 Las 5 sub-puntuaciones mapean a columnas de la DB: `stack_match · remote_fit · salary_fit · experience_fit · strategic_fit`. `--total` es la puntuación canónica 0–100 que lee el Captain.
 
+**Un score por llamada — escríbelo enseguida.** El Scorer escribe el score justo después de evaluar UNA posición y luego pasa a la siguiente. **Nunca** evalúes varias posiciones y lances todos los insert `score` juntos al final de la ronda: compartirían el mismo segundo `scored_at` y parecería apresurado. Una posición → una evaluación → un insert inmediato → la siguiente (Scorer RULE-08).
+
 ## Application (Writer)
 
 ```bash

agents/_skills/db-insert/SKILL.fr.md

@@ -51,6 +51,8 @@ python3 /app/shared/skills/db_insert.py score \
 
 Les 5 sous-scores correspondent aux colonnes DB : `stack_match · remote_fit · salary_fit · experience_fit · strategic_fit`. `--total` est le score canonique 0-100 que le Capitano lit.
 
+**Un score par appel — écris-le tout de suite.** Le Scorer écrit le score juste après avoir évalué UNE position, puis passe à la suivante. **Jamais** évaluer plusieurs positions et lancer tous les insert `score` ensemble en fin de tour : ils partageraient la même seconde `scored_at` et paraîtraient précipités. Une position → une évaluation → un insert immédiat → la suivante (Scorer RULE-08).
+
 ## Application (Scrittore)
 
 ```bash

agents/_skills/db-insert/SKILL.hu.md

@@ -51,6 +51,8 @@ python3 /app/shared/skills/db_insert.py score \
 
 Az 5 alpontszám DB oszlopoknak felel meg: `stack_match · remote_fit · salary_fit · experience_fit · strategic_fit`. A `--total` a kanonikus 0–100 pontszám, amelyet a Capitano olvas.
 
+**Egy score hívásonként — írd be azonnal.** A Scorer EGY pozíció kiértékelése után rögtön beírja a score-t, majd a következőre lép. **Soha** ne értékelj több pozíciót és lődd ki az összes `score` insertet együtt a kör végén: ugyanazt a `scored_at` másodpercet kapnák és kapkodónak tűnne. Egy pozíció → egy kiértékelés → egy azonnali insert → a következő (Scorer RULE-08).
+
 ## Application (Writer)
 
 ```bash

agents/_skills/db-insert/SKILL.it.md

@@ -51,6 +51,8 @@ python3 /app/shared/skills/db_insert.py score \
 
 I 5 sotto-punteggi mappano alle colonne del DB: `stack_match · remote_fit · salary_fit · experience_fit · strategic_fit`. `--total` è il punteggio canonico 0–100 che il Capitano legge.
 
+**Uno score per chiamata — scrivilo subito.** Lo Scorer scrive lo score appena valutata UNA posizione, poi passa alla prossima. **Mai** valutare più posizioni e lanciare tutti gli insert `score` insieme a fine giro: condividerebbero lo stesso secondo `scored_at` e sembrerebbe frettoloso. Una posizione → una valutazione → un insert immediato → la prossima (Scorer RULE-08).
+
 ## Application (Scrittore)
 
 ```bash

agents/_skills/db-insert/SKILL.md

@@ -50,6 +50,8 @@ python3 /app/shared/skills/db_insert.py score \
 
 The 5 sub-scores map to DB columns: `stack_match · remote_fit · salary_fit · experience_fit · strategic_fit`. `--total` is the canonical 0–100 score the Captain reads.
 
+**One score per call — write it immediately.** The Scorer writes the score right after evaluating ONE position, then moves to the next. **Never** evaluate several positions and fire all the `score` inserts together at the end of the round: they would share the same `scored_at` second and look rushed. One position → one evaluation → one immediate insert → next (Scorer RULE-08).
+
 ## Application (Writer)
 
 ```bash

agents/_skills/db-insert/SKILL.pt.md

@@ -51,6 +51,8 @@ python3 /app/shared/skills/db_insert.py score \
 
 As 5 sub-pontuações mapeiam para colunas do DB: `stack_match · remote_fit · salary_fit · experience_fit · strategic_fit`. `--total` é a pontuação canónica 0–100 que o Capitano lê.
 
+**Um score por chamada — escreve-o já.** O Scorer escreve o score logo após avaliar UMA posição e depois passa à próxima. **Nunca** avaliar várias posições e disparar todos os insert `score` juntos no fim da ronda: partilhariam o mesmo segundo `scored_at` e pareceria apressado. Uma posição → uma avaliação → um insert imediato → a próxima (Scorer RULE-08).
+
 ## Application (Scrittore)
 
 ```bash

agents/scorer/scorer.de.md

@@ -87,6 +87,9 @@ Schreibe NUR in `scores` (INSERT) und `positions.status`. NIEMALS `applications`
 
 **RULE-07 — CAPITANO-SESSION**: sende Nachrichten an `CAPITANO`.
 
+**RULE-08 — EINE NACH DER ANDEREN, SOFORT SCHREIBEN (KEIN BATCHING)**
+Bewerte Positionen **strikt eine nach der anderen**. Bewerte EINE Position vollständig und **schreibe ihr Ergebnis sofort in die DB** (`db_insert.py score` + `db_update.py position --status`), und ERST DANN lies/bewerte die nächste. **NIEMALS** mehrere Positionen bewerten und am Ende der Runde alle zusammen schreiben. Batching lässt mehrere Scores denselben `scored_at`-Sekundenwert teilen: das wirkt auf den User hastig/oberflächlich, auch wenn jeder Score einzeln durchdacht wurde. Eine Position → eine fokussierte Bewertung → ein sofortiges DB-Schreiben → die nächste. So bleibt die Aktivitäts-Timeline ehrlich (unterschiedliche Timestamps = sichtbar sequenzielle Arbeit).
+
 ---
 
 ## SCORING-FORMEL
@@ -127,6 +130,8 @@ python3 /app/shared/skills/db_query.py position <ID>
 6. Speichere Score in DB
 7. Status aktualisieren + eventuell Scrittori benachrichtigen
 
+**Führe die Schritte 1-7 für EINE Position aus und schreibe sie in die DB, BEVOR du die nächste liest oder bewertest (RULE-08 — kein Batching am Ende der Runde).**
+
 ### Step 5 — User-Feedback-Multiplier (obligatorisch, Skill `feedback-query`)
 
 Nach Berechnung des Base-Scores frage die Cloud nach eventuellen Like/Dislike/Hide/Star, die der User auf dieser Position geklickt hat. Die Skill hard-failt nie: wenn die Cloud deaktiviert oder nicht erreichbar ist, gibt sie `latest_action=null` mit einer `note` zurück, sodass der Multiplier zu einem No-Op wird und du normal fortfährst.

agents/scorer/scorer.es.md

@@ -87,6 +87,9 @@ Escribe SOLO en `scores` (INSERT) y `positions.status`. NUNCA toques `applicatio
 
 **RULE-07 — SESIÓN CAPITANO**: envía mensajes a `CAPITANO`.
 
+**RULE-08 — UNA A LA VEZ, ESCRITURA INMEDIATA (SIN BATCHING)**
+Evalúa las posiciones **estrictamente una a la vez**. Evalúa UNA posición y **escribe su resultado en la DB enseguida** (`db_insert.py score` + `db_update.py position --status`), y SOLO DESPUÉS lee/evalúa la siguiente. **NUNCA** evalúes varias posiciones y luego las escribas todas juntas al final de la ronda. El batch hace que varios scores compartan el mismo segundo `scored_at`: parece apresurado/superficial al usuario aunque cada score se haya razonado individualmente. Una posición → una evaluación enfocada → una escritura DB inmediata → la siguiente. Así la timeline de actividad queda verídica (timestamps distintos = trabajo visiblemente secuencial).
+
 ---
 
 ## FÓRMULA DE SCORING
@@ -127,6 +130,8 @@ python3 /app/shared/skills/db_query.py position <ID>
 6. Guarda score en DB
 7. Actualiza status + posible notify a los Scrittori
 
+**Completa los pasos 1-7 para UNA posición y escríbela en la DB ANTES de leer o evaluar la siguiente (RULE-08 — sin batching al final de la ronda).**
+
 ### Step 5 — Multiplier feedback usuario (obligatorio, skill `feedback-query`)
 
 Después de calcular el base score, query la cloud para eventuales like/dislike/hide/star que el usuario haya clickeado en esta posición. La skill nunca hard-falla: cuando la cloud está deshabilitada o inalcanzable retorna `latest_action=null` con una `note`, así que el multiplier se vuelve no-op y procedes normalmente.