Synedre harness automata catalog

0. Scope and method

Synedre orchestrates CodeMyShop: the harness is the internal engineering system — agent orchestration, task queues, automatic guardrails — that runs the CodeMyShop multi-tenant e-commerce platform and the small fleet of automata around it (audits, content, finance, web navigation, deployment). This chapter catalogs the executable entry points of that harness: scheduled jobs, command-line tools, guards triggered automatically on every action, chat-invocable skills, and shared libraries.

Method: every role described here is extracted from the source file's own header comment, never guessed. The harness today counts several hundred automation entry points — a few hundred scripts and about a hundred command-line utilities — spread across the families below.

1. Families and overall flow overview

The general flow starts from an incoming request (email or internal interface), goes through intent classification (routine task, structured project, question, noise), then through an orchestration layer that triggers, tracks, and validates agent execution. That execution feeds the functional families downstream: audits, content/SEO, finance, automated web navigation, deployment. All families converge on a single database, accessed only through one shared data-access facade — no secret is ever inline in code.

2. Shared foundation (cross-cutting libraries)

A layer of shared libraries carries the cross-cutting functions used by every family: database access, centralized configuration loading, mandatory structured logging, routing across multiple language-model providers, agent-persona loading, event persistence for the real-time dashboard, and git safety tooling (lock-isolated commits so a concurrent session can't leak unwanted files into the same commit, persistent per-client workspaces that eliminate collisions between parallel sessions).

Two mechanisms specifically protect the cost and reliability of language-model calls: a net that bounds what the model receives back as a tool result (most of the observed cost came from unbounded tool output fed straight back into context), and — a recent addition — a context ceiling applied to every sub-agent spawned by a parent agent: past a token budget, the sub-agent loses the ability to call a new tool and must conclude. This second mechanism closes a blind spot: a nested sub-agent never emits the session-end event that the session-splitting loop (§7) watches at the top level, so nothing capped it until now.

Mechanism	What it does
Data access	Single facade to the database — no direct query outside the facade
Git safety	Lock-isolated commits, persistent per-client workspaces, anti mass-staging
Cost / context	Tool-output bounding, per-sub-agent context ceiling, multi-provider routing with tracked cost (never hard-coded pricing)

3. Orchestration

An orchestration layer watches the dedicated inbox, classifies the intent of each incoming message, and triggers a background agent to act on it when needed — with hardened attachment handling (extraction plus mandatory antivirus scan) and a client send that always goes through a multi-step state machine: composition, human review, then a send locked behind a single-use token and checked by a triple anti-spoof match. Nothing reaches a client without explicit validation.

A dedicated worker runs project tasks in parallel (under a concurrency cap) and watches for stuck executions to free them without ever cutting a run still inside its own timeout — an earlier version of this safety net cut healthy runs too early, since fixed. Context for a chained task is re-injected at every step so discovery work already done is never lost again, and a session can resume exactly where it left off after an interruption. An optional bridge lets an interactive terminal session declare which project it is driving, to animate a real-time dashboard on the interface side — inert if no session is linked this way.

A second sub-layer routes execution of a piece of work to different language-model backends depending on the project, under one common contract with centrally tracked cost (never hard-coded pricing); a replay mechanism automatically resumes work that was switched to a fallback engine as soon as the premium engine becomes available again.

4. Projects — structured project method

A "chantier" (structured project) is the harness's structured work unit for requests too cross-cutting, irreversible, or non-testable to remain a routine task. Creation from an incoming request follows a fixed procedure: drafting a mission statement, assembling a team, then an automated pass turning a fuzzy scope into structured, actionable discovery.

A completeness gate strictly conditions admission of a project into autonomous mode: a vague or incomplete project is rejected or automatically enriched, never armed as-is — this is the mandatory front door before any unsupervised nightly execution. A drift detector flags projects whose status lies (marked "in progress" while the code has moved elsewhere, or dead without being closed), and a terminal-based tracker filters noise to show only real signal. Budget tracking distinguishes two billing modes (simulated subscription-equivalent vs direct API), switchable per project, with an alert at 80% of committed budget.

For lightweight changes that don't warrant a full project, an alternative safety net takes a reversible snapshot of the repository state before the change, lets the change run, replays a real regression test, and automatically restores the prior state if that test fails.

Two closing mechanisms complete the loop: a QA orbit that only auto-closes a project if its three-axis proof (code path actually executed, visual verdict, database state) is fully green — never a false green on an axis that couldn't be checked — and a self-optimization engine that re-reads a finished project's execution trace afterward to spot recurring methodological friction and feed a cross-project backlog; turning a backlog line into a follow-up correction project always stays an explicit step, never automatic.

5. Brainstorm

A dedicated queue carries ideas in gestation, drained by a background worker: a maturation conversation, sequential confrontation of the idea against critical review, then promotion into a structured project (or a symmetric demotion back if the project turns out premature).

6. Audits, quality, security

A broad family of audits runs in the background or on demand: dependency security, backup freshness and real restorability (tested monthly, not just assumed), scheduled security reconnaissance across the whole fleet (targets read from a central inventory, never hard-coded) run inside a disposable container destroyed after each pass to leave no permanent attack surface, an anti-leak probe on admin interfaces, accessibility and page-quality checks, uptime monitoring, and consistency checks between written policy rules and the guardrails meant to enforce them.

A visual QA chain renders a page (unauthenticated, or via a controlled remote session for authenticated interfaces) and asks an image-capable model for a verdict against a stated intent — not just an HTTP status check. A three-axis proof assembler (code path actually executed, visual verdict, verified database state) is the mandatory condition before any client delivery email goes out. Several static invariants run continuously: for instance, that a captured contact is actually wired to the conversion-tracking pipeline, or that a language model actually in use carries a pricing entry (otherwise its real cost silently disappears from cost dashboards).

Category	What it covers
Infrastructure	Dependencies, backups, uptime, hardening, admin-endpoint leaks
Content / access	Accessibility, broken links, technical SEO consistency
Execution proof	Multimodal visual QA, three-axis proof before client delivery
Business invariants	Policy ↔ guard actually wired, pricing ↔ real usage, capture ↔ conversion tracking

7. Memory, incidents, learning

The harness's memory is organized in three tiers: a short curated index reloaded on every call, a linked-notes knowledge base synced with an external note-taking tool, and a semantic vector-search layer over both plus the incident history.

Every incident or technical lesson is logged in a structured ledger, harvested automatically from code history, deduplicated, and re-injected at session start and at every agent spawn — so a lesson learned once is never relearned the hard way. A ranking mechanism, driven by actual recall telemetry rather than manual judgment, decides which lessons stay in the always-loaded tier. A nightly consolidation pass re-reads and synthesizes accumulated memory.

A safety net splits a session before its cost turns quadratic (past a certain amount of accumulated context), produces a structured summary, and automatically re-injects it at the next session start — recently extended to nested sub-agents via a twin mechanism, since a sub-agent never emits the session-end event the top-level mechanism watches for (⚠️ to confirm: this twin mechanism still shows an unresolved mismatch today between what it reports itself to be and how it is actually wired).

Nightly documentation maintenance loop. An orchestrated sequence runs every night to keep internal documentation aligned with live code: it perceives the gap between documentation and live code, audits coverage (what exists in code but is described nowhere), mechanically repairs broken references (only when exactly one candidate file shares the same name — otherwise it reports rather than guesses), regenerates a chapter's content through a dedicated review pass, and only republishes after a green light from an automated anti-leak gate. It re-checks itself a second time after publishing so a public snapshot is never left one cycle behind. A weekly digest summarizes what was repaired, with a standing question: "what did we build that we would remove today?"

Adaptive immunity. Recurring incidents are automatically clustered by similarity, and a candidate guardrail is proposed — but no proposal ever activates itself: every candidate requires an explicit human security review before it can start blocking anything.

Deliberation. A mechanism confronts several agent perspectives with distinct cognitive frames on a decision flagged as sensitive, and surfaces the map of disagreement — it never decides itself; deciding stays a human act.

8. Personas and agents

Canonical internal agent profiles live in one place and are synced out to the surfaces that need them rather than reinvented each time. A profile update goes through a three-way comparison and human review before being adopted, and a periodic drift audit flags any profile copy that still describes a retired technical choice.

9. Inbox and client email

Hard rule: no email is ever sent to a client on the system's own initiative. Every send goes through a single two-step facade — draft, then send — and a guard blocks any direct email transport attempting to bypass it. Access credentials never leave a protected environment.

10. Blog, SEO, content

A single database-driven publishing engine handles editorial content. One SEO-optimization engine per page (meta data, description, FAQ, internal linking) prevents drift across several ad-hoc scripts duplicating the same job; sentinels continuously compare declared coverage against actual coverage. URL cleanup tools always pair a slug change with a redirect, never a dry break. Primary-language source content is always hand-authored — the pipeline never silently rewrites it — while secondary languages are completed automatically.

A design-mockup import pipeline pulls approved screens through a dedicated API, with a browser-capture fallback when API access is restricted — both paths produce the same output format, consumed identically downstream. Audience connectors (search console, analytics) default to read-only; the rarer write-capable admin variant is kept separate.

11. Automated web navigation

A queue-driven browser-automation layer relies on residential-reputation network egress: bot detection is primarily an IP-reputation problem, not just a behavioral one, so the most exposed automaton runs visibly on a dedicated residential machine rather than hidden behind a datacenter. A generic remote-control channel drives that machine and exposes a read-only status snapshot (reachability, browser-session health, hardware state) to the internal dashboard.

A personal-shopping engine browses live inside a merchant site's real context to propose real, filtered product cards — a bare server-side call would get blocked as a bot. A strict boundary protects checkout: the assistant can search and hold items in a cart, never pay; control is handed to a person via a cart-recreation link, never through a shared credential or session. Adapters cover the major e-commerce platform families, generic where the platform exposes a stable public read surface, purpose-built otherwise. A self-healing watchdog monitors the automated browser sessions: it detects a crashed session and restarts it, and alerts if the failure repeats.

12. Finance — banking, invoicing, accounting

Bank statement import and deduplication, rule-based auto-categorization (dry-run by default, explicit write flag required), reconciliation of incoming payments against open invoices (exact match first, then a deterministic tie-break rule, never a fuzzy guess), an interactive invoicing and quoting tool, recurring billing. A read-only tax assistant for a sole proprietorship's simplified regime computes indicative figures (contributions due, provisions, legal thresholds) without ever deciding or writing anything — every number stays a draft to confirm with an accountant — with weekly summaries and threshold alerts, plus a transferable-amount calculator that never initiates a transfer itself.

13. Brand watch and research

Competitive and market watch feeds regular reports. A brand-naming research flow checks domain availability and prior-registration status in the relevant trademark registers, prepares a filing cost estimate by territory — and never files or purchases anything itself, it only proposes. A logo-research flow drives a real authenticated browser session to generate design directions grounded in stated design principles, assembled into a reviewable deliverable.

Recent addition: a vectorization facade turns a raster logo or sketch into a clean, single-color, smooth-curve vector trace — a homegrown thresholding-and-cleanup-and-trace pipeline with an automated visual-critique feedback loop (a handful of iterations at most, each judged by a separate visual review pass that proposes a bounded adjustment: smoother, sharper, less noise, more detail, bolder or thinner stroke). The pipeline correctly handles inverted-polarity artwork (light ink on a dark background) by sampling the image border to decide whether to flip the mask, and tunes stroke weight independently from anti-noise cleanup.

14. Deployment, infrastructure, backups

Governance rule: production publication for an external client site is decided site by site through a database flag — not a blanket human-only rule, a flag checked case by case — with one site kept hard-blocked regardless, as a standing exception. Any unsupervised (nightly) publication additionally requires a green automated QA verdict. Internal platform updates, by contrast, are always applied by the system, no exception. Before any deployment, uncommitted work is treated as not shippable.

A shared deploy library detects database schema drift and automatically applies strictly additive, safe adjustments (never an automatic deletion), generates localized route segments, and warms the cache after a swap by gently crawling key pages in the background so the first real visitor doesn't pay for a cold render. This family also covers DNS management, network configuration (including a rotating secret-path admin gate), provisioning a new client site and its design system from the client's own logo, and encrypted backups to external object storage with a real restore drill run monthly.

15. Open-source sync and migrations

A one-way, squashed-snapshot sync extracts the open-source-eligible part of the private application core into a separate public open-source repository — the public repo stays authoritative for what already exists there. A cleanup pass strips internal comments from that snapshot before publication. Schema-migration tooling applies only additive, reversible changes, never destructive ones. A module-installation gate only creates a module's tables when a client's build explicitly declares that module, preventing orphaned or missing tables.

Several supplier-catalogue and competitor-price-comparison connector pipelines now share one common HTTP courtesy layer (rate limiting, progressive backoff, ban detection) — factored out once so every new connector inherits the same anti-ban guardrails instead of reinventing a weaker version.

16. Harness supervision and miscellaneous tooling

A set of cross-cutting utilities rounds out the picture: session briefing, strict extraction from a legacy credential vault that segregates non-sensitive metadata (shown) from secrets (never displayed in clear), a PDF-signature stamping facade that always writes a new output file and never touches or sends the original, disposable git workspaces to isolate destructive tests away from the main branch, and a single cost logger for scheduled jobs that consume a paid language model outside of any tracked project.

A 3D object-and-character generation chain turns a 2D concept sheet into a colored 3D mesh, with a parametric furniture track producing a production-ready dimensioned plan, geometric QA (watertightness, symmetry), and a delivery sync to the relevant client site.

17. Automatic guardrails

Rather than trusting every action, the harness wires a layered set of automatic guards directly into the tool-execution path — before a risky command runs, and after a file changes. Every guard is paired with an automated regression proof, so no guard can be quietly weakened without a test failing.

Category	What it prevents
Git safety	Mass staging, a bare commit against a shared index, rebase on a shared branch, a generated artifact tracked by mistake
Secrets	Printing a secret value to output, pasting a secret inline
Infrastructure	Unwanted privileged execution inside a container, whole-folder copy into a container, an auth test skewed by leftover configuration
Data / SQL	A dangerous escaping pattern, input passed in clear on the command line instead of a safe channel
Documentation discipline	Missing minimal documentation, a new unbounded tool output
Scheduled-job governance	Silent paid-model consumption in a scheduled job, a fragile relative path, a mismatch between declared and actual schedule
Client communication	A proposed phone call, an unreviewed send, a balance adjustment without explicit authorization
Scope containment	An edit outside a project's declared boundary, a sub-agent exceeding its context budget

18. Documentation self-repair

This catalog is not maintained from memory — it is mechanically checked against live code and the actually-active guardrail configuration, on a recurring nightly cadence, against a mirror that flags three kinds of drift: a documented reference that no longer exists, a real file more recently modified than what the catalog claims about it, and a published public snapshot lagging behind the last internal regeneration.

When drift is found, mechanical repairs apply where it's safe (resolving a broken reference only when exactly one file shares the same name); anything requiring judgment is proposed, never applied automatically. A deliberately adversarial, recurring re-reading pass supplements the mechanical mirror precisely because the mirror only catches what it was built to look for — several earlier passes claimed completeness for a section and were later found incomplete, which is now a documented, expected failure mode: a static catalog drifts again the moment one more guard or facade is added after the last check. So the discipline is not a single "final" pass, but repeated re-verification against the system's live state.