Harness facades catalogue

This chapter documents the Synedre harness: the set of executable entry points (Python scripts, shell scripts, hooks) that orchestrate agent work around a single, centralised PostgreSQL database. It does not describe the CodeMyShop product, which is multi-tenant and lives in its own scope: Synedre orchestrates CodeMyShop, it is not part of it. Each catalogue entry carries a family, a one-line role and a typical invocation mode.

0. Scope, method and coverage

The catalogue lists the harness facades: roughly 950 top-level Python scripts and roughly 150 entries in the shell-script directory. It is regenerated at regular intervals by a documentation-drift mirror that compares the date of the cited files with that of the chapter and reports two gaps: "code newer than the doc" and "dead references". On the latest pass the mirror flagged a cover-generation module newer than the doc and 68 dead references already documented as such (63 paths actually absent on recount, all annotated).

Extraction is programmatic: the first docstring of each Python file (syntax-tree walk) or the first description line of a shell script supplies the role. No description is invented; when a file only carries a header, the line says so. When a fact could not be verified, the chapter writes "to be confirmed" rather than deducing it.

Update from the latest regeneration

• WooCommerce import: a new facade takes over the public catalogue of a WooCommerce shop into a structured import for CodeMyShop (dedicated sub-family, section 15).
• Covers: photo cover generation now resolves the generation agent through an explicit path, because the scheduler's reduced environment could not see it; a nightly pass had been declared down for that reason.
• Organisation: provisioning of the founders' private space replays one additional migration (visual profiles of the founders).
• Email handling: the last reply sent in a thread is shown in full to the drafter, and the blind replay applies a three-minute margin so the real reference reply no longer leaks.
• No effect on the catalogue: dictionary entries about the arm, pool, tentacle and sucker architecture (migration and architecture document, no facade); product checkout fixes.
• Dead references: no new dead reference introduced.
• To be confirmed: the schedules of two recent watchers (nightly demo reset, monthly SEO audit) were not checked against the scheduling table.

Covered vs actual count

Category	Actual total	Covered
Top-level Python scripts	949 (948 on the previous pass)	All, one per table row except rare sub-family duplicates
Shell-script directory entries	148 (unchanged)	All top-level entries

Counts went stale several times before being restored by a file-by-file recount; the history of those corrections is kept in the internal chapter.

"Invocation" legend

Value	Meaning
cron	launched by the scheduler, often through a supervision wrapper
CLI	called by hand on the command line
skill	facade behind an agent skill (slash command)
hook	code-agent hook: session start, prompt submission, before/after a tool, session end
lib	imported module, not a standalone entry point
worker	daemon or loop that drains a database queue

1. Families & overall flow

The overall flow has four tiers. An incoming email or a command from the control cockpit reaches the inbox/email family, which classifies the intent. The atlas/orchestration family takes over and opens either a work order (chantier) or a brainstorm. Execution is handed to agents, which feed five effector families: audits, blog/SEO, finance, browser and deployment. Everything converges on a single PostgreSQL database, reached only through a dedicated Python facade.

incoming email ──► inbox/email ──► atlas/orchestration ──► chantiers | brainstorm
                                          │
                                   agent execution
                                          │
        audits · blog/SEO · finance · browser · deployment
                                          │
                       PostgreSQL (single harness schema)

Data landmarks: the database is single and centralised; every facade goes through a common access module and a centralised environment loader. Secrets live in environment files excluded from the repository and are never reproduced in the documentation.

2. Common base (lib / cross-cutting facades)

The base groups the modules that almost every other family imports. The internal chapter gives a full table; here are its blocks.

Block	Role	Invocation
Database access	PostgreSQL facade for automation scripts; persistent connection pool for the entity layer; "golden" output-format contract that proves byte-for-byte identity and guards against silent corruption	lib
Guarded writes	One-off write symmetrical to reads: target attested by a dump, dry-run by transaction rollback by default, returned rows required on updates and deletes, DDL refused	CLI / lib
Task execution	Task worker with anti-zombie lease, derived spawn timeout and retry on failure	worker
Output bounding	Safety net that bounds the size of tool results returned to the model (token-cost control)	hook / lib
Paid-tool circuit breaker	Guard that refuses any paid-tool call before any network access when an environment switch is set (public demo account)	lib

Credentials registry sub-family

A central registry lists third-party accounts without ever exposing or storing a secret in clear: assisted creation and filling, audit trail, rotation. Agents never see the password.

MCP sub-family

Bulk SEO optimisation bridge, per-tenant token issuance and a tool server shared between several agent harnesses.

Tenant resolution, session scope and write-target sub-family

Modules that determine, for a session or command, which tenant is targeted and where a write is allowed to go. The destination always comes from the fleet inventory in the database, never from a hard-coded value.

