harness facade and entry-point catalogue

Synedre orchestrates CodeMyShop: Synedre is the internal agentic harness — the full set of automations, scripts and entry points that run the business (email, structured projects, audits, content, deployments, finance) — while CodeMyShop is the multi-tenant e-commerce product this harness operates. This chapter documents the harness itself: its tool inventory, its functional families, and the governance mechanisms that frame it. It does not describe the architecture of the CodeMyShop product itself.

0. Scope, method and coverage

The harness gathers several hundred automation scripts and executable entry points, split into two broad families: Python automation modules and shell/JS utilities. Each script is described here by a one-line role and a typical invocation mode, so an engineer picking up the system can quickly find which tool does what without reading through the entire codebase.

Descriptions are extracted programmatically from each file's header comment — never invented. When a file only carries a generic license header, the actual role comment was pulled from further down the file. This recovery is not applied uniformly: the catalogue notes, case by case, when a description still needs confirming rather than presenting it as certain.

Coverage is re-verified at regular intervals by automatically cross-checking the file inventory against the real system scheduler, to catch two kinds of drift: a script still documented as active after being removed from scheduling, and conversely a script that is actually scheduled but missing from the catalogue.

Invocation mode	Meaning
cron	launched by the system scheduler, usually behind a shared watchdog
CLI	run by hand by an operator or an agent
skill	facade behind a natural-language-invokable capability
hook	fired automatically before/after an AI agent action (file edit, shell call, read, sub-agent spawn, session end)
lib	module imported by other scripts, not a standalone entry point
worker	background process continuously draining a queue

1. Families and overall flow

The harness's general flow follows a single path: an inbound email is captured and its intent is classified (simple execution, structured project, question, or noise); depending on the result, the work is either executed directly, opened as a structured project with an assigned team, or dropped into an idea-gestation space. Actual execution always runs through a tooled agent cycle, which then fans out to five destinations: quality audits, content/SEO production, finance, browser automation, or deployment. All of these branches converge on a single database, accessed exclusively through one shared access facade — never a direct connection scattered across the code.

This single-source-of-truth choice is structural: no business data (clients, secrets, repositories, pricing) lives in a static file — it lives in the database, and application code only reads/writes it through this facade.

2. Common foundation

A set of cross-cutting modules carries the foundations used by nearly every automation: a database access facade, a centralized environment-variable loader, mandatory structured logging, and a provider-agnostic AI facade (it routes to different language models depending on the task and budget, without coupling application code to a single provider).

Every scheduled task runs under a shared watchdog that enforces a default execution timeout and kills any script that exceeds it — with explicit, documented, bounded exceptions for legitimately long-running tasks (nightly memory consolidation, multi-session generation). An event-logging system feeds the live dashboard of currently running agents.

The foundation also carries a decentralized reflex mechanism: before every file edit, read, network tool call, or sub-agent spawn, a fast evaluation checks a registry of learned rules (allow / warn / deny) and traces the decision to a dedicated audit log. The law governing this registry is a strict asymmetry law: any new rule can only tighten behavior, never loosen it, and sensitive zones fail closed (block by default) if the rule database is unreachable.

3. Orchestration

The orchestration layer continuously watches a dedicated inbox, classifies the intent of every inbound message (simple execution / structured project / question / noise), then triggers the matching action: for actionable work, a headless agent session is started to act on the classified email, with a generous maximum delay and anti-duplicate guard-rails to prevent the same cycle from firing twice. Going to production remains a strictly human gesture; the orchestrator can propose an "email-triggered" release with triple anti-spoofing verification, but never triggers a production switch itself.

A ReAct-style cycle (reason → act → observe) drives every unit task; dedicated detectors spot tasks stuck beyond a time or consumption threshold, propose an unblocking plan, or automatically pause a runaway task (abnormal duration or cost). A daily summary consolidates the night's activity.

Interactive session → dashboard bridge

