The Hub: the harness administration cockpit

What it is for: the Hub is the private administration interface of the Synedre OS agentic harness. This scope is the orchestration platform (a single, centralised database): Synedre orchestrates CodeMyShop, it is not the (multi-tenant) CodeMyShop product itself. The Hub is a standalone Nuxt application, served on the orchestration server's loopback interface and reachable only through an SSH tunnel behind an access gate at the reverse-proxy level; the founder uses it to drive agents, chantiers, runs, negotiations, memory and infrastructure.

1. The Hub's Nuxt application

1.1 Location and nature

• The application is standalone: it does not extend the CodeMyShop core ("total autonomy") and loads neither an internationalisation module nor a light/dark theme module (French only, dark theme only). Four Nuxt modules are actually loaded: Tailwind, image handling, fonts and icons.
• It is private: it listens on the orchestration server's loopback interface. It is not the founder's showcase site, which is a separate tenant on another server.
• The cockpit is dark-only: the light/dark switch was removed (decision of May 2026); the layout forces the dark class on the document root on mount and removes it on unmount.
• Interface switcher: the single layout serves two logical interfaces — the harness cockpit (active) and a "household" interface that is currently only an empty shell ("coming soon"). The choice is remembered in the browser and the page title follows the active interface. The household interface has no dedicated page: it is a switching mechanism put in place ahead of the domestic agents (meals, budget, pets). The same menu carries a "demo mode" entry, greyed out until the demonstration URL is set (§1.3).
• No scheduler in demo: if the build is produced in demo mode, the list of Nitro scheduled tasks is empty — the demonstration stack registers no task, makes no network call and writes nothing to its sample data.

1.2 Layered architecture (modules = Nuxt layers)

The Hub is not a monolith: functionality is split into modules loaded as Nuxt layers (the extends key), not as Nuxt modules.

Scar from a migration phase (May 2026): these folders carry a manifest and an empty configuration, which is the layer pattern. Declared as Nuxt modules, they fail at load time ("Could not load module").

Each layer auto-discovers its pages, server endpoints and server middlewares through Nitro. A module can therefore provide:

• cockpit pages,
• server endpoints split into three families: cockpit, back-office and voice,
• server code (database access, utilities).

Nuxt application
├── configuration         extends: one layer per module   (32 layers)
├── single layout         2 interfaces (cockpit / household), mobile drawer
├── page middleware       pass-through (access control upstream)
├── server/
│   ├── boot              Nitro polyfill: secrets read at launch
│   ├── middleware        session supplied platform-side
│   ├── utilities         session guard (employee / founder / role)
│   └── api/              CORE endpoints (not carried by a module)
├── cockpit pages         17 CORE pages (entry redirect, SRE, costs, maintenance, finances, playbooks, telephony…)
└── modules/
    ├── agents-ui      (60 cockpit pages + one public showcase)   pages, no server
    ├── agents-engine  (233 cockpit endpoints)                    server, no page
    ├── chantier       (cockpits, chantier sheet, CLI console)
    ├── acquisition / agenda / social
    ├── drill / cicatrices / conduite / automates / backlog / monitoring …
    ├── atelier3d      (2 pages + dedicated server)
    ├── studio-video   (2 editing pages)
    └── fleet / invoicing / reunions / academy …   (server only, no page)

The 32 extended layers are: academy, acquisition, aetracker, agenda, agents-engine, agents-ui, atelier3d, autoblog-article, automates, backlog, centaure, chantier, cicatrices, clientconfig, conduite, daily-meet, drill, employeeextra, expertise, feedback, fleet, hub, impersonation, incidents, invoicing, monitoring, page-meta, reunions, snake, social, studio-video, tools — that is, the 32 module folders.

Known limitation: the configuration comment still announces "28 internal modules" while the list in code declares 32 (acquisition, agenda and social were added). The comment is stale, the list is authoritative — the same drift pattern as in previous passes.

History: the former "agents" module was split (September 2026) into an interface layer (pages, no server) and an engine layer (server, no page). The household interface no longer exists as a layer: it is a display mode of the layout. The 3D workshop and video studio layers have carried cockpit pages since their creation.

