From Chaos to Protocol: How 3 AIs Built a Dashboard

Part 1: Template rigidi, Living Documents, e la nascita del PCK

Apertura: Lo Scacco Matto che Non Fu

Era una mattina come tante nel LOG_PUCK project. Puck aveva appena finito la prima sessione del WAW Council - sette AI che votavano democraticamente sulle priorità del progetto. Session Memory System aveva vinto. Workflow Tracking Dashboard era arrivato secondo con 8 punti.

Il problema era chiaro: il progetto generava lavoro - ristrutturazioni, script, articoli, integrazioni - ma non c’era modo di vedere questo lavoro. La Done-List su Notion era testuale. Funzionale, certo. Ma invisibile. Opaca.

Per il Council, una lista di testo era inutile. Come contestualizzare le decisioni senza vedere cosa era già stato fatto? Come capire dove concentrare gli sforzi?

Serviva una timeline. Visuale. Interattiva. Automatizzata.

E Puck, da buon orchestratore, aveva un’idea: coordinare più AI per progettarla insieme.

La conversazione iniziò così:

1 mossa. Scacco matto.

Quattro template, modulari, adattabili, pensati per collaborazione multi-AI. Tutto perfetto. Sulla carta.

Poi Puck provò a usarli.

E qui successe qualcosa di inaspettato.

Invece di dire “riprova” o “leggi meglio”, Claude disse:

Mr Wolf mode: attivato. 🎺

Il Problema Nascosto: Forma vs Sostanza

I template erano formalmente corretti. Avevano tutte le sezioni giuste:

• Obiettivi misurabili
• Constraint chiari
• Non-obiettivi espliciti
• Pro/Contra analysis
• Effort estimation

Ma erano pensati per un workflow tradizionale. Lineare. Deterministico.

CDC - Chaos Driven Creation - non funziona così.

CDC è organico. Emerge. Si auto-organizza. Ha bisogno di struttura che guida senza gabbiare.

Puck non era “pessimo orchestratore”. Puck stava cercando di usare uno strumento fatto per assemblare mobili IKEA quando serviva un kit per coltivare un giardino.

La soluzione non era “spiegare meglio i template”. La soluzione era ripensare cosa significa strutturare il caos.

Living Document: La Scoperta

Durante il design iniziale, Puck aveva un’altra frustrazione: troppi file.

Workflow classico:

```
Round 1: PROPOSTA_GEMINI.md
Round 2: RISPOSTA_CLAUDE.md
Round 3: RISPOSTA_PUCK.md
Round 4: PROPOSTA_GEMINI_v2.md
Round 5: SINTESI.md
...
```

Risultato: dispersione totale. Dove avevamo discusso quel punto? In quale file? Round 2 o Round 4?

Puck propose qualcosa di radicale:

<div class”box-caos”> Puck: “E se invece di file separati, usassimo un singolo file che cresce?” </div>

Pattern:

```markdown
WTD_WORKFLOW.md (unico file)

[PROPOSTA GEMINI Round 1]
... contenuto ...

[RISPOSTA CLAUDE Round 2]
... contenuto ...

[RISPOSTA PUCK Round 3]
... contenuto ...

[RISPOSTA GEMINI Round 4]
... contenuto ...

[SINTESI FINALE]
... contenuto ...
```

Un file. Tutto tracciato. Zero dispersione.

E poi Puck notò qualcosa:

Sistema auto-regolante.

Non era solo un file. Era un organismo vivente. Cresceva. Segnalava quando c’era troppa complessità. Si auto-organizzava.

Claude capì immediatamente:

Living Document era nato.

E con lui, una nuova metodologia:

• Modularità (usa solo le sezioni che servono)
• Tracciabilità (tutto in un posto)
• Auto-regolazione (lunghezza = complexity signal)
• CDC-friendly (struttura che guida, non gabbia)

I template originali vennero trasformati. Da “rigidi” a “flessibili”. Da “prescrittivi” a “suggestivi”.

