🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
inspectrum
Advanced tools
inspectrum - npm Package Compare versions
| # Paysage concurrentiel d'Inspectrum — juillet 2026 | ||
| État : analyse stratégique fondée sur des sources consultées le 30 juillet | ||
| 2026. Les capacités actuelles sont des faits sourcés ; les projections à 12 et | ||
| 24 mois sont des inférences explicitement signalées. | ||
| ## Résumé de décision | ||
| La contre-analyse réfute la promesse générique d'Inspectrum : | ||
| **« demander une seconde opinion à un autre modèle » est déjà une commodité**. | ||
| Un développeur peut la reproduire avec un skill, un hook et deux appels | ||
| headless en un à trois jours. Les harnais natifs proposent déjà sous-agents, | ||
| équipes, revue, hooks, sorties structurées et traces. Les SDK rendent | ||
| « reviewers parallèles + juge » banal. Les produits de pull request possèdent | ||
| la distribution, les annotations et l'apprentissage qu'Inspectrum n'a pas. | ||
| Le seul espace qui mérite encore une expérience est plus étroit : | ||
| **un checkpoint de revue portable et mesuré à une frontière de risque**, qui | ||
| conserve la provenance, le désaccord, les budgets, les échecs et la décision | ||
| humaine. Même cet espace n'est pas un moat aujourd'hui. Il ne le devient que si | ||
| des données réelles montrent quels reviewers trouvent quels défauts | ||
| supplémentaires à budget égal, et si ces données réduisent le bruit et les | ||
| retours arrière. | ||
| Conséquences : | ||
| - revue de plan : créneau expérimental principal, sous condition de preuve ; | ||
| - revue de changements : extension d'expérience, pas prochaine « version | ||
| évidente » ; | ||
| - commit et pull request : repousser ; marché saturé et fonctions natives | ||
| fortes ; | ||
| - pair programming : abandonner comme produit autonome ; | ||
| - discussion multi-modèles : abandonner le débat libre ; conserver seulement | ||
| un comparateur de désaccords en un tour. | ||
| ## Méthode et niveau de preuve | ||
| Le registre contient [198 sources](evidence/competitive-source-ledger.csv) : | ||
| 90 documentations officielles, 15 releases, 9 lignes classées | ||
| `peer-reviewed paper`, plus 2 pages de prépublication d'articles évalués par | ||
| les pairs, des préprints, dépôts, prix, issues et communautés. Les signaux | ||
| communautaires couvrent notamment 22 pages Reddit, 6 fils Hacker News, | ||
| 31 pages GitHub et 2 vidéos YouTube. Ce volume décrit la largeur de collecte, | ||
| pas la force d'une conclusion. | ||
| Ces comptes descriptifs se recouvrent : « page GitHub » est un domaine, pas une | ||
| classe de preuve. Une normalisation mutuellement exclusive des `source_type` | ||
| donne exactement **135 sources produit/standard primaires, 25 sources de | ||
| recherche et 38 sources communautaires**, soit 198. | ||
| Les identifiants ne sont volontairement pas continus après fusion des vagues | ||
| de recherche ; le nombre de lignes du registre, pas le dernier numéro, fait | ||
| foi. | ||
| Le contrôle automatisé du 30 juillet 2026 atteint directement 193 URL sur 198 | ||
| (réponse HTTP 2xx/3xx). Deux pages OpenAI répondent 403, deux fils Hacker News | ||
| 429, et la page Sonar Review répond 404 au client direct alors que son contenu | ||
| reste indexé par la recherche officielle. Ces cinq exceptions sont des limites | ||
| d'accès ou de stabilité, pas des preuves négatives sur les produits. Le CSV | ||
| contient 145 lignes classées de qualité haute, 41 moyenne ou moyenne-haute et | ||
| 12 basse ou basse-moyenne ; cette auto-classification facilite le triage mais | ||
| ne remplace pas l'examen de la méthode de chaque source. | ||
| Les 12 lignes basses ou basses-moyennes ne soutiennent que des anecdotes | ||
| signalées comme telles : confusion des surfaces de configuration, règle | ||
| ignorée, friction MCP, pertes de handoff, coût/observabilité multi-agent, | ||
| traitement du désaccord et du juge, cadrage confidentialité, un finding | ||
| CodeRabbit et une démonstration vidéo. Aucun seuil, choix de wedge ou argument | ||
| de moat ne dépend seul de ces lignes. | ||
| Chaque source porte une affirmation, un signal, une qualité et ses limites. | ||
| Les règles suivantes s'appliquent : | ||
| - documentation et code : preuve de capacité, jamais de qualité ; | ||
| - papier ou mesure reproductible : preuve limitée à son protocole ; | ||
| - benchmark fournisseur : affirmation du fournisseur, pas classement | ||
| indépendant ; | ||
| - Reddit, Hacker News, forum, issue ou vidéo : anecdote, pas fréquence ni | ||
| volonté de payer ; | ||
| - étoiles, téléchargements et sponsoring : exclus comme preuve de valeur. | ||
| Trois lots indépendants ont mené deux vagues tardives chacun. Ils ont ajouté | ||
| des noms — Windsurf, Warp, Korbit, Kodus, Cubic, Ellipsis, Sonar Review — mais | ||
| plus aucune catégorie matérielle. La recherche est arrêtée par **saturation de | ||
| catégories**, pas par quota. Les accès automatisés bloqués en 403/429, pages | ||
| vivantes sans date et transcripts absents sont consignés dans le ledger. | ||
| ## Taxonomie des substituts | ||
| | Famille | Exemple minimal | Ce qu'elle remplace | Limite qui peut rester utile à Inspectrum | | ||
| |---|---|---|---| | ||
| | Instruction ou skill | `AGENTS.md` / `SKILL.md` demandant une revue fraîche | prompt, rôle, format et étape volontaire | déclenchement et conformité restent probabilistes | | ||
| | Sous-agent ou mode reviewer | agent lecture seule, modèle et outils dédiés | contexte frais, spécialisation, attribution basique | schémas et garanties diffèrent par harnais | | ||
| | Script ou intégration continue | deux interfaces en ligne de commande + JSON + fichier | fan-out, validation, timeout, journal | maintenance des identités, versions, quotas et erreurs | | ||
| | Hook natif | sortie de plan, `Stop`, avant commit ou push | déclenchement déterministe et blocage/réessai | événements et UX non portables | | ||
| | Serveur MCP générique | outil `review_plan` ou « council » | invocation typée et portée multi-client | le client peut ne jamais l'appeler ; nouvelle surface de confiance | | ||
| | Équipe ou Oracle natif | Claude/Codex/Cline teams, Amp Oracle | parallèle, débat et second fournisseur | coût, contexte et erreurs corrélées | | ||
| | SDK d'agents | graphe reviewer → critique → juge | reprise, budgets, tracing et humain dans la boucle | ce sont des primitives, pas une preuve de meilleure décision | | ||
| | Contrôle déterministe | tests, schémas, policy-as-code, analyse statique | invariants vérifiables avec faible bruit | ne comprend pas l'intention métier | | ||
| | Produit de pull request | bot natif ou spécialiste | installation, inline, historique et workflow d'équipe | bruit, confidentialité, coût par push | | ||
| L'alternative de référence n'est donc pas « ne rien faire ». C'est : | ||
| ```text | ||
| skill portable | ||
| → hook natif | ||
| → deux appels headless indépendants | ||
| → schéma JSON + délai + artefacts | ||
| → validation humaine | ||
| ``` | ||
| Cette pile est inspectable, utilise des abonnements existants et évite une | ||
| nouvelle dépendance. Son coût initial est faible ; sa maintenance sur 90 jours | ||
| est moyenne. Inspectrum doit battre ce témoin, pas une copie manuelle naïve. | ||
| ## Harnais de codage : matrice de substitution | ||
| Les cellules décrivent les capacités documentées au 30 juillet 2026. | ||
| | Harnais | Instructions / skills | Reviewer ou équipe | Hook / politique | Headless / contrat | Menace principale | | ||
| |---|---|---|---|---|---| | ||
| | [Claude Code](https://code.claude.com/docs/en/features-overview) | `CLAUDE.md`, rules, skills, plugins | sous-agents, teams, `/review`, `/code-review`, `/ultrareview` | hooks bloquants, événements agent et outils | print + JSON Schema, coût/usage | peut emballer presque tout le flux dans un plugin natif | | ||
| | [Codex](https://learn.chatgpt.com/docs/agent-configuration/subagents) | `AGENTS.md`, skills, plugins | sous-agents natifs, `/review`, revue GitHub | hooks, permissions, sandbox | exécution non interactive et sortie structurée | revue locale de working tree/base/commit déjà native | | ||
| | [Gemini CLI](https://geminicli.com/docs/hooks/reference/) | `GEMINI.md`, `AGENTS.md`, extensions, skills | sous-agents en préversion | hooks JSON et policy engine | headless / JSON | `AfterAgent` peut refuser une sortie et relancer | | ||
| | [OpenCode](https://opencode.ai/docs/agents) | rules, commands, skills | agent reviewer lecture seule | permissions ordonnées et plugins | oui | recette reviewer déjà documentée | | ||
| | [Cursor](https://docs.cursor.com/en/cli/using) | `.cursor/rules`, `AGENTS.md` | modes, agents en arrière-plan, Bugbot | guardrails ; hooks moins complets dans les sources | print JSON, mais accès en écriture à surveiller | possède éditeur, contexte et revue avant push | | ||
| | [GitHub Copilot](https://docs.github.com/en/copilot/concepts/agents/code-review) | instructions, `AGENTS.md`, skills multi-chemins | agent code review natif | hooks CLI/cloud | GitHub Actions, IDE et CLI | distribution GitHub et revue automatique | | ||
| | [Aider](https://aider.chat/docs/usage/modes.html) | conventions et contexte manuel | architect + editor | lint/test/git | scriptable | le pair planning/exécution existe depuis longtemps | | ||
| | [Continue](https://docs.continue.dev/cli/headless-mode) | rules et prompts | séparation de modes | politiques par outil | CLI headless ; recette hook Git | `git diff | reviewer` est déjà documenté | | ||
| | [Cline](https://docs.cline.bot/features/subagents) | rules, `AGENTS.md`, skills | sous-agents et teams CLI | huit types de hooks | JSON et coûts enfants | contrôle de coût/lecture seule déjà visible | | ||
| | [Roo Code](https://docs.roocode.com/features/boomerang-tasks) | règles par mode | Orchestrator / Boomerang | groupes d'outils et approbations | partiel | summaries perdent une partie de la preuve | | ||
| | [Kilo Code](https://kilo.ai/docs/customize/custom-subagents) | rules et skills | reviewer spécialisé, PR review | permissions et sandbox | oui | reviewer à modèle/étapes/permissions configurables | | ||
| | [goose](https://block.github.io/goose/) | skills et recettes YAML | sous-agents, adversary reviewer | permissions et sandbox | recettes CI et API | offre déjà un reviewer modèle-neutre | | ||
| | [Amp](https://ampcode.com/manual) | `AGENTS.md` et règles | review agent et Oracle cross-vendor | permissions SDK | CLI/plugin API | exemple direct d'avis cross-vendor ; le rend lent/cher et optionnel | | ||
| | [OpenHands](https://docs.openhands.dev/openhands/usage/cli/command-reference) | repository skills | composition SDK | sandbox, approbations, sécurité | JSONL | orchestration ouverte, plus lourde à installer | | ||
| | [Windsurf](https://docs.windsurf.com/de/windsurf/cascade/hooks) | rules et `AGENTS.md` | modes Cascade | hooks système/utilisateur/workspace | partiel | ajoute blocage et audit d'appels MCP | | ||
| | [Warp](https://docs.warp.dev/agent-platform/capabilities/rules) | reconnaît huit formats de règles | plateforme agent | rules/policies | oui | étend la convergence des formats, pas une nouvelle catégorie | | ||
| Lecture : la capacité est banalisée. La différence possible se déplace vers la | ||
| qualité mesurée, la politique de panne portable et l'historique de décisions. | ||
| ## Orchestration : « plusieurs agents + juge » n'est pas un moat | ||
| ### Le bon « Hermes » | ||
| Le projet pertinent est | ||
| [NousResearch/Hermes Agent](https://github.com/NousResearch/hermes-agent/blob/main/AGENTS.md), | ||
| observé en release `v2026.7.20`, et non le modèle Hermes 3 ni d'autres | ||
| homonymes. Hermes Agent expose délégation isolée, concurrence et profondeur | ||
| bornées, plusieurs fournisseurs, mixture-of-agents, skills et MCP | ||
| [OD-HERMES-001 à 003]. Il remplace directement un « comité de reviewers » | ||
| configurable pour ses utilisateurs. | ||
| ### SDK et frameworks | ||
| | Famille | Produits observés | Primitives déjà disponibles | Conséquence | | ||
| |---|---|---|---| | ||
| | SDK fournisseurs | [Claude Agent SDK](https://code.claude.com/docs/en/agent-sdk/overview), [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/) | sous-agents, hooks, MCP, sorties typées, handoffs, agents-outils, guardrails, sessions, tracing et parallèle | une boucle reviewers + juge tient dans peu de code | | ||
| | Microsoft | [Agent Framework](https://learn.microsoft.com/en-us/agent-framework/overview/), AutoGen, Semantic Kernel | graphes typés, checkpoints, approbations, sessions, group chat, Magentic | la garantie opérationnelle générique devient bibliothèque | | ||
| | Graphes / workflows | [LangGraph](https://langchain-ai.github.io/langgraph/concepts/multi_agent/), [Mastra](https://mastra.ai/ai-workflows), [Pydantic AI](https://pydantic.dev/docs/ai/guides/multi-agent-applications/) | parallèle, branche, boucle, reprise, interruptions, idempotence, durable execution | Inspectrum ne possède pas ces primitives | | ||
| | Équipes | [CrewAI](https://docs.crewai.com/), [CAMEL](https://docs.camel-ai.org/key_modules/workforce), [Agno](https://docs.agno.com/teams/overview), [smolagents](https://huggingface.co/docs/smolagents/main/en/tutorials/building_good_agents) | crews/workforces, sorties structurées, humain, mémoire et métriques | un comité est une configuration | | ||
| | Plateformes cloud | [Google ADK](https://adk.dev/workflows/), [Strands/harness-sdk](https://strandsagents.com/docs/user-guide/concepts/multi-agent/graph/) | séquence, boucle, parallèle, A2A, délais, statuts, traces et évaluations | copie rapide par fournisseurs majeurs | | ||
| | Sociétés logicielles | [MetaGPT](https://github.com/FoundationAgents/MetaGPT), [ChatDev](https://github.com/OpenBMB/ChatDev) | rôles spécialisés et procédures de développement | le récit « agents qui discutent » est ancien et reproductible | | ||
| Le prototype [llm-council](https://github.com/karpathy/llm-council) suffit à | ||
| montrer la barrière technique : plusieurs avis via OpenRouter, classement | ||
| anonymisé et « président » dans une application locale. Son statut de | ||
| prototype non maintenu ne crée pas un moat pour le concept. | ||
| ## Produits de revue : marché saturé | ||
| ### Spécialistes | ||
| | Produit | Surface / garantie | Prix public observé | Menace pour Inspectrum | | ||
| |---|---|---:|---| | ||
| | [CodeRabbit](https://docs.coderabbit.ai/management/plans) | PR incrémentale, règles, sévérité, fixes, multi-dépôt, MCP | 24–30 $/développeur/mois Pro | large distribution et apprentissage ; bruit mesuré | | ||
| | [Qodo / PR-Agent](https://docs.qodo.ai/code-review) | agents spécialisés + juge, multi-forge, BYOK/entreprise | crédits ; montant simple non trouvé | architecture presque identique à « reviewers + juge » | | ||
| | [Greptile](https://www.greptile.com/docs/introduction) | graphe de dépôt, P0–P2, apprentissage, fixes | 30 $/développeur actif + dépassement | contexte et apprentissage, mais coût par revue | | ||
| | [Graphite Agent](https://graphite.com/docs/billing-plans) | revue dans stacked PR, règles, métriques d'acceptation | 20–40 $/siège/mois | avantage de distribution du workflow | | ||
| | [Bito](https://docs.bito.ai/help/billing-and-plans/overview) | Git/IDE/CLI, incrémental, plusieurs forges, self-hosted | 12–25 $/siège/mois | offre large à bas prix | | ||
| | [Sourcery](https://docs.sourcery.ai/Code-Review/Code-Reviews-on-Pull-Requests/Overview/) | PR/MR, IDE, règles, sécurité, interaction | prix privé exact non trouvé | promet une revue de collègue, admet ne pas encore l'égaler | | ||
| | [Cubic](https://www.cubic.dev/pricing-plans) | PR, CLI, agents personnalisés, wiki | 30–40 $/développeur/mois dans la source relevée | vend déjà le « faible bruit » | | ||
| | [Korbit](https://www.korbit.ai/index.html) | multi-forge, règles supérieures, on-prem | 12–15 $/utilisateur/mois dans la source relevée | pression prix forte | | ||
| | [Ellipsis](https://www.ellipsis.dev/pricing) | agents définis au dépôt, budgets, BYOK/private cloud | exemple vendeur ≈ 0,74 $/revue | orchestration programmable et budgétable | | ||
| | [Kodus](https://kodus.io/pricing/) | open source, hosted/self-hosted, BYOK, mémoire/MCP | 10 $/développeur + jetons | portabilité et BYOK déjà peu chers | | ||
| ### Revue native | ||
| | Plateforme | Surface actuelle | Menace | | ||
| |---|---|---| | ||
| | Claude Code | revue locale, plugin quatre agents, ultrareview cloud, revue PR managée | très forte ; parallèle, vérification, budgets et check run natifs | | ||
| | OpenAI Codex | working tree, base, commit, GitHub `@codex review` et automatique | couvre exactement la revue de commit envisagée | | ||
| | GitHub Copilot | GitHub, CLI, mobile, IDE, automatique, effort, skills/MCP | distribution dominante ; modèle interne non exposé | | ||
| | Cursor Bugbot | GitHub/GitLab, `/review` avant push, règles et MCP | possède l'activation dans l'éditeur | | ||
| | GitLab Duo | merge request, CI, contexte projet, modèle sélectionnable, self-managed | prix annoncé de 0,25 $/revue et intégration native | | ||
| | Amazon Q | `/q review`, GitHub et IDE, règles et fixes | forte pour les clients AWS | | ||
| ### Hybrides déterministes + IA | ||
| [Snyk/DeepCode](https://docs.snyk.io/scan-with-snyk/snyk-code), | ||
| [DeepSource](https://deepsource.com/), | ||
| [Sonar Review](https://docs.sonarsource.com/sonarqube-cloud/ai-capabilities) | ||
| et [Codacy](https://docs.codacy.com/codacy-ai/codacy-ai/) | ||
| combinent règles, analyse de flux, portes de branche et génération. Pour | ||
| sécurité, conformité et conventions explicites, leur échec est plus | ||
| interprétable qu'un vote de modèles. | ||
| ## Ce que la recherche scientifique autorise à dire | ||
| ### Résultats favorables, limités | ||
| - ReConcile rapporte jusqu'à `+11,4` points sur sept benchmarks et attribue une | ||
| partie du gain à la diversité [OD-RES-001]. | ||
| - Mixture-of-Agents rapporte `65,1 %` contre `57,5 %` pour GPT-4 Omni sur | ||
| AlpacaEval 2.0 ; l'hétérogénéité bat des échantillons répétés dans son | ||
| ablation [OD-RES-002]. | ||
| - PairCoder rapporte `91,0 % pass@1`, jusqu'à `+20,3` points et `40–70 %` de | ||
| tokens en moins que ses baselines multi-agents, mais seulement sur HumanEval, | ||
| pas sur un dépôt réel [OD-RES-016]. | ||
| ### Résultats qui réfutent un bénéfice général | ||
| - Une étude Nature Machine Intelligence du 24 juillet 2026 trouve, sur six | ||
| benchmarks et cinq architectures, un effet de `+80,8 %` à `-70,0 %` selon | ||
| tâche/topologie, **0,0 % de gain agrégé moyen**, une légère dégradation sur | ||
| SWE-bench et une saturation avec un agent fort. Son exploration de | ||
| modèles hétérogènes reste préliminaire ; ce n'est pas une étude de revue de | ||
| plan [OD-RES-004]. | ||
| - MAST trouve `41 %` à `86,7 %` de traces multi-agents en échec selon les | ||
| systèmes et tâches [OD-RES-005]. | ||
| - Le débat n'aide que si le critique classe mieux que le juge et si le juge | ||
| vérifie ses affirmations ; un seul tour réponse → critique → juge capture | ||
| l'essentiel du gain [OD-RES-006]. | ||
| - Sur des tâches de natural-language inference et RewardBench — pas de revue de | ||
| code — neuf juges de sept familles représentent environ deux votes | ||
| indépendants ; le meilleur juge seul égale ou bat le panel [OD-RES-008]. | ||
| - Même entre fournisseurs, les erreurs sont corrélées sur un corpus de | ||
| classements généralistes : parmi plus de 350 modèles, deux modèles qui se | ||
| trompent donnent la même mauvaise réponse 60 % du temps. Ce chiffre est | ||
| propre au dataset et ne mesure pas la revue de plan [OD-RES-009]. | ||
| - La critique mono-modèle avec outils externes est un témoin sérieux. Tests, | ||
| compilateurs, analyse statique et localisation d'erreur passent avant le | ||
| nombre de logos [OD-RES-010 à 013]. | ||
| Conclusion : **l'accord n'est pas une preuve, le désaccord n'est pas | ||
| automatiquement utile, et le juge est un risque**. Le produit doit conserver | ||
| les opinions et preuves séparées, puis mesurer l'erreur marginale. Le juge peut | ||
| éditer une synthèse ; il ne doit pas masquer la minorité ni simuler un vote | ||
| indépendant. | ||
| ## Demande, vécu et volonté de payer | ||
| ### Douleur crédible | ||
| Plusieurs communautés décrivent le même déplacement de coût : le code se | ||
| génère vite, mais un reviewer senior doit reconstruire intention et contexte. | ||
| Une anecdote estime `30–40 %` de temps économisé quand l'IA pré-trie avant | ||
| revue humaine [RMD-051] ; une autre décrit une fuite de confidentialité rare | ||
| détectée par CodeRabbit après qu'un reviewer humain a manqué l'interaction | ||
| [RMD-064]. Ce sont des tâches à accomplir plausibles, pas une mesure de marché. | ||
| ### Bruit mesuré | ||
| - L'étude CodeRabbit sur `31 073` paires de revue/retour observe `56,3 %` de | ||
| rejets et `36,4 %` d'acceptations ; faux positifs, redondance et hors-périmètre | ||
| dominent [RMD-045]. | ||
| - SWE-PRBench plafonne le meilleur système étudié à `31 %` de détection, avec | ||
| `0,193–0,417` de faux positifs ; davantage de contexte plat dégrade les huit | ||
| modèles du protocole [RMD-046]. | ||
| - Les communautés répètent les mêmes mécanismes : nouvelle vague de findings | ||
| après correction, contexte ignoré, sévérité erronée, plusieurs cycles de | ||
| triage et alertes progressivement ignorées [RMD-050, 053–055, 060, 065]. | ||
| Le bon objectif n'est pas le nombre de commentaires, mais les **défauts majeurs | ||
| confirmés uniques par minute de triage humain**. | ||
| ### Paiement et quotas | ||
| Les prix montrent une catégorie financée, mais pas une volonté de payer pour | ||
| Inspectrum. Les anecdotes acceptent 15–25 $ pour authentification, paiement ou | ||
| données à haut risque ; elles refusent souvent un abonnement supplémentaire | ||
| quand Codex, Claude ou Copilot est déjà payé [RMD-050, 057–059]. Le coût par | ||
| push de Bugbot peut rendre la revue continue prohibitive [RMD-056]. | ||
| Hypothèse de paiement : une équipe paiera pour un risque ou du temps senior | ||
| évité, pas pour « deux modèles ont parlé ». Elle doit être testée par pilote, | ||
| jamais inférée des tarifs concurrents. | ||
| ### Confidentialité | ||
| « Local » décrit l'orchestrateur et le journal, pas le transit. Le plan ou le | ||
| code quitte la machine vers chaque reviewer cloud. CodeRabbit documente un | ||
| partage avec OpenAI/Anthropic ; Bito clone puis transmet du contexte ; Claude | ||
| Code Review managé est indisponible en Zero Data Retention ; plusieurs outils | ||
| proposent opt-out, BYOK ou moteur local [RMD-003, 014, 020, 028, 032]. | ||
| Une promesse honnête doit séparer : | ||
| 1. stockage du journal ; | ||
| 2. transit du contenu ; | ||
| 3. rétention et entraînement par fournisseur ; | ||
| 4. possibilité de routage local ; | ||
| 5. multiplication du périmètre avec chaque reviewer. | ||
| ## Coût de substitution et garanties | ||
| | Garantie | Skill seul | Hook + script | SDK / produit spécialisé | Inspectrum aujourd'hui | Différentiel non prouvé | | ||
| |---|---|---|---|---|---| | ||
| | déclenchement | volontaire/probabiliste | déterministe par hôte | déterministe | déterministe sur `ExitPlanMode` Claude | portabilité réelle entre hôtes | | ||
| | contrat de sortie | convention | JSON possible | typé courant | Zod + structured MCP | stabilité sémantique et migrations | | ||
| | attribution | faible | complète si journalisée | agents/traces | reviewer attribué | modèle/version/effort au niveau du finding | | ||
| | trace | chat/fichier | artefact complet | tracing/checkpoints | session Markdown locale | replay, disposition humaine et historique calibré | | ||
| | échec | implicite | à coder | retries/branches | fail-open du gate | politique adaptée au risque et état partiel normalisé | | ||
| | budget | prompt | délai/coût/process | limites natives | timeout et tours | escalade adaptative à valeur marginale mesurée | | ||
| | reproductibilité | faible | moyenne | moyenne | hash/cache partiels | variance et fixtures réalistes versionnées | | ||
| | humain | manuel | explicite | interruptions/checks | approbation finale conservée | présentation qui réduit le temps de décision | | ||
| Le produit actuel combine utilement plusieurs cases. Mais chaque case est | ||
| copiable ; seule leur performance historique, mesurée sur des cas réels, peut | ||
| devenir coûteuse à reproduire. | ||
| Aucune source du ledger ne prouve qu'un système unique réunit déjà ces | ||
| garanties sur plusieurs harnais, ni qu'Inspectrum les exécute mieux. La | ||
| « garantie portable » est donc une **hypothèse intégrée à tester**, construite à | ||
| partir de primitives disponibles séparément — pas un différentiel actuel | ||
| validé. | ||
| ## Risques de substitution à 12 et 24 mois | ||
| ### Prévision à 12 mois — juillet 2027 | ||
| **Inférences, confiance moyenne à forte :** | ||
| - skills et instructions multi-clients convergent davantage ; la copie du | ||
| workflow devient moins chère ; | ||
| - hooks, sorties typées, sous-agents et revues de diff/PR deviennent standards | ||
| dans les grands harnais ; | ||
| - OpenAI, Anthropic, GitHub, Cursor et GitLab ajoutent budgets, provenance et | ||
| filtres anti-bruit à leurs revues ; | ||
| - les SDK absorbent reprise, approbation et observabilité ; aucune valeur | ||
| durable dans un graphe reviewer/juge ; | ||
| - les seconds avis cross-vendor restent optionnels et activés par risque, comme | ||
| l'Oracle d'Amp, car coût et latence empêchent un déclenchement universel ; | ||
| - MCP/A2A améliorent la portabilité mais élargissent les risques de confiance et | ||
| de supply chain. | ||
| Fonctions copiables rapidement : nouveau backend, juge, agents parallèles, | ||
| sortie JSON, timeout, hook, résumé, stockage Markdown et plugin. | ||
| Actifs encore plausiblement défendables : corpus de défauts confirmés, | ||
| calibration par modèle/version/tâche, mesure de corrélation, historique de | ||
| disposition humaine et routage coût/qualité basé sur ces données. | ||
| ### Prévision à 24 mois — juillet 2028 | ||
| **Inférences, confiance moyenne :** | ||
| - le « plan » discret peut reculer face aux agents continus et aux exécutions | ||
| longues ; un produit lié uniquement à `ExitPlanMode` risque l'obsolescence ; | ||
| - la frontière durable se déplace du nom de l'artefact vers un **point de | ||
| décision risqué** : avant migration, mutation de données, déploiement, | ||
| paiement, authentification ou merge ; | ||
| - les plateformes natives peuvent copier provenance, budget et replay ; elles | ||
| possèdent l'UX et la distribution ; | ||
| - une couche indépendante ne survit que si elle prouve une calibration | ||
| inter-fournisseurs supérieure, une politique commune multi-harnais ou un | ||
| dossier de conformité/audit que les plateformes ne veulent pas partager ; | ||
| - sans données et usage récurrent, Inspectrum devient au mieux une petite | ||
| utilité open source ; sans gain net mesuré, il doit être maintenu en mode | ||
| minimal ou arrêté. | ||
| ## Comparaison avec la roadmap héritée | ||
| Cette section est un constat historique sur la roadmap antérieure ; elle | ||
| n'autorise aucun travail. Les décisions actives vivent uniquement dans la | ||
| [thèse](moat-thesis.md), la | ||
| [roadmap d'exécution](outcome-moat-roadmap-post-0.2.2.md) et le | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md). | ||
| La roadmap locale observée sur | ||
| `chore/growth-combined-validation` au commit `2f1561b` choisissait déjà la revue | ||
| de plan Claude→Codex, puis proposait résilience, changements, gates locaux et | ||
| pull requests. Elle avait correctement identifié l'attribution, le fail-open, | ||
| le fallback et la validation humaine. | ||
| Cette recherche modifie trois décisions : | ||
| 1. **Le créneau plan n'est plus présumé valide.** Il doit battre le témoin | ||
| skill + hook + un modèle fort avec outils, à budget égal. | ||
| 2. **La revue de code/commit/PR n'est plus la suite automatique.** Codex couvre | ||
| le commit ; Claude/Copilot/Cursor/GitLab et les spécialistes dominent les PR. | ||
| 3. **Le moat n'est pas l'arbitrage multi-fournisseur.** C'est, au mieux, la | ||
| donnée de calibration et l'assurance mesurée accumulée à travers versions et | ||
| harnais. | ||
| Le travail de distribution 0.2.2 reste séparé et n'est ni modifié ni | ||
| cherry-pické. Cette contre-analyse porte uniquement sur l'après-publication. | ||
| ## Signaux historiques repris par les décisions actives | ||
| Cette synthèse est explicative, pas normative. Les seuils et horloges vivent | ||
| uniquement dans le | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md) ; les règles de | ||
| portefeuille vivent uniquement dans la | ||
| [roadmap d'exécution](outcome-moat-roadmap-post-0.2.2.md). | ||
| Les signaux de risque identifiés par la recherche sont : | ||
| - un harnais majeur fournit une revue de plan cross-vendor native avec preuve, | ||
| budget et humain final ; | ||
| - le second fournisseur n'ajoute pas de défauts majeurs confirmés à budget égal | ||
| face à un modèle fort + outils ; | ||
| - la réutilisation parmi les utilisateurs réellement réexposés échoue à la | ||
| porte P3 ; | ||
| - le temps de triage ajouté dépasse le rework évité ; | ||
| - le plan cesse d'être une étape distincte dans les usages cibles ; | ||
| - un substitut de moins de 100 lignes produit une utilité statistiquement | ||
| indistinguable. | ||
| Ces critères ont rendu la suite falsifiable. Le créneau actif et l'expérience | ||
| la moins coûteuse pour le réfuter sont maintenant définis dans les trois | ||
| documents de décision liés ci-dessus. |
| # Protocole de preuve post-0.2.2 | ||
| État : protocole expérimental défini le 30 juillet 2026, état contrôlé le | ||
| 1er août 2026. **Aucune porte P1, P2 ou P3 n'a encore réussi ; le gain net de | ||
| fiabilité inter-fournisseurs et le moat fondé sur les preuves restent non | ||
| prouvés.** Ce document contient uniquement | ||
| les trois portes qui autorisent ou arrêtent les investissements fondés sur un | ||
| gain inter-fournisseurs. La | ||
| [roadmap d'exécution](outcome-moat-roadmap-post-0.2.2.md) reste l'unique source | ||
| pour le produit, le calendrier et la croissance. | ||
| Le positionnement public et les travaux à faible regret de la Phase B peuvent | ||
| avancer sans attendre ces portes. P1 et P2 utilisent une baseline 0.2.2 figée | ||
| et versionnée. P3 mesure le build de Phase B publié, puis figé et versionné | ||
| avant le premier utilisateur. Une capacité développée en parallèle n'entre pas | ||
| silencieusement dans un bras mesuré. | ||
| L'horloge commence à l'ouverture écrite de la Phase C. Le premier passage P1 à | ||
| P3 tient dans 18 semaines. Une seule reprise par porte est autorisée et le | ||
| protocole entier s'arrête au plus tard à 26 semaines. Au-delà, la décision est | ||
| `STOP` ou `MAINTENANCE`, jamais une prolongation silencieuse. | ||
| ## Définitions | ||
| - **Cas admissible :** tâche à risque dont l'issue peut être établie par un | ||
| test rouge, un rollback, un incident, un correctif causal, un invariant | ||
| déterministe ou une adjudication indépendante. | ||
| - **Cas apparié :** même paquet de plan, contexte, tests et preuves présenté | ||
| aux deux conditions comparées. | ||
| - **Cas adjudiqué :** cas dont les constats ont été codés par un reviewer | ||
| non-auteur selon la grille pré-enregistrée. | ||
| - **Cas publiable :** cas admissible, assaini et partagé avec consentement. | ||
| Un cas peut être admissible à l'expérience sans être publiable. Les volumes de | ||
| 30 à 50 cas en P1, 120 à 150 cas en P2 et 12 utilisateurs en P3 répondent à des | ||
| questions différentes ; ils ne s'additionnent pas en un « data moat ». | ||
| ## P1 : test de décorrélation plan | ||
| Objectif : tuer rapidement l'hypothèse « autre fournisseur = angle mort | ||
| utile ». | ||
| ### Jeu de cas | ||
| - 30 à 50 plans historiques à issue connue ; | ||
| - inclure seulement les plans satisfaisant au moins un déclencheur de risque | ||
| pré-enregistré ; | ||
| - privilégier migrations, authentification, paiement, données et | ||
| compatibilité ; | ||
| - conserver original, issue ex post et transformation assainie ; | ||
| - inclure des plans corrects pour mesurer les faux positifs ; | ||
| - exclure les plans dont l'issue ne peut pas être établie. | ||
| Une opinion du créateur du plan ne suffit pas comme vérité terrain. | ||
| La préparation peut prendre jusqu'à deux semaines avant les deux jours | ||
| d'exécution. Si 30 cas admissibles et adjudicables ne sont pas disponibles, P1 | ||
| est `STOP`, sans prolongation indéfinie. | ||
| Deux évaluateurs sont sélectionnés avant les sorties pour leur expérience du | ||
| domaine. Ils déclarent leurs conflits, n'ont écrit ni Inspectrum ni le | ||
| protocole et restent aveugles à l'identité du bras. Ils codent indépendamment | ||
| au moins 20 % des cas ; accord brut et kappa de Cohen sont publiés. | ||
| `κ < 0,60` interdit tout calcul de décision. La seule révision autorisée, | ||
| pré-enregistrée avant les sorties, porte sur une catégorie que les deux | ||
| évaluateurs ont indépendamment marquée ambiguë ; elle ne change ni seuil ni | ||
| sévérité. Le lot entier est alors recodé une fois, avec un nouvel échantillon | ||
| double-codé. Si `κ` reste inférieur à 0,60, P1 est `STOP`. Les désaccords | ||
| restants au-dessus du seuil vont à un troisième arbitre indépendant. | ||
| ### Protocole | ||
| Un test purement opérationnel, sans cas d'issue ni mesure de qualité, doit | ||
| d'abord montrer qu'une configuration atteint la cible de latence P3. Cette | ||
| configuration est ensuite pré-enregistrée et ne change plus. Si aucune | ||
| configuration ne tient la cible, P1 est `STOP` avant collecte. | ||
| 1. pré-enregistrer prompts, modèles, versions, effort, budget, classes de | ||
| défaut et grille de sévérité ; | ||
| 2. lancer Claude et Codex séparément, sans voir l'autre sortie ; | ||
| 3. randomiser l'ordre de présentation aux évaluateurs ; | ||
| 4. faire normaliser manuellement les constats, indépendamment, par les deux | ||
| évaluateurs non-auteurs avec une grille figée ; l'arbitre tranche les | ||
| désaccords, sans juge qui vote ni kit de calibration produit ; | ||
| 5. mesurer recouvrement, erreurs confirmées uniques, faux positifs, minutes de | ||
| triage, latence et échecs ; | ||
| 6. publier méthode et résultats négatifs avec les cas qui peuvent l'être. | ||
| Cette porte est directionnelle : elle ne permet pas d'affirmer une précision | ||
| universelle. | ||
| ### Décision | ||
| `GO P2` seulement si : | ||
| - recouvrement des objections confirmées inférieur ou égal à 70 % ; | ||
| - au moins 10 % des cas reçoivent une contribution marginale confirmée ; | ||
| - au moins 15 % des défauts utiles sont supplémentaires ; | ||
| - les intervalles bootstrap pré-enregistrés à 90 % excluent zéro gain pour ces | ||
| deux mesures ; | ||
| - faux positifs et triage ne rendent pas l'utilité nette négative. | ||
| `STOP` si : | ||
| - recouvrement supérieur à 70 % sans utilité marginale ; | ||
| - aucun défaut majeur unique confirmé ; | ||
| - objections non falsifiables ; | ||
| - coût du test supérieur au rework historique plausible. | ||
| Si P1 s'arrête, Inspectrum reste une utilité locale de seconde opinion. Les | ||
| Phases D et E de la roadmap ne démarrent pas. | ||
| ## P2 : comparaison à budget égal | ||
| Objectif : battre le meilleur substitut raisonnable, pas une absence de revue. | ||
| ### Porte de faisabilité | ||
| P2 ne démarre que lorsque 120 cas admissibles au minimum sont inventoriés, | ||
| dédupliqués et auditables. Les sources permises sont : | ||
| - cas historiques privés avec consentement du propriétaire ; | ||
| - issues, correctifs, pull requests ou post-mortems publics sous licence | ||
| compatible ; | ||
| - cas contribués volontairement avec droit d'usage explicite. | ||
| Les cas utilisés en P1 sont exclus de P2 et du test court qui choisit la | ||
| baseline. P2 utilise des sessions fraîches sur un lot distinct pour éviter une | ||
| sélection influencée par les résultats du premier test. | ||
| La provenance et l'ordre d'éligibilité sont pré-enregistrés pour empêcher la | ||
| sélection favorable. Deux évaluateurs non-auteurs et un arbitre de désaccord | ||
| sont engagés avant le premier run ; leur rémunération, leurs conflits et leur | ||
| disponibilité sont documentés. Aucun travail gratuit n'est supposé. | ||
| L'étude P1 à P3 dispose d'une enveloppe ponctuelle distincte du budget de | ||
| maintenance et de croissance : au plus 100 heures d'opération, 100 heures | ||
| cumulées d'évaluation externe, 10 000 euros de rémunération externe et 1 000 | ||
| euros de modèles ou d'infrastructure. | ||
| Les minutes attendues par cas sont pré-enregistrées. Chaque plafond est un | ||
| maximum, pas un budget à consommer ; son épuisement pendant l'étude produit | ||
| `STOP`, sans rallonge. Si les cas, les évaluateurs ou le financement ne sont | ||
| pas sécurisés dans l'horloge de 18 semaines, la décision est aussi `STOP`, sans | ||
| construire d'automatisation pour compenser. | ||
| ### Deux bras seulement | ||
| Sur environ 120 à 150 cas appariés : | ||
| - **A, meilleur substitut :** meilleure configuration du même fournisseur | ||
| parmi second passage critique, sous-agent en lecture seule avec outils et | ||
| tests, ou déclenchement par skill, hook ou intégration continue ; | ||
| - **B, Inspectrum :** second passage d'un autre fournisseur sur le même paquet | ||
| de preuves figé, avec le skill ou hook 0.2.2 inchangé. | ||
| Les deux bras reçoivent le même plan, contexte, sorties de tests et artefacts | ||
| déterministes. Aucun ne produit de nouveau test pendant la mesure principale ; | ||
| l'effet de tests supplémentaires est mesuré séparément. | ||
| « Même budget » signifie, par cas, un plafond pré-enregistré identique de coût | ||
| fournisseur équivalent, de contexte et de temps opérateur. La latence murale | ||
| reste une mesure. Les quotas d'abonnement reçoivent un prix implicite publié. | ||
| La configuration A est choisie avant P2 par un test court sur des cas de | ||
| calibration exclus de l'analyse, avec la même grille d'utilité. Une seule | ||
| configuration gagnante entre dans les deux bras. | ||
| Ces configurations sont des artefacts jetables d'expérience : elles ne sont | ||
| ni distribuées ni réutilisées comme produit. Recette, version et résultats | ||
| assainis sont archivés pour reproductibilité. | ||
| Pas de comité à quatre bras, de débat ou de juge obligatoire. Un troisième | ||
| bras exige un calcul de puissance et une nouvelle pré-inscription. | ||
| ### Mesures | ||
| Mesures principales : | ||
| - défauts majeurs confirmés uniques ; | ||
| - précision utile : constats acceptés et confirmés / constats triés ; | ||
| - minutes de triage par constat confirmé ; | ||
| - coût marginal par défaut confirmé ; | ||
| - rework évité selon une grille pré-enregistrée ; | ||
| - taux de runs échoués, partiels ou sautés. | ||
| Mesures secondaires : | ||
| - accord ou corrélation par classe de tâche ; | ||
| - variance entre répétitions ; | ||
| - latence p50 et p95 ; | ||
| - capacité d'un test ou outil déterministe à remplacer le reviewer. | ||
| Le suivi principal dure deux à quatre semaines, puis une fenêtre de maturation | ||
| de deux semaines capte correctifs, rollbacks et rework tardifs. Preuves, | ||
| prompts, hook, versions et séparation de l'effet des tests sont figés avant le | ||
| premier cas. | ||
| ### Décision | ||
| `GO P3` seulement si B produit une utilité nette positive et un gain matériel | ||
| pré-enregistré sur A : | ||
| - au moins 10 % des cas avec défaut majeur marginal ; | ||
| - au moins 15 % de défauts utiles supplémentaires ; | ||
| - intervalles bootstrap à 90 % excluant zéro gain ; | ||
| - aucune hausse supérieure du triage. | ||
| `REVISE` une fois si le protocole découvre un défaut de mesure corrigeable sans | ||
| changer la question. Une seconde reprise est interdite. | ||
| `STOP` si : | ||
| - les intervalles restent compatibles avec aucun gain utile ; | ||
| - triage ou latence annule le rework évité ; | ||
| - tests ou outils déterministes expliquent le gain ; | ||
| - le résultat dépend d'un seul modèle ou disparaît à la version suivante ; | ||
| - la baseline skill ou hook est indistinguable. | ||
| ### Couture P2 vers P3 | ||
| Avant le premier utilisateur P3, le build publié de Phase B est rejoué sur | ||
| l'ensemble du corpus P2 figé. Les modèles, prompts, efforts, délais et entrées | ||
| reviewer restent identiques ; seuls l'enveloppe de preuve, les états et la | ||
| disposition humaine peuvent différer. | ||
| Le replay doit conserver les seuils de gain et d'utilité nette de P2, nommer | ||
| exactement chaque état dégradé et mesurer p50/p95. Toute modification de | ||
| modèle, prompt, effort ou délai invalide le protocole courant et produit | ||
| `STOP`, sans consommer ni créer une reprise. Si la qualité régresse ou si la | ||
| latence P3 reste hors seuil, la décision est aussi `STOP`. Aucun réglage n'est | ||
| effectué après le gel du build P3. | ||
| ## P3 : pilote comportemental et commercial | ||
| Objectif : vérifier que l'effet mesuré devient un comportement récurrent sans | ||
| affaiblir la vigilance humaine. | ||
| ### Cohorte et parcours | ||
| - 12 utilisateurs externes ciblés ; | ||
| - gratuit pendant six semaines ; | ||
| - autorité et consentement sur les plans utilisés ; | ||
| - tâches à haut risque sélectionnées explicitement ; | ||
| - support d'installation sans collecte silencieuse ; | ||
| - au plus six contacts existants et au moins six recrutements froids, avec | ||
| résultats rapportés séparément. | ||
| ```text | ||
| invitation ciblée | ||
| -> installation publique | ||
| -> doctor | ||
| -> première session verte | ||
| -> disposition de chaque constat | ||
| -> confirmation ex post | ||
| -> nouvelle exposition à une tâche risquée | ||
| -> deuxième utilisation ou skip explicite | ||
| ``` | ||
| ### Mesures | ||
| Activation : | ||
| - au moins 70 % des accompagnés atteignent une session verte ; | ||
| - médiane installation vers valeur inférieure à 10 minutes ; | ||
| - moins de 20 % d'échecs opérationnels. | ||
| Usage : | ||
| - au moins huit utilisateurs sont réexposés à une tâche à risque ; | ||
| - au moins 50 % des réexposés réutilisent le checkpoint sous six semaines et | ||
| la borne basse unilatérale de Wilson à 80 % reste au moins à 20 % ; | ||
| - le skip volontaire est suivi ; | ||
| - p50 inférieur ou égal à 45 secondes et p95 inférieur ou égal à 120 secondes. | ||
| Vigilance : | ||
| - demander une décision de risque avant la revue ; | ||
| - ne jamais afficher un vert sans preuve et statut complet ; | ||
| - comparer temps et justification d'approbation avant et après ; | ||
| - faire coder les décisions par un tiers non impliqué, aveugle au bras lorsque | ||
| les traces le permettent ; | ||
| - arrêter si, dans au moins deux cas confirmés ou 10 % des cas observables, le | ||
| vert accélère l'acceptation sans vérification ou augmente la confiance alors | ||
| que l'exactitude baisse. | ||
| Valeur : | ||
| - défauts majeurs confirmés uniques ; | ||
| - rework évité avec preuve ex post ; | ||
| - minutes de triage ; | ||
| - cas exportés volontairement. | ||
| Paiement : | ||
| - après trois usages ou à la sixième semaine, présenter une offre réelle ; | ||
| - prix exploratoire de 10 à 20 euros par mois ou pilote équipe payé ; | ||
| - servir l'offre manuellement avec la baseline gelée, sans automatisation | ||
| nouvelle, et rembourser si la garantie annoncée n'est pas tenue ; | ||
| - le paiement pour une seconde opinion générique valide seulement cette | ||
| utilité, pas le moat de confiance ; | ||
| - comparer à prix égal seconde opinion générique et garantie inter-fournisseurs | ||
| avec provenance, échec visible, cas adjudiqués et calibration publique. | ||
| ### Décision | ||
| `GO` vers les Phases D et E seulement si qualité, comportement et vigilance | ||
| passent. | ||
| `REVISE` une fois si moins de huit utilisateurs sont réexposés à la sixième | ||
| semaine. | ||
| `STOP PRODUIT` si : | ||
| - récurrence inférieure à 20 % sur au moins huit réexposés ; | ||
| - fausse confiance au seuil défini ; | ||
| - activation inférieure à 40 %. | ||
| La décision commerciale est indépendante : | ||
| - `OFFRE PAYANTE` seulement si au moins cinq personnes ont réellement accepté | ||
| de payer et au moins trois préfèrent la garantie inter-fournisseurs ; | ||
| - `OPEN SOURCE` si ce seuil manque : aucune offre payante ni automatisation | ||
| commerciale, sans annuler un éventuel `GO` produit ; | ||
| - un pilote équipe isolé ne suffit pas sans cinq décisions payantes | ||
| individuelles. | ||
| ## Tableau go/no-go complet | ||
| | Signal | Go | Revise | Stop ou maintenance | | ||
| |---|---|---|---| | ||
| | version publique | alignée, parcours réel vert | blocage d'activation corrigeable | dérive ou échec silencieux | | ||
| | décorrélation | ≤70 % + deux seuils marginaux + intervalles >0 | protocole ambigu | >70 % sans gain ou un seuil absent | | ||
| | qualité face à la baseline | gain pré-enregistré, utilité nette positive | mesure corrigeable une fois | indistinguable ou négative | | ||
| | activation | ≥70 %, <10 min | 40 à 69 % | <40 % ou >20 min | | ||
| | récurrence exposée | ≥50 %, n≥8, borne Wilson ≥20 % | n<8 ou signal incertain | <20 % avec n≥8 | | ||
| | vigilance | stable ou améliorée | signal ambigu | fausse confiance | | ||
| | latence | p50 ≤45 s, p95 ≤120 s | défaut de mesure corrigeable avant le gel | cible manquée après le gel | | ||
| | paiement et garantie | offre payante si ≥5 payants dont ≥3 préfèrent la garantie | paiement générique ou pilote seul | aucune offre payante ; maintien open source | |
Sorry, the diff of this file is too big to display
| # Boucle de croissance GitHub d'Inspectrum | ||
| État : plan post-publication 0.2.2, mis à jour le 1er août 2026. Les chiffres | ||
| sont des instantanés datés, pas des preuves de qualité, de fiabilité ou de moat. | ||
| ## Point de départ | ||
| | Signal | Valeur observée | Lecture | | ||
| |---|---:|---| | ||
| | étoiles GitHub | 2 | découverte presque inexistante | | ||
| | visiteurs uniques sur 14 jours | 9 | trop peu pour mesurer une conversion | | ||
| | cloneurs uniques sur 14 jours | 8 | signal faible, mais plus proche de l'essai | | ||
| | référents GitHub visibles | 0 | aucun canal organique identifié | | ||
| | téléchargements npm sur 30 jours | 430 | concentrés autour des releases, donc non assimilables à des utilisateurs | | ||
| | téléchargements de l'actif MCPB 0.2.1 | 7 | usage Desktop encore marginal | | ||
| Sources : | ||
| - <https://github.com/yannmenec/inspectrum> | ||
| - <https://api.npmjs.org/downloads/range/last-month/inspectrum> | ||
| - API de trafic GitHub du dépôt, visible par son propriétaire. | ||
| Ordres de grandeur concurrents observés le même jour : PR-Agent dépasse | ||
| 12 000 étoiles, Roo Code 24 000, Aider 47 000, Cline 65 000, OpenHands 82 000, | ||
| OpenCode 191 000 et Hermes Agent 222 000. Ces nombres mesurent surtout leur | ||
| distribution ; l'avantage produit d'Inspectrum reste à démontrer. | ||
| ## Rôle des étoiles | ||
| Une étoile GitHub signifie : « je veux retrouver, suivre ou soutenir ce | ||
| projet ». Elle ne prouve ni installation, ni activation, ni rétention. | ||
| La hiérarchie des mesures est : | ||
| 1. checkpoint à risque avec statut exact et décision humaine ; | ||
| 2. installation externe réussie ; | ||
| 3. cas, retour ou contribution externe ; | ||
| 4. étoile GitHub ; | ||
| 5. impression, vue ou téléchargement brut. | ||
| Une campagne est saine seulement si les niveaux 1 à 3 progressent avec les | ||
| étoiles. | ||
| ## Boucle composée | ||
| ```text | ||
| tâche réelle à risque | ||
| → checkpoint Inspectrum | ||
| → preuve ou échec visible | ||
| → cas assaini et consentant | ||
| → benchmark / comparaison / démonstration | ||
| → découverte GitHub | ||
| → étoile qualifiée | ||
| → installation | ||
| → nouvelle tâche réelle à risque | ||
| ``` | ||
| La boucle peut produire simultanément distribution et actif candidat. Un | ||
| article sans cas réel crée une pointe de trafic ; un cas confirmé peut aussi | ||
| enrichir la calibration. Aucun de ces effets n'est encore prouvé. | ||
| ## Ce qui mérite une étoile | ||
| La page d'accueil doit répondre, dans cet ordre : | ||
| 1. quel risque est évité ; | ||
| 2. quand Inspectrum intervient ; | ||
| 3. pourquoi un skill seul peut être insuffisant ; | ||
| 4. ce qui se passe si la revue échoue ; | ||
| 5. quelle donnée quitte la machine ; | ||
| 6. comment obtenir une première preuve en moins de 10 minutes ; | ||
| 7. quel cas réel confirme ou réfute la valeur. | ||
| Actifs nécessaires : | ||
| - démonstration réelle de 60 à 90 secondes ; | ||
| - schéma animé ou capture du checkpoint ; | ||
| - cas positif, résultat nul et panne visible ; | ||
| - comparaison honnête avec skill/hook, Amp Oracle et revue native ; | ||
| - commande d'installation copiée une seule fois ; | ||
| - exemple de session lisible sans installer ; | ||
| - badges limités à version, tests, couverture, sécurité et licence ; | ||
| - `CONTRIBUTING.md` avec une contribution de moins de 30 minutes. | ||
| ## Jalons | ||
| | Horizon | Repère de distribution | Preuve qui doit accompagner les étoiles | | ||
| |---|---:|---| | ||
| | 14 jours | 15 étoiles | 5 installations externes, 3 retours distincts | | ||
| | 30 jours | 25 | 10 installations, 3 cas ou issues utiles | | ||
| | 90 jours | 100 | 25 activations, 10 cas, 3 contributeurs externes | | ||
| | 6 mois | 250 | 50 activations, 30 cas, 5 contributeurs | | ||
| | 12 mois | 500 | 100 activations, résultat du protocole publié, 10 contributeurs | | ||
| Ces repères dimensionnent seulement le budget de distribution à partir d'une | ||
| base trop faible pour établir une prévision. Aucune cible d'étoiles n'est un | ||
| critère de sortie d'une phase produit. Elle n'autorise ni spam, ni achat, ni | ||
| concours sans rapport avec le produit. | ||
| ## Séquence de lancement | ||
| ### État public au 1er août 2026 | ||
| - npm 0.2.2 et la release GitHub sont disponibles ; | ||
| - le MCP Registry et Glama référencent Inspectrum ; | ||
| - la soumission Claude Community est en attente ; | ||
| - PulseMCP ne référence pas encore Inspectrum ; | ||
| - la capture terminal reste une preuve 0.2.1 et ne doit pas être présentée | ||
| comme une preuve 0.2.2. | ||
| ### J0 à J2 | ||
| - vérifier `doctor` et un checkpoint depuis un environnement vide avec la | ||
| version npm publique ; | ||
| - enregistrer une démonstration réelle ; | ||
| - publier la note de release centrée sur l'outcome ; | ||
| - mettre à jour description, aperçu social, sujets GitHub et README. | ||
| ### J3 à J7 | ||
| - soumettre aux catalogues MCP et Claude déjà préparés ; | ||
| - publier un cas réel assaini avec méthode, coût et limite ; | ||
| - contacter directement 10 à 20 mainteneurs concernés par migrations, | ||
| authentification, paiement ou données, sans message de masse ; | ||
| - demander un essai ou un cas, jamais une étoile isolée ; | ||
| - répondre à chaque problème d'installation le jour même. | ||
| ### Semaines 2 à 4 | ||
| - publier le résultat nul et l'échec visible ; | ||
| - proposer une comparaison reproductible avec un skill de moins de 100 lignes ; | ||
| - contribuer un guide aux communautés Claude Code, Codex et MCP ; | ||
| - candidater aux listes « awesome » pertinentes après validation publique ; | ||
| - transformer les questions répétées en documentation, pas en réponses privées. | ||
| ### Mois 2 à 3 | ||
| - publier le premier rapport de calibration ; | ||
| - lancer une issue « good first case » ; | ||
| - inviter des mainteneurs externes à contester le protocole ; | ||
| - publier les corrections et résultats négatifs aussi vite que les succès ; | ||
| - refaire un lancement seulement pour un nouvel actif de preuve, pas pour une | ||
| hausse mineure de version. | ||
| ## Canaux | ||
| Priorité : | ||
| 1. marketplace Claude Code, npm et registre MCP ; | ||
| 2. README, release GitHub et cas reproductibles ; | ||
| 3. communautés Claude Code, Codex, MCP et sécurité logicielle ; | ||
| 4. Reddit, Hacker News et YouTube lorsque le cas est démontrable ; | ||
| 5. listes « awesome », newsletters et mainteneurs d'outils ; | ||
| 6. comparaisons recherchées : skill, hook, Oracle, revue native. | ||
| Chaque publication pointe vers un artefact précis. Aucun message générique | ||
| « découvrez mon outil ». | ||
| ## Cadence soutenable | ||
| Budget normal : deux heures par semaine, hors semaine de release. | ||
| La fenêtre de lancement J0 à J14 dispose d'un budget exceptionnel maximal de | ||
| huit heures de distribution au total, puis revient au budget normal. Les | ||
| corrections produit de Phase A ont leur propre estimation et ne sont jamais | ||
| masquées dans ce budget. L'étude P1 à P3 possède l'enveloppe ponctuelle définie | ||
| dans le [protocole de preuve](evidence-protocol-post-0.2.2.md) ; aucune cible de | ||
| croissance ne suppose une adjudication gratuite. | ||
| - une preuve ou amélioration documentaire toutes les deux semaines ; | ||
| - un rapport de calibration par trimestre ; | ||
| - une seule démonstration maintenue ; | ||
| - une seule page de comparaison par alternative réellement rencontrée ; | ||
| - triage des issues deux fois par semaine ; | ||
| - aucune présence quotidienne obligatoire sur les réseaux ; | ||
| - automatiser collecte de métriques, contrôle de liens et génération des | ||
| tableaux datés. | ||
| Le plafond de deux jours par mois dans la roadmap concerne la maintenance du | ||
| produit. Si la croissance dépasse son propre budget de deux heures par semaine | ||
| pendant deux mois, couper le canal ou l'actif le moins corrélé aux | ||
| installations. | ||
| ## Tableau de bord minimal | ||
| Enregistrer chaque semaine : | ||
| - nouvelles étoiles, forks et contributeurs ; | ||
| - visiteurs et cloneurs uniques ; | ||
| - téléchargements npm et actifs de release, avec anomalies de CI séparées ; | ||
| - installations externes confirmées ; | ||
| - `doctor` verts rapportés ; | ||
| - cas soumis, acceptés, refusés et publiables ; | ||
| - temps médian vers la première valeur ; | ||
| - issues d'installation ouvertes et résolues ; | ||
| - provenance des visites lorsque GitHub la fournit. | ||
| Un CSV daté suffit. Pas de produit analytique ni de télémétrie embarquée. | ||
| Ratios utiles : | ||
| - étoiles / visiteurs uniques ; | ||
| - installations confirmées / cloneurs uniques ; | ||
| - cas utiles / installations confirmées ; | ||
| - contributeurs externes / étoiles ; | ||
| - étoiles accompagnées d'une activation / nouvelles étoiles. | ||
| Les ratios restent directionnels sur les petits volumes. | ||
| ## Interdits | ||
| - acheter, échanger ou automatiser des étoiles ; | ||
| - demander une étoile avant l'essai ; | ||
| - concours et cadeaux sans rapport avec un cas produit ; | ||
| - messages privés de masse ; | ||
| - cacher les faux positifs, pannes ou résultats nuls ; | ||
| - gonfler les téléchargements npm par automatisation ; | ||
| - ajouter une intégration uniquement pour profiter du nom d'un concurrent ; | ||
| - confondre communauté et support gratuit illimité. | ||
| ## Décisions | ||
| - étoiles en hausse, activations stables : corriger onboarding et message ; | ||
| - activations en hausse, étoiles faibles : améliorer preuve partageable et | ||
| découverte ; | ||
| - étoiles seules en hausse : arrêter le canal de curiosité concerné ; | ||
| - cas et contributeurs en hausse : investir dans le protocole et les outils de | ||
| contribution ; | ||
| - aucune installation externe après 30 jours : revenir au wedge et à la | ||
| démonstration avant toute fonctionnalité. |
| # Thèse de créneau et d'avantage défendable | ||
| État : thèse stratégique post-0.2.2, mise à jour le 1er août 2026 et fondée sur le | ||
| [paysage concurrentiel](competitive-landscape-2026-07.md) et son | ||
| [registre de 198 sources](evidence/competitive-source-ledger.csv), consultées | ||
| le 30 juillet 2026. | ||
| ## Décision en une phrase | ||
| **Créneau principal à tester : un checkpoint d'assurance avant l'exécution | ||
| d'une tâche agentique à haut risque, activé aujourd'hui à la sortie du plan, | ||
| qui montre les preuves et désaccords d'un reviewer indépendant sans supprimer | ||
| la décision humaine.** | ||
| Ce créneau utilise l'actif déjà construit sans prétendre que le « plan » ou le | ||
| « multi-modèle » est durable. Son avantage actuel est une intégration pratique, | ||
| pas un moat. Un avantage potentiel serait une position de tiers neutre et un | ||
| historique de calibration : quels reviewers, versions et politiques trouvent | ||
| quels défauts confirmés, à quel coût et avec quelle corrélation. À la taille | ||
| actuelle, ce n'est pas encore un actif défendable. | ||
| ## Décision d'exécution du 30 juillet 2026 | ||
| La publication de 0.2.2 est vérifiée sur npm et GitHub ; le MCP Registry et | ||
| Glama exposent aussi Inspectrum. Le positionnement est donc adopté sans | ||
| attendre les expériences de gain marginal ou le pilote commercial : | ||
| > **Inspectrum est le contrôle pré-vol indépendant avant qu'un agent exécute | ||
| > un changement difficile à annuler. Il garde les preuves, désaccords et | ||
| > échecs visibles. L'humain décide.** | ||
| Cette décision change le positionnement, pas le niveau de preuve. Le moat reste | ||
| une cible, jamais une affirmation publique. Au 1er août 2026, aucune porte du | ||
| protocole n'a réussi et les expériences n'ont pas prouvé de gain net de | ||
| fiabilité. Si elles sont lancées, elles alimenteront le corpus, la calibration | ||
| et le routage qui pourraient rendre la cible défendable. | ||
| Trois documents transforment cette décision en exécution : | ||
| - [roadmap orientée résultats et moat](outcome-moat-roadmap-post-0.2.2.md) ; | ||
| - [protocole de preuve et portes d'arrêt](evidence-protocol-post-0.2.2.md) ; | ||
| - [boucle de croissance GitHub](github-star-growth-loop.md). | ||
| Les travaux à faible regret peuvent commencer après 0.2.2 : positionnement, | ||
| activation, contrat de preuve, provenance, états dégradés, disposition humaine, | ||
| export assaini. Aucun nouvel adaptateur d'hôte ne démarre avant le `GO` du | ||
| protocole. Les extensions pull request, pair programming et débat multi-tours | ||
| restent hors portefeuille. | ||
| ## Contre-thèse la plus forte | ||
| Un développeur compétent n'a pas besoin d'Inspectrum. Il peut écrire : | ||
| ```text | ||
| AGENTS.md / SKILL.md | ||
| → hook natif de fin de plan ou Stop | ||
| → un modèle fort avec tests/outils | ||
| → éventuellement un second appel headless | ||
| → JSON + délai + artefacts | ||
| → décision humaine | ||
| ``` | ||
| Cette solution demande environ quelques heures pour une revue volontaire et un | ||
| à trois jours pour un gate journalisé. Elle utilise les abonnements et les | ||
| interfaces déjà installés, évite une nouvelle configuration et s'adapte mieux | ||
| au harnais principal. Amp offre déjà un Oracle d'un autre fournisseur ; Claude, | ||
| Codex, Copilot, Gemini, Cline et Windsurf offrent les briques de hook, review ou | ||
| sous-agent. Les SDK offrent graphes, budgets, reprise et traces. | ||
| La recherche ne prouve pas non plus le mécanisme causal vendu par le produit : | ||
| - fournisseur différent ne signifie pas erreur indépendante ; | ||
| - le meilleur juge seul peut égaler un panel sur des tâches hors revue de code ; | ||
| - l'étude multi-agent la plus actuelle trouve 0,0 % de gain agrégé moyen sur | ||
| six benchmarks et cinq architectures, avec forte variation ; | ||
| - tests et critique mono-modèle outillée peuvent produire le même gain à | ||
| moindre coût ; | ||
| - la revue de code actuelle souffre déjà de faux positifs et de fatigue. | ||
| Conclusion honnête : **l'utilité de réduire le copier-coller est réelle ; le | ||
| gain de fiabilité net ne l'est pas encore.** Si l'expérience ne mesure pas ce | ||
| gain, Inspectrum doit rester une petite utilité open source ou cesser | ||
| d'élargir son produit. | ||
| ## Utilisateurs et tâches à accomplir | ||
| ### Segment initial | ||
| Développeur indépendant, mainteneur ou petite équipe qui : | ||
| - utilise déjà Claude Code et Codex, ou deux harnais de fournisseurs distincts ; | ||
| - fait des changements où une erreur de plan entraîne migration ratée, | ||
| corruption de données, faille d'authentification, incident de paiement, | ||
| rupture de compatibilité ou plusieurs heures de rework ; | ||
| - garde une approbation humaine et accepte une latence supplémentaire seulement | ||
| sur les tâches à risque ; | ||
| - peut partager volontairement un résumé assaini du résultat pour un pilote. | ||
| Ce n'est pas le bon produit pour une petite correction évidente, une équipe | ||
| mono-harnais satisfaite de sa revue native ou une organisation qui interdit | ||
| l'envoi du même contenu à plusieurs fournisseurs. | ||
| ### Tâche à accomplir principale | ||
| > Avant d'autoriser mon agent à exécuter une décision coûteuse à inverser, | ||
| > donne-moi un second signal borné, attribué et vérifiable, puis montre-moi | ||
| > clairement ce qui a échoué ou divergé pour que je décide vite. | ||
| ### Tâches secondaires | ||
| - conserver une preuve minimale de ce qui a été relu, par quel modèle et à | ||
| quelle version ; | ||
| - éviter de repayer une revue inchangée ; | ||
| - savoir quand la revue n'a pas eu lieu ou n'est que partielle ; | ||
| - apprendre quels reviewers valent leur latence sur les tâches réelles du | ||
| projet. | ||
| ## Les cinq surfaces, décidées séparément | ||
| ### 1. Revue de plan entre modèles — créneau principal expérimental | ||
| | Dimension | Décision | | ||
| |---|---| | ||
| | Douleur | une hypothèse erronée validée avant implémentation peut provoquer un rework disproportionné | | ||
| | Alternative native/bricolée | skill + appel headless ; hook `ExitPlanMode`/`Stop` ; sous-agent reviewer ; Amp Oracle | | ||
| | Valeur différentielle | activation certaine au bon moment, état d'échec visible, input hashé, preuves/désaccords, attribution, humain final | | ||
| | Coût de substitution | <2 h volontaire ; 1–3 jours pour hook + JSON + logs ; maintenance récurrente moyenne | | ||
| | Latence/coût | une inférence supplémentaire ; effort maximal observé ici entre 126 et 226 s sur prompts bornés, et deux échecs à 10 min ; produit cible bien plus court | | ||
| | Confidentialité | plan transmis à chaque provider cloud ; journal local n'élimine pas le transit | | ||
| | Produit minimum désirable | un reviewer indépendant, un tour, activation par risque, sortie « must fix / information / dissent », skip/failure explicite, pas de juge opaque | | ||
| | Preuve requise | défauts majeurs confirmés uniques **ex post**, rework évité, triage, latence, coût, vigilance humaine et réutilisation par exposition | | ||
| | Dépendances | cas historiques à issue connue, test/rollback/correctif/incident ou adjudication indépendante, capture modèle/version/effort, baseline skill/hook | | ||
| | Abandon | échec d'une porte du protocole, fausse confiance ou disparition du plan discret | | ||
| Pourquoi principal : le produit et sa distribution existent déjà ; la frontière | ||
| avant exécution est claire ; l'expérience peut se faire sans nouvelle | ||
| architecture. Pourquoi seulement expérimental : le hook est copiable et la | ||
| demande récurrente n'est pas prouvée. | ||
| ### 2. Revue de changements entre modèles — instrumentation, pas extension produit | ||
| | Dimension | Décision | | ||
| |---|---| | ||
| | Douleur | contexte d'auteur, erreurs inter-fichiers et logique non couverte par tests | | ||
| | Alternative native/bricolée | Codex `/review`, Claude `/review`, Copilot/Kilo, `git diff` vers deux CLIs | | ||
| | Valeur différentielle | findings ancrés, déduplication, provenance, tests/reproduction, feedback humain | | ||
| | Coût de substitution | environ un jour pour script local ; 2–5 jours pour CI robuste | | ||
| | Latence/coût/confidentialité | contexte plus large, risque d'exfiltration accru, faux positifs coûteux | | ||
| | Produit minimum désirable | fixture locale sans publication : diff exact, statut non validé, accepted/rejected/duplicate/out-of-scope | | ||
| | Preuve requise | vérité terrain pour relier une objection de plan à un défaut de changement confirmé | | ||
| | Dépendances | changements/bugs historiques, lignes stables, tests et adjudication | | ||
| | Abandon | aucun bug unique matériel confirmé, triage net plus long ou substitut simple équivalent | | ||
| Cette surface n'est pas une version à construire après le plan. Elle sert | ||
| d'instrumentation au protocole : le diff, le test ou le correctif ex post peut | ||
| confirmer ou réfuter une objection formulée sur le plan. | ||
| ### 3. Revue commit et pull request — repousser | ||
| | Dimension | Décision | | ||
| |---|---| | ||
| | Douleur | gate d'équipe, commentaires ancrés, politique de branche et audit | | ||
| | Alternative native/bricolée | Codex commit/GitHub, Claude Code Review, Copilot, Bugbot, GitLab Duo, CodeRabbit, Qodo, Greptile, GitHub Action | | ||
| | Valeur différentielle | politique inter-fournisseurs et preuve portable, encore hypothétique | | ||
| | Coût de substitution | faible pour commit local ; élevé pour application multi-forge fiable | | ||
| | Latence/coût/confidentialité | chaque push multiplie facture et bruit ; secrets/identités de forge ; contexte cloud | | ||
| | Produit minimum désirable | aucun avant preuve locale ; au plus export d'un dossier de findings acceptés | | ||
| | Preuve requise | gain clair face au meilleur natif/spécialiste et demande d'une politique cross-forge | | ||
| | Dépendances | distribution forge, identités, permissions, sécurité CI, SLA | | ||
| | Abandon | plateforme native offre provenance/budget/désaccord, ou équipe refuse un check de plus | | ||
| Le marché est saturé, les plateformes contrôlent l'activation et GitLab annonce | ||
| 0,25 $ par revue. Inspectrum ne doit pas devenir un bot de pull request | ||
| généraliste. | ||
| ### 4. Pair programming entre modèles — abandon produit | ||
| | Dimension | Décision | | ||
| |---|---| | ||
| | Douleur | séparer planification, exécution et critique | | ||
| | Alternative native/bricolée | Aider architect/editor, Amp Oracle, équipes et sous-agents, changement manuel de modèle | | ||
| | Valeur différentielle | aucune démontrée ; les harnais possèdent contexte, éditeur et boucle | | ||
| | Coût de substitution | nul à quelques heures | | ||
| | Latence/coût/confidentialité | tours répétés, contextes dupliqués, plusieurs providers | | ||
| | Produit minimum désirable | aucune nouvelle surface ; au plus un seul checkpoint reviewer dans l'expérience plan | | ||
| | Preuve requise | temps total de tâche plus court ou moins de rework à budget égal | | ||
| | Dépendances | benchmark de dépôt longue durée inexistant | | ||
| | Abandon | déjà satisfait : absence de preuve et substitution native immédiate | | ||
| PairCoder justifie une expérience bornée auteur → reviewer → tests → révision, | ||
| pas un produit de discussion continue. | ||
| ### 5. Raisonnement, désaccord et discussion — abandon du débat libre | ||
| | Dimension | Décision | | ||
| |---|---| | ||
| | Douleur | hypothèses cachées et confiance excessive | | ||
| | Alternative native/bricolée | council, agent team, trois appels réponse/critique/juge | | ||
| | Valeur différentielle | conserver la minorité, preuve et arrêt humain ; pas faire « parler » les agents | | ||
| | Coût de substitution | <1 jour prototype ; semaines pour calibration fiable | | ||
| | Latence/coût/confidentialité | pire surface : plusieurs tours et copies de contexte | | ||
| | Produit minimum désirable | comparaison déterministe d'opinions indépendantes en un tour | | ||
| | Preuve requise | meilleure décision que reviewers indépendants sans discussion | | ||
| | Dépendances | oracle et mesure de corrélation | | ||
| | Abandon | consensus augmente confiance sans exactitude ou discussion augmente bruit/latence | | ||
| Le juge reste un éditeur optionnel. Il ne compte jamais les reviewers comme des | ||
| votes indépendants et ne doit pas effacer le dissent. | ||
| ## Trois créneaux candidats | ||
| | Rang provisoire | Candidat | Utilisateur / activation | Pourquoi maintenant | Menace principale | Décision | | ||
| |---:|---|---|---|---|---| | ||
| | 1 | checkpoint avant exécution d'une tâche à haut risque | solo/petite équipe ; sortie du plan | produit existant, activation claire, expérience peu coûteuse | hook + skill natif ; plan peut disparaître | **wedge principal à tester** | | ||
| | 2 | dossier local de preuves pour diff/commit | mainteneur ; après exécution | seule vérité terrain ancrée disponible pour le plan | revues Codex/Claude natives, bruit PR | **instrumentation du candidat 1, aucun budget produit** | | ||
| | 3 | kit de calibration open source pour reviewers | mainteneur de harnais/équipe plateforme ; changement de modèle/version | pourrait matérialiser une neutralité publique | autre utilisateur, demande inconnue, bénéficie aussi aux concurrents | **gelé pendant le pilote** | | ||
| Le troisième candidat n'est pas une option active. Créer un framework | ||
| d'évaluation sans cas réels serait une architecture sans demande et publierait | ||
| la capacité au bénéfice d'acteurs disposant de beaucoup plus de données. | ||
| ## Moat : présent, potentiel et érosion | ||
| ### Moat actuel | ||
| **Aucun.** | ||
| - le MCP, le prompt, le juge, le hook, le stockage Markdown et les backends sont | ||
| copiables ; | ||
| - la portabilité est un avantage d'acquisition, pas une barrière ; | ||
| - le fail-open est une bonne décision de sécurité, pas un moat ; | ||
| - la marque et les catalogues peuvent aider la découverte, pas empêcher la | ||
| copie ; | ||
| - aucune donnée de rétention, précision ou volonté de payer n'existe encore. | ||
| ### Avantage potentiel — pas encore un moat | ||
| Un avantage défendable demanderait quatre couches cumulées : | ||
| 1. **Corpus consenti de défaillances réelles** : plan, issue connue, | ||
| transformation assainie, oracle, disposition humaine. | ||
| 2. **Calibration longitudinale** : modèle/version/effort/prompt, classe de tâche, | ||
| erreur marginale, corrélation, faux positifs, variance et coût. | ||
| 3. **Politique adaptative** : un seul reviewer par défaut, escalade seulement | ||
| quand risque ou désaccord historique le justifie. | ||
| 4. **Neutralité et confiance opérationnelle** : déclenchement observé, état dégradé exact, | ||
| replay, compatibilité multi-harnais et rapport exploitable par un humain. | ||
| À 12 utilisateurs et quelques dizaines de cas, le corpus est une preuve de | ||
| concept, pas un moat. Les fournisseurs disposent de volumes très supérieurs et | ||
| les données se périment à chaque changement de modèle. La seule asymétrie | ||
| structurelle possible est la neutralité : Anthropic n'a pas intérêt à calibrer | ||
| Codex, ni OpenAI à calibrer Claude. Cette position devient crédible seulement | ||
| avec méthode publique, audit externe, mises à jour régulières et usage | ||
| récurrent. Elle reste un moat de confiance/standard, non un monopole de données. | ||
| ### Risques d'érosion | ||
| - Anthropic/OpenAI/Cursor/GitHub ajoutent revue cross-vendor ou provenance | ||
| complète ; | ||
| - les règles/skills/hooks deviennent parfaitement portables ; | ||
| - le plan disparaît comme artefact ; | ||
| - changements de politiques interdisent la réutilisation des abonnements par un | ||
| produit tiers ; | ||
| - les modèles convergent et l'erreur marginale tombe ; | ||
| - absence de télémétrie empêche d'apprendre, tandis qu'une collecte intrusive | ||
| détruirait la promesse locale ; | ||
| - peu d'utilisateurs acceptent de partager des cas ; | ||
| - un meilleur modèle avec outils bat toujours le comité à budget égal. | ||
| ## Hypothèses et critères d'abandon | ||
| La thèse dépend de sept observations : douleur avec rework vérifiable, utilité | ||
| marginale face au meilleur substitut, utilité nette après triage et latence, | ||
| vigilance humaine préservée, activation et réutilisation, absence de parité | ||
| native à coût inférieur, et demande commerciale distincte de la curiosité. | ||
| Les seuils, échantillons et issues autorisées vivent uniquement dans le | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md). La règle de substitution | ||
| native vit uniquement dans les conditions de recentrage de la | ||
| [roadmap d'exécution](outcome-moat-roadmap-post-0.2.2.md). La thèse ne duplique | ||
| aucun nombre normatif. | ||
| ### Protocole de preuve | ||
| Les expériences, leur numérotation, leurs seuils et leur calendrier vivent | ||
| uniquement dans le | ||
| [protocole de preuve post-0.2.2](evidence-protocol-post-0.2.2.md). La thèse | ||
| explique pourquoi ces portes existent ; elle ne constitue pas une seconde | ||
| source d'exécution. | ||
| ## Positionnement recommandé | ||
| Ne pas dire : | ||
| > Plusieurs modèles débattent et rendent votre plan correct. | ||
| Dire : | ||
| > Avant une tâche risquée, Inspectrum fait passer le plan par un checkpoint | ||
| > indépendant, conserve ce qui a été trouvé ou échoué, et vous laisse décider. | ||
| La preuve publique doit montrer une entrée, un finding confirmé, la décision | ||
| humaine, le coût et la limite. Un échec ou un faux positif documenté vaut mieux | ||
| qu'un taux de « confiance » sans oracle. | ||
| ## Acquisition et activation | ||
| ### Acquisition | ||
| Après la publication 0.2.2, cibler les personnes qui possèdent déjà Claude Code et | ||
| Codex et publient des tâches de migration, auth, paiements ou données. Les | ||
| canaux utiles sont les catalogues natifs, dépôts/communautés des deux harnais, | ||
| le premier cas éligible pré-enregistré et consentant, résultat positif ou nul, | ||
| et des invitations directes. Les refus de publication restent comptés. Une | ||
| campagne large ou des étoiles avant preuve créeraient de la curiosité, pas de | ||
| rétention. | ||
| Avantages de distribution existants : | ||
| - plugin Claude Code et parcours à deux commandes ; | ||
| - MCP local réutilisable par plusieurs hôtes ; | ||
| - npm, GitHub, MCP Registry et Glama déjà publics ; Claude Community en attente | ||
| et PulseMCP absent au 1er août 2026 ; | ||
| - preuve locale exportable sans compte Inspectrum. | ||
| Ils facilitent l'essai mais seront copiés. Le vrai canal organique potentiel est | ||
| le cas de défaut confirmé partageable : « ce changement semblait sûr ; voici | ||
| l'hypothèse trouvée avant exécution ». | ||
| ### Activation | ||
| Moment d'activation : | ||
| 1. l'utilisateur marque ou accepte une tâche comme risquée ; | ||
| 2. la sortie de plan déclenche une revue unique ; | ||
| 3. le résultat nomme reviewer, durée, statut et preuves ; | ||
| 4. l'utilisateur accepte/rejette chaque finding ; | ||
| 5. l'agent revient au plan ou à l'approbation humaine ; | ||
| 6. un résumé assaini peut être exporté volontairement. | ||
| Indicateurs d'usage récurrent : | ||
| - première session verte ; | ||
| - deuxième utilisation parmi les personnes réellement réexposées à une tâche | ||
| à risque sous six semaines ; | ||
| - taux de skip volontaire par niveau de risque ; | ||
| - findings majeurs acceptés et uniques ; | ||
| - minutes de triage par finding accepté ; | ||
| - rework évité déclaré puis vérifié quand possible ; | ||
| - taux d'échec/partiel et p50/p95 ; | ||
| - export volontaire d'un cas. | ||
| ### Volonté de payer | ||
| Elle est **absente pour Inspectrum**. Les prix concurrents et anecdotes montrent | ||
| seulement que certaines équipes paient pour du temps senior ou des bugs évités. | ||
| Elles ne fixent ni prix, ni demande, ni porte pour Inspectrum. | ||
| Si personne ne paie malgré une utilité répétée, maintenir l'outil open source | ||
| léger peut rester rationnel ; cela invalide le SaaS, pas nécessairement | ||
| l'utilité. | ||
| Le test doit distinguer paiement pour une seconde opinion générique et paiement | ||
| pour la garantie inter-fournisseurs. Le protocole P3 fixe seul le moment, les | ||
| seuils et les issues commerciales ; la roadmap fixe seule la forme autorisée | ||
| d'une éventuelle offre de Phase E. | ||
| ## Décision de portefeuille | ||
| - **Principal :** checkpoint de plan haut risque, borné et mesuré. | ||
| - **Instrumentation :** diff/commit local uniquement comme vérité terrain, pas | ||
| comme produit. | ||
| - **Avantage potentiel :** neutralité, corpus et calibration ; aucun moat tant | ||
| que volume, rétention et audit n'existent pas. | ||
| - **Gelé :** kit de calibration public pendant le pilote. | ||
| - **Repoussé :** intégration pull request/multi-forge. | ||
| - **Abandonné :** pair programming continu et débat libre. | ||
| - **À retirer du message :** « plus de modèles = plus fiable » et « local = | ||
| aucune donnée ne quitte la machine ». | ||
| La [roadmap d'exécution](outcome-moat-roadmap-post-0.2.2.md) fixe les résultats | ||
| et le portefeuille ; le | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md) fixe les portes d'arrêt ; | ||
| la [boucle GitHub](github-star-growth-loop.md) fixe la distribution. Aucun de | ||
| ces documents ne peut autoriser seul une extension du produit. |
| # Roadmap post-0.2.2 orientée résultats, wedge et moat | ||
| État : décision d'exécution du 30 juillet 2026, mise à jour le 1er août 2026. | ||
| `inspectrum@0.2.2`, la release GitHub, la fiche MCP Registry et la fiche Glama | ||
| sont publiques. La soumission Claude Community est en attente et Inspectrum | ||
| n'est pas référencé par PulseMCP. Cette roadmap est active ; elle n'autorise ni | ||
| nouvelle publication, ni extension de portée sans la porte correspondante. | ||
| Les investissements fondés sur un gain inter-fournisseurs restent gouvernés | ||
| par le [protocole de preuve](evidence-protocol-post-0.2.2.md). Le | ||
| positionnement et la Phase B à faible regret avancent en parallèle ; les | ||
| Phases D et E exigent un `GO` du protocole. | ||
| ## Cap | ||
| ### Catégorie à posséder | ||
| **Assurance indépendante des changements agentiques à risque.** | ||
| Inspectrum se concentre sur une frontière précise : le moment avant qu'un agent | ||
| prenne une action difficile à annuler. Les comités de modèles, bots de pull | ||
| request et harnais généralistes restent hors de cette catégorie. | ||
| ### Positionnement | ||
| > **Inspectrum est le contrôle pré-vol indépendant avant qu'un agent exécute | ||
| > un changement difficile à annuler. Il garde les preuves, désaccords et | ||
| > échecs visibles. L'humain décide.** | ||
| Version courte : | ||
| > **Independent pre-flight review for risky coding-agent changes.** | ||
| « Indépendant » signifie ici un reviewer distinct du modèle auteur, exécuté | ||
| séparément sans voir sa sortie. Le terme ne prétend jamais que leurs erreurs | ||
| sont statistiquement indépendantes. | ||
| ### Wedge | ||
| Le wedge, c'est-à-dire le premier usage étroit qui ouvre le marché, reste | ||
| `ExitPlanMode` dans Claude Code : | ||
| - l'utilisateur prépare une migration, une modification d'authentification, un | ||
| paiement, une rupture d'interface, un déploiement ou une refonte coûteuse ; | ||
| - Inspectrum déclenche un reviewer indépendant une fois ; | ||
| - le résultat distingue constat, preuve, désaccord et échec ; | ||
| - l'utilisateur garde l'approbation finale. | ||
| Le nom durable de la frontière est **avant décision difficile à inverser**. La | ||
| sortie de plan est la première intégration, pas la définition définitive du | ||
| produit. | ||
| ### Moat à construire | ||
| Le moat visé, c'est-à-dire l'avantage durable difficile à reproduire, | ||
| combinerait quatre actifs : | ||
| 1. cas réels consentis avec défaut et issue confirmés ; | ||
| 2. calibration par modèle, version, classe de risque, coût et latence ; | ||
| 3. routage qui appelle le bon reviewer et n'escalade que si cela vaut son coût ; | ||
| 4. protocole neutre de preuve et d'état dégradé réutilisable entre harnais. | ||
| Chaque fonction isolée reste copiable. Leur historique vérifié, leur méthode | ||
| publique et la confiance acquise forment l'actif défendable potentiel. | ||
| **Au 1er août 2026, ni le gain net de fiabilité ni ce moat potentiel ne sont | ||
| prouvés.** Aucune porte P1, P2 ou P3 n'a encore réussi. | ||
| ## Règles de construction | ||
| 1. **Un noyau.** Un serveur local, un outil MCP `review_plan`, un contrat de | ||
| preuve et des adaptateurs minces. | ||
| 2. **Aucune infrastructure propriétaire.** Pas de serveur HTTPS, base distante, | ||
| compte Inspectrum ou télémétrie cachée. | ||
| 3. **Une seule nouvelle frontière à la fois.** Claude Code d'abord ; les autres | ||
| harnais consomment le même contrat. | ||
| 4. **Preuve avant spectacle.** Pas de débat multi-tours, de vote ou de nombre de | ||
| modèles affiché comme score de confiance. | ||
| 5. **Le cas utilisateur produit l'actif.** Chaque usage peut, avec consentement, | ||
| devenir un cas assaini, une entrée de calibration et une preuve publique. | ||
| 6. **Budget de complexité fixe.** Toute capacité nouvelle nomme ce qu'elle | ||
| remplace ou supprime. Pas de backend ajouté uniquement pour afficher un logo. | ||
| 7. **Compatibilité avant vitesse.** Les changements de contrat ont version, | ||
| migration, fixture et test. | ||
| ## Étoile polaire et mesures | ||
| L'étoile polaire produit est : | ||
| > **Nombre mensuel de checkpoints à risque terminés avec statut exact, | ||
| > disposition humaine et issue vérifiable.** | ||
| Sans télémétrie, elle est mesurée par cas volontairement exportés, pilotes, | ||
| issues consenties et retours structurés. Les étoiles GitHub mesurent la | ||
| distribution et la confiance publique ; elles ne remplacent jamais l'usage. | ||
| Mesures secondaires : | ||
| - installation publique vers premier `doctor` vert en moins de 10 minutes ; | ||
| - première revue réussie, partielle ou échouée correctement nommée ; | ||
| - findings majeurs acceptés puis confirmés ; | ||
| - minutes de triage par finding confirmé ; | ||
| - deuxième utilisation lorsqu'une nouvelle tâche à risque se présente ; | ||
| - exports assainis et cas réutilisables ; | ||
| - étoiles, forks, contributeurs externes et installations qualifiées ; | ||
| - coût et latence par checkpoint. | ||
| ## Séquence sur douze mois | ||
| | Phase | Période après 0.2.2 | Résultat utilisateur | Actif candidat, non prouvé | | ||
| |---|---:|---|---| | ||
| | A : posséder la catégorie | J0–J30 | comprendre, installer et voir une vraie revue en moins de 10 minutes | aucun ; positionnement seulement | | ||
| | B : rendre la garantie tangible | M1–M2 | savoir exactement ce qui a été revu, échoué et décidé | enveloppe de preuve et disposition humaine | | ||
| | C : lancer la boucle de preuves | M2 jusqu'au `GO`, premier passage ≤18 semaines, plafond absolu 26 semaines | comparer les reviewers sur des cas confirmés | premier corpus et première calibration publique | | ||
| | D : devenir portable sans grossir | à partir du `GO`, jamais avant M6 | réutiliser la même garantie depuis trois harnais | contrat commun et adaptateurs communautaires | | ||
| | E : transformer les données en produit | à partir du `GO`, jamais avant M6 | obtenir le bon niveau de revue au bon coût | routage calibré, historique et confiance neutre | | ||
| Les objectifs GitHub vivent uniquement dans la | ||
| [boucle de croissance](github-star-growth-loop.md). Ils ne sont jamais un | ||
| critère de sortie d'une phase produit. | ||
| ## Phase A : posséder la catégorie | ||
| ### Résultat attendu | ||
| Un développeur comprend en trente secondes le risque traité, installe en deux | ||
| commandes et voit un statut honnête en moins de dix minutes. | ||
| ### Livrables | ||
| - README centré sur le contrôle pré-vol, avec l'alternative skill expliquée ; | ||
| - démonstration réelle de 60 à 90 secondes, sans montage trompeur ; | ||
| - un cas positif, un résultat nul et un échec visible ; | ||
| - tableau « skill maison / revue native / Inspectrum » sur les garanties ; | ||
| - `doctor` et message d'activation sans ambiguïté ; | ||
| - pages de catalogue cohérentes avec le même positionnement ; | ||
| - modèles d'issue pour cas, friction d'installation et faux positif. | ||
| ### Garde-fous | ||
| - aucune promesse de meilleure exactitude ; | ||
| - aucun cas artificiel présenté comme usage réel ; | ||
| - aucune demande d'étoile avant d'avoir montré la valeur ; | ||
| - aucune fonctionnalité majeure pendant les 48 premières heures publiques. | ||
| ### Décision | ||
| Si l'installation publique ou le premier checkpoint échoue, corriger | ||
| l'activation avant tout travail de moat ou de croissance. | ||
| ## Phase B : rendre la garantie tangible | ||
| ### Résultat attendu | ||
| L'utilisateur peut répondre à cinq questions : qui a relu, avec quelle version, | ||
| qu'est-ce qui a réussi, qu'est-ce qui a échoué et qu'ai-je décidé ? | ||
| ### Portée produit | ||
| - provenance exacte du reviewer : fournisseur, modèle, version, effort, durée ; | ||
| - états `reviewed`, `partial`, `unreviewed` sans conversion d'un échec en vert ; | ||
| - séparation `claim`, `evidence`, `dissent` et `uncertainty` ; | ||
| - disposition humaine : `accepted`, `rejected`, `duplicate`, `out_of_scope`, | ||
| `unverified` ; | ||
| - export local assaini et volontaire ; | ||
| - schéma de preuve versionné avec fixtures de migration ; | ||
| - juge optionnel et éditorial, jamais compteur de votes. | ||
| - instrumentation p50/p95 sur la baseline avant P3, sans changer modèle, | ||
| prompt, effort ou délai du reviewer. | ||
| ### Simplicité | ||
| Ces informations restent dans les fichiers de session. Aucun tableau de bord, | ||
| compte, synchronisation ou base distante. | ||
| ### Résultat de qualité | ||
| Cent pour cent des fixtures de panne affichent le bon état ; aucun reviewer ne | ||
| peut muter le dépôt ; les anciennes sessions restent lisibles. | ||
| ## Phase C : lancer la boucle de preuves | ||
| ### Résultat attendu | ||
| Chaque constat important peut être relié à une issue confirmée ou rester | ||
| explicitement non vérifié. | ||
| ### Livrables | ||
| - protocole public minimal de soumission consentie ; | ||
| - 10 premiers cas publiables, positifs ou négatifs ; | ||
| - jeu de cas versionné couvrant migration, données, authentification, paiement | ||
| et compatibilité ; | ||
| - rapport trimestriel de résultats par modèle/version : défauts uniques, faux | ||
| positifs, triage, coût, latence et échecs ; ce rapport publie des mesures, | ||
| pas un kit ou framework de calibration réutilisable ; | ||
| - comparaison avec le meilleur skill/hook simple, pas avec l'absence de revue ; | ||
| - résultats négatifs conservés. | ||
| ### Forme soutenable | ||
| Le registre commence en CSV/Markdown et se reconstruit par script. Une | ||
| contribution passe par pull request et validation automatique. Pas de service | ||
| de collecte permanent. | ||
| ### Décision | ||
| Les dix premiers cas publiables sont un actif de transparence, pas une preuve | ||
| statistique ni un moat. La décision suit P1, P2 et P3 du | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md). | ||
| `GO` vers les Phases D et E seulement si P1, P2 et P3 rendent tous `GO` selon | ||
| les critères complets du | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md). Toute issue `STOP | ||
| PRODUIT` maintient Inspectrum comme utilité locale et interdit routage calibré | ||
| et plateforme. | ||
| Au terme du premier passage de 18 semaines, moins de dix cas publiables | ||
| abandonnent l'hypothèse de moat de données. Ce résultat n'allonge pas le | ||
| protocole et n'est pas compensé par des cas choisis après coup. | ||
| ## Phase D : devenir portable sans grossir | ||
| Cette phase ne démarre que si la Phase C et le protocole de preuve rendent | ||
| `GO`. | ||
| ### Résultat attendu | ||
| Le même contrat de preuve fonctionne depuis Claude Code, Codex et un troisième | ||
| harnais choisi par demande observée. | ||
| ### Architecture | ||
| - le serveur et `review_plan` restent le noyau ; | ||
| - le comportement automatique Claude Code reste un adaptateur ; | ||
| - Codex et le troisième harnais utilisent skill, hook ou recette mince ; | ||
| - les adaptateurs vivent hors du noyau lorsqu'ils ont un cycle de release | ||
| différent ; | ||
| - la communauté peut maintenir un adaptateur sans modifier l'orchestrateur. | ||
| ### Critère de choix du troisième harnais | ||
| Choisir entre OpenCode, Gemini CLI, Cursor ou autre à partir des issues, | ||
| installations et contributions, jamais à partir du nombre d'étoiles du | ||
| concurrent. | ||
| ### Limite | ||
| Trois harnais maximum maintenus par le projet. Les suivants sont communautaires | ||
| ou documentés comme recettes. | ||
| ## Phase E : transformer les données en produit | ||
| Cette phase ne démarre que si la Phase C et le protocole de preuve rendent | ||
| `GO`. | ||
| ### Résultat attendu | ||
| Une tâche reçoit le reviewer, l'effort et le budget adaptés au risque, sans | ||
| comité systématique. | ||
| ### Portée | ||
| - profils de risque explicites et modifiables ; | ||
| - recommandation de reviewer fondée sur la calibration observée ; | ||
| - escalade seulement quand l'historique montre une valeur marginale ; | ||
| - budget de coût et de latence avant lancement ; | ||
| - avertissement quand la calibration est absente ou périmée ; | ||
| - comparaison des versions dans le temps ; | ||
| - rapport d'assurance local exportable. | ||
| Le routage commence par des règles lisibles. Aucun apprentissage automatique | ||
| avant un volume et une qualité de données suffisants. | ||
| ### Modèle soutenable | ||
| Le noyau open source reste local et gratuit. Des revenus peuvent ensuite venir | ||
| de rapports de calibration vérifiés, politiques d'assurance d'équipe, support | ||
| et audits, sans héberger le code ni les plans. | ||
| Aucune offre payante n'est construite avant la décision commerciale `OFFRE | ||
| PAYANTE` de P3 dans le | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md). Avant cette porte, la | ||
| livraison reste documentaire et manuelle, en mode concierge. Elle ne crée ni | ||
| compte, ni synchronisation d'équipe, ni automatisation propre. | ||
| ## Contrat de qualité | ||
| « Qualité parfaite » devient un contrat vérifiable : | ||
| - zéro vulnérabilité de production haute ou critique à la release ; | ||
| - aucun test, typecheck, lint, couverture ou test de contrat rouge ; | ||
| - couverture maintenue au-dessus des seuils existants, jamais abaissée ; | ||
| - aucun statut vert lorsqu'un reviewer a échoué ou n'a pas répondu ; | ||
| - aucune mutation du dépôt par le reviewer ; | ||
| - versions, prompts, modèles et efforts présents dans les preuves ; | ||
| - compatibilité descendante ou migration documentée ; | ||
| - limites, coûts et confidentialité écrits dans le même changement que la | ||
| fonctionnalité ; | ||
| - release reproductible et paquet vérifié ; | ||
| - un seul moyen recommandé d'accomplir chaque tâche importante. | ||
| Un défaut critique bloque la release. Un défaut de documentation qui change la | ||
| promesse publique est traité comme un défaut produit. | ||
| ## Portefeuille explicitement fermé | ||
| Ne pas construire pendant ces douze mois : | ||
| - bot généraliste de pull request ; | ||
| - produit autonome de revue de commit ; | ||
| - pair programming continu ; | ||
| - débat libre ou multi-tours entre modèles ; | ||
| - interface Web, SaaS ou hébergement de plans ; | ||
| - base de données distante ; | ||
| - marketplace propriétaire ; | ||
| - nouveau protocole de transport ; | ||
| - orchestration d'équipe générique. | ||
| Le diff et le commit restent des instruments de confirmation ex post. Une | ||
| nouvelle frontière n'entre au portefeuille que si elle réutilise le même | ||
| contrat, les mêmes preuves et le même actif de calibration. | ||
| ## Conditions de recentrage | ||
| - après 30 jours, terminer l'enveloppe de preuve de Phase B comme seul travail | ||
| produit autorisé ; avec 1 à 4 installations externes réussies, corriger | ||
| positionnement et activation ; avec zéro installation, suspendre tout travail | ||
| après Phase B et revoir le wedge, la démonstration et les canaux ; | ||
| - adaptateur équivalent en moins de 100 lignes : le traiter comme canal, pas | ||
| comme différentiel produit ; | ||
| - fonction native équivalente sur déclenchement, contrat, preuve, échec et | ||
| portabilité, démontrée par une vérification indépendante reproductible à coût | ||
| inférieur ou égal : déplacer Inspectrum vers le standard ouvert ou la | ||
| maintenance ; | ||
| - coût de maintenance supérieur à deux jours par mois hors release : supprimer, | ||
| externaliser ou geler la surface responsable. | ||
| ## État au 1er août et prochains pas | ||
| 1. npm 0.2.2, la release GitHub, le MCP Registry et Glama sont disponibles ; | ||
| 2. Claude Community reste en attente et PulseMCP reste absent ; | ||
| 3. remplacer la capture terminal 0.2.1 seulement par une preuve publique 0.2.2 | ||
| reproductible ; | ||
| 4. exécuter `doctor` et un checkpoint non artificiel hors checkout ; | ||
| 5. publier la démonstration, le cas réel et le résultat nul ; | ||
| 6. aligner description GitHub et catalogues quand leur statut change ; | ||
| 7. lancer la boucle GitHub décrite dans | ||
| [github-star-growth-loop.md](github-star-growth-loop.md) ; | ||
| 8. ouvrir le schéma de preuve de Phase B, sans autre extension. |
| # Stratégie post-0.2.2 | ||
| État public vérifié le 1er août 2026. Ce dossier est la source de vérité pour | ||
| les décisions produit prises après Inspectrum 0.2.2. | ||
| ## Décision active | ||
| Inspectrum est un **contrôle indépendant avant un changement agentique | ||
| difficile à annuler**. Sa première intégration est le point de sortie du mode | ||
| plan (`ExitPlanMode`) dans Claude Code. L'utilisateur garde la décision finale. | ||
| « Indépendant » signifie qu'un reviewer distinct du modèle auteur est invoqué | ||
| séparément. Cela ne signifie pas que leurs erreurs sont statistiquement | ||
| indépendantes. **Ni le gain net de fiabilité, ni un avantage durable difficile | ||
| à reproduire ne sont prouvés à ce jour.** Aucune porte du protocole de preuve | ||
| n'a encore réussi. | ||
| ## Documents normatifs | ||
| - [Roadmap orientée résultats](outcome-moat-roadmap-post-0.2.2.md) : portée, | ||
| séquence et portefeuille autorisé. | ||
| - [Protocole de preuve](evidence-protocol-post-0.2.2.md) : expériences et portes | ||
| d'arrêt qui peuvent autoriser les investissements conditionnels. | ||
| - [Thèse de créneau et d'avantage défendable](moat-thesis.md) : raisonnement, | ||
| contre-thèse et hypothèses à réfuter. | ||
| Documents d'appui : | ||
| - [paysage concurrentiel daté de juillet 2026](competitive-landscape-2026-07.md) | ||
| et son [registre de sources](evidence/competitive-source-ledger.csv) ; | ||
| - [boucle de croissance GitHub](github-star-growth-loop.md), qui gouverne la | ||
| distribution sans servir de preuve produit. | ||
| L'[ancienne roadmap post-0.2.2](roadmap-post-0.2.2.md) est remplacée et ne donne | ||
| plus d'autorité d'exécution. | ||
| ## État de distribution | ||
| | Canal | État au 1er août 2026 | | ||
| |---|---| | ||
| | npm | disponible en version 0.2.2 | | ||
| | GitHub | dépôt et release 0.2.2 disponibles | | ||
| | MCP Registry | version 0.2.2 disponible | | ||
| | Glama | fiche Inspectrum disponible | | ||
| | Claude Community | soumission en attente | | ||
| | PulseMCP | aucune fiche Inspectrum observée | | ||
| ## Portefeuille fermé | ||
| La revue de code, la revue de pull request et le pair programming ne sont pas | ||
| des extensions autorisées. Ils restent hors portefeuille tant que les portes | ||
| de preuve n'ont pas réussi ; leur succès ne les ouvrirait pas automatiquement, | ||
| car une décision de roadmap explicite resterait nécessaire. |
| # Roadmap post-0.2.2 — remplacée | ||
| État : **remplacée le 1er août 2026**. | ||
| Cette ancienne roadmap n'est plus une source d'exécution. La stratégie active | ||
| est décrite dans l'[index post-0.2.2](README.md), la | ||
| [roadmap orientée résultats](outcome-moat-roadmap-post-0.2.2.md) et le | ||
| [protocole de preuve](evidence-protocol-post-0.2.2.md). | ||
| En particulier, ses anciennes expansions vers la revue de code, la revue de | ||
| pull request ou le pair programming ne sont plus autorisées. |
+23
-2
@@ -8,2 +8,3 @@ import * as fs from "node:fs"; | ||
| import { loadConfig, getConfigPath, defaultConfig } from "./config.js"; | ||
| import { getPackageVersion } from "./version.js"; | ||
| /** | ||
@@ -51,4 +52,8 @@ * Resolves which model/reasoning-effort a codex review will actually use: | ||
| const Z = useColor ? "\x1b[0m" : ""; | ||
| let hasWarnings = false; | ||
| const pass = (label) => process.stdout.write(` ${G}✅${Z} ${label}\n`); | ||
| const warn = (label) => process.stdout.write(` ${Y}⚠${Z} ${label}\n`); | ||
| const warn = (label) => { | ||
| hasWarnings = true; | ||
| process.stdout.write(` ${Y}⚠${Z} ${label}\n`); | ||
| }; | ||
| const failMsg = (label) => process.stdout.write(` ${R}❌${Z} ${label}\n`); | ||
@@ -164,4 +169,17 @@ const hint = (text) => process.stdout.write(` ${text}\n`); | ||
| const pluginLabel = `inspectrum@inspectrum${plugin.version ? ` ${plugin.version}` : ""}`; | ||
| const packageVersion = getPackageVersion(); | ||
| if (plugin.warning || !plugin.ok) | ||
| warn(`${pluginLabel}${plugin.warning ? ` — ${plugin.warning}` : ""}`); | ||
| else if (plugin.version && plugin.version !== packageVersion) { | ||
| const mismatch = `${pluginLabel} — version mismatch: automatic plan gate uses inspectrum@${plugin.version}; this doctor uses inspectrum@${packageVersion}`; | ||
| if (config.plan_gate.enabled) { | ||
| failMsg(mismatch); | ||
| allOk = false; | ||
| } | ||
| else { | ||
| warn(`${mismatch} — plan gate is disabled`); | ||
| } | ||
| hint("Fix: claude plugin uninstall inspectrum@inspectrum && claude plugin marketplace remove inspectrum"); | ||
| hint("Then: claude plugin marketplace add yannmenec/inspectrum && claude plugin install inspectrum@inspectrum"); | ||
| } | ||
| else | ||
@@ -174,3 +192,6 @@ pass(pluginLabel); | ||
| if (allOk) { | ||
| process.stdout.write(`${G}✅ All checks passed${Z}\n\n`); | ||
| if (hasWarnings) | ||
| process.stdout.write(`${Y}⚠ Checks passed with warnings${Z}\n\n`); | ||
| else | ||
| process.stdout.write(`${G}✅ All checks passed${Z}\n\n`); | ||
| } | ||
@@ -177,0 +198,0 @@ else { |
@@ -8,29 +8,28 @@ # Codex plugin: review a plan with Claude | ||
| The plugin does not add a tool or change the server architecture. Its bundled | ||
| MCP configuration starts the candidate package with: | ||
| MCP configuration starts the public package with: | ||
| ```text | ||
| npx -y inspectrum@0.2.2 | ||
| npx -y inspectrum@0.2.3 | ||
| ``` | ||
| The package selector must match `package.json`; the contract test fails if the | ||
| two versions drift. | ||
| two versions drift. Codex allows the MCP call 330 seconds: Inspectrum's default | ||
| reviewer limit is 300 seconds, leaving 30 seconds for aggregation, session | ||
| writing, and result delivery. The MCP server startup has a separate timeout. | ||
| ## Public installation | ||
| The public installation smoke test is currently **blocked**. npm and the public | ||
| GitHub release still expose `0.2.1`, while this plugin belongs to the `0.2.2` | ||
| candidate. Do not install the older public package as a silent fallback. | ||
| For version `0.2.3`, verify the exact package after it is published: | ||
| After `0.2.2` is published to npm and this marketplace is merged into `main`, | ||
| verify the exact package first: | ||
| ```bash | ||
| npm view inspectrum@0.2.2 version | ||
| npx -y inspectrum@0.2.2 doctor | ||
| npm view inspectrum@0.2.3 version | ||
| npx -y inspectrum@0.2.3 doctor | ||
| ``` | ||
| Both commands must resolve `0.2.2`. Then install the repository marketplace | ||
| and plugin: | ||
| Both commands must resolve `0.2.3`. If an older manual MCP registration already | ||
| uses the name `inspectrum`, remove it before installing the plugin; otherwise | ||
| the duplicate name can hide the plugin's bundled server: | ||
| ```bash | ||
| codex mcp remove inspectrum | ||
| codex plugin marketplace add yannmenec/inspectrum --ref main | ||
@@ -46,7 +45,17 @@ codex plugin add inspectrum@inspectrum | ||
| ## Validation before publication | ||
| On the first call, Codex asks whether the `inspectrum` MCP server may run | ||
| `review_plan`. Choose **Allow for this session** to continue without granting a | ||
| permanent permission. This interactive authorization is expected; a first call | ||
| from non-interactive `codex exec` can be cancelled because nobody can answer | ||
| the prompt. | ||
| Before the npm package exists, validate the local candidate rather than | ||
| claiming a public end-to-end success: | ||
| The public end-to-end smoke test completed successfully on 0.2.2: Codex invoked | ||
| `review_plan`, Claude returned a structured `revise` verdict in 46.3 seconds, | ||
| and Inspectrum wrote the local session. The user remained in control of the | ||
| review and no repository file was changed by the smoke task. | ||
| ## Validation | ||
| Validate repository changes with: | ||
| ```bash | ||
@@ -61,7 +70,4 @@ npm ci | ||
| The repository build and tests run the local `0.2.2` source. The targeted | ||
| contract validates the Codex manifest, marketplace entry, pinned MCP package, | ||
| reviewer direction, and failure semantics. The committed plugin launcher | ||
| itself cannot complete its public npm smoke test until `inspectrum@0.2.2` is | ||
| published. | ||
| The targeted contract validates the Codex manifest, marketplace entry, pinned | ||
| MCP package, reviewer direction, activation guidance, and failure semantics. | ||
@@ -68,0 +74,0 @@ ## Failure and privacy |
| # Inspectrum 0.2.2 submission kit | ||
| Status: candidate only, prepared on 2026-07-30. **Do not submit** to any | ||
| external channel until every hard gate below is checked. | ||
| Status: maintained distribution record, prepared on 2026-07-30 and updated on | ||
| 2026-08-01. This file records completed listings and remaining submissions; it | ||
| does not authorize publication. | ||
| **Do not submit** to a new channel, resubmit a pending application, or publish | ||
| an update without explicit authorization and the relevant green checks. | ||
| Technical identifiers stay lowercase where registries require them: | ||
@@ -11,2 +15,15 @@ `inspectrum` for npm and Claude namespacing, and | ||
| ## Channel status | ||
| | Channel | Status on 2026-08-01 | Public evidence | | ||
| |---|---|---| | ||
| | npm | Available | `inspectrum@0.2.2` | | ||
| | GitHub | Available | repository and release `v0.2.2` | | ||
| | MCP Registry | Available | `io.github.yannmenec/inspectrum@0.2.2` | | ||
| | Glama | Available | public Inspectrum listing with one tool | | ||
| | Claude Community | Pending | no public catalog listing yet | | ||
| | PulseMCP | Absent | no Inspectrum listing observed | | ||
| The OpenAI Plugin Directory is not part of the current availability claim. | ||
| ## Reusable listing copy | ||
@@ -16,12 +33,12 @@ | ||
| **Short description:** Review coding-agent plans on demand with peer models, | ||
| attributed findings, and a structured verdict. | ||
| **Short description:** Add an independent checkpoint before a risky | ||
| coding-agent change becomes difficult to undo, starting at plan exit. | ||
| **Long description:** | ||
| Inspectrum adds a second model's review before a coding plan reaches execution. | ||
| Its Claude Code plugin can run a bounded Codex review when plan mode exits; its | ||
| local MCP server exposes `review_plan` to hosts that support local | ||
| standard-input/output MCP. Findings retain reviewer attribution and the user | ||
| keeps final approval. | ||
| Inspectrum adds an independent pre-flight checkpoint before a coding-agent | ||
| change becomes difficult to undo. Its first automatic integration runs a | ||
| bounded Codex review when Claude Code exits plan mode; its local MCP server | ||
| exposes `review_plan` to hosts that support local standard-input/output MCP. | ||
| Findings retain reviewer attribution and the user keeps final approval. | ||
@@ -38,6 +55,12 @@ Inspectrum runs locally, has no first-party telemetry, and stores successful | ||
| **Claude Community:** `A repeatable second-model checkpoint for Claude Code | ||
| plans: automatic at the plan boundary, bounded, fail-open, evidence-backed, and | ||
| always leaves final approval to you.` | ||
| Inspectrum has not yet proved that a cross-provider review produces a net | ||
| reliability gain after false positives, triage, cost, and latency. It has no | ||
| proved moat. Code review, pull-request review, and pair programming remain out | ||
| of scope; successful evidence gates would not authorize them automatically, | ||
| because an explicit roadmap decision would still be required. | ||
| **Claude Community:** `An independent pre-flight checkpoint for risky Claude | ||
| Code plans: automatic at plan exit, bounded, fail-open, and always leaves final | ||
| approval to you.` | ||
| **MCP directories:** `Turn ad-hoc second opinions into a repeatable plan-review | ||
@@ -47,2 +70,6 @@ checkpoint. One local MCP tool returns attributed findings and one structured | ||
| **Current MCP Registry description:** `Review coding-agent plans on demand with | ||
| peer models, attributed findings, and a structured verdict.` This is the public | ||
| 0.2.2 manifest text; use the revised copy above for a future authorized update. | ||
| **Primary category:** Developer Tools | ||
@@ -61,3 +88,3 @@ | ||
| **Public URLs after release:** | ||
| **Public URLs:** | ||
@@ -67,2 +94,4 @@ - Source: https://github.com/yannmenec/inspectrum | ||
| - Release: https://github.com/yannmenec/inspectrum/releases/tag/v0.2.2 | ||
| - MCP Registry: https://registry.modelcontextprotocol.io/ | ||
| - Glama: https://glama.ai/mcp/servers/yannmenec/inspectrum | ||
| - Documentation: https://github.com/yannmenec/inspectrum#readme | ||
@@ -86,11 +115,11 @@ - Privacy: https://github.com/yannmenec/inspectrum/blob/main/PRIVACY.md | ||
| | `assets/brand/social-preview.png` (1280x640) | Ready | Optional wide preview | | ||
| | `assets/brand/terminal-doctor.png` (1280x720) | Blocked | Real 0.2.1 evidence; never present it as 0.2.2 | | ||
| | `assets/brand/terminal-doctor.png` (1280x720) | Archived | Real 0.2.1 evidence; never present it as 0.2.2 | | ||
| Replace the terminal capture only after installing public `inspectrum@0.2.2` in | ||
| an empty temporary environment and obtaining a green release-candidate | ||
| validation. Preserve the transcript; update hashes and provenance in | ||
| `assets/brand/README.md`; exclude credentials, real home paths, tokens, and | ||
| private plan content. | ||
| The terminal capture remains unchanged because it is accurately labeled 0.2.1. | ||
| Replace it only after installing public `inspectrum@0.2.2` in an empty | ||
| temporary environment and obtaining a green validation. Preserve the | ||
| transcript; update hashes and provenance in `assets/brand/README.md`; exclude | ||
| credentials, real home paths, tokens, and private plan content. | ||
| ## Hard gates before any external submission | ||
| ## Release evidence and remaining checks | ||
@@ -100,15 +129,18 @@ - [ ] The release-candidate report explicitly marks its required build, type, | ||
| Record its commit and evidence URL in the release record. | ||
| - [ ] `inspectrum@0.2.2` is publicly retrievable from npm. | ||
| - [ ] GitHub release `v0.2.2` is public, not a draft or prerelease, and contains | ||
| - [x] `inspectrum@0.2.2` is publicly retrievable from npm. | ||
| - [x] GitHub release `v0.2.2` is public, not a draft or prerelease, and contains | ||
| `inspectrum-0.2.2.mcpb`. | ||
| - [ ] `main` publicly contains the 0.2.2 `package.json`, `server.json`, Claude | ||
| - [x] `main` publicly contains the 0.2.2 `package.json`, `server.json`, Claude | ||
| plugin manifests, Codex Git marketplace, privacy notice, documentation, | ||
| and optional brand assets. | ||
| - [ ] `npm audit --omit=dev` has no high-severity production finding for the | ||
| - [x] MCP Registry lists `io.github.yannmenec/inspectrum@0.2.2`. | ||
| - [x] Glama lists Inspectrum with the single `review_plan` tool. | ||
| - [x] `npm audit --omit=dev` has no high-severity production finding for the | ||
| exact lockfile used to build the Claude Desktop bundle. | ||
| - [ ] `npm run check:submission -- --public` exits successfully. | ||
| - [x] `npm run check:submission -- --registry` exits successfully, including | ||
| the public npm and GitHub checks. | ||
| - [ ] A fresh public install returns `0.2.2`, exposes exactly `review_plan`, and | ||
| passes `doctor` without leaking secrets. | ||
| The local-only check is safe before release: | ||
| The local checks remain safe after release: | ||
@@ -121,6 +153,6 @@ ```bash | ||
| Use the official `validate` subcommand for this local check. Do not authenticate | ||
| or invoke `publish` until every hard gate below passes. | ||
| Use the official `validate` subcommand. Do not authenticate or invoke a publish | ||
| command merely to recheck an existing listing. | ||
| ## Channel 1 — MCP Registry | ||
| ## Channel 1 — MCP Registry — available | ||
@@ -132,10 +164,6 @@ The registry requires a valid `server.json`, a public install artifact, matching | ||
| `yannmenec`. Local standard-input/output servers are supported; no HTTPS server | ||
| is needed. The registry remains in preview. | ||
| is needed. Version 0.2.2 is publicly listed. Recheck without publishing: | ||
| After all hard gates pass, an authorized operator may run: | ||
| ```bash | ||
| mcp-publisher login github | ||
| mcp-publisher validate server.json | ||
| mcp-publisher publish server.json | ||
| npm run check:submission -- --registry | ||
@@ -153,6 +181,6 @@ ``` | ||
| `.agents/plugins/` and a validated plugin under `plugins/inspectrum/`. This makes | ||
| Inspectrum directly installable from its GitHub repository after 0.2.2 is public; | ||
| Inspectrum directly installable from its public GitHub repository; | ||
| it does not by itself create a listing in OpenAI's curated Plugin Directory. | ||
| After all hard gates pass: | ||
| Install from the existing public source: | ||
@@ -171,3 +199,3 @@ ```bash | ||
| ## Channel 3 — OpenAI Plugin Directory | ||
| ## Channel 3 — OpenAI Plugin Directory — not pursued | ||
@@ -183,3 +211,4 @@ OpenAI's public portal accepts skills-only, MCP-only, and combined submissions. | ||
| plugin's bundled local MCP configuration. This is a follow-up deliverable, not a | ||
| claim that the current package is submission-ready. | ||
| claim that the current package is submission-ready. No submission is claimed | ||
| by this document. | ||
@@ -200,3 +229,3 @@ Before submission: | ||
| ## Channel 4 — Claude Community | ||
| ## Channel 4 — Claude Community — pending | ||
@@ -208,3 +237,4 @@ The target is `claude-community`; `claude-plugins-official` is curated separately | ||
| Prepared form copy: | ||
| The submission is pending and Inspectrum is not present in the public community | ||
| catalog checked on 2026-08-01. Prepared form copy: | ||
@@ -215,5 +245,5 @@ - Display name: `Inspectrum` | ||
| - Plugin path: repository root | ||
| - Description: `A repeatable second-model checkpoint for Claude Code plans: | ||
| automatic at the plan boundary, bounded, fail-open, evidence-backed, and | ||
| always leaves final approval to you.` | ||
| - Description: `An independent pre-flight checkpoint for risky Claude Code | ||
| plans: automatic at plan exit, bounded, fail-open, and always leaves final | ||
| approval to you.` | ||
| - Privacy summary: `No first-party telemetry. Plans are sent to user-configured | ||
@@ -223,6 +253,4 @@ reviewer tools or endpoints and successful sessions are stored locally as | ||
| Rerun `claude plugin validate . --strict`, then use the individual-author form: | ||
| https://platform.claude.com/plugins/submit. The Claude.ai form requires a Team or | ||
| Enterprise organization plus directory-management access: | ||
| https://claude.ai/admin-settings/directory/submissions/plugins/new. | ||
| Rerun `claude plugin validate . --strict` before responding to review feedback. | ||
| Do not resubmit while the current submission remains pending. | ||
@@ -234,18 +262,11 @@ - https://code.claude.com/docs/en/plugins | ||
| ## Channel 5 — Glama | ||
| ## Channel 5 — Glama — available | ||
| Glama verifies GitHub write or administrator access, then builds, runs, and | ||
| introspects the server in a sandbox; a failed reproducible build is not | ||
| discoverable. It also ingests the official MCP Registry. | ||
| discoverable. It also ingests the official MCP Registry. The public | ||
| [Inspectrum listing](https://glama.ai/mcp/servers/yannmenec/inspectrum) reports | ||
| one tool, `review_plan`. Do not opt into Glama hosting or create an HTTPS | ||
| endpoint merely to maintain the listing. | ||
| 1. Publish to the MCP Registry. | ||
| 2. Search https://glama.ai/mcp/servers for `Inspectrum` and | ||
| `io.github.yannmenec/inspectrum`. | ||
| 3. If no listing appears, use **Add Server** with | ||
| https://github.com/yannmenec/inspectrum while signed in as a repository | ||
| maintainer. Do not opt into Glama hosting or create an HTTPS endpoint. | ||
| 4. If a summary field is available, use the **MCP directories** copy above. | ||
| 5. Verify the listing reports one tool, `review_plan`, and the intended local | ||
| standard-input/output install command. | ||
| - https://glama.ai/ | ||
@@ -255,3 +276,3 @@ - https://glama.ai/mcp/servers | ||
| ## Channel 6 — PulseMCP | ||
| ## Channel 6 — PulseMCP — absent | ||
@@ -262,6 +283,8 @@ The server flow at https://www.pulsemcp.com/submit directs maintainers to the | ||
| 1. Publish to the MCP Registry. | ||
| 2. Wait up to one week, then search https://www.pulsemcp.com/servers for | ||
| Inspectrum was not observed in the directory on 2026-08-01. The MCP Registry | ||
| publication is complete. After the documented ingestion delay: | ||
| 1. Search https://www.pulsemcp.com/servers for | ||
| `Inspectrum` and the registry name. | ||
| 3. If still missing or incorrect, email the source URL, registry name, expected | ||
| 2. If still missing or incorrect, email the source URL, registry name, expected | ||
| title, **MCP directories** copy above, and affected field. Exclude | ||
@@ -274,3 +297,3 @@ credentials and private evidence. | ||
| ## Evidence to retain after submission | ||
| ## Evidence to retain for listings | ||
@@ -277,0 +300,0 @@ - MCP Registry: publisher output and the exact API result for version 0.2.2. |
+1
-1
| { | ||
| "name": "inspectrum", | ||
| "version": "0.2.2", | ||
| "version": "0.2.3", | ||
| "description": "Automatic Codex plan review in Claude Code; on-demand in local MCP hosts; human approval stays yours", | ||
@@ -5,0 +5,0 @@ "type": "module", |
+1
-1
@@ -5,3 +5,3 @@ # Privacy and data flow | ||
| This document describes Inspectrum `0.2.2`. Provider and CLI behavior can change independently. | ||
| This document describes Inspectrum `0.2.3`. Provider and CLI behavior can change independently. | ||
@@ -8,0 +8,0 @@ ## Data you provide |
+37
-17
@@ -5,3 +5,3 @@ <div align="center"> | ||
| ### Catch the bad plan before your agent spends the tokens. | ||
| ### Independent review before a risky agent change becomes hard to undo. | ||
@@ -19,7 +19,18 @@ [](https://github.com/yannmenec/inspectrum/actions/workflows/ci.yml) | ||
| Every AI coding disaster starts the same way: a plausible plan, approved in three seconds. | ||
| A plausible plan can commit an agent to a migration, authentication change, | ||
| payment flow, compatibility break, or deployment that is expensive to undo. | ||
| The problem isn't that your agent plans badly — it's that **nobody checks the plan**. You skim it, hit approve, and find out 40 minutes and 200k tokens later that step 2 was wrong. Asking the same model to review its own plan doesn't help: same model, same blind spots, same miss — twice. | ||
| **Inspectrum is an independent pre-flight check before that decision.** Its | ||
| first automatic integration runs when Claude Code exits plan mode: Codex (GPT) | ||
| reviews the plan before the approval dialog reaches you, findings can send the | ||
| plan back for revision, and you keep final approval. If the reviewer cannot | ||
| run, the plan passes through with a visible warning instead of being silently | ||
| reported as reviewed. | ||
| **Inspectrum wires a rival LLM into your agent's plan mode.** When Claude Code finishes a plan, Codex (GPT) reviews it *before* the approval dialog reaches you. Findings bounce the plan back to Claude for revision — so the plan you finally approve has already survived a second opinion. (And if the reviewer can't run, the plan passes through with a warning, never blocked.) | ||
| Here, independent means a reviewer distinct from the author model, invoked | ||
| separately. It does not mean their errors are statistically independent. | ||
| Inspectrum makes the checkpoint repeatable and its failures visible; **a net | ||
| reliability gain and a defensible moat are not yet proven**. The | ||
| [post-0.2.2 strategy](docs/strategy/README.md) defines the evidence gates and | ||
| keeps code review, pull-request review, and pair programming out of scope. | ||
@@ -34,2 +45,9 @@ ## When a skill is enough | ||
| Public availability as of 1 August 2026: | ||
| [npm 0.2.2](https://www.npmjs.com/package/inspectrum/v/0.2.2), | ||
| [GitHub release](https://github.com/yannmenec/inspectrum/releases/tag/v0.2.2), | ||
| [MCP Registry](https://registry.modelcontextprotocol.io/), and | ||
| [Glama](https://glama.ai/mcp/servers/yannmenec/inspectrum). The Claude Community | ||
| submission is pending, and Inspectrum is not listed on PulseMCP. | ||
| ## Quick start | ||
@@ -67,3 +85,3 @@ | ||
| ````text | ||
| Set up inspectrum's Codex plan gate. Use normal approvals only — do not | ||
| Set up Inspectrum's Codex plan gate. Use normal approvals only — do not | ||
| switch to Bypass Permissions or Full Access. | ||
@@ -90,3 +108,3 @@ | ||
| Inside that window, click 'Sign in with ChatGPT', complete the | ||
| login in my browser, then close the Terminal window. inspectrum | ||
| login in my browser, then close the Terminal window. Inspectrum | ||
| is then ready." | ||
@@ -127,7 +145,9 @@ | ||
| ## Why a rival model? | ||
| ## Why a separate reviewer? | ||
| - **Plans are leverage.** A flaw caught at plan time costs a paragraph. The same flaw caught at PR time costs a rewrite. | ||
| - **Self-review is an echo chamber.** The model that wrote the plan is the least qualified to find its blind spots. | ||
| - **Claude and GPT disagree usefully.** Different training, different failure modes, different objections. That disagreement is the product. | ||
| - **Plans are leverage.** A flaw caught before execution can be cheaper to fix than the same flaw found after a difficult-to-reverse change. | ||
| - **Separation makes the check inspectable.** The author and reviewer run independently, and findings remain attributed. | ||
| - **Cross-provider value is a hypothesis.** Claude and GPT can raise different | ||
| objections, but Inspectrum has not yet proved that this produces a net | ||
| reliability gain after false positives, triage, cost, and latency. | ||
| - **Use an existing subscription.** No separate API bill when using your ChatGPT subscription; reviews consume your existing Codex subscription allowance. API-key backends are billed by their provider. | ||
@@ -140,3 +160,3 @@ | ||
| | 🚦 **Plan gate** | Every Claude Code plan reviewed by Codex before it reaches you — automatic, max 2 revision rounds | | ||
| | 🔍 **On-demand review** | `/inspectrum:review` or "Review this plan with inspectrum" from any MCP host | | ||
| | 🔍 **On-demand review** | `/inspectrum:review` or "Review this plan with Inspectrum" from any MCP host | | ||
| | 🧑⚖️ **Multi-reviewer + judge** | Run codex + gemini + claude in parallel; a judge consolidates into one verdict | | ||
@@ -153,3 +173,3 @@ | 📋 **One verdict** | `approve / revise / reject` + findings by severity, with reviewer attribution | | ||
| | **Codex app / CLI** | Claude | `codex mcp add inspectrum -- npx -y inspectrum@latest` + config below | | ||
| | **Claude Desktop** (macOS) | Codex (GPT) | Download [`inspectrum-0.2.2.mcpb`](https://github.com/yannmenec/inspectrum/releases/download/v0.2.2/inspectrum-0.2.2.mcpb), open, confirm. The earlier v0.2.0 bundle was incomplete — use the v0.2.2 asset, not npm/stdio. | | ||
| | **Claude Desktop** (macOS) | Codex (GPT) | Download [`inspectrum-0.2.3.mcpb`](https://github.com/yannmenec/inspectrum/releases/download/v0.2.3/inspectrum-0.2.3.mcpb), open, confirm. The earlier v0.2.0 bundle was incomplete — use the v0.2.3 asset, not npm/stdio. | | ||
| | **Cursor** | Codex (GPT) | [](https://cursor.com/en/install-mcp?name=inspectrum&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsImluc3BlY3RydW1AbGF0ZXN0Il19) | | ||
@@ -163,3 +183,3 @@ | ||
| ````text | ||
| Set up inspectrum so I can review my plans with Claude. Use normal | ||
| Set up Inspectrum so I can review my plans with Claude. Use normal | ||
| approvals only. | ||
@@ -184,6 +204,6 @@ | ||
| - "If claude shows its chat prompt, you're already logged in — | ||
| close the Terminal window. inspectrum is ready." | ||
| close the Terminal window. Inspectrum is ready." | ||
| - "If claude shows /login or opens a browser, complete the sign-in | ||
| with your Claude account, then close the Terminal window. | ||
| inspectrum is then ready." | ||
| Inspectrum is then ready." | ||
| (The ⚠ claude line in the doctor stays even after login because | ||
@@ -295,3 +315,3 @@ claude doesn't expose a status command we can detect — harmless.) | ||
| **`sh: inspectrum: command not found` / `claude mcp list` shows `✗ Failed to connect` — but only when your current directory is the inspectrum repo itself.** `npx inspectrum@<version>` resolves the spec against the *local* package when cwd is inside a package named `inspectrum` whose version matches, and a package's own bin is never self-linked into its `node_modules/.bin`. The published package is fine. Fixes: run from any other directory, or install the real binary once and register that instead: | ||
| **`sh: inspectrum: command not found` / `claude mcp list` shows `✗ Failed to connect` — but only when your current directory is the Inspectrum repo itself.** `npx inspectrum@<version>` resolves the spec against the *local* package when cwd is inside a package named `inspectrum` whose version matches, and a package's own bin is never self-linked into its `node_modules/.bin`. The published package is fine. Fixes: run from any other directory, or install the real binary once and register that instead: | ||
@@ -309,3 +329,3 @@ ```bash | ||
| **If inspectrum caught a bad plan for you, [star the repo ⭐](https://github.com/yannmenec/inspectrum) — it's how other agent-wranglers find it.** | ||
| **If Inspectrum caught a bad plan for you, [star the repo ⭐](https://github.com/yannmenec/inspectrum) — it's how other agent-wranglers find it.** | ||
@@ -312,0 +332,0 @@ MIT — [Yann Menec](https://github.com/yannmenec). Contributions welcome: [CONTRIBUTING.md](CONTRIBUTING.md). |
+2
-2
@@ -11,3 +11,3 @@ { | ||
| }, | ||
| "version": "0.2.2", | ||
| "version": "0.2.3", | ||
| "websiteUrl": "https://github.com/yannmenec/inspectrum/blob/main/docs/claude-code-codex-plan-review.md", | ||
@@ -19,3 +19,3 @@ "packages": [ | ||
| "identifier": "inspectrum", | ||
| "version": "0.2.2", | ||
| "version": "0.2.3", | ||
| "transport": { | ||
@@ -22,0 +22,0 @@ "type": "stdio" |
New alerts
AI-detected potential code anomaly
Supply chain riskAI has identified unusual behaviors that may pose a security risk.
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Fixed alerts
AI-detected potential code anomaly
Supply chain riskAI has identified unusual behaviors that may pose a security risk.
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Improved metrics
- Total package byte prevSize
363915
106.19%- Number of package files
74
12.12%- Lines of code
2957
0.72%- Number of lines in readme file
323
6.6%No dependency changes