1.3 Runtime and build configuration

• Secrets read at LAUNCH, never at build (autumn 2026 security chantier): all runtime-configuration secrets (signing secret, API encryption key, AI-provider keys, database connection string, object-storage keys) are the empty string at build time. A value read at that point would end up in clear text in the compiled output and, for the public part, in the browser bundle. They are supplied by the container environment, under a canonical name or under their historical name copied at startup by a dedicated bridge; a test fails if a key is missing from the alias table. Since Nitro freezes its configuration at import, the bridge is wired in as a startup polyfill. Only variable names travel through the code.
• Public runtime configuration: API base URL, URL of the isolated demonstration hub instance (empty by default), URL of the 3D workshop's live Blender bridge (§6.7), default client identifier. The admin token of the API-keys tab is no longer in public configuration: it is read at runtime by the server and travels only in an httpOnly cookie.
• Fonts: the font module is disarmed — a single font (a monospace face, for the reactor mesh) is self-hosted, with all remote providers disabled. Root cause: the build cache archived a font name longer than 100 bytes into a tar, truncated without error, so a 0-byte font was served for about five days. The build cache has been re-enabled since, and the cockpit deploy ships a tested font guard.
• Delivery guards on the deploy side — the "secrets at launch" principle is backed by guards in the deployment chain, applying to the hub as well as to tenants:
  • an output guard scans the compiled directory (server and public parts) using the source environment files read in memory; a secret value found in the bundle fails the delivery. It is configurable (off, warning only, or blocking); it has been blocking by default since 10 October 2026, after proof that no secret is frozen in the demonstration core or in the hub. A configuration error of the guard itself is never blocking;
  • a "secrets gap" guard refuses the deployment of a tenant whose secrets lived only in its build (its server does not provide them at launch: a new build would lose them). A deliberate waiver exists; the hub is not in the list;
  • PM2 reload re-reads the ecosystem file: it reads the environment when it is loaded, so the deploy reloads through the file (with no downtime in cluster mode) and cold-restarts if the file changed since the last deployment (stored fingerprint). A key added to the environment is thus seen without a manual restart;
  • a font guard checks, before packaging, that no font is empty or missing.
• Nitro scheduler: experimental Nitro tasks enabled + scheduled-task list (§3.1).

2. The map of cockpit modules

September 2026 extension — harness portability. An authenticated page, placed in the advanced "agentic" zone under the label "Portability", composes a bounded selection of profiles and skills. It does not read their content from the browser: an endpoint relays to the host daemon, which re-reads the skill registry and builds the canonical package (versioned schema, manual activation after validation, SHA-256 integrity). The interface is limited to previewing then downloading; no install or activation action is exposed.

2.1 Where the pages live

• 17 CORE pages: an entry redirect, SRE, costs, telephony, agentic learning, chantier list, three finance pages, two playbook pages, five pages of the "mothership" family (anatomy, backups, maintenance, cost-budget, deliberation) and one system page. The cockpit root is not a real page: it is a 302 redirect to the terminal.
  • Finances (3 pages): a consolidated professional ↔ household view, a sole-proprietorship view, a household view. The sidebar points to the consolidated view (label "Finances").
  • Maintenance dial — two tabs:
    • Tab 1 "Dashboard": global gauge, 4 dimensions (proprioception, debt, learning, automata), 7-day sparkline, documentation drift table (drift types: dead reference, stale published, newer code, unpublished). It reads two tables: the nightly loop's health history and the documentation drift mirror.
    • Tab 2 "How others see it": the user picks a public documentation chapter, generates a sanitised prompt, submits it to an external AI then pastes the answer into the form (50,000-character cap, status "submitted"). History is browsable. A dedicated table holds these reviews. 11 chapters are eligible: overview, data-layer, agentic-core, chantiers, automates, hub, email, memory, deploy, facades, skills-hooks.
  • The anatomy and deliberation pages (dedicated sidebar labels) each read one back-office endpoint; the telephony page reads a list and a detail.
  • The detail view of costs per chantier and annual budget (budget tab of the costs page) is not exposed directly in the sidebar.