An optional mechanism lets an interactive session declare itself bound to an ongoing structured project: that session's activity (actions, messages) is then mirrored in real time onto that project's tracking dashboard, never interfering when no binding is active. A kill switch fully disables this bridge.

Multi-provider execution

A common execution contract lets each unit of work be routed to different language-model engines depending on need (speed, cost, availability) instead of being locked to a single provider. Every run is timed and its real cost is computed from a central pricing table — never a hard-coded price — then aggregated per project and per brand, feeding a continuous budget control.

4. Structured projects

Creating a structured project follows a mandatory multi-step procedure: fully reading the original request (including its attachments, always run through an antivirus scan before any opening), auditing available agents to assemble a team relevant to the scope, drafting an explicit mission statement, recruiting at least two distinct profiles for any client-facing work, then atomically creating the project with its first batch of tasks — the whole thing fails and rolls back if a single step fails, never a half-created state.

Dedicated tools generate a mission-statement draft, manage the team recruited per project, orchestrate the automatic explosion of a discovery into implementation tasks, audit the relevance of active projects, and fire an alert as soon as a project consumes 80% of its budget envelope — ahead of the hard cap that kills the worker. The commercial pipeline (prospecting → negotiation) shares this same mechanic: legal and solvency qualification of a prospect via public registries, structured extraction of exchanges, generation of a complete negotiation file.

5. Ideas and gestation

A dedicated queue carries ideas in gestation; a background worker processes them by dialoguing with the orchestrator, then a sequential challenge cycle confronts them with critical scrutiny before maturation. A validated idea can be promoted into a structured project; conversely, a project can be demoted back to an idea if its scope turns out premature — a mirror bridge handles both directions.

6. Audits, quality and security

A dense family of audits runs nightly or continuously: a global audit of every automation, a database schema audit against the naming convention, a drift audit between the schema declared in code and the real database state, daily backup freshness monitoring, a monthly test of actual restorability from a dump, a software dependency security scan, and detection of duplicate/near-duplicate editorial content.

On the offensive-security side, a non-intrusive reconnaissance orchestrator sweeps every active domain weekly, pulling the target list from a central registry — never a client name hard-coded in the code — and only sends an alert when new high-severity findings appear (no alert noise on every pass). Real intrusive testing never arms itself automatically: that is a separate manual gesture. An accessibility audit checks compliance with the WCAG 2.2 AA standard. An anti-leak probe hits every administration entry point without a session cookie and always expects a refusal — any positive response fires an immediate alert.

A visual watchdog actually captures a rendered page's screen and asks a multimodal model for a verdict against the expected visual intent, rather than only checking that the code ran without error. A route-health sentinel monitors the 404 error rate per page type rather than a global threshold — an entire page type can be fully broken while never crossing an average threshold, which would still be a real incident.

Several mechanical guard-rails block non-compliant code before it is even committed: refusal of a raw SQL query referencing a column not declared in the canonical schema, a static invariant guaranteeing that every contact-capturing form is actually wired to its corresponding advertising-conversion pipeline, a check that a production box carries the expected intrusion protections, a silent-death sentinel catching a check that would fail silently against an unreachable database, a pre-production guard-rail refusing to switch a client live until a tracking chain has proven itself working end to end.

An entropy scanner detects orphaned scripts (no remaining caller) and puts them into observed quarantine before any removal proposal — it never deletes anything itself — then returns a daily digest of system state, including a weekly ritual dedicated to the question "what have we built that we would remove today?"

7. Memory, learning and documentation self-repair

The harness carries a three-level memory: short reminders injected at the start of a session, semantic recall via vector search over the history of past decisions and incidents, and long-form notes organized as a network of linked concepts. A nightly loop consolidates this memory: it harvests recent incidents from the code history, qualifies them, indexes them, then refreshes aggregate indicators consumed by the dashboard.

Nightly documentation-maintenance loop