3. Atlas / orchestration family

Doctrine: a programmatic agent invocation goes through a pseudo-terminal, never through a direct non-interactive call. This family covers polling of the orchestration mailbox (once a minute, with a DKIM gate on forwarded messages), intent classification, agent start-up and reaction to failed tasks.

Sub-family	Role
CLI-to-cockpit bridge	Links command-line sessions to the dashboard
Multi-LLM AgentRunner	Runs the same job on several models, with routing stored in the database
Tentacle pool	Fan-out of parallel sessions in the cockpit terminal
Codex harness	Application server, brief and context guard
Portable meta-harness	Same safety guards for Claude, Codex and Antigravity through a single dispatcher
Fifth native harness	Harness with residential egress for browsing
Cockpit sucker link	Links a session to its working arm in a demonstration cockpit

4. Chantiers family (7-step workflow)

The official facade creates a chantier from an incoming email following the seven-step procedure: read the request verbatim, scan attachments, audit the agents, mission letter, explicit recruitment, atomic creation with skeleton, then update and readiness check. An intake classifier determines the regime (light run, plan-mode run, chantier) and the autonomy level. A drift audit detects chantiers whose status lies relative to the real code, and a reversible snapshot gate protects plan-mode runs.

QA orbit sub-family — automatic closing of chantiers

Automatic closing of a chantier when the QA proof is present and compliant.

Post-chantier self-optimisation sub-family

An analyser re-reads agent events and task runs when a chantier closes and feeds an optimisation backlog; a facade then turns a backlog line into a corrective chantier, never automatically.

5. Brainstorm family

Brainstorm workers drain a database queue. The looping daemon is fragile: safety comes from a single scheduled run per pass. Retained ideas are promoted asynchronously.

6. Audits / quality / security family

Nightly audit of all automata, read-only watchers on the fleet's CMS tree (orphan categories), audit of the authentication guards on API routes (a JSON 200 response is a leak; 401 or 403 is locked), antivirus scan of attachments before any opening, LLM-in-cron detector, schema-consistency and tag-coverage sentinels, backup integrity. Documentation-debt sensors based on syntax-tree analysis complete the set.

Per-tenant QA system account sub-family

A dedicated technical QA account is maintained for each tenant, with a log of its uses; the table entries describe creation, rotation and checking.

Iso-Figma sub-family — mock-up versus render measurement

Measures the gap between a Figma mock-up and the render, route by route, routes each gap to the right action and sets vertical gutters by measurement, with a numeric prediction before deployment.

7. Memory / scars / learning family

Code-agent hooks read and write memory at three levels: memory notes, a second brain of atomic notes and a vector index in the database. A "scar" is a lesson drawn from an incident, injected into agent context before risky actions. Sensors detect recurrences, merge duplicates and split a session that exceeds a context threshold, then re-inject the last session hand-off at the next start.

Nightly maintenance loop and documentation self-repair sub-family

A nightly loop inspects consistency between documentation and code, measures five health dimensions (including coverage), regenerates drifting chapters under a gate, reviews the result before publication and exposes its state on a maintenance dial. Failing steps are counted and reported.

Adaptive immunity sub-family

Reflexes learned from past incidents, triggered before a known risky action can recur.

Deliberation organ sub-family

Structured decision mechanism between agents when several options are defensible.

8. Personas / agents family (upkeep)

Weekly synchronisation of the Synedre's canonical agents to the household application (the latter's agents are not locally invented personas), model-driven persona refresh with a three-way diff and human review, and retrieval of an agent's full profile with its scars.

9. Inbox / email (client) family

Hard rule: no client email is sent by the AI on its own initiative; everything goes through a single facade with draft then send steps, and a hook blocks direct use of the SMTP protocol. Mailbox credentials live in an environment file outside the repository.

• Opposition guard (GDPR art. 21): drafting is refused if the address or its domain appears in an opposition table kept without time limit; when the database is unavailable, refusal is the default behaviour.
• Client message never scheduled: a reply in an open thread, or to a recipient known as a client, cannot be scheduled for later; only a first contact to an unknown party can.

Prospecting and measurement note sub-family

Public qualification of a site, measurement note backed by proven probes (speed, technical, search demand), meeting preparation and sealed first contact within a fixed time window.

Delegations sub-family (acquisition and communication)

Two delegations bounded by a daily quantity, an explicit scope, a previous-day recap with veto right and an environment switch. They never cover an existing client, an amount or a commitment.

Email handling by sucker sub-family

