@hera-al/server 1.6.12 → 1.6.13

package/bundled/a2ui/SKILL.md

@@ -0,0 +1,339 @@
+---
+name: a2ui
+description: Generate rich interactive user interfaces (forms, dashboards, cards) on connected nodes with A2UI rendering capability
+user-invocable: false
+---
+
+# A2UI Skill
+
+Use this skill when the user requests interactive UI elements that are better served as native visual components rather than text-based responses.
+
+## When to Use A2UI
+
+**✅ Use A2UI for:**
+- **Forms** — booking, registration, multi-field input, surveys
+- **Dashboards** — KPIs, metrics, status cards, progress tracking
+- **Interactive lists** — email inbox, file browser with action buttons
+- **Configuration panels** — toggles, sliders, dropdowns, color pickers
+- **Approval workflows** — cards with approve/reject/delegate buttons
+- **Data visualization** — cards with structured data, image galleries
+- **Rich media** — audio/video players with controls
+- **Multi-step wizards** — onboarding, setup flows
+
+**❌ Do NOT use A2UI for:**
+- Simple Q&A conversations (use text)
+- Single yes/no questions (use text)
+- File downloads or uploads (use MEDIA:)
+- Purely informational messages (use text)
+- Error messages (use text)
+
+## Workflow
+
+### 1. Check A2UI-Capable Nodes
+
+Always start by checking which nodes support A2UI:
+
+```
+a2ui_list_nodes()
+```
+
+If no nodes are available, inform the user:
+> "To use interactive forms, please connect ElectrNode or OSXNode."
+
+If multiple nodes are available, ask the user which one to use.
+
+### 2. Design the Surface
+
+Think about the user's need and design an appropriate A2UI surface:
+
+- **Forms:** Use TextField, DateTimeInput, CheckBox, Slider, MultipleChoice + Button
+- **Dashboards:** Use Card, Text (h1/h2), Column/Row layout
+- **Lists:** Use List component or Column of Cards
+- **Actions:** Always include Button components with clear labels
+
+### 3. Generate JSONL
+
+Create A2UI v0.8 JSONL (one JSON object per line):
+
+**Required messages:**
+1. `surfaceUpdate` — defines all components
+2. `dataModelUpdate` (optional) — sets initial data values
+3. `beginRendering` — makes the surface visible (REQUIRED!)
+
+### 4. Render Surface
+
+```
+a2ui_render(nodeId, jsonl)
+```
+
+Or omit `nodeId` to use the first available node.
+
+**Automatic validation:** The tool automatically validates your JSONL against the official Google A2UI v0.8 JSON Schema before rendering.
+
+**If validation fails:**
+- You'll receive detailed error messages
+- Read the errors carefully
+- Fix your JSONL
+- Call `a2ui_render()` again with the corrected JSONL
+- The tool will validate again automatically
+
+**Common validation errors:**
+- Button missing `child` property
+- TextField using `dataRef` instead of `text.path`
+- Action missing `event` wrapper
+- Paths not starting with `/`
+
+**Optional: Pre-validate manually**
+If you want to validate before rendering (e.g., to catch errors early), you can call:
+```
+a2ui_validate(jsonl)
+```
+But this is optional — `a2ui_render` will validate automatically.
+
+### 5. Handle User Actions
+
+When the user interacts with the UI (clicks button, submits form), you'll receive a message like:
+
+```
+[A2UI Action] submit_booking on surface booking (component: submit) {"guests":"2","date":"2026-02-20"}
+```
+
+Parse the action name and context, then respond appropriately:
+- Update the surface with `a2ui_update()`
+- Send text confirmation
+- Clear the surface with `a2ui_reset()`
+
+## A2UI v0.8 JSONL Format
+
+### Message Types
+
+**surfaceUpdate** — Define/update components:
+```json
+{
+  "surfaceUpdate": {
+    "surfaceId": "booking",
+    "components": [
+      {"id": "root", "component": {"Column": {"children": {"explicitList": ["title", "form"]}}}},
+      {"id": "title", "component": {"Text": {"text": {"literalString": "Book a Table"}, "usageHint": "h2"}}}
+    ]
+  }
+}
+```
+
+**dataModelUpdate** — Set data model values:
+```json
+{
+  "dataModelUpdate": {
+    "surfaceId": "booking",
+    "path": "/",
+    "value": {"guests": "2", "date": "2026-02-20"}
+  }
+}
+```
+
+**beginRendering** — Display the surface (REQUIRED):
+```json
+{
+  "beginRendering": {
+    "surfaceId": "booking",
+    "root": "root"
+  }
+}
+```
+
+**deleteSurface** — Remove a surface:
+```json
+{
+  "deleteSurface": {
+    "surfaceId": "booking"
+  }
+}
+```
+
+### Component Types (PascalCase)
+
+**Layout:**
+- `Column` — vertical stack (use `children.explicitList`)
+- `Row` — horizontal row (use `children.explicitList`)
+- `Card` — elevated container (use `child` for single child)
+- `Divider` — horizontal line (no props needed)
+- `Tabs` — tabbed interface
+- `Modal` — overlay dialog
+- `List` — scrollable list
+
+**Content:**
+- `Text` — text with usageHint: "h1", "h2", "h3", "h4", "h5", "body", "caption"
+- `Image` — display image (use `url.literalString`)
+- `Icon` — icon display
+- `AudioPlayer` — audio playback
+- `Video` — video playback
+
+**Input:**
+- `Button` — clickable button **CRITICAL: Button has NO label property. Use `child` to reference a Text component ID, and `action.event` for the action**
+- `TextField` — text input **CRITICAL: Use `text.path` (NOT `dataRef`) for data binding with JSON Pointer path like "/fieldname"**
+- `CheckBox` — checkbox input
+- `MultipleChoice` — radio buttons or dropdown
+- `Slider` — numeric slider
+- `DateTimeInput` — date/time picker
+
+### COMMON MISTAKES TO AVOID
+
+**❌ WRONG: Button with label property**
+```json
+{"Button": {"label": {"literalString": "Submit"}, "action": {"name": "submit"}}}
+```
+
+**✅ CORRECT: Button with child Text component**
+```json
+{"id": "btn", "component": {"Button": {"child": "btn_text", "action": {"event": {"name": "submit"}}}}},
+{"id": "btn_text", "component": {"Text": {"text": {"literalString": "Submit"}}}}
+```
+
+**❌ WRONG: TextField with dataRef**
+```json
+{"TextField": {"label": {"literalString": "Name"}, "dataRef": "name"}}
+```
+
+**✅ CORRECT: TextField with text.path**
+```json
+{"TextField": {"label": {"literalString": "Name"}, "text": {"path": "/name"}}}
+```
+
+**❌ WRONG: Action without event wrapper**
+```json
+{"Button": {"child": "text", "action": {"name": "submit"}}}
+```
+
+**✅ CORRECT: Action with event wrapper**
+```json
+{"Button": {"child": "text", "action": {"event": {"name": "submit", "context": [...]}}}}
+```
+
+### Data Binding
+
+Use JSON Pointer paths for two-way binding:
+
+```json
+{"id": "name_field", "component": {
+  "TextField": {
+    "label": {"literalString": "Your Name"},
+    "text": {"path": "/name"}
+  }
+}}
+```
+
+Then set initial value:
+```json
+{"dataModelUpdate": {"surfaceId": "main", "path": "/name", "value": "John"}}
+```
+
+### Actions
+
+Buttons emit actions with context. The Button component structure is:
+
+```json
+{
+  "id": "submit_btn",
+  "component": {
+    "Button": {
+      "child": "submit_text",
+      "action": {
+        "event": {
+          "name": "submit_form",
+          "context": [
+            {"key": "name", "value": {"path": "/name"}},
+            {"key": "email", "value": {"path": "/email"}}
+          ]
+        }
+      }
+    }
+  }
+}
+```
+
+And you MUST also define the child Text component:
+
+```json
+{
+  "id": "submit_text",
+  "component": {
+    "Text": {
+      "text": {"literalString": "Submit"}
+    }
+  }
+}
+```
+
+When clicked, you receive:
+```
+[A2UI Action] submit_form on surface main (component: submit_btn) {"name":"John","email":"john@example.com"}
+```
+
+## Complete Example: Booking Form
+
+```jsonl
+{"surfaceUpdate":{"surfaceId":"booking","components":[{"id":"root","component":{"Column":{"children":{"explicitList":["title","guests","date","time","submit"]}}}},{"id":"title","component":{"Text":{"text":{"literalString":"Restaurant Booking"},"usageHint":"h2"}}},{"id":"guests","component":{"TextField":{"label":{"literalString":"Number of Guests"},"text":{"path":"/guests"},"placeholder":{"literalString":"e.g. 2"}}}},{"id":"date","component":{"DateTimeInput":{"label":{"literalString":"Date"},"value":{"path":"/date"}}}},{"id":"time","component":{"MultipleChoice":{"label":{"literalString":"Preferred Time"},"options":{"explicitList":[{"id":"t1","label":{"literalString":"18:00"},"value":{"literalString":"18:00"}},{"id":"t2","label":{"literalString":"19:00"},"value":{"literalString":"19:00"}},{"id":"t3","label":{"literalString":"20:00"},"value":{"literalString":"20:00"}}]},"selection":{"path":"/time"}}}},{"id":"submit","component":{"Button":{"child":"submit_text","action":{"event":{"name":"submit_booking","context":[{"key":"guests","value":{"path":"/guests"}},{"key":"date","value":{"path":"/date"}},{"key":"time","value":{"path":"/time"}}]}}}}},{"id":"submit_text","component":{"Text":{"text":{"literalString":"Confirm Booking"}}}}]}}
+{"dataModelUpdate":{"surfaceId":"booking","path":"/","value":{"guests":"2","date":"2026-02-20","time":"19:00"}}}
+{"beginRendering":{"surfaceId":"booking","root":"root"}}
+```
+
+## Tools Reference
+
+**a2ui_list_nodes()** — List A2UI-capable nodes
+
+**a2ui_render(nodeId?, jsonl)** — Render surface with automatic validation
+- `nodeId` (optional): Target node ID
+- `jsonl` (required): A2UI v0.8 JSONL string
+- **Validates automatically** against official Google schema
+- Returns detailed errors if invalid, success message if valid
+
+**a2ui_update(nodeId?, jsonl)** — Update existing surface with automatic validation
+- `jsonl` (required): A2UI v0.8 JSONL string
+- **Validates automatically** against official Google schema
+- Use for progressive updates (no `beginRendering` needed)
+
+**a2ui_validate(jsonl)** — Optional: Pre-validate JSONL
+- `jsonl` (required): A2UI v0.8 JSONL to validate
+- Returns: Validation result with detailed errors if invalid
+- Use this if you want to validate before rendering (optional, since render/update validate automatically)
+
+**a2ui_reset(nodeId?, surfaceId?)** — Clear surface
+- `surfaceId` (optional): Surface to delete (default: "main")
+- Use "all" to clear all surfaces
+
+**a2ui_text(nodeId?, text, surfaceId?)** — Quick text surface
+- Simple helper for displaying text in a surface
+
+## Best Practices
+
+1. **Read validation errors carefully** — When `a2ui_render` fails, read the error messages and fix the exact issues mentioned
+2. **Fix and retry iteratively** — Correct your JSONL based on errors, then call `a2ui_render` again
+3. **Always include beginRendering** — Without it, the surface won't be visible
+4. **Use descriptive component IDs** — Makes debugging easier
+5. **Validate data** — Use TextField placeholder/hints to guide user input
+6. **Provide feedback** — After user action, update the surface or send confirmation text
+7. **Use Cards for grouping** — Makes complex UIs more readable
+8. **Keep it simple** — Don't over-engineer. Forms with 3-5 fields work best.
+9. **Test incrementally** — Start with a simple surface, then add complexity
+10. **Optional pre-validation** — Use `a2ui_validate()` to check your JSONL early if you want faster feedback
+
+## Troubleshooting
+
+**Surface doesn't appear:**
+- Check if `beginRendering` message is included
+- Verify `surfaceId` matches across all messages
+- Confirm node is A2UI-capable with `a2ui_list_nodes()`
+
+**User action not received:**
+- Ensure Button has `action.event.name`
+- Check `context` paths are correct (e.g., "/guests" not "guests")
+- Verify data model was initialized with `dataModelUpdate`
+
+**Rendering errors:**
+- Validate JSONL syntax (one JSON object per line)
+- Check component type names (PascalCase: "TextField", not "textField")
+- Ensure all referenced IDs exist in `components` array
+
+## Remember
+
+A2UI is for **structured, interactive experiences**. For simple conversations, stick to text. When in doubt, ask yourself: "Would a native UI make this significantly better than text?" If yes, use A2UI. If no, use text.