• 60 cockpit pages carried by the interface module (pages only, no server), versus 49 in September 2026 (+11), plus one public page outside the cockpit: the orbital showcase of agents. Breakdown:

Family	Pages
Agents / chantier core	agent list and sheet; chantier (list, sheet, kanban per work item, work-item sheet); tasks (creation, sheet); dispatch; reactor
Steering / doctrine	constitution, doctrine, emails, inbox, legal, questions, settings, user model
Skills & runs	skills and skill proposals; runs (list, sheet, Atlas run); sessions; hooks
Negotiations / council	negotiations (list, sheet); council (list, sheet)
Memory	memory (index, tree, search)
Humans / clients	humans (list, sheet, mesh view) and client sheet; the technical sheet shows the access and shortcut to the in-situ cockpit of demonstration sites; new: mesh view of a client's sites (3 poles scored out of 10 — SEO, performance, security — linked to objectives), LinkedIn review queue (read-only), contact-enrichment review queue (nothing is applied from the list)
Extended steering	autonomy, objectives, optimisations, WhatsApp, Bucéphale, film library, brainstorm (list, sheet), runbook playbooks, terminal
New — fleet & go-live	cockpit of tentacles and suckers (profile, session, tenant, objective, desk, slot, worktree, model, git health); go-live page (a button records an orchestration-server deploy in the database, picked up by the host deploy worker — the page survives the rebuild it triggers); functional acceptance campaigns (generic, no tenant hard-coded); experimental cockpit of a Codex runtime (structured events, no pseudo-terminal); harness portability (see extension above)

• One static runbook: an archived third-party 3D sculpting tutorial, transcribed page by page in French with, for each gesture, the 3D workshop cage API command that performs it (42 steps). Frozen documentary content, no database read.
• The run-sheet route receives an identifier and no longer a codename.
• Human sheets and client sheets coexist; their exact relationship: ⚠️ to be confirmed.
• 233 cockpit endpoints in the engine module (server only, no page; 262 files including 20 specs/tests and 10 helpers), versus 230 on 10 October 2026 and 187 in September. Sub-domains: atlas, autonomy, brainstorm, bucéphale, chantier, cinema, clients, council, doctrine, fleet-control, hooks, humans, jukebox, memory, negotiations, objectives, optimisations, questions, acceptance tests, runs, sessions, settings, site audits, sites, skills, CLI console, tasks, user model — plus a few ungrouped files. The "CLI console" family remains the largest (81 files, §6.3).
• 4 CORE cockpit endpoints: an agent profile for a task and three ephemeral-command endpoints (list, dismiss, execute — layout footer).
• Total cockpit endpoints: 257 (233 engine + 15 chantier + 1 conduite + 4 monitoring + 4 CORE), excluding specs and helpers, versus 254 on 10 October and 208 in September.
• Modules without pages (server only): academy, aetracker, agents-engine, autoblog-article, centaure, clientconfig, daily-meet, employeeextra, feedback, fleet, hub, impersonation, incidents, invoicing, page-meta, reunions, snake, tools. Their surface is consumed through the API by other pages or by Python automata.
  • The hub module exposes statistics, constitution/charter and avatar endpoints, with no cockpit page.

Remaining modules with cockpit pages (outside the interface module):

Module	Pages
backlog	2: backlog, planning
chantier	2: chantier sheet, cockpits
drill	2: index and per-agent sheet
cicatrices	1: index
conduite	1: conduct index
automates	1: automata (Tools)
monitoring	2: SEO sentinel, keyword rank-tracker (keyword add and delete, read)
atelier3d	2: project list, project cockpit — 3D sculpting (§6.7)
studio-video	2: editing (list, project) — multi-track cinema studio
acquisition	1: dashboard of arm 4 (business development), read-only: pool, channels (outreach under delegation, freelance platform, public tenders, negotiations), funnel, queue of scheduled sends; a tier not measured shows "not measured", never 0
social	2: distribution (per-channel table, cadence, post queue), retouching of a finished short (notes per shot, nothing enters the queue)
agenda	1 cockpit page (sovereign appointments: requests, slots, configuration) + 1 public appointment-booking page; 5 back-office appointment endpoints