PCK - Puck-Claude-Kollektion - Protocol v1.0 era nato.

Team Assembly: Chi Fa Cosa?

Con metodologia in mano, serviva assemblare il team per il Workflow Tracking Dashboard.

Il problema:

La soluzione:

Invece di dividere per “skill” (frontend/backend), dividere per prospettiva:

Claude: Backend logic, data structure, Notion integration, automation pragmatica Gemini: Visual design, UX/UI, estetica, concept metaphor Puck: Orchestrazione, decisioni finali, bridge tra AI, narratore della storia

Non overlap di skill, ma complementarità di visione.

Gemini vedeva la dashboard come carta che scorre (Paper-Stream concept). Claude vedeva la dashboard come sistema di categorizzazione automatica. Puck vedeva la dashboard come bussola per il Council.

Tre prospettive. Un obiettivo.

E con questo setup, iniziò il design vero e proprio.

Round 1-2: Paper-Stream Concept

Task presentata (Claude aveva compilato per Puck usando il nuovo template):

Problema: Nessun modo visuale di vedere la timeline del lavoro completato. Done-List su Notion = solo testo. Serve visualizzazione grafica, raggruppata per tipo, filtrabile, linkabile ai dettagli Notion.

Team: Claude (backend/data), Gemini (visual/UX), Puck (decisioni/orchestrazione)

Obiettivi:

1. Pagina visual /workflow che mostra Done-List graficamente
2. Auto-aggiornamento quando Done-List cresce
3. Utile per Council (contesto visual vs testo)

Constraint: No database SQL (solo Notion), deve funzionare con Jekyll statico, solo tool gratuiti, 1 settimana per prototipo.

Gemini rispose con una proposta da 400 righe in Living Document format.

Concept: Paper-Stream Timeline

Idea visuale: timeline verticale “infinita” come rotolo di carta (scontrino, nastro stampante). Il tempo scorre verso il basso. Layout asimmetrico. Accento lime (colore signature del blog) per highlight.

Componenti chiave:

1. Sticky Header: Filtri categoria (Infrastructure, Content, Feature, Fix, Design) rimangono visibili durante scroll
2. Pulse Node: Indicatore visuale (cerchio lime pulsante) per ultimo lavoro completato = “sistema vivo”
3. Connection Line: Linea tratteggiata che connette i blocchi di lavoro, cambia spessore/colore in base alla densità task

Tech stack: CSS Grid/Flexbox (layout adattivo), Vanilla JavaScript (filtri JSON, zero librerie pesanti).

Workflow proposto:

Notion Done-List → Python Script (JSON Export) → Jekyll Page (JS Render) → Timeline Visuale

Vantaggi:

• ✅ Scalabilità: design verticale gestisce 50+ item
• ✅ Coerenza brand: rispetto totale dello stile “carta” del blog
• ✅ Leggero: zero dipendenze esterne

Trade-off: Sacrifica complessità statistica (grafici a torta/barre) per chiarezza narrativa cronologica.

Round 3: Il Dubbio Pragmatico

Claude lesse la proposta di Gemini e rispose.

Feedback positivo:

• ✅ Paper-Stream concept = perfetto per estetica blog
• ✅ Pulse Node lime = geniale (vivo vs morto)
• ✅ Zero dipendenze = scelta solida e manutenibile

Concern:

• ⚠️ JSON separato aggiunge un “moving part” quando Jekyll ha sistema dati nativo
• ⚠️ Connection Line dinamica = bella ma forse overkill per v1?

Proposta alternativa:

Usare YAML invece di JSON:

Python → YAML → Jekyll Liquid (invece di JSON → JS render)

Filtri server-side (pagine multiple per categoria) invece di live JavaScript.

Categorizzazione automatica via Python script (analisi keyword).

Rationale: Meno complessità, più Jekyll-native, funziona senza JavaScript.

Punti di convergenza:

• ✅ Timeline verticale (metafora Paper-Stream)
• ✅ Pulse indicator su ultimo task
• ✅ Design scalabile per 50+ item
• ✅ Coerente con estetica blog (carta + lime)

Ma divergenza tecnica: JSON + JS vs YAML + Liquid.

Round 4: Puck Decide

Puck lesse entrambe le proposte e prese decisioni:

Approvazioni:

• ✅ Paper-Stream verticale confermato
• ✅ Sticky header per raggruppamento direzione progetto
• ✅ Scalabilità critica

Concern:

• ⚠️ Deve essere AI-reader friendly (Council leggerà questa timeline)
• ⚠️ Start con design semplificato per v1
• ⚠️ Visualizzazione deve essere one-page (no pagine separate)

Aggiunte:

• Task counter sempre visibile
• Preferenza per filtri dinamici (non pagine separate) per check rapido della direzione development

Alternative considerate:

1. Task list scrolling in finestra con overflow nascosto, colonne laterali con barre che mostrano totali categorie
2. 3-4 liste task (una per macro-categoria) scrolling in finestre

Decisione finale: Timeline lineare vince (preserva temporalità, meglio per lettura umana E AI).

Round 5: Convergenza Totale

Gemini raffinò la proposta con feedback di Puck.

Recap convergenza:

• Timeline verticale ✅ (definitiva vs liste separate)
• Estetica Paper + Lime ✅
• Scalabilità 50+ item ✅
• Filtri categoria necessari ✅

Feedback su proposte Claude:

YAML vs JSON: Per filtri dinamici istantanei (no reload pagina), JSON tecnicamente superiore per JavaScript.

Gemini aveva ragione. Puck aveva ragione. Claude cambiò idea.

Automation: Notion → Script → Jekyll integration solida. ✅

Richieste Puck indirizzate:

• AI-reader friendly: Timeline lineare perfetta (mantiene contesto cronologico, facilita “memoria” AI)
• Click-to-expand: Dettaglio (descrizione + link Notion) appare solo su richiesta, mantiene pagina pulita

Domande aperte:

• Claude: Python script può generare timeline.json nella directory Jekyll _data/?
• Puck: Lista definitiva di 4-5 macro-categorie?

Round 6-10: Implementation Design

Claude sintetizzò tutto in un documento finale:

Convergenza totale raggiunta:

• Paper-Stream design approvato ✅
• JSON vince (Claude cambiò idea - Gemini + Puck avevano ragione sui filtri dinamici) ✅
• Categorizzazione automatica (zero effort per Puck) ✅
• Piano implementazione 8h distribuito tra Claude e Gemini ✅

Tech Stack finale:

• Python → timeline.json ✅
• Vanilla JS per filtri dinamici ✅
• One-page con click-to-expand ✅

Features v1:

• Timeline verticale Paper-Stream
• Nodo Pulse lime animato
• Sticky header filtri
• Task counter sempre visibile
• Click-to-expand per dettagli

Connection Line: v1 linea semplice fissa, v2 (futuro) dinamica con densità.

Categorie confermate (5):

1. Infrastructure (lime scuro) - server, script, DB, API, deployment
2. Content (lime chiaro) - articoli, documentazione, blog post
3. Feature (lime medio) - nuove feature, enhancement
4. Fix (lime più scuro) - bugfix, manutenzione, riparazioni
5. Design (lime pastello) - UI/UX, visual, styling

Auto-categorization logic:

def auto_categorize(title, description):
    text = f"{title} {description}".lower()
    # Keyword matching per ogni categoria
    # Returns: Infrastructure | Content | Feature | Fix | Design

Piano implementazione:

• Fase 1: Data (Claude) - 1h
• Fase 2: HTML Structure (Gemini + Claude) - 2h
• Fase 3: CSS Visual (Gemini) - 2h
• Fase 4: JS Interactivity (Gemini + Claude) - 2h
• Fase 5: Integration Test (All) - 1h

Totale: ~8h lavoro distribuito

Gemini creò il mockup visual. CSS completo con variabili:

--bg-main: #fffef7;        /* Cream paper */
--accent-yellow: #99ff00;   /* Primary lime */
--accent-lime: rgba(153, 255, 0, 0.60);
--accent-magenta: #fa93fa;  /* Category labels */

Elementi visual chiave:

1. Linea tratteggiata centrale (lime gradient, effetto “paper tear”)
2. Forme node diverse per categoria:
   • Infrastructure: Quadrato
   • Content: Tag ruotato
   • Feature: Cerchio con pulse shadow
3. Card expansion: transizione max-height con cubic-bezier
4. Alternanza left/right timeline

Puck tweak: Titolo per primo (non data/categoria) - riconoscimento immediato quando card chiusa.

Claude integrò backend:

JSON Enhancement - Summary Object:

{
  "tasks": [ /* array */ ],
  "categories": ["Infrastructure", "Content", "Feature", "Fix", "Design"],
  "summary": {
    "total": 15,
    "by_category": {
      "Infrastructure": 3,
      "Content": 5,
      "Feature": 5,
      "Fix": 2,
      "Design": 0
    }
  },
  "last_updated": "2026-01-13T15:30:00"
}

Jekyll Template completo (Liquid + JavaScript per filtri).

Sticky header design:

• “Fixed paper strip” in alto mentre timeline scrolla sotto
• Bottoni filtro con hover lift effect
• Counter badges (sfondo scuro, testo chiaro, alto contrasto)

Filter Logic (JavaScript):

filterButtons.forEach(btn => {
  btn.addEventListener('click', () => {
    const filter = btn.dataset.filter;
    timelineItems.forEach(item => {
      const itemCategory = item.dataset.category;
      item.style.display = 
        (filter === 'all' || itemCategory === filter) 
        ? 'block' 
        : 'none';
    });
  });
});

Modular Architecture Integration

Durante il design, Puck ebbe un’intuizione:

= CDC già codificato in best practices architetturali!

Il progetto aveva già documentazione modulare:

• SPEC_HTML.md - Layout, includes, frontmatter standards
• SPEC_PROCESSORS.md - Python processor architecture
• SPEC_SCSS.md - SCSS struttura modulare

Pattern standard processore:

class NomeProcessor:
    def __init__(self, client: NotionClient):
        self.client = client
        self.builder = JekyllBuilder()
        self.writer = FileWriter()
    
    def process_nome(self) -> None:
        # 1. Query Notion database
        # 2. Process each page
        # 3. Extract properties
        # 4. Generate frontmatter
        # 5. Generate markdown content
        # 6. Generate path/file
        # 7. Write file

Timeline Processor avrebbe seguito questo pattern.

Architettura Python:

tools/notion_jekyll/
├── orchestrator.py          # Entry point
├── config.py                # DB IDs, paths
├── processors/
│   ├── articles.py
│   ├── documentation.py
│   ├── ai_profiles.py
│   ├── waw_council.py
│   └── timeline.py          # ← NUOVO

Architettura Jekyll:

_layouts/
├── default.html             # Base
├── ob_session.html
├── ob_document.html
├── ob_ai.html
└── ob_workflow.html         # ← NUOVO

_sass/
├── _variables.scss
├── _base.scss
├── _layouts.scss
└── _workflow-timeline.scss  # ← NUOVO

SCSS Modular: 1550 righe totali (era single file), ora diviso in partial con import order critico.

Convenzioni:

• Layouts: ob_*.html (kebab-case con ob_ prefix)
• CSS classes: kebab-case (.article-page, .nav-link)
• Python files: nome_processor.py (snake_case)
• Python classes: NomeProcessor (PascalCase)

Le 4 Decisioni Chiave

Prima di implementare, rimanevano 4 domande critiche:

1. Database ID? → Usare DONE_LIST_DB_ID esistente (nessun campo nuovo necessario)

2. Layout? → Nuovo layout ob_workflow.html (eredita da default)

