SPB Git forge

spb/admin-ka

Public
41commits 1branches 0releases
172.9 MBsize
maindefault branch
19 days agolast push
JavaScript 65.5% Python 17.8% CSS 13% HTML 3.7%
ZIP tar.gz
NameLast commitUpdated
data chore: retirer aussi data/eco.sqlite du suivi git 24 days ago
deploy admin-ka v1 — console chat Claude Code (administration-ka.com) 1 mo ago
docs docs: README ultra détaillé + visite guidée en 10 captures 26 days ago
node_modules feat(house-ka): House-Ka dans la console admin-ka 27 days ago
public archive 2026-09-04 : retrait de crea-ka, trouve-ka, resto-ka,... 19 days ago
server archive 2026-09-04 : retrait de crea-ka, trouve-ka, resto-ka,... 19 days ago
.gitignore topologie vivante : sites, projets Claude Code et nœuds lus dans le... 19 days ago
CLAUDE.md topologie vivante : sites, projets Claude Code et nœuds lus dans le... 19 days ago
package-lock.json Social: ecran du noeud embarque (noVNC) + reels pro + fix scroll 1 mo ago
package.json Social: ecran du noeud embarque (noVNC) + reels pro + fix scroll 1 mo ago
README.md docs: README ultra détaillé + visite guidée en 10 captures 26 days ago
README.md source

Admin-Ka — écran de connexion

Admin-Ka — administration-ka.com

Le Control Center du Groupe Ka.
Console d'administration privée qui pilote le vrai Claude Code CLI sur le cluster MacLustr,
surveille les 19 sites de l'écosystème en temps réel et mesure le trafic humain de toutes les plateformes.

www.administration-ka.com · nœud M3U96a · port 3300 · launchd + ngrok


Console privée. L'accès est protégé par un mot de passe d'application (haché scrypt, cookie de session HttpOnly/Secure). Il n'y a pas d'inscription : c'est l'outil interne d'exploitation du Groupe Ka. Aucun secret n'est présent dans ce dépôt — la configuration sensible vit dans data/config.json (non versionné) et la clé Anthropic est lue depuis ~/.claude/.env sur le nœud.


# Sommaire

  1. C'est quoi, Admin-Ka ?
  2. Visite guidée en 10 captures
  3. Les modules, en détail
  4. Identité visuelle
  5. Architecture
  6. Modes de permission
  7. Auth & sécurité
  8. Structure du dépôt
  9. Déploiement & exploitation
  10. Apps natives compagnes
  11. Contact

# C'est quoi, Admin-Ka ?

Admin-Ka est né comme une console chat mobile-first pour lancer Claude Code sur le nœud M3U96a depuis un iPhone. C'est devenu, au fil des versions (v2 puis v3 « Control Center »), le poste de commandement complet du Groupe Ka :

text
iPhone / Mac ⇄ https://www.administration-ka.com (ngrok) ⇄ backend :3300 (M3U96a)
                                                              ├── claude CLI local (apps M3U96a)
                                                              ├── ssh <nœud> → claude CLI (apps distantes, repo de prod)
                                                              ├── monitor.js  → health checks 19 sites, sweep nœuds
                                                              ├── analytics.js → trafic humain des plateformes Ka
                                                              └── social.js  → Studio (posts FB, Reels, musique)