Note: the drill module also exposes 4 public pages outside the cockpit (index, history, cicatrices, trial by identifier): this is the Drill's public surface on the Synedre site. They are not counted in the cockpit pages above.

Note: the expertise module provides public/SEO pages (index, PrestaShop categories, sheets), not cockpit pages — unchanged.

2.2 Navigation (sidebar)

The cockpit sidebar is defined in code inside the layout. Two-level model: standalone links and 4 always-visible zones, then 7 zones collapsed behind an "Advanced" button (reorganisations of July 2026, then October 2026: "group acquisition and distribution", "collapse administration access").

Known limitation: the layout's header comment is partly stale — it lists an "EXECUTION" zone with 4 entries whereas the real zone carries 7 (objective first, acceptance and editing added), and "STEERING" omits the agenda. No functional impact: the table in code is authoritative.

• Standalone links (outside zones): Terminal · Humans · Bucéphale. (The "Founder DNA" link left the standalone links for the ADMINISTRATION zone.)
• Always-visible zones:

Zone	Entries
ACQUISITION & DISTRIBUTION	Acquisition · Distribution
STEERING	Backlog · Agenda · Emails · WhatsApp · Telephony · Brainstorm
BUSINESS	Finances · Questions · Negotiations · Council · Legal
EXECUTION	Objective · Autonomy · Runs · Chantier · Acceptance · A.W Factory (3D workshop) · Editing

• Collapsed zones (open by default if the active page lives there, otherwise behind the "Advanced" button whose state is remembered in the browser):

Zone	Entries
DOCTRINE & LEARNING	Doctrine · Runbooks (static) · Conversational playbooks (database) · Cicatrices
AGENTIC	Agents · Skills · Portability · Tools (automata) · Hooks & Reflexes
MEMORY	Brain · RAG Recall
ADMINISTRATION	Fleet Control · Go-live · Founder DNA
SYSTEM	SRE · maintenance dial · anatomy · deliberation · API cost · S3 backups · API keys · Optimisations · Agentic learning
SEO	Rank-tracker · Sentinel
HOUSE	Film library — the page existed before being reachable through navigation.

• Several pages exist in code but appear in no zone: dispatch, reactor, cockpits, planning, sites mesh view, short retouching, Codex runtime and Drill — they are reached by direct address or from another page. The "E-commerce Hub" link (removed in July 2026) remains absent.
• The "Terminal" label points to a page reduced to the tmux terminal alone (former "synedre" page, reduced in July 2026). The cockpit root is not a distinct landing page: it is a 302 redirect to the terminal.
• The active entry is marked on exact match OR on sub-route.
• The sidebar stays in emoji on purpose (decision of July 2026): it is the only place in the cockpit that did not migrate to Tabler icons — a finite, centralised list, every pictogram paired with a text label.
• Mobile — drawer (September 2026): below the md breakpoint, the sidebar leaves the flow and becomes a drawer recalled by a ☰ button in a 40 px bar; dark overlay, closing on navigation or on Escape; labels restored in the drawer. "Short screen" variant (e.g. mobile landscape): root at dynamic height with no stray scrolling, each column scrolls on its own; the mobile bar shows the title of the active navigation, computed (the most specific link wins).

3. Server endpoint families

The split is not merely organisational: it carries rights semantics.

back-office   "founder / cron" — behind the access gate, sometimes WITHOUT application auth
cockpit       employee surface — employee-session guard almost systematic
voice         audio transcription — employee-session guard + CSRF guard

A few smaller CORE folders are added: API keys (list, update, admin token in an httpOnly cookie), a WhatsApp media relay, a page OAuth callback, as well as a health endpoint and the WhatsApp endpoints.

3.1 Back-office