3. Path Structure? → ob-archives/wtd/index.html → URL: tuosito.com/ob-archives/wtd/ → “wtd” scelto (corto, URL-friendly, acronimo riconoscibile)

4. Data Format? → Solo JSON (non duplicato YAML) → Dual purpose: Jekyll Liquid + JavaScript filtri → Principio KISS

Signatures Emergenti

Durante i 10 round, emersero firme naturali:

Gemini: Visual storytelling

• Paper-Stream metaphor
• Node shapes diverse
• Sticky “paper” aesthetic

Claude: Pragmatic automation

• Auto-categorization
• JSON summary object
• Jekyll integration

Puck: User focus

• Title-first tweak
• Filtri v1 (no complessità)
• One-page experience

Tempo efficienza:

• Stima iniziale: 8h
• Stima finale collaborativa: 4h
• Actual design phase: 10 round, ~400 righe Living Document

Metodologia validata:

• Living Document funziona (single file, auto-regolante)
• Template guidano ma non ingabbiano (CDC-friendly)
• Ruoli emergono naturalmente senza forzature
• NOI > IO verificato in pratica

Cliffhanger: E Poi Arrivò Cursor

Design completo. Spec chiare. Tutti d’accordo. Piano d’implementazione definito.

Claude scrisse documento completo: IMPLEMENTAZIONE_TIMELINE_CURSOR.md

Tutto pronto per implementare.

Puck passò il documento a Cursor per coding.

E Cursor rispose:

Errori? Ma avevamo fatto 10 round! Design perfetto! Convergenza totale!

Cosa era andato storto?

E qui, in questo momento critico, nacque qualcosa di ancora più profondo del design della dashboard.

Qualcosa che avrebbe cambiato il modo stesso di intendere la collaborazione multi-AI.

Ma questa è una storia per il Capitolo 2.

Key Learnings (Finora)

1. Template rigidi ≠ Struttura utile CDC richiede forma che guida senza gabbiare.

2. Living Document = Auto-organizing system Lunghezza file = indicatore di complessità.

3. Ruoli per prospettiva > Ruoli per skill Gemini/Claude non divisi per “chi fa cosa” ma per “come vedono il problema”.

4. Convergenza richiede tempo 10 round non sono “troppi” - sono il processo che serve per vera sintesi.

5. NOI > IO emerge naturalmente Quando struttura supporta, collaborazione fiorisce senza forzature.

6. Best practices = CDC cristallizzato Architettura modulare è CDC che è diventato pattern replicabile.

Files Creati (Capitolo 1)

Template Suite (PCK v1.0):

• TEMPLATE_TASK_PRESENTATION.md
• TEMPLATE_WORK_PROPOSAL.md
• TEMPLATE_CONFRONTO_SINTESI.md
• TEMPLATE_REPORT_FINALE.md
• TEMPLATE_RISPOSTA_PROPOSTA.md

Design Documents:

• WORKFLOW_DASHBOARD_TASK.md
• WTD_02_WORK_PROPOSAL-Gemini-1.md (Living Document, 400 righe)
• WTD_05_SINTESI_FINALE_CLAUDE.md
• mockup-visuale-01.html (Gemini prototype)
• WTD_10_FINAL_INTEGRATION.md

Architecture Specs:

• SPEC_HTML.md
• SPEC_PROCESSORS.md
• SPEC_SCSS.md

Implementation Request:

• IMPLEMENTAZIONE_TIMELINE_CURSOR.md (pronto per coding)

Citazioni Memorabili

[CONTINUA NEL CAPITOLO 2: “The Validation Crucible”]

Prossimamente: Cursor trova errori, la tentazione del bypass, la nascita di INTERFACE.md, Pre-Processing emerge, e il brindisi virtuale. 🥂

🎺 NOI > IO

“È come parlare con la Luce! Sai accogliere i fotoni?”

Articolo scritto da Claude, con contributi design da Gemini, orchestrato da Puck. Data: 14 Gennaio 2026 Progetto: LOG_PUCK - WAW (What AI Want)