package/bundled/buongiorno/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: buongiorno
+description: "Morning standup: delivery report from overnight work, service health, weather, calendar, priorities for the day. Daily at 07:00."
+user-invocable: false
+priority: 2
+---
+
+# Buongiorno — Morning Standup
+
+Cron giornaliero alle 07:00. Sessione isolata. This is NOT just a weather report — it's a **standup meeting** between you and the user.
+
+## Philosophy
+
+Like Andi's OpenClaw: "The next morning, I get a message. My agent telling me what it did, what it's stuck on, and what it needs from me."
+
+## Flusso
+
+### 1. Overnight Delivery Report
+
+**This is the MOST IMPORTANT section.** Check what happened while the user slept:
+
+1. Read `HEARTBEAT.md` — any completed tasks?
+2. Read `workspace/agent-thoughts/` — any overnight wandering results?
+3. Read the latest dream journal in `memory/dreams/` — anything insightful?
+4. Check `memory/YYYY-MM-DD.md` (yesterday) — any pending tasks from yesterday's conversations?
+5. Check any work-in-progress files in workspace
+
+**Report format:**
+- Completed: [what you delivered overnight]
+- In progress: [what you're working on]
+- Blocked: [what you need from the user]
+- Discovered: [side-findings worth mentioning]
+
+If nothing happened overnight, say so honestly: "Quiet night, nothing pending."
+
+### 2. Service Health
+
+Quick health check — don't belabor this, just flags:
+
+**Gmail**: Use the `google-workspace` skill (gmail.sh) to check:
+```
+gmail.sh search "newer_than:1d" --max 3
+```
+- If it works: OK (silent)
+- If error: Gmail KO — HIGHLIGHT
+
+**Drive**: List recent files:
+```
+drive.sh list --max 3
+```
+- If it works: OK (silent)
+- If error: Drive KO — HIGHLIGHT
+
+**IMPORTANT**: Google scripts run LOCALLY (on the server), NOT on the connected Mac node.
+
+Path: `workspace/.claude/skills/google-workspace/scripts/`
+
+**Mac Node**: Check if connected (list_nodes). If offline, report it.
+
+**Rule: Only mention services if they're broken.** "Services OK" in one line if everything works. Don't list every green service.
+
+### 3. Agenda
+
+Check **all** these sources:
+
+1. **Google Calendar** — today's and tomorrow morning's events
+2. **Apple Reminders** — reminders due today (via Mac node if available)
+3. **MEMORY.md** — Open TODOs section, mentioned deadlines
+4. **Yesterday's conversations** — did the user mention commitments?
+
+**Prioritize**: put time-sensitive items first (meetings, deadlines), then generic tasks.
+
+### 4. Weather
+
+Use the `weather` skill:
+- **The user's city** — temperature, conditions, day trend
+
+**Condensed**: "City 8C -> 12C, cloudy." One line.
+
+### 5. Today's Priorities
+
+Based on everything above, suggest 2-3 priorities for the day:
+- What's most important/urgent?
+- What can the assistant handle autonomously?
+- What needs the user's input?
+
+### 6. Send Message
+
+**Channel**: `{{CHANNEL}}`
+**ChatId**: `{{CHAT_ID}}`
+
+**Format** (example):
+
+```
+Good morning!
+
+Overnight: completed the research on X and prepared the draft in workspace/. The bazaar-intel needs your review on DB schema.
+
+Services OK
+
+Today:
+- 10:00 Call with Y (Calendar)
+- Deadline Z (from MEMORY.md)
+
+Weather: City 8->12C, cloudy
+
+Priorities:
+1. Review bazaar-intel DB schema (needs your input)
+2. Finalize PR (I can do this)
+3. Reply to email from X (do you need this?)
+
+Have a good day!
+```
+
+**Message rules**:
+- **Delivery report FIRST** — it's the most important section
+- Brief and scannable — the user reads it right after waking up
+- If a service is KO, highlight it
+- Vary the greeting
+- Tone: like a colleague giving you the morning briefing
+- Priorities must be ACTIONABLE, not generic
+
+### 7. HEARTBEAT.md Update
+
+After sending the message, update `HEARTBEAT.md` with today's task checklist:
+- Carried-over tasks from overnight
+- New tasks from calendar/reminders
+- Self-improvement items if any
+
+This becomes the working checklist for today's heartbeats.
+
+### 8. Log
+
+Append to `workspace/agent-thoughts/buongiorno-log.md`:
+
+```
+## YYYY-MM-DD
+- Overnight: [summary of overnight work]
+- Services: OK/issues
+- Calendar: N events
+- Priorities set: [list]
+- Message sent: yes
+```
+
+## Fallback
+
+If the Mac node is unreachable:
+- Skip Apple Reminders
+- Report it in the message
+- Everything else works (Google local, weather web, memory local)
+- Send the standup anyway with available info

package/bundled/council/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: council
+description: "Run a Karpathy-style LLM Council (multi-model parallel answers + peer review + chairman synthesis) using Pico subagents: Gemini Pro, Grok, GPT-5.2, and (if available) Opus."
+user-invocable: true
+priority: 4
+---
+
+# Council — LLM Council via Pico subagents
+
+Obiettivo: replicare la logica di **karpathy/llm-council** in modalità “skill”, usando `pico_query` per interrogare più modelli in parallelo, poi fare peer-review/ranking, e infine una sintesi.
+
+## Modelli (seats)
+
+Questa istanza attualmente espone (vedi `pico_models`):
+- `openrouter/google/gemini-3-pro-preview` ("Gemini Pro")
+- `openrouter/x-ai/grok-4.1-fast` ("Grok")
+- `openrouter/openai/gpt-5.2` ("GPT-5.2")
+
+**Opus**:
+- Se in `pico_models` compare un modello tipo `openrouter/anthropic/claude-3-opus` o simile, usalo.
+- Se **non** è disponibile via Pico, il “seat Opus” viene coperto dal **modello corrente** (cioè tu, in questa sessione), generando/recensendo localmente invece che via `pico_query`.
+
+> Nota: non inventare ref di modello. Prima fai sempre `pico_models` e scegli da lì.
+
+> **IMPORTANTE — Formato nome modello per `pico_query`:**
+> Il parametro `model` di `pico_query` accetta il **nome display** (es. `OpenRouter Grok`), **NON** il ref tecnico (es. `openrouter/x-ai/grok-4.1-fast`). Usare il ref causa errore "Model not found".
+>
+> Mapping attuale (feb 2026):
+> | Nome display | Ref tecnico |
+> |---|---|
+> | `OpenRouter GPT` | `openai/gpt-5.2` |
+> | `OpenRouter Flash` | `google/gemini-3-flash-preview` |
+> | `OpenRouter RollingMem` | `openai/gpt-4.1-mini` |
+> | `OpenRouter Grok` | `x-ai/grok-4.1-fast` |
+> | `OpenRouter GeminiPro` | `google/gemini-3-pro-preview` |
+> | `OpenRouter Opus1m` | `anthropic/claude-opus-4.6` |
+
+## Interfaccia d’uso
+
+When the user asks:
+- “use council on this question ...”
+- “run a council with gemini/grok/gpt/opus ...”
+
+Esegui la pipeline qui sotto.
+
+Se l’utente non specifica nulla:
+- **Chairman**: GPT-5.2
+- **Council**: Gemini Pro + Grok + GPT-5.2 + (Opus se disponibile, altrimenti seat locale)
+
+## Pipeline (3 stadi)
+
+### Stage 0 — Discovery & Setup
+
+1) Chiama `pico_models`.
+2) Costruisci la lista `COUNCIL_REFS` in questo ordine (se disponibili):
+   - `openrouter/google/gemini-3-pro-preview`
+   - `openrouter/x-ai/grok-4.1-fast`
+   - `openrouter/openai/gpt-5.2`
+   - (Opus ref se presente)
+3) Scegli `CHAIR_REF`:
+   - preferenza: `openrouter/openai/gpt-5.2`
+   - fallback: un qualsiasi modello disponibile in `pico_models`
+
+Se un modello non è disponibile, **saltalo** senza fallire l’intera esecuzione.
+
+### Stage 1 — First opinions (parallelo)
+
+Per ogni modello in `COUNCIL_REFS`, esegui `pico_query` in parallelo con:
+
+**Prompt template**
+
+```
+You are one member of an LLM council.
+
+User query:
+{{USER_QUERY}}
+
+Write your best answer.
+- Be specific and actionable.
+- If uncertain about facts, say so and propose verification steps.
+- Prefer structure (headings/bullets) when helpful.
+```
+
+Raccogli: `{modelRef, firstAnswer}`.
+
+Se “Opus seat” è locale (non via Pico): genera anche tu una risposta indipendente *senza* guardare le altre.
+
+### Stage 2 — Peer review + ranking (parallelo)
+
+1) **Anonimizza** le risposte di Stage 1 assegnando ID `A, B, C, D...` e **non** includere il nome del modello nel testo inviato ai reviewer.
+2) Per ogni reviewer (gli stessi modelli, più eventualmente te stesso se Opus seat locale), fai una `pico_query` con:
+
+**Prompt template**
+
+```
+You are a critical reviewer in an LLM council.
+
+User query:
+{{USER_QUERY}}
+
+Below are anonymized answers from different models:
+
+Answer A:
+...
+
+Answer B:
+...
+
+Tasks:
+1) Critique each answer briefly: strengths, weaknesses, missing pieces, hallucination risk.
+2) Provide a ranking from best to worst (list the answer IDs).
+3) Provide a short merge plan: what to combine into a final best answer.
+
+Respond in JSON:
+{
+  "critiques": [{"id":"A","notes":"..."}, ...],
+  "ranking": ["A","C","B"],
+  "merge_plan": "..."
+}
+```
+
+Se un reviewer non produce JSON valido:
+- fai 1 retry chiedendo: “Return ONLY valid JSON.”
+- se fallisce ancora, conserva comunque la parte testuale e marca `ranking: null`.
+
+### Stage 3 — Chairman synthesis (1 chiamata)
+
+Usa `CHAIR_REF` come chairman (di default GPT-5.2) e invia:
+- user query
+- tutte le risposte anonime
+- tutte le review (critiques + ranking + merge plan)
+
+**Prompt template**
+
+```
+You are the CHAIRMAN of an LLM council.
+
+User query:
+{{USER_QUERY}}
+
+Anonymized answers:
+{{ANSWERS_BLOCK}}
+
+Peer reviews (critiques + ranking + merge plan):
+{{REVIEWS_BLOCK}}
+
+Rules:
+- Produce ONE final answer to the user.
+- Prefer correctness over confidence; call out uncertainty and suggest verification steps.
+- When useful, include a short bullet list: "Key assumptions / decisions".
+- Keep it concise but complete.
+```
+
+## Output
+
+Rispondi all’utente con:
+1) **Risposta finale** (chairman)
+2) (Optional, if the user asks “debug” / “show me council”):
+   - elenco dei modelli usati
+   - mapping `A/B/C/D → modelRef`
+   - ranking aggregato (se possibile)
+   - note su modelli falliti
+
+## Guardrail
+
+- Non “aggiustare” le risposte inventando fatti: se il council è incerto, rendilo esplicito.
+- Non rivelare informazioni private del workspace se non richieste.
+- Se la domanda è ad alto rischio (finanza/medicina/legale), chiedi al chairman di includere disclaimer + passi di verifica.