• CORE endpoints: 46 files excluding specs (versus 44). Sub-domains: learning (3), chantier (4), cicatrices (1), costs (8), inbox (7), "mothership" family (10), playbooks (2), SRE (2), telephony (2), tenants (1), WhatsApp (6).
• Module endpoints (18): automata (3), conduite (3), agenda (5), aetracker finances (7). Back-office total: 64.
• The historical inbox synchronisation route is a sentinel: it answers 410 Gone without running the IMAP task. Manual triggering goes through a dedicated script that launches the external synchronisation worker. Nitro task status: 9 declared, of which 2 disabled in comments (inbox and client-email synchronisation — provider IMAP timeouts were blocking the event loop) and 7 active: email queue processing (every 2 min), uptime monitoring (15 min), dictionary watch (30 min), dependency audit (daily 2 h), daily meet (8 h), SSL certificate watch (9 h), brand watch (12 h). Empty list in demo mode (§1.1).
• Examples per sub-domain (sample, not exhaustive):
  • learning: update, apply, feed
  • chantier: re-explode, explode edit, explode status, phase launch
  • cicatrices: indicators
  • costs: dashboard, budget (read/write), costs per chantier, API equivalent per chantier, automata, tasks, time series
  • inbox: synchronisation (410), list, detail, update, attachments, chantier link
  • "mothership" family: anatomy, deliberation, backups (list, download), maintenance board (health + documentation drift); external-review sub-path: chapters, prompt, history, submission
  • SRE: metrics, task trigger
  • WhatsApp: list, detail, update, reply, send status, media
  • playbooks: list, detail; telephony: list, detail
  • tenants: automatic go-live authorisation status

3.2 Cockpit surface

