example.special-ops-cockpit

@lssm-tech/example.special-ops-cockpit

Special Ops Cockpit est une maquette ContractSpec headless, en français et avec données fictives, pour piloter une mission de retournement PME sans transformer l'IA en chatbot ni en outil de surveillance.

Elle matérialise une mission expert-service design partner comme un système pilotable : dashboard, journal privé, structuration des actions, cartes de revue, playbook 48h, synthèse hebdomadaire, gouvernance IA et feuille de route de modules futurs.

Pourquoi cet exemple existe

Les missions de crise mélangent décisions rapides, preuves terrain, risques cash, reporting incomplet et transmission de méthode. Sans structure, les informations restent dans des notes, des mails, des tableurs ou des conversations dispersées.

Ce cockpit montre comment ContractSpec peut rendre ces workflows explicites :

• les opérations sont déclarées comme contrats ;
• les handlers restent déterministes et testables ;
• les données sont synthétiques, françaises et démonstratives ;
• les éléments soumis deviennent auditables ;
• les brouillons et suggestions restent privés tant qu'ils ne sont pas soumis ;
• la validation humaine reste obligatoire avant toute synthèse ou action de pilotage.

Ce que la démo démontre

• Mission Dashboard — état de mission visible par Nathalie, limité aux artefacts soumis et revus.
• Journal de mission — brouillon privé pour Hugo, avec structuration assistée des actions, risques, prochaines étapes et preuves de valeur.
• Trust Panel — séparation explicite entre ce qui est visible, non visible, auditable et interdit.
• Review Cards — cartes soumises avec source attachée, décision humaine et options approuver / modifier / rejeter / inclure / créer action / escalader.
• Playbook 48h — jalons de retournement, preuves attendues, blocages et manques d'information.
• Weekly Report — synthèse hebdomadaire uniquement à partir de cartes approuvées, export Markdown stable, statut brouillon jusqu'à validation.
• AI Stack Governance — lecture des profils d'équipe, niveaux de maturité IA, risques de données et besoins de formation sans recommandation fournisseur définitive.
• Future Modules — roadmap Cash Scenario Simulator, Qualiopi, onboarding, PO/ARC matching, e-invoicing, knowledge base, mission playbook et offre Mission Control.

Modèle de confiance

Doc route: /docs/examples/special-ops-cockpit/trust-model.

Ce n'est pas un dispositif de contrôle salarié. Le cockpit est auditable au niveau mission, pas intrusif au niveau individu.

Le système ne montre pas à Nathalie :

• les brouillons privés non soumis ;
• les suggestions ignorées ;
• les captures d'écran ;
• l'historique navigateur ;
• les temps d'activité ;
• les scores de productivité ;
• les notes brutes avant soumission.

Le système montre uniquement :

• les artefacts explicitement soumis ;
• les cartes de revue créées depuis ces artefacts ;
• les décisions de validation ;
• les preuves attachées à une action mission ;
• les manques de preuve nécessaires pour piloter la mission.

Mapping ContractSpec

Ce qui est simulé

• Client fictif : Fonderie Atlantique, PME industrielle de 85 salariés et 14M€ de CA.
• Mission : crise cash, départ RAF, reporting absent, litiges fournisseurs et risque approvisionnement.
• Données : notes terrain synthétiques, montants de démonstration 42k€, 28k€, 18k€.
• Acteurs : Nathalie D., Hugo V., Marc P., Fritz L., Léa G. et autres personas fictifs.
• IA : assistance structurante simulée, jamais autonome, toujours sous revue humaine.

Running Locally

Depuis examples/special-ops-cockpit :

• bun run build
• bun run typecheck
• bun run test
• bun run smoke
• bun run preflight

Depuis la racine du monorepo, si le workspace est disponible :

• bun ./node_modules/turbo/bin/turbo run typecheck --filter=@lssm-tech/example.special-ops-cockpit
• bun ./node_modules/turbo/bin/turbo run build --filter=@lssm-tech/example.special-ops-cockpit
• bun ./node_modules/turbo/bin/turbo run test --filter=@lssm-tech/example.special-ops-cockpit

Déroulé de démo 10 minutes

Doc route: /docs/examples/special-ops-cockpit/demo-script. Le script importable vit dans @lssm-tech/example.special-ops-cockpit/docs/demo-script-expert-network.