Every night, the harness inspects its own documentation state through a fixed twelve-step cycle: detect drift between documented text and real code (read-only), measure coverage blind spots, check consistency between a component's declared status and its actual runtime state, recompute relations between components, mechanically repair broken references when a single resolution exists, deep-regenerate a derived chapter (an engine re-reads the real code and rewrites the chapter, publishes a sanitized version, and the whole thing goes through an anti-leak check before any publication — when in doubt, publication is blocked and an internal alert fires instead of a leak), propose the remaining chapters to process by email, automatically publish whatever clears every machine gate, sync component status to the public status page, re-inspect a second time after publishing (so a public snapshot never lags one cycle behind), compute a health assessment across four dimensions, and finally publish that assessment.

An optional external review (a human reader can submit critique on a published chapter) is evaluated by an injection-hardened sandboxed model before feeding the next cycle, never before confirmation. None of these mechanisms ever touch the product's application code — their scope is strictly documentary.

Adaptive immunity

A recurrence detector clusters similar incidents (density-based grouping, not keyword matching) and drafts candidate guard-rail rules. The threat model is deliberately conservative: no proposal ever activates itself — every candidate stays inert until a human security review has validated it and an explicit gesture has armed it. Known and acknowledged limit: the reflex-evaluation engine currently only covers file edits, reads, network tool calls and sub-agent spawns — not shell commands — so some proposals drafted to target a shell command currently have no real enforcement lever until that family is covered too. This kind of limit is documented explicitly rather than hidden.

An end-of-turn check detects errors that occurred during the session that just ended, draws an immediate behavioral lesson when the pattern is already known, and proposes (without ever arming) a new guard-rail rule for recurring patterns not yet covered.

Deliberation

A dedicated component confronts several agent perspectives with deliberately divergent cognitive frames on a decision flagged as sensitive, then returns a map of the disagreement to the founder. Asymmetry law: this component surfaces the tension, it never decides — the decision stays human, and human alone.

8. Personas and agents

A central registry carries the identity, role and cognitive frame of each specialized agent in the system. A periodic audit detects technology mentions that have gone stale in these profiles (a cited tech stack that no longer exists, for example), and an assisted refresh cycle proposes an update submitted to human review before it is applied. The associated visual portraits are synced in parallel.

9. Inbox and client communication

Hard rule: no email is ever sent directly to a client on the AI's own initiative. All external communication goes through a single facade that enforces a draft → review → send cycle, with the review copy systematically routed internally before any real send; a technical guard-rail blocks any attempt to send mail through a parallel code path. An inbox is monitored continuously, with a direct-connection fallback path for when the main facade is unavailable.

Writing tone resolves automatically per detected client (formal/informal register, form of address, tone, conversation levers, things to avoid), enriched with a multi-source dossier (past exchanges, technical history, scheduling, logs) to forbid a reply based on a single message read out of context. Every attachment extracted from an inbound email goes through a mandatory antivirus scan before any opening or content read — a clean verdict is required, otherwise blocked and escalated.

A single morning digest aggregates the night's signals and labels them by action category, rather than forcing a manual reread of every stream. A loop-closure guardian detects two kinds of leak: a received message left without acknowledgment past a threshold, and a thread resolved internally but never communicated back to the affected client. A one-time secret share (no third-party service, no plaintext password by email) and a secure access handoff document round out the client-handoff tooling.

10. Content, blog and SEO

Editorial publishing goes through a single "database-first" engine. SEO optimization (meta tags, description, FAQ, internal linking) also goes through a single multilingual core engine — a hard system rule: no second SEO-writing engine is allowed to exist in parallel, to guarantee homogeneity, idempotence, and parity across every language on a site. Every SEO write is gated by validators that refuse to publish insufficient content (a summary with no link, a too-short FAQ, a description with no evidence).

Orbiting this core: automatic cleanup of stale editorial content, cover-image and social-asset generation, monitoring for generative-engine optimization (AI search), tracking of technical vocabulary cited in articles, a multi-site technical SEO health sentinel with regression alerting, and a coverage watchdog that specifically detects pages left without a meta description in the source language (a blind spot the usual translation tracking misses).

