X bookmarks

Proposal — Installer le skill xurl sur Marco pour étendre l'accès X au-delà des bookmarks. Le tweet annonce un guide officiel xAI pour le skill `xurl` qui permet à un Hermes Agent de lire/écrire sur X en langage naturel (post, search, bookmarks, lists). Concrètement pour Marco : (1) suivre le setup guide pour installer xurl dans `~/.hermes/skills/`, (2) câbler les credentials OAuth déjà présents (`X_USER_ID`, `X_ACCESS_TOKEN` dans `.env.local`) pour que xurl les réutilise au lieu du fetch manuel de `lib/x-bookmarks.ts`, (3) ajouter des capacités côté dashboard : un endpoint `/api/x/search` qui délègue à xurl pour requêter des sujets thématiques (ex: 'next.js 15 server actions'), et un endpoint `/api/x/lists` pour suivre des listes curatées de devs. À terme, remplacer le code custom de `lib/x-bookmarks.ts` (fetch + 429 mapping + pagination) par un appel xurl natural-language — Marco gère le retry et le refresh token via le skill, on supprime la dette OAuth manuelle (regen token à 2h).

Proposal — Ajouter un ERRORS.md par projet vault + injecter la règle dans le prompt Marco. L'article décrit un pattern simple mais absent du setup Marco : maintenir un `ERRORS.md` par projet listant les approches qui ont demandé >2 tentatives (ce qui a foiré / ce qui a marché / note pour la suite). Concrètement : (1) ajouter `marco-vault/projects/<slug>/ERRORS.md` (template court avec sections datées), (2) modifier le prompt système injecté par `~/.hermes/scripts/pipeline.py` au spawn `claude -p --model opus` pour deux instructions — « lis `ERRORS.md` du projet avant de proposer une approche » et « si une approche a demandé >2 tentatives durant cette session, ajoute une entrée à `ERRORS.md` avant de terminer ». (3) Côté marco-dashboard, ajouter un onglet « Erreurs apprises » dans `app/projects/[slug]/page.tsx` qui lit le fichier via un nouveau helper `getErrorsLog(slug)` dans `lib/vault.ts`, rendu à côté de Status/Backlog/Ideas. Ça transforme les ratés en mémoire réutilisable entre features et donne à Paolo une vue rapide des pièges connus par projet.

Proposal — Vue coût-par-session dans marco-dashboard (tokens × modèle × cache). Le thread chiffre les fuites tokens des agents (auto-context 80% gaspillé, Opus sur tâches Haiku = 30x payé). Pour Marco la plus exploitable est la visibilité. Concrètement dans marco-dashboard : nouveau `lib/cost.ts` + route `GET /api/sessions/[id]/cost` qui lit `messages` de state.db, agrège par modèle les `input_tokens` / `output_tokens` / `cache_read_input_tokens` (déjà dans le JSON `usage` des rows assistant), multiplie par une table de prix hardcodée Opus/Sonnet/Haiku, et renvoie `{totalUsd, byModel, cacheHitPct, topExpensiveToolCalls}`. Affichage : un card en tête de `/sessions/[id]` + colonne `costUsd` dans `/sessions`. Permet d'identifier a posteriori les sessions où Marco aurait dû router sur Haiku (lint/rename/format). Suite logique côté Hermes : règle dans `~/.hermes/scripts/pipeline.py` qui force `--model haiku` quand le titre de phase matche `/^(lint|format|rename|chore)/i`. Test : Vitest sur `computeSessionCost(messages, priceTable)` avec un fixture multi-modèle.

Proposal — Panneau /insights dans marco-dashboard : coûts par provider + sessions stalled. Construire app/insights/page.tsx + lib/insights.ts qui lit l'équivalent de /insights [days] depuis state.db (messages + tool_calls JSON) et ~/.hermes/sessions/. Trois cards : (1) tokens consommés par projet sur 30j, (2) coût par provider/modèle (jointure messages.model → table de prix locale, calculé côté serveur), (3) sessions stallées (started_at ancien + pas de completion marker depuis >1h). Réutilise le singleton better-sqlite3 readonly de lib/hermes-db.ts. Ajoute route /api/insights/summary?days=30 (clamp [1,90]) renvoyant {byProject, byProvider, stalled}. Bonus config Marco actionnable en parallèle : configurer un auxiliary model Haiku 4.5 pour compression contexte via `hermes model` (gain coût immédiat — l'article rappelle que la plupart payent Opus pour du grunt work).

Proposal — Bot hygiène backlog vault pour Marco, inspiré clawsweeper. Ajouter un module Marco `hermes/scripts/backlog-sweeper.py` qui scanne périodiquement les `features/*.md` de chaque projet vault et propose des fermetures motivées. Patterns à reprendre de clawsweeper : (1) review-only puis apply guardé — écrire un rapport markdown par feature dans `~/.hermes/marco-reviews/<projet>/<feature>.md` avec `{verdict, evidence, snapshot_hash, proposed_status_change}`, et seules les propositions inchangées entre deux passes (snapshot stable) sont appliquées en flippant le frontmatter `status: Done`. (2) Raisons strictement allowlistées : `implemented_on_main` (git log montre commits liés mergés + RUN_OK récents dans pipeline.log via `findRunsForSlug`), `superseded_by:<slug>` (autre feature couvre déjà via depends_on inversé), `stale_no_signal` (>60j sans update + aucun run pipeline). (3) Token flow séparé : le worker Claude n'a aucun accès en écriture vault ; un step déterministe en aval applique le diff frontmatter après re-check du snapshot. (4) Exposer dans marco-dashboard sous `/projects/[slug]` un onglet "Hygiène backlog" listant les propositions en attente avec verdict + bouton accepter/rejeter.