beats-pm-kit

Beats PM Kit (le harnais agentique Beats pour la gestion de produit) est un projet OfficeBeats qui encapsule un harnais local-first, multi-runtimes, pour des workflows de gestion de produit étayés par des preuves. Il archive localement en Markdown le contexte de produit dispersé — réunions, fils de discussion, e-mails, documents et notes — le rend searchable, et le triangule en workstreams et tâches qu’un agent IA peut exécuter. Le README précise que rien n’est uploadé par le kit lui-même. Structure et concepts Le kit utilise une taxonomie de coffre-fort numérotée : 0. Incoming, 1. Company, 2. Products, 3. Meetings, 4. People, 5. Trackers, 6. Resources, 6. SOPs, 7. Partners, 8. Clients, plus .agent/ pour les agents canoniques, règles, compétences, templates et workflows, et system/ pour les scripts, tests et docs. L’état canonique des tâches réside dans 5. Trackers/tasks/ sous forme de notes Markdown lisibles par l’homme avec des IDs stables, des liens vers les preuves, le progrès et les décisions ; TASK_MASTER.md et les notes de workstream sont décrits comme des navigations générées sur ces fichiers, pas une seconde source de vérité. Source de vérité unique .agent/command-registry.json contrôle le routage, les alias, les profils d’exécution et la politique de runtime ; .agent/workflows/ contient le comportement des workflows ; .agent/skills/ contient les méthodes PM réutilisables. Les fichiers d’adaptateur racine (AGENTS.md, CLAUDE.md, GEMINI.md, CODEX_COMMANDS.md), .omp/config.yml et les fichiers d’ignore des outils sont des vues générées produites par system/scripts/sync_cli_adapters.py — l’édition de .agent/ et la régénération sont le chemin prévu, car les fichiers générés édités à la main sont écrasés par conception. Commandes et contexte Chaque commande slash est résolue via le registre vers un fichier de workflow et un profil d’exécution (Fast, Balanced ou Deep), et porte un niveau de promotion par runtime : les commandes promues sont expédiées comme des compétences natives, les commandes gardées nécessitent une confirmation, et le reste est uniquement en dispatch. La boucle d’exécution documentée est : router, charger le contexte borné, agir avec les outils, faire un checkpoint, vérifier, persister l’artefact ; la récupération initiale est plafonnée et les preuves brutes restent adressables par hash localement, avec un contexte compacté traçable jusqu’aux fichiers sources. Runtimes supportés Des points d’entrée sont listés pour omp, Claude Code, OpenAI Codex CLI, Google Antigravity, Gemini CLI, GitHub Copilot, et une UI Obsidian optionnelle sur le même coffre-fort. Le README indique que le comportement est sélectionné par des capacités détectées positivement plutôt que par une hiérarchie de fournisseurs, les valeurs par défaut du modèle sont héritées du runtime, et les capacités inconnues échouent en mode fermé. Premiers pas et workflows L’installation est un git clone plus ./install.sh, une fine enveloppe autour de python3 system/scripts/bootstrap.py --agent --non-interactive. Bootstrap vérifie le repo, exécute une porte de compatibilité de mise à jour sur les workspaces existants, crée des dossiers de workspace locaux ignorés, ensemence les templates, synchronise les adaptateurs de runtime, installe les hooks git si possible, et exécute des vérifications de confidentialité et de santé des adaptateurs. Les utilisateurs ouvrent ensuite le dossier dans un runtime et exécutent /start ou /help. Les workflows sont groupés en intake et preuves (/paste, /find, /memory, /context, /chat et intégrations de messagerie), réunions (/meet, /transcript, /prep, /boss), planification et stratégie (/plan, /create, /deck, /discover, /interview, /intel, /prioritize, /sprint, /retro), tracking (/track, /day, /week, /handoff), comms et docs (/sop, /office-cli, /review, /challenge, /improve-plan), qualité et maintenance (/accuracy, /regression, /build, /vibe, /maintain, /update, /vacuum, /archive) et setup/orchestration (/start, /help, /obsidian, /pack, /team, /fan-out). L’entrée en langage naturel est également supportée. Utilitaires locaux Le travail répétable est délégué à des scripts Python uniquement stdlib dans system/scripts/, y compris vault_query.py pour des requêtes en lecture seule bornées sur les tâches, labels et citations ; context_router.py pour la récupération full-text indexée à travers les dossiers de preuves locales ; task_store.py et task_intake_fast.py pour les écritures canoniques de notes de tâche et l’intake rapide ; transcript_pipeline.py pour préparer, valider et traiter les transcriptions de réunion ; pm_decision_router.py pour classifier l’entrée PM désordonnée avant l’exécution ; obsidian_bridge.py pour utiliser le dossier du kit comme un coffre-fort Obsidian ; pack_manager.py pour activer des capacités optionnelles dormantes comme Trello ; upgrade_compat.py pour la pré-vérification et la migration réversible des configurations legacy ; et privacy_guard.py / adapter_guard.py pour bloquer les fuites de contenu privé et la dérive des adaptateurs générés. Confidentialité et tests La posture de confidentialité est local-first : les dossiers de coffre-fort personnels sont ignorés par git et suivis uniquement via des fichiers squelettes .gitkeep, avec l’état local du runtime dans un .beats/ ignoré. Les scripts de garde (privacy_guard.py --tree, adapter_guard.py --mode check) bloquent le contenu privé, les chemins personnels, les chaînes de caractères ressemblant à des tokens, les transcriptions et la dérive des adaptateurs des commits partagés. WATCHDOG.md définit les règles de l’advisor, telles que pas de citations, IDs ou dates fabriqués, l’approbation explicite de l’utilisateur pour les envois sortants, et le maintien de l’état des tâches dans les trackers canoniques. Le README ajoute la mise en garde que le kit ne synchronise jamais les fichiers vers un service cloud, mais le runtime IA choisi traite les prompts et les sorties d’outils sous les propres paramètres de ce fournisseur. Les tests résident dans system/tests/ au style pytest et couvrent le registre, les adaptateurs, le store de tâches, le pipeline de transcription, les gardes de confidentialité et d’adaptateur, la compatibilité de mise à jour et les invariants du coffre-fort. Crédits Beats PM Kit est construit à partir du travail quotidien de gestion de produit ; la politique de sortie action-first est décrite comme une approche formulée indépendamment, inspirée par le projet i-have-adhd sous licence MIT, sans plugin ou code de hook en amont inclus.