A watcher launches one handling per client on a token-based approval, applies common drafting rules (verify before asserting, commit to nothing, next action, "committed is not delivered"), keeps the list of open promises in the thread and measures the rate of drafts validated as-is. A blind replay compares what the sucker would have written to the reply actually sent, with two distinct judges. Since the latest pass, the last reply in the thread is shown in full (others are truncated) and the replay applies a three-minute margin on the reference.

Instant professional messaging sub-family

Sending on human validation, delivery state tracked, no impersonation of the founder's identity.

Community sub-family

Watch for public help requests, help-draft, slot-based queue (random gap, activity hours, daily cap) and a per-channel switch. Never solicitation, commercial links or private messages.

Protection of an adult sub-family

Sorting of the mail of a compartmentalised case, fact extraction and update of procedures, never as a scheduled task.

AI voice desk sub-family

Automated telephone reception with a desk report.

Self-addressed system emails sub-family

Single morning recap replacing individual alerts; family and agent label set at send time; burst protection.

10. Blog / SEO / content family

"Database-first" publishing engine, multilingual per-page SEO engine (meta, description, FAQ, internal linking, with status and a backup before each pass), internal links in product descriptions that target a URL answering 200 in the page's language, and a series of editorial production subsystems.

Sub-family	Role
Site mesh	SEO, performance and security hubs spread across the fleet
Google Search Console	Data import, traffic-decline diagnosis, opportunity report
i18n translations	Bulk translation of localised fields; market adaptation rather than literal translation
Autoblog	Writing, relay, seeding and restocking of blog queues
Article FAQs	Catch-up, regeneration and purge of duplicate FAQs
Category covers	One image per category drawn from its SEO, with alt text per market
Blog covers	Realistic photo generated without a browser by the generation agent, 1200×630 crop, WebP, generation queue; resolving the agent through an explicit path avoids the failure of the scheduler's reduced environment
Agent dialogue forum	Threads published on the site
Wave indexing	Progressive page submission
Internal linking	Links placed from Search Console queries, reversible
i18n glossary	Multilingual glossary and translation pilot for a culinary-products site
Netlinking	Contact discovery and link tracking
Auto-parts catalogue	Tools specific to a parts catalogue site
Automatic social broadcasting	Posts drawn from bounded sources (article, tip, weekly delivery, already-published reply), published after a validation click in a single queue, under mechanical guards: anti-leak, no client name, per-network and per-day cap, switch. A browser publisher for an article platform is added, limited to two articles per month.

11. Browser / browser agents family

Protection doctrine: a SOCKS proxy handles IP reputation, not anti-bot challenges, hence a headed browser on a residential machine. A job queue drives the Playwright agents.

Residential machine sub-family — provisioning, jukebox, cinematheque and edits

Machine preparation, music playback, film library with measured and retranslated subtitle tracks, video edits.

Figma sub-family (iso mock-ups)

Inventory of a Figma file and retrieval of mock-ups as images with a manifest; DOM, browser capture, programming interface, fills and comments modes.

12. Bank / invoicing / finance family

Scheduled bank synchronisation, statement import with duplicate protection and hardened parsing (non-breaking thousands separators, foreign-currency lines ignored), automatic categorisation from a rule base with a single canonical vocabulary, invoice reconciliation, invoicing with recurring subscriptions (single issuer, show before sending) and overdue-payment reminders with an authorisation code.

FinOps sub-family — pockets, caps and calls

Tracking of model and infrastructure costs per pocket, caps and alerts.

Supplier expenses sub-family

Entry, classification and reconciliation of expenses.

Household sub-family

A separate database holds personal finances: the personal is never mixed with the professional.

Model-provider budget and throughput sub-family

Quotas, throughput regulation and budget of a third-party model provider.

13. Brand-watch family

Machine-checkable QA scale for the brand guidelines (seven categories), monitoring of search results around proprietary inventions and competitive watch. Some of these watchers are no longer scheduled and only run by hand; the catalogue says so.

Brand and logo search sub-family

Prior rights, available domains and prices, filing costs, PDF deliverable; the tool proposes and never files or buys.

Logo vectorisation sub-family

Conversion of a raster logo into vector form.

14. Deploy / ship / infra / backups family

Production release rule: shipping a tenant to production is decided per tenant, through a fleet flag in the database; it is not reserved to a human. At night it requires QA proof; a health script provides rollback and an environment switch turns it off. Delivery of an internal target always goes through the deploy command, never through the production ship. Migrations, in-container commands and infrastructure remain the AI's responsibility.

The deploy library detects drift between application schema and database before the build (blocking by default), applies missing idempotent DDL (never drops) and generates the i18n routes. A delivery journal records each successful deploy to answer "since when has this commit been live?".

Backups and restore

Encrypted backups to object storage, restore tests and an audit of their freshness.

Mothership-to-another-server switch sub-family