Principe fondateur — rien de simulé : le chat parle au vrai binaire claude (jamais à l'API Messages pour coder), le monitoring frappe les vrais sites en HTTPS, les analytics comptent les vrais visiteurs, les actions d'admin exécutent de vrais pm2 restart / git log sur les nœuds.

Un seul opérateur, dix-neuf sites, vingt nœuds : tout se pilote depuis cette page.


# Visite guidée en 10 captures

Les captures 03 à 10 montrent la console connectée (après authentification) ; les captures 01, 02 et le login mobile montrent ce que voit un visiteur non authentifié : un simple mot de passe, rien d'autre.

# 01 — Écran de connexion (desktop)

Écran de connexion

La porte d'entrée : pastille « Ka » orange, un champ mot de passe, un bouton. Aucune information n'est exposée avant l'authentification — la mention discrète M3U96a · MacLustr rappelle seulement sur quel nœud la console tourne.

# 02 — Écran de connexion (mobile)

Connexion mobile

Le même login, pensé iPhone d'abord : carte centrée, safe-areas respectées, champ à 16 px (anti-zoom iOS).

# 03 — Console connectée : la Vue d'ensemble

Console connectée

Premier écran après connexion : le cockpit. Sidebar de navigation à gauche (Vue d'ensemble, Claude Code, Sessions, Prompts, Écosystème, Visiteurs, Studio, Réglages), KPIs en tuiles (humains en ligne / aujourd'hui, sessions, pages vues, 19/19 sites en ligne, incidents, uptime 24 h, latence moyenne, sessions Claude actives, coût Claude cumulé), graphique « Visiteurs humains — 30 jours » avec l'ancienne série v1 en pointillé, chips d'état des 19 sites avec leur latence live, et le journal des incidents récents.

# 04 — Onglet Sessions

Onglet Sessions

Toutes les conversations Claude Code, filtrables par recherche, application et statut. Chaque ligne affiche le premier prompt, l'app cible (ou « Orchestrateur multi-sites »), le modèle, la taille de contexte (ctx), le coût en dollars et l'ancienneté — avec un bouton Reprendre (le --resume du CLI, transcript rejoué) et une suppression.

# 05 — Onglet Écosystème

Onglet Écosystème

Le monitoring temps réel : bandeau global (19/19 en ligne, uptime 24 h, latence moyenne, 36,5 k checks/24 h, échecs, incidents), puis une carte par site — sparkline de latence, barre d'uptime, p95/p99, nombre de checks, et la ligne d'infrastructure : nœud, état du process (pm2/launchd), âge du dernier commit, jours restants sur le certificat SSL.

# 06 — Console mobile

Console mobile

La même console sur iPhone : bottom nav 5 entrées (Vue d'ensemble, Claude Code, Écosystème, Visiteurs, Plus), cartes empilées, tout le contenu de l'Écosystème accessible au pouce. C'est l'usage d'origine d'Admin-Ka : administrer le groupe depuis n'importe où.

# 07 — Vue d'ensemble (rafraîchie)

Vue d'ensemble

Le cockpit se met à jour en continu (horodatage maj en haut à droite) : latences recalculées à chaque cycle de checks, ligne de synthèse du filtrage de trafic du jour (ex. « 92 humains · trafic filtré : 51 149 crawler + 36 datacenter + 274 automation »), anomalies de la dernière heure.

# 08 — Onglet Claude Code

Onglet Claude Code

Le cœur historique : « Le vrai Claude Code, lancé sur le nœud de chaque app du Groupe KA ». Picker de cible (une app précise, ou Tous les sites KA (20) = mode orchestrateur multi-sites), choix du modèle et du mode de permissions, suggestions de démarrage, reprise en un tap des dernières sessions, et le champ « Demander à Claude Code… » avec son bouton d'envoi orange.

# 09 — Onglet Prompts

Onglet Prompts

La bibliothèque de prompts réutilisables : chaque prompt a un titre, une app cible (ou « app au choix »), un aperçu, et quatre actions — Lancer (démarre une session Claude Code avec ce prompt), ✨ Améliorer (l'upgradeur de prompts réécrit la demande via l'API Anthropic avec la connaissance du Groupe Ka injectée), Éditer, Dupliquer, plus favoris ★ et compteur d'usage.

# 10 — Onglet Visiteurs

Onglet Visiteurs

Les analytics v2 : bascule Humains / Tout le trafic, KPIs (en ligne < 2 min, humains du jour avec variation vs hier, sessions, pages vues, uniques 7 j / 30 j), barre de répartition par classe (humains / crawlers / datacenter / automation / interne — ici 900 humains pour 51 153 hits de crawlers filtrés), temps réel, panneau d'anomalies avec inspecteur d'IP/visiteur, puis les cartes par application (humains, sessions, pages, 7 j, tendance vs hier).


# Les modules, en détail

# 1) Claude Code — pilotage du vrai CLI

L'exigence non négociable du projet : jamais l'API Messages pour coder, toujours le binaire claude, en mode headless :

text
claude -p --output-format stream-json --verbose --include-partial-messages
  • cwd = le repo de prod de l'app choisie, sur son nœud de déploiement. Les apps de M3U96a tournent en local ; les autres (lou-ka sur M3U96b, immo-ka sur M4M64a, house-ka sur M4M64b, trouve-ka sur M2M32…) sont pilotées via SSH sur leur nœud — le repo de prod est la seule source de vérité, aucun clone.
  • Streaming intégral : chaque événement du stream (texte, thinking, tool_use, tool_result, result) est relayé au navigateur et rendu comme dans le terminal — diffs colorés pour Edit/Write, blocs outils repliables, TodoWrite en checklist, Markdown (marked) + coloration syntaxique (highlight.js), copie des blocs de code.
  • Options exposées dans l'UI : modèle par session (Fable 5 par défaut, Opus, Sonnet, Haiku — --model toujours passé explicitement, sinon les nœuds retombent sur leur défaut local), mode de permissions, choix du projet, /clear /compact /cost /resume, modèle actif, session ID, coût cumulé en direct, tokens de contexte (+ %), file d'attente de messages, chrono d'exécution.
  • Mode orchestrateur multi-sites : la cible « Tous les sites KA » lance une session qui coordonne des changements sur l'ensemble du parc (c'est le mode utilisé pour les campagnes transverses — mobile, stats, README…).
  • Chaque run reçoit un --append-system-prompt maison : après toute modification → rebuild + pm2 restart + healthcheck + commit/push spbgit (origin, jamais GitHub).

# 2) Sessions — détachées, reprenables, rejouables

Le process claude ne dépend jamais du WebSocket :

  • On peut fermer l'onglet, verrouiller l'iPhone, perdre le réseau — la tâche continue sur le nœud.
  • Le transcript est persisté en JSONL (data/transcripts/*.jsonl) ; à la reconnexion, l'app rejoue l'historique manqué puis reprend le live.
  • Reprise auto durcie : la console rouvre la dernière conversation au lancement (lastChatId) et force reconnexion + resync au retour au premier plan (visibilitychange / online — iOS coupe le WS à l'écran verrouillé). Reconnexion avec backoff + indicateur d'état.
  • États clairs : en cours / en attente de permission / inactive ; notifications in-app en fin de tâche ou quand une permission attend.
  • --resume <session-id> pour continuer une session CLI existante, coût et contexte conservés.

# 3) Prompts — bibliothèque + upgradeur de prompts

  • Prompts réutilisables associés à une app (ou « app au choix »), avec favoris ★, duplication, compteur d'usage, recherche et filtre par app.
  • Upgradeur de prompts : le bouton ✨ Améliorer envoie la demande brute à l'API Anthropic (modèle configurable, Opus par défaut) avec un système de connaissance du Groupe Ka injecté (les 19 sites, leurs nœuds, leurs process managers, les conventions remote-first) — et renvoie un prompt excellent, prêt pour Claude Code. L'upgradeur ne répond jamais lui-même : il ne fait que réécrire.

# 4) Écosystème — monitoring des 19 sites

server/monitor.js, zéro dépendance native (node:sqlite intégré) :

  • Health checks HTTPS toutes les 45 s de chacun des 19 sites du groupe depuis M3U96a : latence, code HTTP, jours restants sur le certificat SSL.
  • Sweep des nœuds toutes les 5 min : charge / RAM / disque + statut, CPU et mémoire des process PM2 + âge du dernier commit git. Les sites sous launchd (KA Guardian sur M4M36) sont gérés spécifiquement — pas de pm2 sur ce nœud.
  • Historique SQLite (data/eco.sqlite, rétention 35 j) : uptime 24 h / 7 j / 30 j, latence moyenne et p95/p99, sparklines, graphique 24 h, barres d'uptime 14 j.
  • Incidents : 2 échecs consécutifs → alerte ; rétablissement → alerte verte ; vue Incidents globale avec durées.
  • Actions d'admin par site, exécutées localement ou via ssh sur le nœud du site : redémarrer PM2 (/api/admin/action), logs récents (/api/admin/logs), git & derniers commits (/api/admin/commits).
  • Push temps réel vers l'UI via le même WebSocket que le chat.

# 5) Visiteurs — analytics v2 « trafic humain »

server/analytics.js + le beacon public/ka-a.js, déployé sur les sites du groupe. Définitions officielles :

  • Visiteur humain : identifiant classé human = UA navigateur + JS réellement exécuté + réseau non-datacenter/non-proxy + pas interne + pas de flood.
  • Session : trou > 30 min = nouvelle session. Page vue : événement pv réel (navigation, SPA incluse) — un heartbeat n'est jamais une page vue. En ligne : dernier événement humain < 120 s, expire tout seul.
  • 5 classes : human / crawler / datacenter / automation / internal, classées à l'insertion (regex UA + cache IP-intelligence avec hosting/proxy/ASN, reclassement rétroactif, anti-flood). Les métriques principales n'affichent que les humains ; le reste vit dans la barre de répartition et le toggle « Tout le trafic ».
  • Beacon v2 (ka-a.js) : vid/sid en localStorage, pv SPA via pushState, heartbeat 25 s seulement onglet visible + interaction récente. Le beacon v1 reste supporté (dé-duplication côté serveur) et l'ancienne série s'affiche en pointillé « ancien comptage v1 (non filtré) » — jamais comparée directement.
  • Tables SQLite : events (brut, 45 j), ipinfo (cache), daily2 (rollup quotidien par classe, long terme). Anomalies de trafic + inspecteur d'IP / de visiteur intégré.
  • Suite de tests : node server/test-analytics.mjs — 28 scénarios (humain/refresh/SPA, Googlebot, bot d'uptime, IP AWS, curl, interne, dédup v1, invariants uniques ≤ sessions ≤ pv, expiration en ligne). À lancer depuis une copie du dépôt (écrit dans data/).

# 6) Vue d'ensemble — le cockpit

La page d'accueil de la v3 « Control Center » : elle agrège tout ce qui précède en un écran — KPIs humains + écosystème + Claude (dont le coût cumulé), graphique 30 jours, chips des 19 sites, incidents récents, anomalies de la dernière heure, raccourcis vers les sessions Claude.

# 7) Studio — module Social (Facebook & Reels)

server/social.js + server/social/*.py :

  • Auto-post Facebook : cartes statistiques et carrousels générés aux couleurs de chaque site du groupe (rendu HTML → image), publiés sur la page Facebook Groupe Ka.
  • Reels multi-scènes : make_reel.py assemble des vidéos verticales multi-scènes à partir des données live des plateformes.
  • Moteur musical numpy : music_engine.py synthétise les pistes audio des Reels (pas de banque de sons externe).
  • Galerie des rendus dans l'onglet Studio, insights de page (insights.py).
  • Les rendus vivent dans data/social/ (non versionné).

# 8) Gardiens KA Guardian (ka2 / ka4 / ka6)

Les trois agents gardiens autonomes des connecteurs (ka2.bot / ka4.bot / ka6.bot — un seul repo FastAPI sur M4M36, sous launchd) sont intégrés à la console :

  • Chat direct avec chaque gardien depuis Admin-Ka.
  • Cartes dédiées dans l'Écosystème (health checks, latence, uptime comme les autres sites).
  • Actions launchd sur M4M36 (redémarrage des gardiens) depuis l'interface.

# 9) Écran du nœud (noVNC)

Un pont WebSocket intégré (/vncws) relie le client noVNC embarqué au Partage d'écran du nœud (127.0.0.1:5900) : on voit et contrôle l'écran de M3U96a directement dans le navigateur, sans exposer VNC sur le réseau — utile notamment pour le module Social (automatisation d'interface).


# Identité visuelle

L'identité Groupe Ka, déclinée « console » :

  • Crème #F2F1EC en fond, orange #F97316 en accent (traits de graphe #e05f00), encre #1a1611.
  • Héritage néo-brutaliste (cartes à bords francs, pills, pastille « Ka », typo ronde) modernisé en v3.1 : hairlines + ombres douces, rayons contenus, segmented controls nets — esprit Linear/Vercel, identité crème + orange conservée.
  • Dark mode réel (ka_theme auto / clair / sombre) via variables CSS.
  • Desktop-first depuis la v3 : sidebar ≥ 1020 px + topbar ; mobile : bottom nav 5 entrées avec safe-areas iPhone.
  • Statuts jamais en couleur seule (● ▲ ■ + libellé).

# Architecture

text
iPhone / Mac ⇄ wss://www.administration-ka.com (ngrok) ⇄ backend :3300 (M3U96a, loopback)
   backend ⇄ claude CLI (local — apps M3U96a)
   backend ⇄ ssh <nœud> claude CLI (apps distantes, repo de prod)
             └ tunnel SSH inverse -R : cartes de permission (perm-mcp MCP)
   backend ⇄ monitor.js  : health checks 45 s + sweep nœuds 5 min + SQLite + push WS
   backend ⇄ analytics.js: beacon ka-a.js → events/ipinfo/daily2 (SQLite)
   backend ⇄ social.js   : Studio (Python : cartes, Reels, musique)
   backend ⇄ /vncws      : pont noVNC → Partage d'écran 127.0.0.1:5900
  • Node.js pur (modules ES), serveur HTTP + WebSocket maison — deux seules dépendances npm : ws et @novnc/novnc. SQLite via node:sqlite intégré (aucune dépendance native).
  • Frontend une page, aucun framework : public/index.html + app.js + style.css, vendors locaux (marked, highlight.js, noVNC).
  • Permissions distantes : server/perm-mcp.js est un serveur MCP stdio (--permission-prompt-tool mcp__adminka__approve), déployé aussi sur M3U96b / M4M64a / M4M64b / M2M32 dans ~/.adminka/. Chaque demande de permission devient une carte Autoriser / Refuser dans le chat (long-poll, timeout 10 min → refus). Comme l'IPv4 LAN n'est pas routée entre tous les nœuds et que Tailscale inter-nœuds est bloqué, les réponses transitent par un tunnel SSH inverse (-R).
  • Persistance (data/, non versionné) : config.json (secrets et réglages), sessions.json, chats.json, transcripts/*.jsonl, eco.sqlite, analytics.sqlite, audit.jsonl, logs.

# Modes de permission

  • Sûr (défaut) : lecture libre (Read, Glob, Grep, LS, WebFetch, WebSearch, TodoWrite, NotebookRead, Task) ; tout le reste (Bash, Edit, Write…) déclenche une carte dans le chat : Autoriser / Toujours (cet outil) / Tout autoriser / Refuser.
  • « Tout autoriser » : le serveur approuve toutes les permissions suivantes jusqu'à la fin de la conversation — la tâche va au bout sans jamais réattendre l'utilisateur.
  • Modes CLI également exposés : acceptEdits, plan, et bypass (--dangerously-skip-permissions) derrière une confirmation explicite dans l'UI.

# Auth & sécurité

  • Mot de passe d'application haché scrypt → cookie akid HttpOnly/Secure, 7 j d'inactivité / 30 j max.
  • Rate-limit login : 8 échecs / 15 min / IP.
  • Backend lié à 127.0.0.1 — seul le tunnel ngrok y accède.
  • Audit complet : data/audit.jsonl (logins, prompts, tool_use, permissions, coûts).
  • Changement de mot de passe : node server/set-password.js '<nouveau>' puis redémarrage du backend.
  • Aucun secret dans le dépôt : data/ est hors git (config, bases, transcripts), la clé Anthropic vient de ~/.claude/.env du nœud.

# Structure du dépôt

text
admin-ka/
├── server/
│   ├── server.js          # HTTP + WS :3300, orchestration claude (local + ssh), upgradeur de prompts, pont /vncws
│   ├── monitor.js         # Écosystème : checks 45 s, sweep nœuds, eco.sqlite, incidents, push WS
│   ├── analytics.js       # Analytics v2 : classification humain/crawler/…, sessions, rollups, API
│   ├── perm-mcp.js        # Serveur MCP stdio (permission-prompt-tool) — aussi déployé sur les nœuds distants
│   ├── social.js          # Studio : posts FB, Reels, galerie, insights
│   ├── social/            # Python : make_reel.py, music_engine.py (numpy), render_card_html.py, insights.py
│   ├── set-password.js    # Changement du mot de passe d'app (scrypt)
│   └── test-analytics.mjs # 28 tests analytics
├── public/
│   ├── index.html         # SPA sans framework — 8 vues
│   ├── app.js             # logique complète du front (WS, replay, rendu stream-json, thème…)
│   ├── style.css          # design system crème/orange, dark mode, mobile
│   ├── ka-a.js            # beacon analytics v2 embarqué par les sites Ka
│   └── vendor/            # marked, highlight.js, noVNC (locaux)
├── deploy/
│   ├── io.adminka.backend.plist   # launchd : node server/server.js (KeepAlive)
│   └── io.adminka.ngrok.plist     # launchd : ngrok http --url=www.administration-ka.com 3300
├── docs/screenshots/      # les 10 captures de la visite guidée
├── CLAUDE.md              # exigences + pièges connus (à lire avant toute modif)
└── data/                  # NON VERSIONNÉ : config.json, SQLite, transcripts, audit, logs

# Déploiement & exploitation (sur M3U96a)

Le service tourne sous launchd (KeepAlive) sur le nœud M3U96a, exposé par ngrok sur le domaine réservé :

bash
# statut
launchctl print gui/501/io.adminka.backend | head -20
curl -s http://127.0.0.1:3300/healthz

# redémarrer
launchctl kickstart -k gui/501/io.adminka.backend
launchctl kickstart -k gui/501/io.adminka.ngrok

# logs
tail -f ~/apps/admin-ka/data/backend.err.log ~/apps/admin-ka/data/ngrok.log

# changer le mot de passe d'app
node server/set-password.js '<nouveau>' && launchctl kickstart -k gui/501/io.adminka.backend
  • Clé API : lue depuis ~/.claude/.env (ANTHROPIC_API_KEY) au démarrage du backend (pas de login OAuth sur les nœuds).
  • Projets proposés dans le sélecteur : ~/groupe-ka/* (clones des repos spbgit), ~/apps/* (apps déployées sur ce nœud), et ~ (home).
  • Registre des déploiements du cluster : cluster-deployments.json (laptop, source de vérité).
  • Repo git : spbgit (git perso) — ~/srv/git/admin-ka.git sur M3U96a, remote origin. Pas GitHub.

# Pièges connus (ne pas re-découvrir)

  • Tailscale inter-nœuds bloqué (ACL) : depuis M3U96a, joindre les nœuds via les noms Bonjour .local ; M2U64 = sous-réseau 192.168.0.x.
  • IPv4 LAN non routée entre certains nœuds (EHOSTUNREACH) : les permissions distantes passent par le tunnel SSH inverse.
  • ControlPath ssh trop long avec les hostnames .local%C.
  • Sans --model, un nœud retombe sur son défaut local → toujours le passer explicitement.

# Apps natives compagnes

La console a deux enveloppes natives (WKWebView + identité Ka), distribuées hors de ce dépôt :

  • Admin-Ka iOS — app SwiftUI (repo spbgit admin-ka-ios.git), distribuée via TestFlight ; panneaux JS natifs (WKUIDelegate), icône et splash Ka.
  • Admin-Ka macOS — app SwiftUI notarisée (Developer ID, repo spbgit admin-ka-macos.git), livrée en DMG.

# Contact


© Groupe Ka — Admin-Ka v3 « Control Center ». Console privée d'exploitation ; tout est branché sur le vrai CLI et les vrais sites, rien n'est simulé.