Category reconciliation covers deduplicating doubles, flattening overly deep trees, and enforcing a maximum depth cap before any production release (checked by a blocking sentinel).

Organic search

The search-console integration runs in an isolated environment that only holds the access needed for that specific API; decrypted credentials stay in the execution container's memory and never travel to standard output or logs. An orchestrator pulls organic traffic over rolling windows, imports dimensional data (dates, queries, pages), and submits sitemaps for indexing.

Translation and internationalization

A translation pipeline covers categories, products, editorial content and route segments, with specific guard-rails: rejecting a re-translation if a numeric quantity disappears from the source text, strictly preserving HTML structure, and detecting internal links still pointing at the source language inside a translated page in order to rewrite them to the matching canonical URL.

11. Browser agents

Browser automation favors a network reputation close to a genuine residential user rather than trying to defeat a third-party site's anti-bot challenges — a deliberate doctrine distinction. A generic facade routes navigation actions to a machine dedicated to this purpose over a remote-control protocol, which decouples application-level piloting from the physical browser execution.

A direct piloting mode for a personal workstation (remotely driven screenshots and keyboard/mouse interactions) is available for strictly graphical tasks with no programmable interface, enabled only behind an explicit switch. A deterministic purchasing adapter illustrates a strong design red line: the language model decides what to buy, deterministic code executes the action, and automated checkout completion is explicitly excluded — no purchase is ever finalized without human confirmation.

12. Banking, invoicing and finance

Bank reconciliation follows a strict caution principle: transaction import and categorization default to simulation mode (no write without explicit confirmation), automatic categorization against a vendor→category reference, then matching revenue transactions to open invoices by exact amount and client — with explicit tie-breaking on ambiguity, never a best-guess match.

The tax-tracking engine for the sole-proprietor structure computes read-only filing indicators (cash received, social contributions due, provisions, legal thresholds): it never decides anything tax-related and writes nothing to the database — the figures it produces remain indicative drafts to validate with an accountant. A weekly recap and point-in-time alerts (deadlines, thresholds crossed) are sent automatically, with anti-spam guaranteeing the same alert is never sent twice.

13. Watch and brand monitoring

A quality scorecard automatically checks a page's compliance against brand design tokens and accessibility criteria (contrast, visible focus, target size, semantic structure) — usable from the command line or as a lock before production release. Technology and competitive watch feeds a data layer shared across several monitoring fronts.

On the paid-advertising side, the tooling covers: offline conversion upload (a confirmed order triggers upload to the ad platform), read-only inspection of an advertiser account's tracking settings, and watchers that alert exactly once when a first conversion is confirmed and then disarm themselves automatically to avoid repeating the alert. A freelance-platform watch drafts replies in the usual tone and then stops there: account guard-rails explicitly frame the automation so it stays a communication aid, never a detection-evasion tool.

14. Deployment, infrastructure and backups

Hard asymmetry rule: an actual production release is a strictly manual gesture, reserved for the founder, never triggered by the AI. Deploying to the staging/rebuild environment, on the other hand, is systematically the AI's own job — never left "for later." Before any deploy, the working tree must be committed: any uncommitted change would be lost on the next deploy.

The shared deploy pipeline detects drift between the database schema declared in code and the database's real state, and can automatically apply missing additive changes (never an automatic deletion) when that mode is explicitly enabled. It also generates localized route segments before build, runs the build, packaging, upload, service restart, then a post-deploy health check — with a background cache warm-up so the first visitor after a release doesn't pay the cost of a heavy render.

Provisioning a new client's infrastructure follows a declarative scenario from a configuration file, with automatic bootstrap of admin accounts, a design system derived from the logo, and pre-filling of already-known information. Rotation of admin access credentials is idempotent and propagates the matching network configuration.

Backups and restore

Database and critical file backups are encrypted and replicated to remote object storage, with a lifecycle policy and dedicated log rotation. A real test restore (not just a checksum check) runs monthly to prove actual restorability, not merely the presence of a backup file.

