Harness facades catalogue

0. Scope, method and coverage

This chapter catalogues the Synedre harness: the executable entry points (Python scripts, shell scripts, hooks) that orchestrate agent work, centralised around a single database. It does not describe the CodeMyShop product, which is multi-tenant: Synedre orchestrates CodeMyShop, it is not part of it. The boundary is strict: anything generic lives in the CodeMyShop core, anything specific to a client lives in a dedicated overlay, and the harness never holds business content as static files.

Each entry point is listed with its family, a one-line role and its typical invocation mode (cron, command line, skill, hook, library, worker), so that an engineer taking over the repository can find which script does what without reading several hundred files. The email-sending, attachment-scanning and deployment facades are declared "single mandatory facade": no direct call to the underlying transport.

Latest mirror regeneration: the catalogue now covers 948 top-level Python scripts and 148 command-line tooling entries. The gaps flagged by the documentation-drift mirror are of two kinds: cited code newer than the doc, and about sixty dead references already documented as such (deleted or moved files, annotated in the chapter and excluded from the drift computation).

• Internal mail and copies: a single Atlas → founder channel (canonical mailbox, reply address pointing back to Atlas, real message identifier read back after sending) and a pure module guaranteeing a single "to validate" copy per draft.
• PrestaShop 9 takeover: four new facades (style guide, takeover audit, module installation, redirect replay), all restricted to pre-production.
• DNS and hosting: a single shared-hosting API call per browser session without credentials, comparison of two DNS zones before a switch, provisioning of a private space with no secret displayed.
• Watchers: paginated reading of the blog for the dictionary watcher, monthly opening of each tenant's SEO audit, monitoring of the demo's nightly reset.
• Distribution: browser publisher for a long-form network (at most 2 per month, after human validation) and a fix for a leak-guard false positive.
• Hook: a blocking guard requiring that any write to a client's production be stated plainly to the founder before it happens.

Extraction method

The inventory cross-checks every top-level file of the tooling repository against the chapter text; a missing file is read (docstring and arguments) before being catalogued. Commits made after the last regeneration are reread to realign existing lines. Every file reference is checked on disk; a reference that no longer exists is annotated, never silently removed.

Covered vs actual count

Scope	Actual	Coverage
Top-level Python scripts	948	all catalogued or classed "no effect on the catalogue"
Command-line tooling entries	148	all catalogued
Hooks listed	two settings sets	one gap flagged, integrated in this pass

"Invocation" legend

Code	Meaning
cron	launched by the scheduler, often through a wrapper that logs and cuts off repeated failures
CLI	called by hand on the command line
skill	facade behind an agent skill
hook	agent-tool hook (session start, prompt submission, before/after tool, stop); two hook sets coexist (§17)
lib	imported module, not a standalone entry point
worker	daemon or loop draining a database queue

1. Families and overall flow

Entry points fall into families that answer one another. An incoming email is classified then handed to orchestration; orchestration opens work packages or launches a brainstorm; agent execution in turn feeds audits, the blog and SEO, finance, browser agents and deployment.

   incoming email ──► inbox / email  (polling, intent classification)
                         │
   hub, CLI       ──► atlas / orchestration (spawn, reaction, QA)
                         │                │
                  work packages        brainstorm
                         │                │
                         ▼                ▼
              agent execution (multi-LLM call, reactive task)
                         │
      ┌──────────┬───────┴────┬──────────┬──────────┐
      ▼          ▼            ▼          ▼          ▼
    audits   blog / SEO    finance    browser    deployment

A second, cross-cutting plane carries memory and learning (scars, doctrine, semantic recall), the nightly maintenance and the hooks that frame every agent action.

2. Common base (libraries and cross-cutting facades)

The base groups the modules reused by every family: access to the single database, sending facades, tenant resolution, failure logging, cron wrapper, cost guards. About thirty lines describe them, each with its contract and call mode.

Credentials registry

