Hub — Synedre OS Administration Interface

The Hub — administration interface of the agentic harness

The Hub is the private administration interface of Synedre OS. Accessible only from the mother-ship VPS via a secure tunnel, it centralises the control of agents, projects, runs, negotiations, memory and infrastructure.

Application architecture

The Hub application is built on Nuxt standalone, with no shared-layer inheritance from other products. It is deliberately restricted to French and to the dark theme: the light/dark toggle has been removed, and the dark class is forced at mount time on the root HTML element.

The Hub is not a monolith. Its features are distributed across independent modules, loaded as Nuxt layers via the extends directive of the main configuration. Each layer auto-discovers its pages, its API endpoints and its server-side code. A module can therefore contribute:

• pages accessible under /hub/*,
• dedicated API endpoints,
• server-side logic (database, utilities).

The application currently has 27 active layers, covering the following domains: activity tracking, agents, automated writing, automatons, backlog, client-centricity, projects, scars, configuration, conduct, correspondence, daily stand-ups, exercises, collaborator data, expertise, feedback, fleet, central hub, session impersonation, incidents, billing, SRE monitoring, page metadata, meetings, e-commerce integration and cross-cutting tools.

Architecture note: these modules must be declared as layers via the extends directive, not as Nuxt modules in modules:[]. This confusion causes a loading error — the correct pattern requires each layer to have a manifest file and a minimal Nuxt configuration.

Module and page map

Core application pages

Eight pages are hosted directly in the application core, outside any module:

• Home page — is not a full page in its own right: it automatically redirects (HTTP 302) to the main terminal.
• Resilience monitoring (/hub/sre) — SRE dashboard.
• Costs (/hub/cost) — aggregated cost view.
• Agentic learning — synthesis of learnings gathered from runs.
• Project index — list of active projects.
• Backups — backup status of the mother-ship.
• Budget detail — cost breakdown by project and annual budget; accessible from the main cost page, not exposed in the sidebar.
• Maintenance dial — dashboard of the documentation self-inspection loop, described below.

The maintenance dial

The maintenance dial is the dashboard of the nightly documentation inspection and gated regeneration loop. It exposes two tabs:

1. Global dashboard: synthetic health gauge, four analysis dimensions (proprioception, debt, learning, automatons), a 7-day trend curve and a documentation drift table. Detected drifts are classified by type: dead reference, published content that has become stale, code more recent than the documentation, content not yet published.
2. External review: the operator selects a public documentation chapter, generates a prompt stripped of all sensitive data, submits it to an external AI model, then pastes the response into the form. The submission history is browsable. The maximum size of a submitted response is 50,000 characters. Available chapters cover eleven domains: overview, data layer, agentic core, projects, automatons, hub, e-mail, memory, deployment, facades, skills and reflexes.

Pages provided by modules

Modules contribute 49 additional pages under /hub/*, distributed as follows:

Functional domain	Number of pages	Scope covered
Agentic core	38	Agents, brainstorm, projects, clients, advisory, constitution, dispatch, doctrine, e-mails, reflexes, inbox, legal, memory, negotiations, questions, reactor, runs, sessions, settings, skills, tasks, user model
Backlog & planning	3	Backlog, planning, system backlog
Projects	2	Project sheet, cockpits
Exercises	2	Exercise session, exercise by agent
Scars	1	Scar log
Conduct	1	Conduct board
Automatons	1	System automaton manager
SEO monitoring	1	Multi-client SEO cockpit (described below)

Public surface of exercises: the exercises module also exposes four publicly accessible pages on synedre.com (outside /hub/): exercise index, history, public scar log and individual trial detail. These pages are not counted in the 49 hub pages above.

The SEO monitoring cockpit

The SEO monitoring cockpit is a multi-client technical dashboard accessible by direct URL, not referenced in the main sidebar. For each client it displays:

• an SEO health verdict,
• the 404 error rate (leading indicator),
• click and impression trends via Google Search Console (lagging indicator),
• an observation-only or auto-remediation mode,
• an alert log.

Server-only modules

Eighteen modules expose no Vue pages: they exclusively provide API endpoints and database logic consumed by other Hub pages or by Python automatons. These domains cover: internal training, activity tracking, automated writing, client-centricity, per-client configuration, correspondence, daily stand-ups, collaborator data, user feedback, fleet, central hub (statistics, constitution, charter), session impersonation, incidents, billing, public page metadata, periodic meetings, e-commerce integration and cross-cutting tools.

Special case: the expertise module contributes public-facing SEO pages (outside /hub/), with no administration page in the cockpit.

Navigation — the sidebar

The cockpit sidebar is organised into seven functional zones, hard-coded in the main layout:

Zone	Entries
Steering	Terminal, E-mails, Brainstorm, User model
Business	Negotiations, Advisory, Legal
Execution	Backlog, Project, Runs, Questions, New task, Sessions
Doctrine & Learning	Doctrine, Constitution, Scars, Exercises
Agentic	Agents, Reactor, Skills, Skill proposals, System automatons, Dispatch, Reflexes & Hooks, Agentic learning
Memory	Brain (structured memory), Recall RAG (semantic search)
System	SRE, Maintenance dial, Costs, Backups, Settings

Active-entry detection works by exact match or sub-route prefix: an entry is marked active if the current route is identical to the target or starts with that target followed by a separator.

Recent change: the direct shortcut to the e-commerce surface has been removed from the sidebar. The terminal, the default entry point of the Hub, is the page to which the /hub root redirects.

The three endpoint families

The API surface split is not merely organizational: it carries an access-rights semantic. Three routing prefixes coexist, each with its own access model.

• Founder back-office / cron — protected upstream by an infrastructure barrier; some endpoints add no further application-level check.
• Employee cockpit (hub) — employee session guard applied quasi-systematically across all routes.
• Audio transcription (voice) — employee session guard and CSRF defense applied cumulatively.

Founder back-office

This family groups several dozen endpoints spread across functional sub-domains. The main domains covered are:

• Learning — browsing the learning feed, applying and editing cards.
• Project site — decomposition, rescheduling, status changes and phase launches for a given site.
• Cost indicators — dashboard, budget (read/write), time series and breakdown by site.
• Inbound messaging — IMAP synchronization triggered by cron (see below), message list and detail, attachment management, linking to a site.
• System operations — backups (list, download), observability metrics, automated dispatch status per tenant.
• Documentation maintenance — reading corpus health status and detected drift; dedicated sub-section for external review: list of eligible chapters, generation of the cleaned prompt for an external AI model, revision history with filters, revision submission (model, external response, author traceability).

Back-office authentication model

Some endpoints in this family rely exclusively on the infrastructure barrier (described in the Authentication section below) rather than on the application session guard. This is notably the case for the inbound messaging synchronization route, designed to be called by an external scheduler (system cron).

An internal scheduler embedded in the application server has been reactivated and handles seven recurring tasks:

• E-mail send queue processing — every 2 minutes.
• Availability monitoring — every 15 minutes.
• Dictionary watch — every 30 minutes.
• Dependency watch — daily at 02:00.
• Automated daily standup — daily at 08:00.
• SSL certificate monitoring — daily at 09:00.
• Brand watch — daily at 12:00.

Inbound messaging synchronization is deliberately excluded from this internal scheduler due to constraints tied to the server I/O model (blocking operation incompatible with the event loop); it is handled by an independent system cron.

Employee cockpit

This family is by far the largest: it covers employees' day-to-day interactions with the system. The employee session guard is applied in the vast majority of handlers; the only exceptions are internal utilities not directly exposed and certain real-time data streams (Server-Sent Events).

The main route families cover:

• Management of sites and their tasks, works, teams, context and audit relevance.
• History and detail of agent runs (including responses, patch spawns, agent profiles).
• Negotiations, advisory sessions, brainstorming.
• Agent memory, doctrine and skills.
• Questions, user model, settings.
• Global dispatch, Atlas map state, list of agents available for a prompt.
• Event hooks and Synedre CLI interface.
• Real-time agent event streams (SSE) at site and run level.

Audio transcription

A single endpoint receives a WAV audio file in multipart and returns the transcribed text along with metadata (detected language, duration, model used, transcription engine). Delegation is made to an internal transcription service.

Several safeguards are applied cumulatively:

• Mandatory employee session guard.
• Maximum audio file size: 5 MB.
• Rate limiting: 100 transcriptions per 5-minute window per session.
• Audio never written to disk — in-memory processing only.
• CSRF defense via origin-to-host header matching.

---

Authentication

A two-layer independent model

Access security rests on two orthogonal layers that complement each other:

• Infrastructure layer — an encrypted tunnel combined with an HTTP filtering barrier (access cookie + secret identifier) ensures that only the authorized operator can reach the application server. Requests therefore arrive already qualified as "owner only."
• Application layer — a startup middleware automatically sets a signed founder session cookie on every request that does not yet have a valid session. The application session guard therefore always sees a valid employee; actual security is delegated to the infrastructure layer.

Session guards

A central utility manages the entire session lifecycle:

• Session read — decodes the session cookie (JSON encoded in base64url, signed by HMAC-SHA256). Returns null if the cookie is absent or invalid.
• Standard employee guard — returns the session if the user type is employee, triggers a 401 error otherwise. This is the guard applied across all cockpit and audio routes.
• Founder guard — additionally requires SaaS Super-Admin status; returns 403 otherwise.
• Role or SaaS guard — accepts either a specific functional role or SaaS Super-Admin status.
• SaaS Super-Admin detection — a hard-coded e-mail address whitelist in the source, deliberately kept out of the database: any modification requires an explicit code review.

A session structure contains: employee identifier, e-mail address, first name, last name, role, profile identifier, client identifier, user type, administrator flag.

The automatic founder session

The startup middleware (highest priority in the chain) intercepts every request lacking a valid session and immediately signs a session cookie whose payload corresponds to the founder profile (Super-Admin role, 30-day lifetime). On the mothership runtime, the standard employee guard therefore always passes — real protection is provided by the infrastructure (tunnel + HTTP barrier).

Strict scope — this middleware exists only on the mothership runtime. It is absent from client modules and public tenant runtimes, where the session guard remains fully mandatory.

The front-end routing middleware is disabled

A client-side routing middleware referenced by a large number of cockpit pages has been deliberately reduced to a neutral no-op function: the infrastructure barrier and the SSH tunnel handle authentication upstream, making this middleware redundant. It remains declared in the code to avoid breaking the page metadata that references it.

Consistency note — the header comment of this file states a number of pages referencing the middleware that is lower than the actual count; this discrepancy has no functional impact (the middleware being a no-op) but should be corrected at the next maintenance pass.

---

Cockpit layout

The cockpit relies on a single layout that structures all employee pages: side navigation, header, main content area. This layout is self-contained — the mothership inherits no base layer shared with client modules.

• The browser title follows the template … — Synedre OS.
• The visual identity (favicon) points to the Synedre logo.
• The user displayed in the interface is a static constant; dynamic Nuxt-side authentication has been removed, security being carried by the infrastructure.
• Pages declare exclusively client-side rendering (ssr: false), in particular real-time views (reactor dashboard, site tracking).

Consistency note — the layout's header comment lists navigation entries incompletely (two entries present in the actual configuration are absent from the comment). The effective navigation table configuration always takes precedence over the comment.

Hub Control Surfaces

The Hub exposes several control consoles dedicated to agents. Each console corresponds to a distinct functional domain: scoped executions, project management, commercial negotiations, fleet supervision, or real-time orbital view. Data is centralised in a shared model whose business entities are shared across the various modules.

Scoped Executions (Runs)

A run represents the execution of Atlas within a defined scope — mothership or tenant — triggered from the chat, an incoming email, or a scheduled task. Each run exposes the following information: identifier, trigger source, trigger nature, scope, title, status, type and reference identifier, as well as creation and completion timestamps.

Two trigger sources exist:

• Incoming email — Atlas processes the message and opens an associated run.
• Chat console — the operator interacts directly from the Hub interface.

Note: emails whose intent is classified as a question, noise, or project opening do not generate a run: they are handled respectively in the Questions and Projects consoles. A scheduled task execution is a distinct entity from an Atlas run.

The Runs console exposes the following capabilities via its endpoints:

• Listing and filtering runs by scope and range.
• Individual run detail (profile, real-time events via SSE stream).
• Generation and validation of reply drafts.
• Triggering a fix from a run (spawn-fix).

Project Management (Chantiers)

A chantier is the primary project unit in Synedre OS. It decomposes hierarchically:

1. A chantier groups a set of work packages.
2. Each work package contains a set of tasks.

The canonical creation of a chantier follows a seven-step procedure that automatically instantiates the skeleton structure (chantier + initial work packages + tasks), team links, and audit context.

The associated interfaces include:

• A list view of active chantiers.
• A kanban board per work package.
• A work package detail view with its tasks.
• Cockpits — consolidated views of active sessions.

The endpoints cover the full lifecycle: active sessions, bug detection, mission generation, archiving, closure with email draft, brainstorm mode switch, management of deliverables, team members, and audit relevance.

Concurrency Control and Audit Mechanisms

Several components ensure the consistency of concurrent operations on a chantier:

Component	Role
Chantier lock	Distributed lock per chantier. Prevents two parallel sessions (operator session and spawned sub-agent) from concurrently modifying the same chantier. Composite key (chantier identifier, owner type). TTL of 30 minutes, renewable via heartbeat. Backward-compatibility mode: if the lock table is absent, acquisition is considered successful.
Active lock error	Exception raised when a chantier context is requested while another session holds the lock. Caught by the chantier processing module to return an explicit message to the operator.
Discovery audit log	Records each invocation of the automatic work-package discovery pipeline. An entry is created in pending state and then updated to success, validation_failed, llm_failed, or killswitched. Notable columns: AI model used, provider, tokens consumed, estimated cost in euros, generated plan, number of work packages created. Retention: 90 days. A counter over the last 24 hours serves as a configurable circuit-breaker before each execution.
Task dependency graph	Models dependencies between tasks within a work package as a directed acyclic graph (DAG). Adding a dependency validates: absence of self-reference, membership in the same work package, absence of cycle (DFS detection). Cross-work-package dependencies have a dedicated table (status to be confirmed). Explicit errors: cycle detected, tasks belonging to different work packages.

Integrated CLI Console

A dedicated surface allows operators to drive a real Claude CLI session from the cockpit, without leaving the Hub interface. It exposes three operations:

• Status — queries a daemon running on the host machine (not inside an isolated container); returns { ok, alive, info }. When the daemon is unavailable, the response remains an HTTP success with alive: false — the internal error message is never forwarded to the client.
• Keystroke sending — forwards keyboard input to the active session.
• Real-time stream — SSE stream of the CLI session output.

Security: the daemon targets the host machine and not the application container — a fix aligned this behaviour during a stabilisation work package.

Commercial Negotiations

The Negotiations console materialises the incoming lead qualification pipeline:

1. An incoming email is forwarded to Atlas.
2. Atlas classifies the intent as negociation.
3. A negotiation record is created.
4. Agents work on this record from the detail view.

Operations available on a negotiation cover: assignment, contact management, deliverables (with attachments), email history, events, commercial proposals (with accept/reject decision), status, and timeline.

Fleet Supervision

The fleet module is a server-side module with no dedicated Hub interface at this stage. It maintains a registry of instances deployed at customer sites, storing for each instance: customer identifier, name, domain, subscribed offer, monthly recurring revenue, installation fees, status, VPS region, administration URL, provider, and AI model in use.

⚠️ Points of attention:

• Operational fleet management is carried out primarily via the Hub site and user administration consoles — not directly through this registry.
• The operational source of truth for customer VPS instances is a separate table; the exact relationship between the two registries is to be confirmed.
• This registry is a legacy schema inherited from the PaaS era. It historically contained columns for access secrets — this schema is under audit and must not be considered the canonical source of secrets. The current doctrine mandates zero plaintext secrets in business tables.

Orbital View — Reactor

The Reactor page provides a real-time orbital visualisation of agent activity. It is composed of three concentric rings:

• Inner ring — director agents.
• Middle ring — scoping and execution agents.
• Outer ring — validation agents.

An octopus logo occupies the centre. Updates are received in real time via an SSE stream. The page is rendered client-side only. It shares its visual model with the dedicated public marketing page for the reactor.

Entry Points for Contributors

Objective	Mechanism
Add an entry to the Hub navigation bar	Declare the entry in the navigation sections array of the Hub layout.
Add a /hub/X page	Create the page in the relevant module and declare the hub layout via page metadata.
Add a cockpit endpoint	Create the endpoint in the module's API directory and apply the employee session verification middleware.
Understand authentication	Refer to the session utilities and the mothership auto-session middleware.
Wire up a new application module	Declare the module in the Nuxt extension configuration, provide its manifest and local configuration.
Access the runs and chantiers data model	Refer to the shared business entities and their corresponding tables: runs, chantiers, work packages, tasks, negotiations.
Maintenance dial and documentation drift	Refer to the Hub maintenance page and its associated endpoints, which rely on the documentation health and detected drift tables.
External documentation review	Refer to the external review panel component and its endpoints, which rely on the external reviews table.
Reflex registry and agent hooks	Refer to the dedicated Hub hooks page and its listing endpoint, which exposes the reflex registry organised by tier (trunk / arms).
Chantier lock — CLI concurrency management	The distributed lock exposes the following operations: acquisition attempt, force acquisition, release, heartbeat.
Automatic discovery audit log	The audit log exposes the following operations: retrieval of recent entries by chantier, count over the last 24 hours.
Task dependency graph (DAG)	The dependency manager exposes: add, remove, list by work package, with depth-first cycle detection.

Secrets: no secret is stored in plaintext in the codebase. The session signing secret is consumed by the session cryptography module (HMAC) and lives exclusively in environment files excluded from version control, in accordance with the secrets doctrine documented separately.