• 257 endpoints in total (§2.1) — +49 since September 2026, carried by the engine module (233, versus 187).
• Authentication: the employee-session guard is called in 316 files of the application code (excluding specs/tests; measured by grep, versus 313 the day before, 234 in September and 144 in June 2026). Exceptions are internal helpers (daemon client, pane pipe, depth, overload, heartbeat policy) or SSE streams. Typical pattern, at the top of every handler:

  export default defineEventHandler(async (event) => {
    requireEmployeeSession(event)
    ...

• Main families (engine module): chantier (32), runs (10), negotiations (17), council (9), clients (9), humans (9), brainstorm (14), jukebox (14), fleet-control (11), memory, doctrine, skills, sessions, questions, tasks, user model, settings, CLI console (61 endpoints / 81 files), hooks, atlas, autonomy, bucéphale, cinema, objectives, optimisations, acceptance tests, sites, site audits.
• The chantier module adds its own 15 endpoints: active cockpits, active sessions, dashboard, active runs and discovered bugs per chantier, the live CLI console (start, stop, reset, state) with an SSE stream of agent events, and for Atlas runs: draft reply, fix launch, profile and SSE stream. The draft reply exists for both reading AND writing.
• Negotiations (engine module) comprise 17 files: list, archiving, reclassification, detail, and per negotiation: event, status, timeline, emails, contacts, deliverable (file), proposals, events, contact, work start, assignment, deliverables, plus the decision on a proposal.

3.3 Audio transcription

• A single endpoint — unchanged.
• Contract: multipart POST (WAV audio required, optional locale — French by default) → text, locale, duration, model, backend. It delegates to a transcription service.
• Safeguards: employee-session guard, 5 MB maximum, rate limit of 100 transcriptions per 5-minute window per session, audio never persisted to disk (memory only), and CSRF defence through Origin/Referer verification against the host.

4. Authentication

4.1 The two-layer model

┌──────────────────────────────────────────────────────────┐
│  INFRA LAYER (the real gate)                              │
│  SSH tunnel (loopback) + proxy access gate                │
└─────────────────────────────┬────────────────────────────┘
                              │  the request arrives already "owner only"
┌─────────────────────────────▼────────────────────────────┐
│  APPLICATION LAYER (Nuxt)                                 │
│  session server middleware: supplies a signed session     │
│  to the platform                                          │
│  → the session guard always sees a valid employee         │
└──────────────────────────────────────────────────────────┘

4.2 Employee-session guard and relatives

Unchanged (file re-audited, last change in May 2026):

• Session reading decodes the session cookie (base64url JSON signed with HMAC-SHA256, verified by a dedicated cryptography module). It returns null if the cookie is missing or invalid.
• The employee guard returns the session if the user type is "employee", otherwise answers 401. It is the standard guard of cockpit and voice endpoints (316 files, see §3.2).
• The founder guard additionally requires SaaS super-administrator status (403 otherwise).
• The "role or SaaS" guard requires a given role OR SaaS super-administrator status.
• Super-administrator status relies on a static allowlist in code, deliberately kept out of the database: "touching this list = code change + review".

Session shape: employee identifier, email, first name, last name, role, profile identifier, client identifier, user type, administration flag.

4.3 The platform-supplied session

The session server middleware is unchanged: on every request lacking a valid session cookie, it signs a token (cached) and sets a 30-day httpOnly cookie whose payload is an administrator-profile session. Consequence: on the orchestration-server runtime, the session guard always passes — real security is the infrastructure (SSH tunnel + access gate). This middleware is scoped to the orchestration server: it exists neither in the CodeMyShop core nor in tenants; on public tenants, the session guard remains mandatory (scar from an earlier phase: an access gate is not a substitute for authentication).

4.4 The page middleware is a pass-through

The Hub page middleware is a pass-through — unchanged. It was disabled during a fix phase (May 2026) because the proxy access gate and the SSH tunnel handle control upstream. It remains exported because 71 pages reference it in their metadata (versus 57 in September and 45 in June 2026 — growth proportional to the number of cockpit pages).

Known limitation: the middleware comment still announces "16 pages" — stale. The pass-through being deliberate, the divergence has no functional impact; the comment should be updated on the next pass.

The reverse-proxy access gate (cookie + URL segment) lives on the infrastructure side, not in this Nuxt application. The infrastructure runbook documents it. ⚠️ The detail of its configuration is not in the application code — to be confirmed on the infrastructure side.

5. The Hub layout

• Single layout, the only layout of the cockpit of the standalone application, shared by the 2 interfaces (§1.1). It overrides nothing: the application being standalone (no extension of the CodeMyShop core), there is no parent layout to override.
  • Known limitation: two comments in the file ("override of the core layout" and the layer extension mechanism) are still obsolete — leftovers from before the switch to a standalone application, not fixed. The navigation tables are authoritative over the header comment (§2.2).
• The layout's user is a fixed value: Nuxt authentication was removed. Unchanged.
• Page head: title reactive to the interface switcher ("… — Synedre OS" or the household interface name) and a dedicated favicon.
• The layout footer mounts a component of ephemeral commands to run (list, dismiss, execute).
• Pages declare the cockpit layout, the pass-through middleware and ssr: false rendering (90 pages reference the cockpit layout, versus 74 in September). Client-only rendering is common on real-time pages (reactor, chantier).

6. Console surfaces (runs · chantiers · negotiations · fleet)

The Hub materialises several agent-steering "consoles". Central data model: the Python entities of the entity layer and the PostgreSQL tables of a single schema in the harness's central database.

6.1 Runs

• Pages: run list, run sheet, Atlas run sheet.
• API: the runs folder of the engine module (10 files: list, scopes, scope, scoped chat, job) and, on the chantier module side, the Atlas run endpoints (draft reply, fix launch, profile, SSE stream).
• Model: sy_run entity. A run is a scoped execution of Atlas (chat/email/cron) over a "platform" or "tenant" perimeter. List response: identifier, source, trigger, scope, title, status, reference type and identifier, creation date, end date. The "atlas-inbox" source is an email, "console" is a chat. Emails of intent question/chantier/noise are not materialised as runs (they stay on the questions and chantiers pages). A task run is not a run.

6.2 Chantiers

• Pages: list, sheet, kanban per work item, work-item sheet (interface module); chantier sheet and cockpits (chantier module); CORE chantier list.
• API (chantier module, 15 cockpit endpoints in total — §3.2): active cockpits, active sessions, dashboard, active runs and discovered bugs per chantier, the live CLI console (start, stop, reset, state) with an SSE stream of agent events, and the Atlas run endpoints (§6.1).
• API (engine module, 32 files under chantier): per chantier (mission-letter drafting, automatic run, archiving, closing with email draft, move to brainstorm, update, deliverables), tasks/team/work/context, relevance audit, billing mode, tenants, work items (⚠️ content of subfolders not re-audited file by file).
• Model: 1 chantier → N work items → N tasks (chantier, work-item and task entities). Real tables: chantier = ps_ac_chantier, work item = ps_ac_chantier_travail, tasks = sy_chantier_tache, links sy_chantier_agent / sy_travail_agent. Canonical creation = creation with skeleton, atomic (7-step procedure).
  • Known limitation: naming debt between the historical ps_ac_* prefix and sy_* (gradual migration): chantier and work item remain ps_ac_*, while tasks and link tables are already sy_*. There is neither a sy_chantier nor a sy_travail table or view.
• Concurrency-control and audit entities:

Entity	Table	Role
Chantier lock	sy_chantier_lock	Distributed lock per chantier — refuses 2 sessions on the same chantier; composite key (chantier, owner type: user session or spawned worker); 30-minute TTL + heartbeat; compatibility mode (table absent → lock acquired). Operations: acquire, release, force claim, heartbeat.
Lock error	— (exception)	Raised when reading a chantier's context while the lock is held by another active session. Intercepted by the chantier-steering command.
Explode audit	sy_chantier_explode_run	Audit log of every invocation of the explode pipeline: one row created "pending", then updated to success / validation failed / LLM failure / killswitched. Notable columns: model, provider, input and output tokens, cost in euros, JSON plan, work items created. 90-day retention. Lookup of recent runs and 24-hour count (called before the run for the configured-cap kill-switch).
Task dependencies	sy_tache_dep	Intra-work-item dependency DAG (task→task). Adding is subject to blocking validations: no self-loop, same work item, no cycle (depth-first search), maximum depth of 100. Removal and per-work-item listing. Raises a cycle error or a cross-work error. Inter-work-item dependencies live in sy_travail_dep (composite key, foreign keys, anti-loop constraint), which has no Python class: it is handled in direct SQL on the Nuxt server side (read for the automatic run, write by atomic replacement with cycle detection by breadth-first search). ⚠️ the add error message pointing to sy_travail_dep was not re-verified.

The work-item entity also carries, in its inter-work-item cycle detection, a maximum-depth guard of 200 with a set of visited nodes — distinct from the depth of 100 of task dependencies.

6.3 CLI console

• CLI console API: 81 files (including 61 endpoints excluding specs/helpers; versus 77 including 58 the day before and 38 in September). Base: state, key sending, stream, multi-stream, usage, handoffs, lost sessions, camp switch, model switch, reincarnation, desks (list, rename, assignment), tentacle pages, lexicon, tenants, quota history, mailbox mandate, objective, button configuration, Antigravity models, scope preview, resize, file upload, start/stop, slot, agents, system, sessions, pool spawn. New since September: pools (list, preview, recruitment, conducts), sucker spawn, spawn, release, heartbeat (+ heartbeat policy), clear request, automatic reply, human command, profiles, git health, portability package (§2), and the Codex runtime subfolder (start, stop, status, turn, response, interrupt, events). ⚠️ Scope not re-audited item by item — a dedicated pass over this family is recommended.
• The state endpoint always forwards to a host daemon (not the container — work item "fix container vs host"), through daemon-client helpers. It returns success, an activity flag, information. When the daemon is down: no 5xx, activity flag false, and the error message is never exposed to the client (QA review fix). It is the surface that drives a real CLI session from the cockpit.

6.4 Negotiations

• Pages: list and sheet (interface module).
• Rich API (17 files, §3.2): list, archiving, reclassification, detail, assignment, contacts, deliverables, deliverable file, emails, events, proposals, work start, status, timeline, decision on a proposal.
• Model: sy_negociation table (negotiation entity). Pipeline: forwarded email → Atlas, intent "negotiation" → negotiation item → sheet where agents work.

6.5 Fleet — server-only module and fleet cockpit

• fleet module: manifest + configuration + database-access layer — unchanged. No page of its own.
• Model: ps_ac_fleet_instance table, in the central schema. Columns: instance identifier, client, name, domain, offer, MRR, setup fee, status, VPS IP and region, admin URL and credentials, API key, database password, note, AI provider and model, dates.
• ⚠️ The operational source of truth for VPSs remains the client-server inventory table, not ps_ac_fleet_instance. Exact relationship between the two tables: to be confirmed.
• Not to be confused with the cockpit's fleet-control page (interface module + 11 files of the engine module): it drives tentacles/suckers (agent sessions in tmux panes, desk, slot, worktree, git health), not the fleet of client VPSs.

Known limitation: ps_ac_fleet_instance contains credential columns (admin password, database password, API key). It is a legacy schema inherited from the platform — inconsistent with the "zero secrets in business database" doctrine. To be audited; do not treat this table as the canonical source of secrets.

6.6 Reactor

• Cockpit page (outside the sidebar, see §2.2): live orbital view (3 concentric rings per agent group), octopus logo at the centre, SSE stream through a dedicated composable, client-only rendering. Agent source: an agents endpoint. Engine-module server endpoints: agents, agents-ia, reviews, reactor, reactor stream.
• Public page (without the cockpit layout, dark theme): same orbital staging, fed by the statistics endpoint (agent count), without cockpit authentication.

6.7 3D workshop — sculpting cockpit and live Blender bridge

• Pages of the atelier3d module (§2.1): project list, and project cockpit — three.js viewer in an iframe, version timeline, live Phidias terminal, Gemini prompt generator, launch of retopology / colours / cutting / control jobs.
• Dedicated API (44 endpoints, outside the cockpit family — not counted in the §3.2 total): project/version CRUD, reference upload (character design, technical drawing, anatomical study), Phidias job launch, and the cage, marker, asset, job, volume, version and reference-sheet families (spline cage workshop — lock, operation, replay, volume, borders…).
• Live Blender bridge: a separate host process relays over WebSocket, under an authentication token and bound to loopback, the scene state of a Blender add-on (objects, mode, mesh counters, selection, image preview) to the project cockpit. The bridge URL is set only in a cockpit session that has the SSH tunnel to this bridge — without it, the live connection is not attempted. The browser drives Blender read-only (scene snapshot, preview capture); no .glb file write leaves the cockpit.
• The message protocol (hello, command, state, preview) is validated on the Python side, with tests.

7. Picking up the code — entry points

You want to…	Look at
Add a sidebar entry	the three navigation tables of the cockpit layout (standalone links, visible zones, advanced zones)
Add a cockpit page	a new .vue file in the interface module (or another pages-only module), with the cockpit layout declaration
Add a cockpit endpoint	the engine module (or another server-only module), with the employee-session guard
Study authentication	the session utility and the session server middleware
Wire a new layer	the extends key of the Nuxt configuration + the module's manifest and configuration
Add a runtime secret	the environment-variable alias table (tested) — empty string in runtime configuration, never reading a variable at build (§1.3)
Secret delivery guards	the output guard, the "secrets gap" guard and the ecosystem-file reload in the deploy library, with the output scanner (§1.3)
Runs / chantiers (database)	entities of the entity layer and tables sy_run, ps_ac_chantier (+ ps_ac_chantier_travail, sy_chantier_tache), sy_negociation
Maintenance dial / documentation drift	the cockpit maintenance page and its back-office endpoint (health and documentation drift tables)
External documentation review	the external-review component, its back-office endpoints (chapters, prompt, history) and the list of valid chapters (dedicated review table)
Hooks & reflexes registry	the hooks page and its list endpoint (sy_reflex table, trunk / arm tiers)
CLI console (tmux, sessions, quotas)	the CLI console endpoint family of the engine module (§6.3)
Tentacles cockpit / go-live	the fleet-control and go-live pages + the fleet-control endpoints of the engine module
Chantier lock (CLI concurrency)	the lock entity (sy_chantier_lock table) — acquire, force claim, release, heartbeat
Explode-run audit	the audit entity (sy_chantier_explode_run table) — recent lookup, 24-hour count
Task dependencies (DAG)	the dependency entity (sy_tache_dep table) — add, remove, per-work-item list; anti-cycle by depth-first search
3D workshop / live Blender bridge	the project cockpit page (live connection), the bridge process and the message protocol (§6.7)

Secrets: no clear-text secret in this documentation. The session-cookie signing secret is consumed by the session cryptography module (HMAC); its environment variable lives in environment files kept outside the repository, never in code. Since the autumn 2026 security chantier, runtime-configuration secrets are injected at container launch (§1.3), no longer at build.