RFC: tuner observability + control surface for the app (commands, displays, visual git tracking)

[Nibbler1250]

Plan — Surface complète du système tuner + interface (control-plane app de Terry)

But : répertorier TOUTES les commandes, affichages et suivis du tuner, et les mapper
sur des panneaux de l'app (web + Tauri, #285), avec un suivi git visuel de bout en bout.

---

1. INVENTAIRE de la surface tuner

A. Commandes & outils (les "verbes")

Surface	Verbes	Où
CLI wisecron	cron-run (détecte→propose), apply <id> --alt, mature (évalue fitness), status, diagnose	claudeclaw-outcome skills-tuner/cli
Gate MCP tuner__*	propose, propose_external (research), pending, list, apply, refuse, mature, status	gate-mcp.ts
Télémétrie MCP telemetry__*	capabilities, query (read-only)	telemetry-mcp.ts (= PR #286)
Scouts de recherche	model-routing, mcp-plugin, memory (LLM) + registry-refresh (fetch+drift)	research-scout-pilot/
Pending → Telegram boutons	wisecron-proposals-notifier.py (boutons ✅/⏸/❌) + pending-worker.py (dispatch)	agent/scripts

B. Sources de données (les "noms" à afficher)

Source	Contenu
wisecron.db	proposals (pending/applied/refused), outcomes (baseline→mesuré→verdict), priors (EWMA), subject_state, rollback_history, telemetry_cache
Chaîne d'audit (tamper-evident)	gate_propose, gate_apply, gate_refuse, wisecron_proposal_applied (+commit_sha), wisecron_auto_revert(+_failed), wisecron_rollback, wisecron_cycle_start/complete, wisecron_signature_mismatch, wisecron_validate_failed, fitness_active/inactive, telemetry_query
pending_actions.db	actions Telegram (status approved/done, decision, telegram_message_id)
Repos git (NOUVEAU)	simon-memory, fichiers de config → commits [tuner] <subject> #<id> + inverse_patch + .bak

---

2. PANNEAUX de l'interface (mapping)

1. 🚪 File du gate humain (le cœur) — propositions pending : sujet, source (research vs télémétrie), diff preview, boutons Approuver/Plus-tard/Rejeter. ← tuner__pending + proposals.
2. 🔁 OutcomeLoop / Outcomes — appliquées : baseline → fitness mesuré → verdict, fenêtre d'observation, auto-revert status. ← outcomes + priors.
3. 📊 Observabilité télémétrie — les 10 streams, dispo par stream (available+reason), courbes fitness par sujet. ← telemetry__* + telemetry_cache.
4. 🧩 Sujets — les 8 TunableSubjects : enabled, risk_tier, dernier cycle, # propositions. ← subject_state.
5. 🔬 Scouts de recherche — fraîcheur du registre, rapport de drift (⚠ DRIFT, ✚ NEW), runs des scouts, rejets de la vérif adversariale (la sécu qui fait son job), source:research. ← model-registry.json _meta + logs scouts.
6. 🔒 Chaîne d'audit — log infalsifiable, provenance de chaque nombre/décision, verify-chain status (✓/✗). ← audit log.
7. 🌳 Suivi GIT visuel (NOUVEAU — voir §3).

---

3. SUIVI GIT VISUEL (la demande)

Maintenant que chaque apply commit [tuner] <subject> proposal #<id> (alt …) via <source> sur la cible git-trackée, on a un trail exploitable visuellement :

• Timeline / graphe git des commits tuner across repos (simon-memory + configs) — un nœud par apply, coloré par sujet, lié à son outcome (verdict).
• Par proposition : le commit_sha, le diff visuel (avant/après), git blame (qui/quand/pourquoi), et un bouton Revert = git revert <sha> (en plus de l'inverse_patch).
• 3 couches de revert exposées : .bak (immédiat) · inverse_patch (auto-revert sur régression) · git revert (historique propre) — l'UI montre laquelle est dispo.
• Lien outcome↔commit : chaque ligne d'Outcomes pointe vers son commit ; un auto-revert apparaît comme un 2e commit revert lié.
• Diff de la proposition AVANT apply : tuner__pending expose diff_or_content → preview diff dans la file du gate (avant même le commit).

---

4. CONTRATS API (ce que l'app lit — un seul gateway)

• GET /tuner/proposals?status= ← proposals (pending/applied/refused) + jointure outcomes.
• GET /tuner/outcomes/:id ← baseline/mesuré/verdict/commit_sha.
• GET /tuner/telemetry/:stream ← telemetry__query (read-only, = feat(telemetry): host telemetry over MCP — read-only measurement surface (telemetry__*) [#275 brick 1] #286).
• GET /tuner/audit?since= ← chaîne d'audit + verify-chain.
• GET /tuner/git/:repo/log + /diff/:sha + POST /tuner/git/revert/:sha ← le suivi git visuel.
• POST /tuner/apply/:id + /refuse/:id ← le gate (déjà les boutons Telegram, mêmes appels).
• WS tuner.events ← stream live (nouvelle proposition, apply, revert) pour la file + la timeline.

---

5. PHASING (s'emboîte sur les briques déjà faites)

• Déjà live : gate tuner__* (feat(tuner): OutcomeLoop + model-routing subject — single-subject proof [#275 brick 2, stacked on #286] #287), télémétrie telemetry__* (feat(telemetry): host telemetry over MCP — read-only measurement surface (telemetry__*) [#275 brick 1] #286), boutons Telegram (notifier+worker), git-commit dans l'apply (câblé ce jour), scouts (model-routing live + mcp_plugin/memory écrits).
• Phase 1 (read-only) : panneaux Observabilité (3) + Outcomes (2) + Audit (6) — lecture seule sur les sources ci-dessus. Faible risque, rejoint la "Phase 1" de l'app (RFC: tuner observability + control surface for the app (commands, displays, visual git tracking) #285).
• Phase 2 (gate) : File du gate (1) avec approve/refuse + diff preview — déjà câblé côté Telegram, l'app = 2e surface canonique.
• Phase 3 (git visuel + scouts) : panneau Git (7) + Scouts (5) — la timeline, le diff, le revert, le drift report.
• Phase 4 : Sujets (4) + extension aux autres scouts.

---

6. POUR TERRY (alignement gouvernance)

• Tout mutant reste derrière le gate humain ; l'app rend visible la provenance (audit) + le trail git (revert propre) = exactement l'angle finance-réglementée / governance de POVIEW.AI.
• Read-only d'abord (Phase 1), surface mutante (gate) ensuite — même staging que RFC: tuner observability + control surface for the app (commands, displays, visual git tracking) #285.

[Nibbler1250]

Reframed: this is the tuner panel of the control-plane app you asked about — a full inventory of the tuner surface (commands, data sources, audit chain) mapped to UI panels, plus a visual git-tracking view now that every applied proposal lands a [tuner] … commit (revert via git on top of the inverse-patch). Read-only panels first (Phase 1), gate surface after — same staging as the app discussion in #275. Stacks on #286 (telemetry) + #287 (OutcomeLoop).