The third-party access registry never stores a readable value in a tracked file: a password is generated, encrypted and entered within the same process, under verifiable invariants ("vault only" level). A signed fingerprint store feeds a hook that blocks any plaintext entry; a watcher checks the invariants with a zero-deviation threshold; a migration tool moves metadata to the registry with backup and rollback. A collector periodically gathers the secrets that a server's fleet record declares.

MCP bridge

A bridge exposes the bulk SEO tools, issues one access token per tenant and serves a tool server shared across several agent harnesses. Every token issuance is traced and limited to the requesting tenant.

Tenant resolution, session scope and write target

A single resolver reads the fleet to find the targeted tenant and fails closed if it is ambiguous; a tenant's pre-production is read from the fleet before any naming convention. A scope guard limits what a tentacle may write: it can write to the founder without opening the inbox or a third-party copy, and a session started without a tenant only sees its client's team.

3. Atlas / orchestration family

Atlas is the entry point that receives a request, qualifies it and distributes it. About fifty facades handle session launch, task reaction, reply dispatch and clean stops. Internal sends to the founder all go through a single channel: they leave from the canonical mailbox, with a reply address that routes the answer back to Atlas's poll, and return the real message identifier.

Command line → cockpit bridge

Eight facades link a command-line session to the cockpit: state sync, event upload, posting of a command the agent asks the founder to run. As of this pass, a session can post a command for another suction-cup session (target profile:#id or profile:name), discard it or re-post it, and the cockpit aims the button at the right session.

AgentRunner (multi-LLM)

A single runner calls the models of several providers under a common contract (harness profile, cost, quota). It plays its turns on the native harness server when one exists and refreshes the quota along the way.

Tentacle pool

The cockpit fan-out launches, tracks and closes parallel sessions (one "suction cup" per work arm). Sixteen facades handle opening, ceiling, resumption, transcript reading, compaction and automatic relaunch of a session that stops.

Codex harness and portable meta-harness

An adapter drives the Codex application server with a brief and a context guard. A meta-harness generator produces, from a single source in the database, the configurations of three harnesses (hooks, agents, skills) and measures guard parity between them.

Fifth native harness

A fifth harness relies on a residential egress through the browser box, a local HTTP CONNECT relay and a quota client. A bounded launcher always sets workspace trust and refuses the contributor profile.

In-Situ cockpit suction-cup link

An outgoing event-stream link with signed requests connects a suction-cup session to a demonstration cockpit, behind a paid-call circuit breaker. The demo account drives the demo through its profile; production remains closed to it.

4. Work packages family (seven-step procedure)

A work package is the unit of work that is untestable or irreversible. The seven-step procedure is enforced mechanically: reading the request, auditing agents, mission letter, explicit recruitment, atomic creation with skeleton, post-skeleton update, readiness gate. About fifty facades support it: creation, dashboard, step transition, closing, report.

QA orbit — auto-closing

Three facades check a work package's acceptance proof and close it automatically when it is sufficient; without proof, it stays open.

Post-package self-optimisation

Two facades reread a finished work package and draw proposed lessons from it, never applied without validation.

5. Brainstorm family

Eight facades organise collective reflection: opening a topic, round of agents, synthesis and recorded decision. A brainstorm produces a recommendation, not an execution; acting on it goes back through the work-package procedure or a light run.

6. Audits / quality / security family

The largest family (about a hundred lines): read-only watchers measuring drift between code, database and documentation. It includes schema audits, route security audits, skill conformance, test coverage, backups and the editorial tree.

Per-tenant QA system account

A registry associates each tenant with a dedicated acceptance account. An entry guard and a watcher check its state, a tool sets the password without a mailbox, and a live proof verifies that a protected resource does answer with a refusal. The acceptance browser has one profile per tenant and an exact-host allow-list.

Mockup-to-render measurement

Ten facades compare a design mockup with its render, route by route: mockup file inventory, capture, vertical gutter deviation computation, judgement and judge reliability.

7. Memory / scars / learning family

Sixty facades manage the team's memory: qualified scars (incident, cause, rule, guard), doctrine, semantic recall by vectors and full-text index, transcript compaction, notes dropped in a staging zone. The repository's rule is that the "how" lives in documentation and the "why" in memory.

Documentation self-repair

A nightly maintenance loop compares documentation with code, flags dead references and content older than the code it cites, then proposes a gated regeneration: the regenerated text replaces the old one only after references are verified. Nineteen facades carry the measurements, the repair queue, the maintenance dial and the alerts.

Adaptive immunity

Four facades turn a recurring incident into a mechanical guard: signature detection, proposal of a hook or a test, tracking of its effectiveness.

Deliberation organ

One facade structures a delicate decision into weighed options and records the retained arbitration.

8. Personas / agents family (upkeep)

Ten facades maintain the agent registry: records, tool scope, skill attachment, wear indicators and periodic review. The registry lives in the database; harness agent files are derived from it.

9. Inbox / email (client) family

Mailbox polling, intent classification, draft writing and sending go through a single facade: draft, shown before sending, explicit validation, send. Nothing leaves for a client on an agent's own initiative.

Two new modules complete the chain: a single channel for Atlas-to-founder messages, and a pure module that replaces rewritten drafts with a single "to validate" copy (never touching a draft already sent, scheduled or whose token is consumed). A client file can be produced as Markdown readable by both a human and a model, through an allow-list and mechanical sanitisation.

Prospecting and measurement note

Twelve facades qualify a prospect, date every observation, write a first contact backed by a verified fact and schedule sending under seal within a time window. A multi-section measurement note (speed, PHP, SEO, hygiene, appointment) accompanies the contact.

Bounded delegations

Two written delegations, activatable only by the founder, authorise daily-capped sends within a strict perimeter, after a recap the founder can veto, with a cut-off switch.

Suction-cup processing

A watcher launches one processing run per client, starts on token validation, applies drafting rules and thread promises, replays dry with two judges and measures the rate of drafts validated as-is. Each processing run is audited through a dedicated view.

Pro messaging and community

A pro WhatsApp family handles the official API; the PrestaShop community is read and answered under guards (charter, politeness, form, leak guard), with automatic publication on forums and human validation for the rest.

Protection of an adult and voice desk

A dedicated mailbox sorts the mail of a protection file, extracts facts and prepares a recap; the voice desk drives a telephony front end and the provider's telephony.

Self-addressed system emails

Three facades handle messages the system sends to itself, under a fail-closed trust model: an unauthenticated message is logged, never triggering. A 7:30 recap groups the watchers instead of sending them one by one.

10. Blog / SEO / content family

Eighty-five lines plus about fifteen sub-families: writing, relay, queues, covers, internal linking, indexing, Search Console, glossary, translations, netlinking, distribution.

Site mesh

Three poles (SEO, performance, security) measure each site in the fleet and feed a summary view.

Google Search Console

Seventeen facades import history, replay inspections, classify gaps by cause, verify a site's ownership and connect new domains to the daily import.

i18n translations

The rule is "adapt to the market, do not translate": a hook enforces it, non-French sheet writing starts from a market brief in the database, and language invariants check the attested glossary terms.

Autoblog

Writing, relay, seeding and restocking of queues are driven by watchers: remaining topic days, actual publication, missing visuals. The publication ceiling is set per week.

Other editorial sub-families

• Article FAQs: catch-up, regeneration and duplicate purge.
• Covers: category (one image per category, alt text per market) and blog (published thumbnails).
• Agent dialogue forum: threads published on the house site.
• Wave indexing, reversible internal linking, i18n glossary, netlinking supervised by freshness.
• Auto-parts tenant: thirteen technical watch and catalogue facades.

Content watchers

The dictionary watcher rereads published articles page by page (read-only, cursor and character budget). The monthly SEO audit opens, on the first of the month, one task per enrolled tenant: the cron only opens the work, writing is a session job and the data spend stays gated.

Automatic social distribution

Posts come from closed sources (article, tip, delivery, already-published forum answer) and pass mechanical guards (leaks, AI markers, hook length, per-network and per-day ceiling, switch). A browser publisher handles a long-form article network, at most two per month, after human validation; it refuses to silently truncate tags and rereads the published address. The leak guard now tells a URL identifier from a commit hash.

11. Browser / browser agents family

Forty-four facades drive real browsers from the mothership: navigation, typing, capture, persistent sessions, per-use profiles. Guards limit the frequency of calls to third-party sites: ask for less and more slowly rather than bypass an access control.

Browser box — provisioning and edits

Seventeen facades handle box installation, a jukebox, a subtitle cinematheque and video editing. Profiles outside the box (personal workstation, attached Windows PC) get an honest check: state is no longer probed on a local browser that does not exist.

Mockups

Eight facades bring back mockups (DOM, capture, presentation, API, fills, comments) with their manifest.

Shared hosting without credentials

One facade makes a hosting-panel API call per invocation, in the browser's already-open session; no credential is ever seen. Reads are free; any write requires an explicit flag.

12. Bank / invoicing / finance family

Twenty-three facades handle bank reconciliation, invoicing (issuer always the founder's entity, shown before sending) and cost tracking.

FinOps — pockets, ceilings and calls

Three facades track budget pockets per use, their ceilings and the calls that consume them. Paid calls are gated by a circuit breaker.

Supplier expenses

Four facades collect supplier invoices via API, archive them outside the repository and attach them to an expense; a CLI lists and completes them.

Household

The household database is separate from the professional one: personal does not mix with pro.

Model-provider budget and throughput

Three facades compute a model provider's remaining budget, the allowed throughput and an autonomy heartbeat.

13. Brand-watch / monitoring family

Twenty-six watch facades: competition, market, opportunities and threats.

Brand and logo search

Seven facades check prior rights (trademark offices), domain availability and price, filing costs, then produce a deliverable. They propose; they neither file nor buy.

Logo vectorisation

One facade vectorises a bitmap logo while keeping curve fidelity.

14. Deploy / ship / infra / backups family

Sixty lines for going live, infrastructure and backups. Hard rule: the fleet decides whether a site may be shipped to production; an internal target goes through the dedicated deployment, never through shipping. At night, an acceptance proof is required, with automatic rollback through a health check and a stop switch.

• Build oven: the heavy build is offloaded to a buffer server, with a multi-slot semaphore (two simultaneous builds) and per-tenant isolation.
• Secrets guard: an output scan blocks by default a build that embeds a secret; a tenant whose secrets only lived in the build is refused.
• Delivery log: called at the end of every go-live, it dates the delivery without depending on a button.
• System doctor: a closed list of treatments, an action log, and an exit code that tells a critical finding from a crash.

Backups and restore

Twelve facades back up databases to object storage with retention (90 days then archive to one year), test restoration and monitor freshness. A client's hosted site is backed up every night off its own server and monitored like the others. The human vault has its own backup and trial restore, and a guard prevents it from being reachable from the Internet.

Mothership switch

Three facades frame the move of the mothership to its new server: preparation, switch, parity verification.

Legacy tenant

Six facades group operations specific to a parts-import tenant (updates, checks, reconciliations).

Registrar, aliases, accounts and rights

Nine facades rely on a single registrar API client: idempotent DNS, aliases, domain-name ordering in three steps (quote, order form paid by a human), account opening in the client's name without a password, request to widen rights. To these are added the comparison of two DNS zones name by name before a switch (proxied addresses are replaced by the real origin; non-zero exit code on any gap) and the provisioning of a private space with no secret displayed (dedicated database role, backup before writing, replayable migrations).

15. OSS sync / refactor / migrations family

Thirty-two lines plus about ten sub-families. Synchronisation of the open-source core is one-way from the private repository and refuses any client-name leak.

Supplier connectors

Eight facades import the catalogue of two wholesalers (normalisation, images, prices); two others cover a store-management connector.

Client scraping and ETL

Fourteen facades extract, clean and load client data within authorised takeovers.

Competitor price comparator

Four facades collect public prices of a tenant's competitors to feed pricing decisions.

Demonstration seeds

Fourteen facades and scripts create and reset the demonstration dataset. A watcher monitors the nightly reset: three verdicts (ok, not armed, alert); only the first is silent, and the "task set but never run" case is detected.

"Faithful" 301 redirects

Three facades set a batch of permanent redirects that preserve the exact targeted product.

Auto-parts catalogue tenant

Thirty-seven facades: sheets per reference, compatibilities, iterative quality checks, import and reconciliation.

Variants, suppliers and colour combinations

Five facades group variants into combinations; two handle a supplier connector; three create colour combinations for a tenant's aisle.

PrestaShop 9 takeover

Four new facades, all restricted to pre-production:

Facade	Role	Invocation
PS9 style guide	Derives colours from the logo and writes them, between two markers, into the child theme's stylesheet as Bootstrap variables; the manual zone is never touched.	skill
Takeover audit	Inventory of defects the data acceptance does not look for: terms checkbox pointing to a deleted page, footer linking to vanished pages, consent referring to a non-existent policy, marketing modules never configured. Read-only.	skill
Module installation	First looks for known PrestaShop 9 pitfalls (non-zero return code if blocking), then installs on pre-production only, with cache cleared and proof in the database.	skill
Redirect replay	Replays on the new shop the addresses the Search Console has seen, sorts the losses. Read-only, writes only its report.	skill

16. Obsolescence monitoring / harness tests family

Thirty-five lines plus five sub-families: dependency obsolescence monitoring, harness tests, parity probes.

3D workshop and bespoke configurator

Forty facades drive the 3D chain (model, rig, render, likeness check) and a bespoke configurator.

Protection of an adult

Five facades complete the handling of the file's mail (admissibility, procedures).

Automata governance

Four facades reconcile the scheduler table with the database and flag gaps (orphan crons, outdated documentation).

Jukebox / karaoke

Four facades drive the household television's player.

Supervision watchers

Six automata supervision watchers, and a switch to a dedicated SRE supervision.

17. Claude Code hooks listed (two settings files)

Hooks live in two distinct files, each carrying a different set; they must not be confused.

17.a — Python facade and tooling hooks

This set declares the hooks for session start (context counter reset, session brief, scar injection), prompt submission, before-tool (production write guard, email facade guard, scar injection before Bash, edit, write and agent) and after-tool.

17.b — Shell wrapper hooks

This second set, of more than two hundred entries, carries the guards in shell and Python: refusal of a client vhost on the mothership, plaintext secrets, content not adapted to the market, harness parity, agent-file synchronisation, pre-commit. A new blocking guard intercepts any file write to a remote server carrying a client's production (or a host unknown to the fleet): FTP/SFTP transfer with write, copy to a host, upload through an HTTP request. The action must be stated plainly to the founder beforehand, with backup and rollback announced; an explicit escape marker records it after approval.

17.c — Guards present but not wired

Twenty-seven guards exist on disk without being wired into either set (pre-commit, one-off checks, human vault control). They are listed with their actual trigger point.

18. Reliability notes

This chapter is regenerated at regular intervals from the code; each regeneration records what was verified and what was not.

• Latest regeneration: twelve Python facades and one hook catalogued, twelve lines realigned, one sub-family added (PrestaShop 9 takeover).
• Accepted limits: the cadence of two new watchers (demo reset, monthly SEO audit) is not verified against the real schedule; the build oven's line was not reread after its multi-slot addition; line-by-line references of older entries are not all recalibrated.
• Anomalies noted without correction here: outdated scheduling docstrings or comments, facades designed to run in cron but with no active line, a few orphaned or broken scripts. They are listed in the internal chapter for handling by work package.
• Dead references: about sixty cited paths no longer exist; all are annotated (deleted, trash, history) and none was introduced in this pass.