Pipeline de stratégie (Phase 11)

Appelé par [[drive-business]] CHEMIN B, ou directement quand l'opérateur demande de planifier une entreprise productisée existante.

Déclencheurs

• company_plan
• company_capabilities
• company_plan_apply
• set up strategy
• capability audit
• 30 day plan
• marketing plan
• blockers
• strategy inputs

Pipeline (5 outils, dans l'ordre)

1. company_capabilities(<slug>)

Audit du vault + outils + skills. Écrit capabilities.md. Retourne une map structurée.

2. Récupérer les inputs de stratégie auprès de l'opérateur en chat

Puis company_set_strategy_inputs(slug, …) — MODÉRÉ. Champs :

• target_audience (spécifique, pas "entreprises")
• competitors (3-5 par nom)
• current_challenges / unique_selling_points
• budget_type (organique / mixte / payant) + budget_amount + budget_period
• risk_tolerance (0-100)
• primary_goals (3-5 parmi : Brand Awareness, Lead Gen, Sales Growth, Retention, Thought Leadership, Community, Content Authority, Market Disruption, Competitive Advantage, AI Search Visibility)
• strategy_mode (standard / unconventional / guerrilla / brand-awareness / controversial)
• focus (full / seo / geo / content / paid / social / email / brand)
• timeline_hint

3. company_plan(<slug>, override_strategy_mode=…, override_focus=…)

Prépend de manière déterministe le CONTEXTE OPÉRATIONNEL (calendriers actifs + ledger des 7 derniers jours + funnel prospects + missions) pour que la stratégie couvre CHAQUE surface, pas seulement what_we_sell. Écrit strategy/proposed/<timestamp>.yaml.

4. company_plan_apply(<slug>) — MODÉRÉ

Atomiquement :

• Détecte les blockers (5 types — voir ci-dessous)
• Mission + N objectifs (tactic_meta packée dans plan_json) + calendriers (depuis timeline.month1/2/3 via execution_priority)
• Écrit voice_proposed.yaml depuis creativeDirections.hookTemplates
• Écrit blockers.yaml
• Promeut proposed → active, archive prior

5. company_plan_approve(<slug>, note="…") — MODÉRÉ

Finalisation opérateur. Touche la mission stratégique pour que l'arbiter la classifie haut.

Résolution des blockers (3 chemins)

Chaque blocker dans blockers.yaml a une resolution_proposal :

• ask : l'opérateur doit agir (credentials, décisions métier). Surface en chat avec build_hint.
• build : le candidat arbiter depuis from_buildable_blockers invoque self_create_plugin (build_method) ou skill_promote. PERMISSIONS CRITIQUES à chaque build. En mode chat, n'essaye que si l'opérateur approuve explicitement.
• defer : l'opérateur a marqué la tactic comme hors scope. Note et continue.

Couverture des surfaces (CRITIQUE)

Le bloc CONTEXTE OPÉRATIONNEL liste chaque surface active (X growth, Pump.fun, email, funnel prospects, etc.). La stratégie résultante DOIT adresser chacune — pas seulement what_we_sell. Une stratégie mono-surface pour une entreprise multi-surface est un échec qualité.

Règles strictes

• ❌ Ne saute pas company_capabilities — pas de contexte opérationnel = stratégie étroite.
• ❌ Ne saute pas l'approbation de strategy_inputs par l'opérateur — ces appels ne sont pas les tiens.
• ❌ Ne promeut pas proposal en active via file_write — utilise company_plan_apply.
• ❌ N'appelle pas apply + approve dos-à-dos sans surfacer les blockers entre.
• ❌ N'invoque pas self_create_plugin sur un blocker build sans approbation chat explicite.
• ❌ Ne replanie pas une entreprise avec une stratégie active sauf si l'opérateur demande.

Vérifier

• [ ] 5 étapes ont tourné dans l'ordre
• [ ] strategy/active/strategy.yaml existe
• [ ] blockers.yaml surfacé à l'opérateur
• [ ] Voice amorcée si hookTemplates peuplée
• [ ] Tactics couvrent toutes les surfaces du contexte opérationnel