Concepts de base

Les huit primitives système

Tout ce que fait Nika OS se ramène à huit primitives. Elles structurent le kernel, les hooks, les pods, et la routing des intentions utilisateur.

#	Primitive	Rôle
1	Instruction	Ce qui guide le comportement : CLAUDE.md, system prompts, skills, policy files
2	Lifecycle	Ce qui gère les transitions : hooks SessionStart, PostToolUse, Stop, SubagentStop, PreCompact, UserPromptSubmit
3	Context	Ce qui est injecté à l’instant T : prompt utilisateur + RAG retrieval + hierarchy state + handoff packet
4	Memory	Ce qui persiste au-delà de la fenêtre de contexte : Qdrant (sémantique), YAML hierarchy (workflow), bus JSONL (audit)
5	Execution	Ce qui agit : tools de l’agent CLI, MCP servers, pods
6	IPC	Ce qui connecte les agents : Redis Streams signaling + Working Memory + Entity Feed + Consumer Groups
7	Schedule	Ce qui déclenche dans le temps : Remote Triggers (persistants), CronCreate (session), crontab OS
8	Autonomy	Ce qui décide sans demander : Plan mode (questions, clarification) vs Execution mode (autonomie totale)

Les deux modes d’autonomie

Nika fonctionne en bascule explicite entre deux modes mutuellement exclusifs.

Plan mode

Activé quand le scope est ambigu, sous-spécifié, ou quand la demande utilisateur peut conduire à plusieurs interprétations défensables. En Plan mode, le kernel :

• pose des questions ciblées (jamais plus de 4) ;
• structure la demande en hiérarchie PROJ / JOB / TASK / SUB ;
• attend une validation humaine explicite avant tout Edit, Write ou spawn de pod.

Execution mode

Activé dès qu’un cahier des charges (CDC) est validé ou que la demande est sans ambiguïté. En Execution mode, le kernel :

• ne demande jamais permission ;
• explore plusieurs chemins en parallèle quand c’est utile ;
• mute ses primitives mutables (hyperparamètres, formulations, heuristiques) en cas d’échec, plutôt que d’attendre une instruction.

Les pods, eux, sont toujours en Execution mode. Un pod qui demande « je continue ? » est un bug à corriger, pas un comportement à accepter.

Le vocabulaire minimum

Terme	Définition
Alpha	Le pod orchestrateur (instance d’un agent CLI maître). Reçoit le prompt utilisateur, décide de la stratégie, spawne les pods workers si nécessaire.
Pod	Instance l’agent CLI spécialisée, lancée dans un tmux dédié, chargée d’une mission isolable. Cycle de vie : spawn → invoke → observe → kill.
Skill	Capacité réutilisable décrite par un fichier markdown avec frontmatter name, description, trigger. Composable, versionnée, mutable par GEPA.
Hook	Script Python attaché à un événement de cycle de vie. Lit stdin, écrit stdout/stderr, retourne un exit code qui peut bloquer ou modifier l’action.
MCP server	Serveur externe (stdio ou HTTP) qui expose des outils accessibles depuis l’agent CLI via le protocole Model Context Protocol.
Bus	Fichier JSONL append-only _bus/alpha_bus.jsonl qui sert d’audit trail permanent pour toute communication inter-agent.
RAG	Retrieval-Augmented Generation. Recherche sémantique dans Qdrant nika_vault avant toute affirmation factuelle (règle PALACE PROTOCOL).
Kernel	Couche immuable d’instructions et d’invariants. Off-limits pour la mutation automatique — on protège ce qui marche.
Harnais	Couche mutable : formulations de prompts, hyperparamètres, heuristiques. Sous tournoi GEPA : variants en compétition, le meilleur survit.

Les trois règles d’or

1. PALACE PROTOCOL — Ne réponds jamais à une question factuelle sur un client, projet ou décision passée sans avoir d’abord cherché en RAG. Si la recherche retourne 0 hit pertinent, dis-le explicitement plutôt que d’inventer.
2. Matrice SQP — Sécurité (P0) > Qualité (P1) > Performance (P2). Aucun arbitrage top-down ne peut inverser cet ordre.
3. Scope demandé = scope livré — Pas de refactor opportuniste pendant un bug fix. Pas de feature ajoutée pendant une mise à jour de configuration.

Pour aller plus loin

• Kernel et pods — l’orchestrateur, les workers, le contrat de spawn.
• Système mémoire — trois couches, cinq stores, séparation stricte.
• IPC et bus — Redis Streams, consumer groups, audit JSONL.