Pepper

Contexte

Un side project sur un terrain que je ne connaissais pas : administrer un VPS, écrire un harness d'agent à la main, brancher un modèle via OpenRouter. Le cas d'usage : un vault Obsidian partagé avec un tiers, accessible de partout, sans abonnement de synchronisation. Une seule copie du vault sur le VPS, Telegram en interface. Pepper lit et écrit les notes Markdown, crée des todos, les assigne et notifie la personne concernée.

Périmètre

Mené seul, de bout en bout : specs et plan technique écrits avant de coder, puis développement, tests et mise en production sur le VPS. Le harness est écrit à la main plutôt que repris d'un framework, ce qui garde le contrôle sur ce que le modèle peut faire.

Décisions produit

• Surface d'outils limitée à cinq tools (lire, écrire, lister les notes, lister les assets, générer une image) : pas de shell, pas d'accès web, pas de suppression
• Cloisonnement des zones appliqué dans le harness, chemins validés : le modèle n'atteint jamais la zone de l'autre utilisateur
• Pas de base de données : les fichiers Markdown font la source de vérité, aux conventions Obsidian (wikilinks, tags, frontmatter), donc Obsidian Sync reste une option plus tard
• LLM derrière une interface à une seule méthode : OpenRouter en production, client pré-enregistré en test, modèle choisi par variable d'environnement
• Commandes /status, /notes et /help traitées sans appel au modèle : immédiat et sans coût

Points clés

• Boucle de tool-calling avec mémoire de conversation, sur Gemini Flash via OpenRouter
• Assignation : la todo part dans la zone partagée et l'autre utilisateur reçoit un message direct
• Génération d'images, renvoyées sur Telegram et archivées dans le vault
• Tests colocalisés par module (Vitest), CI sur lint, typecheck, tests et build à chaque push
• Exécution continue sur VPS sous pm2, redémarrage automatique, SSH durci (clés, UFW, fail2ban)
• Coût d'exploitation de 5 à 8 € par mois, plafond de dépense posé sur l'API dès la mise en service

Stack