1. Positionner la promesse — présenter une maquette fonctionnelle de cockpit mission, pas un produit fini ni un chatbot.
2. Ouvrir le Mission Dashboard — montrer l'état de la mission, les risques cash et les artefacts visibles par Nathalie.
3. Passer au Journal de mission — montrer l’espace et la frontière de brouillon privé sans exposer son contenu, puis expliquer que rien ne remonte sans soumission.
4. Structurer une note terrain — transformer une note brute en action, risque, preuve et prochaine étape.
5. Soumettre une entrée — créer une trace auditée et des cartes de revue.
6. Afficher le Trust Panel — expliciter ce qui est visible, non visible et interdit.
7. Revoir les cartes — Nathalie approuve, modifie, rejette ou escalade des éléments soumis.
8. Lire le Playbook 48h — relier les entrées soumises aux jalons et preuves attendues.
9. Composer la synthèse hebdo — inclure uniquement les cartes approuvées et garder le rapport en brouillon.
10. Terminer par la roadmap — relier le pilote à l'offre Mission Control : cash scenario, Qualiopi, onboarding, PO/ARC, e-invoicing et knowledge base.

Script commercial court

J'ai préparé une maquette fonctionnelle, pas comme un produit fini, mais pour matérialiser ce que pourrait être un cockpit Special Ops. L'idée n'est pas un chatbot ni un outil de surveillance. L'idée est de transformer une mission en système pilotable : playbook, journal de mission, validation, synthèse et capitalisation.

Le bon premier pilote serait une mission réelle ou anonymisée avec journal de mission, review Nathalie, playbook 48h et synthèse hebdo.

Pilote expert-service design partner suggéré

• Semaine 1 : choisir une mission réelle ou anonymisée, cadrer le journal de mission et les cartes de revue.
• Semaine 2 : valider le playbook 48h, les preuves attendues et la synthèse hebdomadaire.
• Semaine 3 : tester la gouvernance IA par persona et choisir les deux modules suivants.
• Semaine 4 : transformer les apprentissages en offre Expert Mission Control Sprint.

Public Entry Points

• @lssm-tech/example.special-ops-cockpit
• @lssm-tech/example.special-ops-cockpit/contracts
• @lssm-tech/example.special-ops-cockpit/docs
• @lssm-tech/example.special-ops-cockpit/docs/special-ops-cockpit.docblock (alias of ./docs)
• @lssm-tech/example.special-ops-cockpit/docs/demo-script-expert-network
• @lssm-tech/example.special-ops-cockpit/example
• @lssm-tech/example.special-ops-cockpit/fixtures
• @lssm-tech/example.special-ops-cockpit/handlers
• @lssm-tech/example.special-ops-cockpit/proof
• @lssm-tech/example.special-ops-cockpit/special-ops-cockpit.feature
• @lssm-tech/example.special-ops-cockpit/ui
• @lssm-tech/example.special-ops-cockpit/ui/SpecialOpsCockpitPreview
• @lssm-tech/example.special-ops-cockpit/ui/special-ops-cockpit-preview.data

Preview / export workflow

The public template preview for this example is package-native: the ./ui export renders a contained interactive cockpit with nested navigation, a landing screen, and eight workflow-specific targets for mission dashboard, journal, trust panel, review cards, 48h playbook, weekly report, AI governance, and future modules from deterministic fixtures already owned by this package. The sidebar is scoped to the preview surface so hosts can embed it below their own headers without viewport overlap. The eight operational screen keys and order remain the compatibility contract; landing and navigation data are additive.

Reusable shell exception: unlike compatible examples such as Integration Hub, BillingOS France SME, and Service Business OS, this preview intentionally does not wrap the cockpit in NestedCommandShell. Its local shell owns a contained nested navigation rail so host pages can embed the cockpit below their own headers without fixed-position overlap, viewport takeover, or leakage of private-draft trust boundaries. Keep the local navigation exception documented here unless those containment guardrails move into the shared nested-safe shell contract.

Consumers should keep the docs, sandbox, LLMS, source, preview, and render-model fallback links visible. A registry refresh must be produced by the generator rather than by hand-editing generated files.

Notes d'implémentation

• Les fixtures restent fictives et ne doivent pas contenir de données client réelles.
• Les handlers doivent rester purs, déterministes et sans accès réseau, LLM, DB, filesystem ou environnement.
• Les exports publics incluent ./ui : les écrans restent alimentés par des fixtures déterministes et des render models de démo.
• Toute refresh de registry doit passer par le générateur, jamais par édition manuelle.
• Les changements de démo et de metadata doivent rester cohérents avec AGENTS.md, CHANGELOG.md, package.json, les docblocks et les exports publics.

Declaration publication uses contractspec-bun-build types through build:types; build runs bundle and declaration generation. The build config preserves declared exports and excludes test-only files from generated build artifacts. Package tests and typecheck remain separate verification gates.