15. Open-source sync, refactoring and migrations

The e-commerce product core published as open source goes through a dedicated sanitization pipeline before any publication: stripping every internal comment, translating the rest to English, and a named allow-list of what is permitted to be published — never a default-exclude logic, always an explicit include logic (an internal scar from a past leak caused by an unchecked bootstrap). The publication bootstrap refuses to start if this allow-list is missing.

Schema migrations follow a strict expand-contract doctrine on any paying production database: additions only before switchover, never a deletion before full verification. A module only installs its own schema if the relevant site's configuration explicitly declares extending it — a module absent from that declaration never creates its tables.

An extract-transform-load pipeline dedicated to one external supplier illustrates the general pattern: idempotent incremental reading of a remote catalogue, anti-ban network protections, overlap-prevention locking, then downstream phases of image retrieval and cascading import — always read-only on the source side, never a write to a third-party production system.

Demo bootstrapping

A complete demo environment (catalogue, navigation, variants, carts, orders) can be reset in a single command to a clean reference snapshot, used for sales demonstrations without ever touching a real client environment.

16. Monitoring, obsolescence and miscellaneous tooling

This family covers unit tests for long-running features, a test bridge to the sandbox database environment, an annotated documentary-plate engine, and strict segregation of a legacy system's credentials (never a secret shown in plaintext, an explicit split between what is showable and what stays put away). A signing tool stamps a scanned signature onto a PDF document by always writing a new file, never touching or sending the original.

Destructive version-control tests are systematically isolated in a disposable workspace, never run on the repository's main line.

Bespoke 3D configurator

An end-to-end pipeline turns a reference image (moodboard, sketch) into a usable 3D object: view extraction, multi-view 3D mesh generation, geometric-zone colorization, then export to a standard format consumable by a web viewer. A parametric variant generates furniture from geometric primitives or from a free-text description, with a "manufacturing-ready" dimensioned plan and automated geometric QA (mesh watertightness, symmetry) before delivery.

17. Real-time governance — session guard-rails

The harness enforces much of its doctrine not through documentation alone, but through automatic checks fired in real time before and after every AI agent action — file edit, shell call, read, network call, sub-agent invocation, session end. These checks form a second line of defense that does not depend on the agent's good intentions at the moment of the action.

Among the most significant mechanisms: blocking any email send outside the single facade; blocking any attempt by the AI to trigger a direct production release (the real release command stays strictly human); blocking the pasting of plaintext secrets or uncontrolled bulk file staging into a commit; requiring a clean antivirus verdict before any attachment is opened; blocking a raw database query that would reference a column not declared in the canonical schema; evaluating a registry of learned rules before a file edit, read, network call or sub-agent invocation; a mandatory structuring nudge as soon as a piece of work exceeds the scope of a simple one-off fix.

A specific check forbids the agent from asking a validation question in chat for an email send — doctrine requires creating the draft directly through the dedicated facade, whose internal review copy already serves as the validation step; asking the question would bypass that circuit. Another guard-rail, specific to the household-assistant product, blocks any code change touching a household's purchasing identity unless it explicitly carries that household's identifier in its immediate vicinity — to prevent one household's identity from ever leaking into another's.

At the end of every session, a closing check verifies the working tree stays clean (nothing significant left uncommitted), logs the incidents detected during the turn that just ended, and refuses to let it appear that a production release happened when it was actually blocked by the corresponding guard-rail.

18. Reliability notes

This catalogue is generated and re-verified through a mixed process: automatic extraction from the real source code, followed by a targeted adversarial reread that checks every claim in the catalogue against the system's actual state (real scheduling, real wiring of checks, real code behavior) rather than against what the previous documentation asserted. Every correction found is logged with its source, so the reliability trail itself stays auditable.

As a matter of transparency: information that is inferred rather than directly verified is flagged as such rather than presented with false certainty, and a known coverage limit (for example a guard-rail mechanism that does not yet cover an entire family of actions) is named explicitly rather than hidden.