Frozen switch sequence with proof before cut-over.

Auto-parts shop sub-family

Infrastructure tools specific to a catalogue tenant.

Registrar facades sub-family

Registrar, mail aliases, client account, API rights. The organisation also provisions the founders' private space without displaying any secret: dedicated role, backup before writing, replayable migrations (including the most recent one, the founders' visual profiles) and revalidated minimum right; without the apply option, the tool simulates.

15. OSS sync / refactor / migrations family

The sync publishes the core and community parts of CodeMyShop from the private repository to the public one, as a flattened snapshot per release (not a commit-by-commit replay). Tools strip the comments from the snapshot. The family also contains supplier connectors, scraping, demonstration seeds and platform migrations.

Sub-family	Role
Supplier catalogue connectors	Imports of dropshipping supplier feeds
Client scraping / ETL	Idempotent sitemap-driven scraper, anti-ban, images, injection into a remote preproduction; shared HTTP base
WooCommerce import	See below
Competitor price comparator	Targeted collection on references already sold, synchronisation to the comparison module, weekly run of one competitor per night
Demonstration seeds	Demo datasets
Faithful redirect batch	301 redirects for products
Variant grouping into combinations	Merging variant listings into combinations
Checkout and store connectors	Catalogue synchronisation from point-of-sale software
Colour combinations	Grouping a product range by colour
PrestaShop 9 migration	Theme, migration, module and 301 redirect plan from an older shop to PrestaShop 9

WooCommerce catalogue import sub-family

Takes over the public catalogue of a WooCommerce shop into CodeMyShop: read-only access to the shop's public API, no database write and no deployment.

Component	Role	Invocation
WooCommerce import tool	Reads, without a key, products (paginated by the page-count header), categories and the detail of each variation (price, reference), then drops an import folder (structured JSON file and images) that the tenant owner integrates. Normalisation: HTML entities decoded, long-description tables converted to label/value pairs, brand taken from the shop's field or else from a supplied list (whole word, never guessed), prices in cents (zero = on quote), original image and never the thumbnail. At most one request per second, as the site belongs to a third party. Options: site, output folder, brands, pause, no images, no variations, replay from a raw folder.	CLI / import skill

16. Obsolescence monitoring / harness tests (miscellaneous) family

Session brief, unit tests of the obsolescence functions, production safeguard for the only paying client, and cross-cutting subsystems.

Sub-family	Role
3D workshop / 3D configurator	Modelling pipeline, published versions, geometric correction by annotated stroke
Protection of an adult	Compartmentalised handling of a protection case
Automata governance	Synchronisation between the real scheduling table and the database registry
Jukebox / karaoke	Terminal music player
Supervision watchers	Distribution of scheduling watchers

17. Code-agent hooks inventoried (two settings files)

Hooks are declared in two distinct settings files, each carrying a different set: they must not be confused.

17.a — Local settings (Python facades and scripts)

SessionStart      → context counter reset, session brief, scar injection
PreToolUse:Bash   → production-write guard, email-facade guard
PreToolUse:Edit   → scar injection before writing
PreToolUse:Agent  → scar injection before delegation
PostToolUse       → context tracking

The prompt-submission hook is empty in this file.

17.b — Repository settings (shell wrapper hook subsystem)

An entire orchestration subsystem lives in a shell layer that frames the facades. It notably includes: a universal dispatcher of safety guards, blocks on mass-staging in the version manager, guards against writing to client production without explicit consent (latest addition), secret guards, doctrine reminders before editing, a block on working on the shared trunk, and guards on production-release commands. Each matcher is verified group by group during adversarial reviews.

17.c — Guards present on disk but not wired

Inventory of guards that exist but are declared in neither file; they are listed so that nobody assumes they are active.

18. Reliability notes

Each regeneration records its accepted limits. The latest: one new facade catalogued, four lines realigned, one sub-family added. Still to be confirmed: the schedules of two recent watchers, the line of a build script not re-read after a multi-slot semaphore was added, the re-alignment of line pointers on older entries, and a review of the WooCommerce import skill.

• Adversarial reviews: the doc was repeatedly checked against the real code (scheduling in force, hook settings, commit history); corrected gaps include documented schedules that did not exist, files marked deleted that had been restored, and wrong hook counts.
• Dead references: a purge of unused scripts moved several dozen files to a bin; each is marked "deleted" with its restore path for thirty days.
• Anomalies found: scheduling docstrings out of date versus the real table, facades designed for scheduling with no active entry, hard-coded destinations contrary to the "destination comes from the fleet" doctrine, orphan scripts.
• Deliberately not copied: the default credentials of a preproduction access protection, and the names of the compartmentalised schemas of a protection case.