// --------------------------------------------------------------------------- // automation/AutomationBuilder.tsx — the BUILDER (owner item 3b, contracts // C1/C2/C4, ruling R1: "exact layout, Loopable skin"). // // THE ANATOMY IS AIRTABLE'S, 1:1, and it is the owner's reference (images 1-9): // a centre column of TRIGGER → ACTIONS with a spine down the left carrying each // step's status chip, dashed add-boxes at the end of each section, and a // Properties panel on the right whose sections are Trigger details / // Configuration / Test step. Every colour, size and weight is OURS (R1, // DESIGN.md) — no Airtable blue, no caps micro-labels (R6: "TRIGGER" is // "Trigger" here, and de-capping takes the letter-spacing with it). // // ⛔ IT RENDERS SYNCHRONOUSLY FROM WHAT IT WAS HANDED (C14 leg 1). No fetch, no // effect, no second frame: the trigger comes from `automation.trigger`, the // actions from `automation.flow`, the machine steps from `automation.graph` — // all three already on the list payload the rail used to draw the row you // clicked. THIS IS THE GHOST FIX. The old detail rendered Steps, then swapped to // the Board when `/board` answered, so switching automations painted the // PREVIOUS one's shape inside the new one's frame for as long as a fetch takes. // A view that cannot be in two shapes cannot show you the wrong one. // // ⛔ NO CLIENT UNION OVER A SERVER VOCABULARY, anywhere. Trigger keys, action // kinds, comparison operators, ending modes, review deciders and every ceiling // ride `GET /automations`. What this file owns is pixels and wording. // // WHAT PERSISTS WHEN. A discrete choice writes immediately — picking a trigger, // adding an action, flipping a switch — because a control you have to remember // to Save is not a control (R9). FREE TEXT does not: a value, a prompt or a name // commits on BLUR, or every keystroke would PATCH a half-typed condition and the // server would refuse most of them out loud (the cron-string precedent in // AutomationTrigger). // --------------------------------------------------------------------------- import type { ReactNode } from "react"; import { useEffect, useRef, useState } from "react"; // ⭐ WAVE 30 · ITEM 7 (R3 + R4) — connector identity, from the ONE module that owns it. Not a // second copy of two SVGs: the directory, this menu and the trigger picker all answer "which // company is this row about", and three answers is how a platform gets added in two of them. import { brandForConnector, brandForKind, hasBrandKind } from "../connectors/brandMarks"; import type { Action, ActionCatalogRow, Automation, Cond, FlowVocab, GraphNode, OAuthStatus, TriggerOption, UserTable, } from "./automationApi"; // ⭐ WAVE 26 · ITEM 22 / D-70 — the Run guard, imported rather than re-derived. This file and // `AutomationDetail` each paint a Run button onto the same paid action; ONE function decides. // ITEM 9 / R11 — `createTable` + `AutomationError` for the in-place "+ New database". import { AutomationError, createTable, runBlock } from "./automationApi"; import CondBuilder, { condComplete } from "./CondBuilder"; import { groupActions, groupBranches, groupByPanel, numberActions, reorderList } from "./steps"; // ⭐ WAVE 25 item 5b (C2) — the grouped picker, and `TriggerMark` with it. The icon vocabulary // MOVED to that file rather than being copied into it: the whole of item 5b is that the compact // control in Properties and the big "+ Add trigger" menu are one control, and two copies of the // marks is how they drift back into looking like two features. import PresetPlan from "./PresetPlan"; import TriggerPicker, { TriggerMark } from "./TriggerPicker"; /** * ⛔ A PRIVATE MIME, AND `text/plain` IS NEVER SET (owner item 11; the wave-13 C-LAYOUT scar). * A drag carrying `text/plain` is a drag the whole operating system understands: drop it on any * input, textarea or contenteditable — this builder is full of them — and the browser TYPES the * payload in, so a mis-aimed reorder silently writes an action id into somebody's condition * value. A private type is inert everywhere except the drop targets below, which is why the nav * rail's own drag uses one (`Shell.tsx:90 NAV_DRAG_TYPE`). * ⚠ The board's card drag still uses `text/plain` (`AutomationBoard.tsx:167`) — noted, not fixed * here: that file belongs to another session this wave. */ const ACTION_DRAG_TYPE = "application/x-loopable-action"; interface Props { automation: Automation; /** * THE AUTOMATION'S NAME (item 15b, C-DETAIL) — it left the page header and Properties is where * it went, at the top, above whatever step is selected. REQUIRED, all three: an optional prop * degrades to "the field does not exist", which looks exactly like never having built it. * * ⚠ TEXT AND COMMIT ARE SEPARATE ON PURPOSE. This is the cron field's shape * (`AutomationTrigger`'s `onCronText` / `onSchedule`): free text stays controlled while typing * and writes ONCE on blur, because per-keystroke would PATCH a half-typed name. Folding them * into one callback would force a choice between a laggy controlled input and a save per * keystroke, and this file has already paid for both. */ name: string; onNameText: (v: string) => void; onNameCommit: () => void; /** The server's trigger vocabulary (C3). Absent is a state this file states, never fills in. */ triggers?: TriggerOption[]; catalog: ActionCatalogRow[]; vocab?: FlowVocab; tables: UserTable[]; oauth: OAuthStatus | null; /** True while a write is in flight — drives the "All changes saved" stamp and disables edits. */ busy: boolean; /** Write a partial definition. The caller owns the request and prints the refusal verbatim. */ onPatch: (body: Record) => void; onToggleNode: (nodeId: string) => void; /** * ⛔ CHOOSING A TRIGGER IS NOT A `{trigger:{key}}` PATCH, and getting that wrong is invisible. * `schedule` is what today's engine actually READS, so a pick has to write BOTH halves or * "At a scheduled time" would store a key and leave the cron switched off — a trigger that * says it is scheduled and never fires. The detail already owns that two-write shape * (`pickTrigger`); the builder calls it rather than composing a second copy of it. */ onPickTrigger: (key: string) => void; onRunNow: () => void; /** * The MACHINE steps' config bodies (source / columns / capture / find / write). They live in * `AutomationDetail`, so they are passed IN rather than moved: a builder that re-implemented * them would be a second copy of five panels whose only job is to agree with the engine. * * ⚠ IT TAKES A PANEL KEY, NOT A NODE (item 5, C-CFG). It used to be * `(node: GraphNode) => ReactNode`, and the caller's whole body was `panelBody(node.panel)` — * so the node was only ever a wrapper around the key. Now that Properties renders the panels * GROUPED BY that key, taking a node would invite the caller to pass one node of a group and * quietly imply the body belongs to it alone. */ renderNodeBody: (panel: string) => ReactNode; /** * The SCHEDULE half of the trigger face (`AutomationTrigger` with its picker hidden). Passed * in for the same reason the node panels are: the cron round-trip, the server's preset list * and the tick-honesty note exist exactly once, and both this view and the board render the * same element rather than two copies of three things that go wrong invisibly. */ scheduleFace: ReactNode; /** * ⭐ WAVE 27 · CONTRACT C11 — is the PROPERTIES panel the one on screen? * * ⛔ THE STATE LIVES IN `AutomationDetail`, NEVER HERE, and the contract says so for a * structural reason: the two panels that share this column are children of DIFFERENT * components — Properties is this file's, the Run log is `AutomationDetail`'s — so the only * place that can know "exactly one is visible" is their common parent. A local boolean here * could hide Properties while the log was also hidden, or show both. * ⚠ REQUIRED. An optional flag defaulting to `true` would make an unmounted toggle look like * a working panel, which is the shape this repo keeps paying for. */ showProperties: boolean; /** The Properties/Run-history switch, OWNED by `AutomationDetail` and drawn in both panel * heads so it is in the same place whichever one is showing. */ panelTabs: ReactNode; /** Announce that a step (or the trigger) was clicked, so the parent can bring Properties * forward — C11's "clicking any step card switches to Properties". */ onStepPicked: () => void; /** * Does the cron drive the CURRENT trigger (owner item 7)? REQUIRED, and decided by the caller * for the reason `AutomationTrigger.schedules` gives: which keys the cron drives is a per-key * fact, and no component below the detail is entitled to name trigger keys. */ schedules: boolean; /** * ⭐ THE DATABASE THE FLOW'S RECORDS WALK (owner item 12a) — the trigger's table, or the * automation's own target, resolved by the caller the way `automation_engine._flow_table` does. * REQUIRED: an absent one degrades to an empty field list, which is the exact defect this prop * exists to fix and is indistinguishable from "this database has no columns". */ walkTable: string; /** * ⭐ WAVE 26 · ITEM 9 / R11 — RE-READ THE DATABASE LIST, after an action's picker created one. * * ⛔ REQUIRED, deliberately. The wave doc's rule is "prefer a REQUIRED prop; an optional one * degrades silently to 'the feature does not exist'" — and here the silent degradation has a * particularly bad shape: the database really would be created, on the server, and simply not * appear in the picker that made it. The user then makes a second one with the same name * (duplicate names are legal), and the automation still points at neither. */ onTablesChanged: () => Promise | void; /** * Is there an edit the HEADER's Save still owns? REQUIRED, and it exists so the panel's * "All changes saved" stamp can stop being a claim about fields it does not cover — the * machine steps' panels moved into Properties this wave and they commit with Save, not on * change. */ dirty: boolean; } /* * ⚠ `"node"` LEFT THIS UNION WITH THE MACHINE CARDS (item 5). It existed so a click on one of * those cards could open its panel; with the cards gone nothing can set it, and a variant no * code path can reach is a branch that reads as supported and is not. */ type Sel = { kind: "trigger" | "action"; id: string }; /** Airtable phrases the empty state's shortcuts; ours come from the SERVER's own list (image 1). */ const SUGGESTED = 6; /** * ⭐⭐ WAVE 30 · W30-T23 / C3 — THE ENRICH KINDS, MIRRORING `automation_engine.ENRICH_KINDS`. * * ⛔ ONE PREDICATE, TWO CALL SITES, and both had to move or the ticket would have half-shipped: * `seedFor` decides whether the menu row can be ADDED at all, and the properties panel decides * whether the added step has any CONTROLS. Widening only the first yields a step a person can add * and cannot configure; widening only the second yields a panel for a row that is permanently * faded. D-79 was that pair coming apart on the Instagram side. * ⚠ Named as a list rather than written twice, because the server's own validator branches on a * TUPLE of the same two names — a third platform must be one edit here, not a grep. */ const ENRICH_KINDS = ["enrich_instagram", "enrich_tiktok"]; const isEnrich = (kind: string): boolean => ENRICH_KINDS.includes(kind); /* ⛔ `TriggerMark` STOOD HERE AND MOVED TO `TriggerPicker.tsx` (wave 25 item 5b, C2). It is IMPORTED back for the trigger card below. Moving rather than copying is the point of the item: the compact control in Properties and this menu are one picker now, and the marks are the thing the owner noticed missing from one of them (reference/ERROR 3.png). */ function ActionMark({ kind }: { kind: string }) { /* ⭐⭐ WAVE 30 · ITEM 7 / R4 — the same one-line resolution `TriggerMark` carries, and for the same reason: this component is drawn in the add-action menu, on every step card and on every machine node, so a connected action must wear its company's logo in all three or it wears two identities on one screen. Unbranded kinds fall through to the house glyphs below, untouched. */ const brand = brandForKind(kind); if (brand) return brand; const common = { width: 15, height: 15, viewBox: "0 0 16 16", fill: "none", stroke: "currentColor", strokeWidth: 1.4, strokeLinecap: "round" as const, strokeLinejoin: "round" as const, "aria-hidden": true, }; if (kind === "group") return ( ); if (kind === "create_record") return ( ); if (kind === "find_records") return ( ); /* ⚠ THE MACHINE KINDS ARE HERE TOO, and leaving them out was a real defect for one render: the engine's nodes are `source | capture | branch | write`, none of which matched above, so "Write to the database" and "Fetch the page" both drew the PENCIL — an edit glyph on a step that reads a web page and a step that writes a database. Caught by reading the screenshot, not by a gate ([[ui-invisible-to-assertions]]): the icon was present, legible and wrong. These are the shapes the retired `AutomationSteps.KindMark` used, kept with their meanings. */ if (kind === "source") return ( ); if (kind === "write") return ( ); if (kind === "capture") return ( ); if (kind === "branch") return ( ); if (kind === "update_record") return ( ); if (kind === "send_email") return ( ); if (kind === "slack") return ( ); if (kind === "run_script") return ( ); if (kind === "generate_ai") return ( ); if (kind === "repeating_group") return ( ); /* ⛔ THE FALLBACK IS NEUTRAL, and it was not the first time round. The default used to BE the pencil — a real member of the set (`update_record`) — so every kind with no arm silently borrowed "edit": `send_email`, `run_script` and `repeating_group` all drew it in the action menu, which reads as three actions that modify a record. A fallback that is a real member cannot be told apart from a match; this one can. */ return ( ); } /** The label a table key reads as. A raw `ut_9f3a…` on a card is a key, not a subtitle. */ function tableLabel(tables: UserTable[], key: string): string { if (!key) return ""; return tables.find((t) => t.key === key)?.label || key; } export default function AutomationBuilder({ automation, name, onNameText, onNameCommit, triggers, catalog, vocab, tables, oauth, busy, onPatch, onToggleNode, onPickTrigger, onRunNow, renderNodeBody, scheduleFace, showProperties, panelTabs, onStepPicked, schedules, walkTable, onTablesChanged, dirty, }: Props) { const [sel, setSel] = useState({ kind: "trigger", id: "" }); const [picking, setPicking] = useState(false); const [adding, setAdding] = useState(false); /** The trigger key awaiting confirmation (image 6) — a change that can invalidate config. */ const [confirmKey, setConfirmKey] = useState(""); /** The card a reorder is hovering over (item 11). `""` = nothing is being dragged. */ const [dragOver, setDragOver] = useState(""); /** * ⛔ ONE DRAG SUPPRESSES EXACTLY ONE CLICK (item 11; `AutomationBoard`'s trap 1, which this * repo has already paid for once). Browsers can deliver a `click` after `dragend`, and the * thing under the pointer here is the card's own selector — so a finished reorder would ALSO * change which step the Properties panel is showing, which reads as the panel jumping on its * own. A ref and not state, because the click arrives before a re-render would land. */ const draggedRef = useRef(false); /** * ⛔ THE TRIGGER MENU IS ANCHORED TO ITS BOX, AND THAT IS A LAYOUT FACT BEFORE IT IS A * DISMISSAL ONE (owner's ERROR 4, 2026-08-06). `` was rendered at * the BOTTOM of this component's fragment — a sibling of `.autox-flow` and the `.autox-props` * aside, inside `.auto-work`, which is `display: flex`. So opening it added a THIRD COLUMN to * the builder: the menu landed to the right of the Properties panel, off the edge of the * window, and the flow column (`flex: 1 1 auto; min-width: 0`) collapsed under it until * "Suggested triggers" wrapped one word per line and the canvas grew a horizontal scrollbar. * Nothing was broken about the menu — it was in the wrong parent. * * It lives inside `.autox-main` beside its own button now, and this ref is what makes the pair * ONE unit: an outside mousedown must not count the button that opens it as "outside", or the * click would close and reopen it forever. `TriggerPicker`'s own doc says the caller owns * open-ness for the `menu` variant precisely because the caller owns the anchor. */ const addWrap = useRef(null); // Escape and an outside click both close it — the `field` variant's rule, applied to the twin // that had neither. Without this the empty state's menu was a one-way door: every row picks a // trigger, so changing your mind meant picking one you did not want. useEffect(() => { if (!picking) return; const onKey = (e: KeyboardEvent) => { if (e.key === "Escape") setPicking(false); }; const onDown = (e: MouseEvent) => { if (!addWrap.current?.contains(e.target as Node)) setPicking(false); }; window.addEventListener("keydown", onKey); window.addEventListener("mousedown", onDown); return () => { window.removeEventListener("keydown", onKey); window.removeEventListener("mousedown", onDown); }; }, [picking]); const trigger = automation.trigger || null; const triggerKey = trigger?.key || (automation.schedule?.enabled ? "schedule" : "manual"); const options = triggers || []; const picked = options.find((t) => t.key === triggerKey) || null; const actions = automation.flow?.actions || []; const nodes = (automation.graph?.nodes || []).filter((n) => n.kind !== "trigger"); const ops = vocab?.condOps || []; const nullaryOps = vocab?.nullaryCondOps || []; const table = tables.find((t) => t.key === (trigger?.table || "")) || null; /** * ⛔ HAS ANYTHING BEEN CHOSEN? — and the first version of this line was wrong in a way only * a screenshot showed. * * It read `!!trigger || key === "schedule" || key === "manual"`, and `triggerKey` DERIVES * "manual" whenever nothing is stored — so it was true for every automation ever, and the * Airtable empty state (image 1) was unreachable code that every gate was happy with. * * The honest test is what the DEFINITION holds, not what the picker displays: the engine * deliberately stores no trigger for manual/schedule ("`schedule` already owns the cron"), so * `trigger === null && !schedule.enabled` IS "nobody has decided yet". Manual is what that * state DOES, not a thing you pick out of it — which is why the suggested list below omits * it: an option whose selection stores nothing would bounce straight back to this state on * the next reload, and a control that undoes itself is worse than no control. */ const chosen = !!trigger || !!automation.schedule?.enabled; /** * ⭐⭐ 2026-08-07 (owner report, the SECOND time on this feature) — *"I still can't do * Enrichment, when the Trigger is Manual, it says that I need to bound it to a database, how?"* * * ⛔ THE DATABASE PICKER EXISTED AND WAS UNREACHABLE FOR THE ONE TRIGGER THAT NEEDS IT MOST, * and the two decisions that combined to hide it were each locally right: * 1. `clean_trigger` STORES NOTHING for `manual` and `schedule` (`:8389`) — "storing a no-op * trigger would be a second copy of that fact". So a manual automation holds `trigger: * null` forever, by design. * 2. `chosen` is therefore FALSE for it (the note above says so explicitly), and W25/R14 hides * the whole Configuration section until a trigger is `chosen`. * ⇒ The picker `caee549` added for exactly this case sits INSIDE that section, so picking * Manual could never reveal it. `run_plain` then refused with *"pick one on the trigger, or in * Properties"* — a sentence naming two doors while rendering neither. MEASURED in the live * nurilab store: `auto_2` "Enrichment test", `kind:'plain'`, `trigger:None`, * `config.targetTable:''`, one `enrich_instagram` action, unrunnable. * * ⚠ AND THE SCREEN DISAGREED WITH THE STORE, which is why the owner reasonably believed they * had picked something: `triggerKey` DERIVES `"manual"` when nothing is stored, so the panel * displays "Manual" over a definition that holds no trigger at all. * * ⛔ THE FIX IS NOT TO START STORING A MANUAL TRIGGER. The note above already argued that out * and it is still right — a control whose selection stores nothing bounces back on reload. What * was wrong is treating "no trigger stored" as "nothing to configure": a `plain` automation * whose trigger carries no table of its own ALWAYS has one thing to configure, the database its * steps walk, and that is true in exactly the state where `chosen` is false. So Configuration * opens for that too — the trigger-specific blocks inside are each keyed off `triggerKey` and * stay hidden on their own. That widening lives in the Properties panel beside the picker it * reveals (`needsOwnTable`), not here: `chosen` still means exactly what it says. */ const configured = !trigger || trigger.configured !== false; /** Write one key of the trigger, keeping the rest — the engine merges against `previous`. */ const patchTrigger = (patch: Record) => onPatch({ trigger: { key: triggerKey, ...patch } }); /** * ⭐⭐ 2026-08-07 (owner report) — PATCH THE AUTOMATION'S OWN CONFIG. * * ⛔ IT SPREADS THE EXISTING CONFIG, and that is not defensive tidiness: `clean_definition` * takes `raw["config"]` WHOLE when it is a dict (`cfg_raw = raw.get("config") if isinstance(...) * else prev.get("config")`) — it does not merge. Sending `{targetTable: x}` alone would erase * the discovery predicates, the lanes and the schedule face in one keystroke. */ const patchConfig = (patch: Record) => onPatch({ config: { ...((automation.config as Record) || {}), ...patch } }); const patchFlow = (next: Action[]) => onPatch({ flow: { actions: next } }); /** * ⭐ ONE TREE WALKER (wave 24, C-FORK). Rewrite or drop any action anywhere, branches included: * `f` returns a replacement, or `null` to remove it. * * ⛔ THIS REPLACED FOUR HAND-ROLLED WALKS, and they were four places to forget the same thing. * A group's children moved from `config.actions` to `config.branches[].actions` this wave, so * every one of them would have quietly stopped descending into a fork — editing, deleting or * counting nothing inside it, with `tsc` perfectly happy because `config` is * `Record` and an absent key is just `undefined`. The failure would have been * "the card is there and the delete button does nothing", per action, per fork. */ const mapTree = (list: Action[], f: (a: Action) => Action | null): Action[] => (list || []) .map((a) => { const next = f(a); if (next === null) return null; if (next.kind !== "group") return next; const brs = groupBranches(next); if (!brs.length) return next; return { ...next, config: { ...next.config, branches: brs.map((br) => ({ ...br, actions: mapTree(br.actions || [], f) })), }, }; }) .filter((a): a is Action => a !== null); /** Replace one action anywhere in the tree, forks included — ids are stable server-side. */ const editAction = (id: string, change: (a: Action) => Action) => patchFlow(mapTree(actions, (a) => (a.id === id ? change(a) : a))); const dropAction = (id: string) => { // ⚠ REMOVING THE LAST ACTION IN A BRANCH IS REFUSED BY THE SERVER ("a branch with no actions // inside it does nothing") and the refusal is printed verbatim, as every other one is. Not // pre-empted here: a client that predicted it would be a second validator, and the honest // repair — delete the branch, not its last child — is one the reader can act on. patchFlow(mapTree(actions, (a) => (a.id === id ? null : a))); if (sel.kind === "action" && sel.id === id) setSel({ kind: "trigger", id: "" }); }; /** * REORDER (owner item 11). The whole `flow.actions` list goes back through `patchFlow` — the * same door every other edit uses — rather than a bespoke move endpoint, because the engine * already validates a whole flow and a second write path would be a second thing to keep * agreeing with `clean_actions`. * * ⚠ TOP-LEVEL SIBLINGS ONLY, deliberately, and it is a SCOPE rather than an oversight: a card * inside a conditional group is not `draggable` at all, so there is no affordance that quietly * does nothing. Group children are about to stop living under `config.actions` and start living * under `config.branches[].actions` (C-FORK), and building a tree-walking reorder against a * shape this same wave replaces would be work done twice with a window of wrongness in between. */ const moveAction = (dragId: string, dropId: string) => { const next = reorderList(actions, dragId, dropId); // `null` = same card, or one of them is not a top-level sibling. Nothing moved, so nothing // is written — an aborted drag must not PATCH the flow back over itself. if (next) patchFlow(next); }; /** * ⛔ A NEW ACTION'S CONFIG MUST BE ONE THE SERVER ACCEPTS — and the first version of this * function got it wrong for FOUR of the five kinds, which is worth writing down because every * gate was green and the harness could not see it (SSR renders no click). * * MEASURED against `clean_actions` itself (`python -c` over the engine module, no server): * `{values:{"":""}}` -> "a value is written to a field with no name" * `{table:"",values:…}` -> the same, twice * `{table:""}` (find) -> "the find records action names no database" * `{cond:…,actions:[]}` -> "a conditional group with no actions inside it does nothing" * So clicking "Add → Update record" would have produced a red banner and NO CARD. This is the * wave-22 discovery-predicate scar reproduced exactly ([[cg-condition-builder-items]] — every * default must be one the server takes), in a file whose own comment cites it. * * The seeds below are built from data this component already holds, and `seedFor` returns * NULL when it cannot build a legal one. A kind with no legal seed is offered DISABLED with * the reason, rather than offered and refused: the two states look identical to a user and * only one of them is honest. */ /** * ⭐ THE WALKING RECORD'S COLUMNS (item 12a). Read off `walkTable`, NOT off `table`. * * `table` is the TRIGGER's database and it answers a different question — which columns the * trigger may watch or test. This one answers what the ACTIONS write to and what a branch's * condition compares, and on any automation without an event trigger (manual, schedule, * `ig_profile_match`) the two are not the same table at all: the first is empty and the second * is where all the records are. Reading actions' fields off the trigger is why every condition * inside a fork offered an empty picker. */ const walkFields = (tables.find((t) => t.key === walkTable) || null)?.fields || []; const firstField = walkFields[0]?.key || ""; const firstTable = tables[0] || null; const firstTableField = firstTable?.fields?.[0]?.key || ""; const seedFor = (kind: string): Record | null => { if (kind === "update_record") return firstField ? { values: { [firstField]: "" } } : null; if (kind === "create_record") return firstTable && firstTableField ? { table: firstTable.key, values: { [firstTableField]: "" } } : null; if (kind === "find_records") return firstTable ? { table: firstTable.key, cond: null, limit: 25 } : null; /* ⭐⭐ WAVE 31 · T38 (contract C5, owner ruling R10) — THE WEB READ, and this branch is here because a gate demanded it rather than because anybody remembered. ⛔ FLIPPING `ready:True` ON THE SERVER IS NOT MOUNTING AN ACTION. `verify_automation_ui`'s seed check DERIVES its subject from the server catalog, so the moment `web_read` became ready it went red with `MISSING: ['web_read']` — the action would have rendered faded, labelled "Needs a database" (a claim about databases, which is not the problem) and been permanently unclickable. That is D-79's scar exactly, and the check written after it is what caught the repeat. A capability is reachable when the SERVER offers it, the ENGINE dispatches it and the CLIENT can seed it; two out of three ships an invisible feature. ⚠ THE SEED IS DELIBERATELY BLANK, and the server was changed to accept that. `url`, `selector` and `field` are what a person types in the panel, so requiring them at validation time would make a freshly-added step refuse itself — the wave-23 illegal-default-seed defect. `_clean_action_config` stores an unconfigured step and the RUNNER fails closed with a sentence naming what is missing, which is the same posture the enrich arm takes with `profileField`. The values below mirror that validator's defaults exactly. */ if (kind === "web_read") return { url: "", selector: "", field: firstField || "", attr: "text", all: false, timeoutMs: 20000 }; /* ⭐⭐ W31 QA — THE OTHER FOUR WEB KINDS, and the comment above predicted this exactly one kind early. When the owner's revocation of D-51/R5 flipped `web_goto`/`web_fill`/`web_click`/ `web_repair` to `ready:True`, the catalog-derived seed check went red with `MISSING: ['web_click','web_fill','web_goto','web_repair']` — all four would have painted faded and PERMANENTLY UNCLICKABLE while the server, the seam and the runner all offered them. Three out of four is still an invisible feature. ⚠ BLANK FOR THE SAME REASON `web_read` IS BLANK: `url` / `selector` / `value` are what a person types in the panel, so seeding them with anything real would either lie or refuse itself at validation time. `_clean_action_config` stores the unconfigured step and the RUNNER fails closed naming what is missing (`WEB_REQUIRED`, per kind) — which is why these seeds carry no field the validator would reject and no field the runner would silently ignore. ⚠ `web_fill` seeds `secret: false` EXPLICITLY rather than omitting it: the flag decides whether the typed value is masked in the run log, and a masking control that only exists once somebody discovers it is a control most people never turn on. */ if (kind === "web_goto") return { url: "", timeoutMs: 20000 }; if (kind === "web_click") return { url: "", selector: "", timeoutMs: 20000 }; if (kind === "web_fill") return { url: "", selector: "", value: "", secret: false, timeoutMs: 20000 }; if (kind === "web_repair") return { url: "", selector: "", hint: "", timeoutMs: 20000 }; /* ⭐⭐ 2026-08-07 (owner report) — THE ENRICH ACTION HAD NO BRANCH HERE, SO IT WAS PERMANENTLY UNCLICKABLE. `disabled={!c.ready || busy || !seedFor(c.kind)}` and this function's `return null` fallback meant the row rendered faded, labelled "Needs a database", with an EMPTY tooltip (`seedBlock` had no sentence for it either). The server declared it `ready:true`, its config panel was fully built and its runner was correct — one client-side list nobody updated made the whole capability unreachable. Owner: *"The enrichment action, says that it needs a database. So I can't even click it and assign a database? thats wicked."* ⛔ IT TAKES NO TABLE, AND THAT IS WHY THE OLD LABEL WAS ALSO WRONG. Enrichment acts on the record WALKING THE FLOW — the flow's own target database — so there is nothing to assign per action. `verify_automation`'s seed-coverage check now derives its subject from the server catalog, so the NEXT ready action added without a seed goes red instead of shipping invisible. The values mirror `clean_action_config`'s defaults exactly. A seed that disagreed with the validator is the wave-23 illegal-seed defect (four kinds shipped a red banner and no card). */ /* ⭐⭐ WAVE 30 · W30-T23 / CONTRACT C3 — ONE ARM FOR BOTH ENRICH KINDS. The server's own validator branches on `ENRICH_KINDS = ("enrich_instagram","enrich_tiktok")` — ONE branch, one set of keys, with `postMetrics`/`commentMetrics` answered `False` for TikTok until W30-T10 wires post capture. So the seed is shared for the same reason: a seed that disagreed with the validator is the wave-23 illegal-seed defect (four kinds shipped a red banner and no card), and TWO seeds for one validator branch is that defect waiting. ⚠ The two metric keys are seeded `false` for BOTH, which is what the server already answers for TikTok — so nothing changes shape when T10 deletes its `and kind != "enrich_tiktok"` clause. Seeding them only for Instagram would have made T10 a client change as well. ⛔ THIS ARM AND ITS `seedBlock` SENTENCE HAD TO LAND TOGETHER. D-79's scar was exactly one of the two missing: the row rendered faded, labelled "Needs a database" — a claim about databases, which was not the problem — with an EMPTY tooltip. */ if (isEnrich(kind)) return { // ⭐ WAVE 28 · R5/R6 — `tier: "anonymous"` and `noFallback: false` are GONE from the seed. // R5 retired the free ladder from enrichment, so a new action must not be born naming a // source strategy the runner no longer consults. The server keeps ACCEPTING both keys on // stored definitions and ignores them (C2, D-65's law) — but a SEED is what a new step // starts with, and seeding a dead key is how a retired concept outlives its removal. // ⚠ `postMetrics`/`commentMetrics` stay `false` here and that is R6's ruling verbatim // ("always both off until toggled on"), matching `clean_action_config`'s reading of an // absent key so the seed and the validator cannot disagree. postMetrics: false, commentMetrics: false, dryRun: false, maxPosts: 10, fromView: "", sortField: "first_found", sortDir: "desc", // ⚠ `skipRecent: true` MATCHES `_ensure_enrich_step`'s server seed, deliberately. One // control must not have two defaults depending on whether the step was added by hand or // seeded onto an Instagram search — that is the split-default class this repo has paid // for twice ([[default-must-pass-its-own-guard]]). It also cannot surprise on first use: // nothing has an `Enriched at` yet, so the cooldown changes nothing until run two, which // is exactly when not re-paying is what you want. // ⛔ NOT the validator's default. `clean_action_config` reads an ABSENT key as False, so // every enrich action stored before today keeps the behaviour it already had — a seed is // what a new step starts with, never a rule applied retroactively (D-65). limit: 25, skipRecent: true, skipRecentDays: 30, }; if (kind === "group") /* ⭐ RE-SEEDED FOR C-FORK, and the old seed would now be REFUSED. It was `{cond: null, actions: [child]}` — the pre-wave-24 shape, which `clean_actions` no longer accepts as a config: the fork's legs live under `branches` and `cond`/`actions` are gone from the group's own config entirely. Clicking "If / then" would have produced a red banner and no card, which is precisely the illegal-default-seed defect this function's header was written about, reproduced by the wave that quotes it. MEASURED against `clean_actions` rather than reasoned: · a branch with no actions -> "a branch with no actions inside it does nothing" · so the one branch is born with the cheapest legal child, exactly as before — not a review, which would also mint a board stage nobody asked for by clicking "If / then". ⛔ `label: ""` ON PURPOSE. The SERVER letters the branches by index and calls a null-cond last leg "Otherwise", but it PRESERVES any label the client sends — so sending one would freeze it, and a branch labelled "A" would still say "A" after the branch above it was deleted. Sending nothing keeps the lettering correct by construction, and this fresh single branch reads "Otherwise" until it is given a condition, which is what it is. */ return firstField ? { branches: [ { id: "b1", label: "", cond: null, actions: [ { id: "", kind: "update_record", enabled: true, when: null, config: { values: { [firstField]: "" } } }, ], }, ], } : null; return null; }; /** Why a kind cannot be added yet — the server's own precondition, said before the click. */ const seedBlock = (kind: string): string => { if (kind === "update_record" || kind === "group") return "Name the trigger's database first — this needs a column to write."; if (kind === "create_record" || kind === "find_records") return "There is no blank database to point at yet."; /* ⛔ NOT `""`. An empty string here renders "Needs a database" with NO tooltip — a disabled control that will not say why, which is exactly how the enrich action sat unreachable and unexplained. A kind that reaches this line is one somebody forgot to seed, so the fallback says the true thing rather than the plausible one: the label above claims a database is missing, and for a forgotten seed that claim is a guess. */ return "This action cannot be added yet — it has no starting configuration."; }; /** * ⚠ `into` NAMES A BRANCH NOW, not just a group (C-FORK). A fork has several legs and "add an * action to this group" stopped being a complete instruction the moment it did — putting it in * the first branch by default would silently attach work to whichever leg happens to be first. */ const addAction = (kind: string, into?: { actionId: string; branchId: string }) => { const seed = seedFor(kind); if (!seed) return; const fresh: Action = { id: "", kind, enabled: true, when: null, config: seed }; if (!into) { patchFlow([...actions, fresh]); } else { patchFlow( mapTree(actions, (a) => { if (a.id !== into.actionId) return a; return { ...a, config: { ...a.config, branches: groupBranches(a).map((br) => br.id === into.branchId ? { ...br, actions: [...(br.actions || []), fresh] } : br ), }, }; }) ); } setAdding(false); }; /** Add an empty-conditioned leg to a fork. The server letters it and enforces the ceiling. */ const addBranch = (actionId: string) => { const seedChild = seedFor("update_record"); if (!seedChild) return; patchFlow( mapTree(actions, (a) => { if (a.id !== actionId) return a; const brs = groupBranches(a); return { ...a, config: { ...a.config, // ⚠ APPENDED LAST, and the server refuses a null-cond branch that is not last — so a // fork that already ends in an Otherwise leg refuses this with its own sentence // rather than silently burying the catch-all in the middle, where every branch below // it would be dead code. branches: [ ...brs, { id: "", label: "", cond: null, actions: [{ id: "", kind: "update_record", enabled: true, when: null, config: seedChild }] }, ], }, }; }) ); }; const dropBranch = (actionId: string, branchId: string) => patchFlow( mapTree(actions, (a) => { if (a.id !== actionId) return a; const kept = groupBranches(a).filter((br) => br.id !== branchId); // A fork with no legs at all "does nothing" — the server says so; do not send an empty // list dressed up as an edit. if (!kept.length) return a; return { ...a, config: { ...a.config, branches: kept } }; }) ); /** * R8's numbers for the whole flow, computed ONCE per render rather than per card — the map is * built by walking the tree, so asking it per card would be quadratic in a deep fork, and more * importantly a per-card computation could not see its siblings and would have to re-derive * the position it is being told. */ const stepNos = numberActions(actions); /** * ⭐ THE ACTION MENU'S GROUP ORDER, FROM THE SERVER (owner item 12b, contract C-ACT). * * ⛔ NEVER A LITERAL LIST OF GROUP NAMES HERE. The server ships `groupOrder` on every catalog * row (1 Web action · 2 Database · 3 Connected · 4 Advanced logic, derived server-side from one * table so two rows cannot disagree about their own group). A client * `["Web action", "Database", …]` would be a second copy of the catalog's structure, and the * day the engine adds or renames a group the client drops it off the end — or drops it * entirely — without anything going red. * * ⚠ AN UNORDERED GROUP SORTS LAST, NOT FIRST, which the server's own gate asserts. `Infinity` * and not `0`: a missing number meant "before everything" under a naive `|| 0`, so a server * older than this client would have led its menu with whatever it had failed to classify. * ⚠ The sort is STABLE over first appearance, so two groups sharing an order keep the payload's * sequence rather than an arbitrary one. */ /* ⭐ WAVE 27 · ITEM 33 / C4 — the ordering above moved into `steps.ts` as `groupActions`, which does the SAME arithmetic and additionally nests connector rows. Two reasons it moved rather than gaining a clause here: `groupTriggers` already does exactly this for the trigger picker and the two must not drift, and a pure function in `steps.ts` is one node can run — `verify_steps` exercises the nest, which no amount of JSX here could be tested against. */ const menuGroups = groupActions(catalog); /** ONE action row, so the nested and un-nested lists cannot render differently. */ const actionRow = (c: ActionCatalogRow) => ( ); // ── the centre column ──────────────────────────────────────────────────────────────────── const chip = () => { if (!chosen) return null; if (!configured) return ( Finish configuration ); if (trigger?.paused) return Paused; if (picked && picked.ready === false) return Not set up; const last = automation.runs?.[0]; if (last) return ( {last.ok ? "Last run succeeded" : "Last run failed"} ); return null; }; const actionCard = (a: Action, depth: number, hasNext = false): ReactNode => { const row = catalog.find((c) => c.kind === a.kind); const isGroup = a.kind === "group"; const branches = isGroup ? groupBranches(a) : []; /** * ⭐ THE PERMANENT FIRST STEP (owner ruling 2026-08-06). An Instagram search produces rows * and has nowhere to put them until something writes them, so Create record is step 1 and * stays. DERIVED from the same rule the server enforces (`ig_action_pinned`) rather than * from a stored flag — and the control is HIDDEN rather than disabled, because the server * re-inserts the action on the next save, so a delete button here would appear to work and * then silently undo itself. */ const pinned = automation.kind === "discover_instagram" && depth === 0 && a.id === actions[0]?.id; /** * ⭐⭐ WAVE 32 · T45 (owner item 10) — CONFIGURED / UNCONFIGURED, and the SERVER decides. * * ⛔ NOT COMPUTED HERE. The same `engine.action_needs` that fills this list also refuses the * run (`400 action_unconfigured`, and `run_now` for the tick and the webhook), so a card * cannot claim Configured over an action the run will reject. A client-side "does it look * filled in" test would be a second rule that agrees until one of them learns a new key. * ⚠ Nested cards get it too: the list is keyed by ACTION ID over the whole flow, branches * included, and a step inside an If / then is the one a person is least able to see. */ const needs = (automation.unconfigured || []).find((u) => u.id === a.id)?.needs || []; /** Only TOP-LEVEL cards reorder (see `moveAction`) — depth 0, and never while a write is up. */ const canDrag = depth === 0 && !busy && !pinned; return (
{ draggedRef.current = true; e.dataTransfer.effectAllowed = "move"; e.dataTransfer.setData(ACTION_DRAG_TYPE, a.id); } : undefined } onDragOver={ canDrag ? (e) => { // Somebody else's drag — a file, a nav row, selected text — is not ours to // accept. Without this test the card would light up for anything dragged over // it and then swallow the drop. if (!e.dataTransfer.types.includes(ACTION_DRAG_TYPE)) return; e.preventDefault(); e.dataTransfer.dropEffect = "move"; setDragOver(a.id); } : undefined } onDragLeave={ canDrag ? (e) => { // Moving onto a CHILD of this card is not leaving it; without this the // highlight flickers off every time the pointer crosses the title. if (e.currentTarget.contains(e.relatedTarget as Node)) return; setDragOver((cur) => (cur === a.id ? "" : cur)); } : undefined } onDrop={ canDrag ? (e) => { const dragId = e.dataTransfer.getData(ACTION_DRAG_TYPE); setDragOver(""); if (!dragId) return; e.preventDefault(); moveAction(dragId, a.id); } : undefined } onDragEnd={() => { setDragOver(""); // Cleared a tick later: the post-drag click arrives BEFORE this would run. window.setTimeout(() => { draggedRef.current = false; }, 0); }} > {pinned ? ( Always first ) : ( )}
{/* ⭐ THE FORK (owner item 12a, ruling R8, contract C-FORK). A group used to hold ONE nested column; it now holds a LETTERED LANE PER BRANCH, because R8 rules that a fork occupies one step number and its legs are alternatives rather than later steps. THE LETTER AND THE "Otherwise" ARE THE SERVER'S WORDS — `br.label`, printed, never composed. `clean_actions` letters by index and names a null-cond last leg "Otherwise", so the lanes re-letter themselves correctly when one is deleted. The nesting ceiling is still the SERVER's `maxGroupDepth`, so the add-here affordance disappears at exactly the depth `clean_actions` refuses. */} {isGroup ? (
{branches.map((br) => (
{br.label} {/* ⚠ NOT A RENDERED CONDITION — the tree is edited in Properties, and a second editable copy here would be two controls for one fact. This says only WHICH leg you are looking at. A null cond is the catch-all, and the server has already labelled it, so this says nothing twice. */} {br.cond ? "when its conditions match" : "everything else"} {branches.length > 1 ? ( ) : null}
{(br.actions || []).map((k) => actionCard(k, depth + 1))} {depth + 1 < (vocab?.maxGroupDepth ?? 2) || !(br.actions || []).length ? ( ) : null}
))}
) : null} {/* THE ARROW BACK INTO THE FLOW (item 12a). The lanes are alternatives and exactly one of them runs — the engine takes the first matching branch and breaks — so they REJOIN, and without a mark saying so a fork at the end of a column reads as several parallel endings. Drawn only when there IS a next step to rejoin: an arrow into nothing is a promise the flow does not keep. */} {isGroup && hasNext ? ( ) : null}
); }; return ( <>
{/* ── TRIGGER ─────────────────────────────────────────────────────────────────── */}
Trigger {chip()}
{chosen && options.length ? (
) : ( /* THE EMPTY STATE (image 1): a dashed add-box and the server's own suggested triggers. One line of chrome, no tour (R13) — the list IS the explanation, and it is the server's list so it cannot describe a trigger we removed. */ <> {/* THE BOX AND ITS MENU ARE ONE UNIT (see `addWrap`). The menu USED to render at the bottom of this component, outside `.autox-flow` entirely, and became a third column of the flex row that holds the canvas and Properties — the owner's ERROR 4. */}
{/* ⭐ WAVE 25 item 5b (C2) — `TriggerPicker`, the SAME component Properties → Trigger details renders in its compact form. Category first (Time / Database / Connector) with connector rows nested under their product. */} {picking ? ( setPicking(false)} /> ) : null}
{options.length ? (

Suggested triggers

{options // ⭐ 2026-08-07 (owner ruling) — MANUAL IS OFFERED AGAIN. It was excluded // (`t.key !== "manual"`) because picking it stored NOTHING and bounced // straight back to this empty state — "a control that undoes itself is // worse than no control", correct while that was true. `clean_trigger` now // STORES `{key:'manual'}`, so the pick sticks, `chosen` goes true and // Configuration opens. Hiding it now would leave the one trigger a person // most expects to find as the only one they cannot choose. .filter((t) => t.ready !== false && !t.planned) .slice(0, SUGGESTED) .map((t) => ( ))}
) : (

This server did not offer a trigger list.

)} {/* ONE LINE (R13), and it is what is TRUE of this state rather than a caption for the box above it: with nothing chosen, Run now is the only thing that starts this automation. Airtable's empty state means "it cannot run"; ours does not, and saying so is the difference between a screen that is honest and one that merely looks the same. */}

Until then, only Run now starts it.

)}
{/* ── ACTIONS ─────────────────────────────────────────────────────────────────── */}
Actions
{actions.map((a, i) => actionCard(a, 0, i < actions.length - 1))} {/* ⛔ THE MACHINE STEPS ARE NOT CARDS ANY MORE (owner item 5, contract C-CFG). They were engine-derived read-only cards sitting under the owner's own actions — "fetch the page", "Bright Data", "Anonymous", "Write" — so the centre column mixed two different things: what the AUTOMATION is, which nobody chose and nobody can reorder, and what the OWNER added, which is the whole subject of this builder. Their configuration and their switches moved to Properties → Configuration → "How this fetches", one section per panel. ⚠ THE ENGINE STILL RUNS THEM. `graph()` emits the same nodes; this surface simply stops DRAWING them, which is why the switches had to move rather than go — R7 names Bright Data (money) and Write's dry run (reads and reports without writing a row) as controls that must survive the cards that carried them. */} {/* THE ACTION MENU (images 7/8): the server's catalog, grouped by its own `group` key, with `ready:false` rows faded and carrying the server's reason. A shorter menu would imply those actions do not exist — the owner asked to see all of them, and `clean_actions` refuses the unready ones at the door, so faded is a wall rather than a decoration. */} {adding ? (
{menuGroups.map((g) => (

{g.key}

{/* ⭐ WAVE 27 · ITEM 33 / C4 — the group's OWN rows first, then one nest per connector. `
` rather than a hand-built disclosure: it IS the chevron-and-submenu the reference shows, it opens on Enter and Space without a keydown handler, and it needs no open/closed state of its own to get wrong. Closed by default — the reference shows collapsed rows, and a connector nobody is using should cost one line, not six. */} {[...g.rows, ...g.sub].map((entry) => ("rows" in entry ? (
{/* ⭐ WAVE 30 · ITEM 7 / R4 — THE COLLAPSED ROW GETS AN IDENTITY. This is the row the owner clicks before choosing Instagram or TikTok, and until now it was the only row in the menu with nothing on its left: the chevron, then a bare word. The mark is resolved from the connector KEY, so a connector the server adds tomorrow gets a slot for free and simply renders no logo. */} {brandForConnector(entry.key) ? ( {brandForConnector(entry.key)} ) : null} {entry.label} {entry.rows.length} action{entry.rows.length === 1 ? "" : "s"} {entry.rows.map((c) => actionRow(c))}
) : actionRow(entry)))}
))}
) : null}
{/* ── PROPERTIES ──────────────────────────────────────────────────────────────────── */} {/* THE CONFIRM (image 6). A trigger change can invalidate the configuration under it, so it ASKS — and it says what it will cost rather than "are you sure". */} {confirmKey ? (

Change the trigger?

Anything configured for {picked?.label || triggerKey} is dropped.

) : null} {/* ⛔ THE PICKER USED TO RENDER HERE, and here is outside both columns. `.auto-work` is a flex row of `.autox-flow` + `.autox-props`, so a third child was laid out as a third COLUMN — the menu appeared past the right edge of the Properties panel and squeezed the canvas until the suggested triggers wrapped one word per line (owner's ERROR 4). It is rendered beside its own "+ Add trigger" box now; see `addWrap`. */} ); } /** One action's subtitle — what it will DO, composed from its own config. */ function actionSub(a: Action, tables: UserTable[]): string { const cfg = a.config || {}; if (a.kind === "update_record") { const keys = Object.keys((cfg as { values?: Record }).values || {}) .filter(Boolean); return keys.length ? `Sets ${keys.join(", ")}` : "No values yet"; } if (a.kind === "create_record") { const t = String((cfg as { table?: string }).table || ""); return t ? `Into ${tableLabel(tables, t)}` : "No database yet"; } if (a.kind === "find_records") { const t = String((cfg as { table?: string }).table || ""); return t ? `In ${tableLabel(tables, t)}` : "No database yet"; } return ""; } function findAction(list: Action[], id: string): Action | null { for (const a of list) { if (a.id === id) return a; // ⚠ THROUGH THE BRANCHES (C-FORK). This read `config.actions`, which a fork no longer has — // so selecting any action inside one would have found nothing and the Properties panel would // have said "that action is no longer part of this flow" about a card visibly on screen. if (a.kind === "group") for (const br of groupBranches(a)) { const hit = findAction(br.actions || [], id); if (hit) return hit; } } return null; } /* * ⛔ `nodePanel()` IS GONE (item 5). It rendered ONE machine node's panel, chosen by the card the * reader had clicked, and included a "that step is no longer part of this automation" branch for * a selection the graph had since dropped. Both facts died with the cards: the panels are now * rendered together under "How this fetches", keyed by PANEL rather than by node id, so there is * no selection left to go stale. */ // ── the Properties panel's two faces ───────────────────────────────────────────────────────── function TriggerProps({ automation, triggerKey, options, picked, table, tables, ops, nullaryOps, vocab, oauth, busy, nodes, onToggleNode, renderNodeBody, onAskChange, onPatchTrigger, onPatchConfig, onPickTrigger, onRunNow, scheduleFace, schedules, chosen, }: { automation: Automation; triggerKey: string; options: TriggerOption[]; picked: TriggerOption | null; table: UserTable | null; tables: UserTable[]; ops: string[]; nullaryOps: string[]; vocab?: FlowVocab; oauth: OAuthStatus | null; busy: boolean; /** The engine's machine steps (item 5) — their switches and bodies live under Configuration. */ nodes: GraphNode[]; onToggleNode: (nodeId: string) => void; renderNodeBody: (panel: string) => ReactNode; /** Ask before a trigger change that can invalidate the config under it (image 6). */ onAskChange: (key: string) => void; onPatchTrigger: (patch: Record) => void; /** Writes the automation's OWN config — the database a table-less trigger has nowhere * else to name (owner report 2026-08-07). Spreads on the way in; see `patchConfig`. */ onPatchConfig: (patch: Record) => void; onPickTrigger: (key: string) => void; onRunNow: () => void; scheduleFace: ReactNode; schedules: boolean; /** * ⭐ WAVE 25 item 5b (ruling R14) — HAS A TRIGGER BEEN PICKED AT ALL? * * REQUIRED and passed IN, never re-derived: it is the same `chosen` the centre column gates its * empty state on, and the honest test is what the DEFINITION holds rather than what the picker * displays (`triggerKey` derives "manual" whenever nothing is stored, so anything computed from * it is true for every automation ever — a mistake this file already made once and only a * screenshot caught). */ chosen: boolean; }) { const trigger = automation.trigger || null; const provider = picked?.connect?.provider || ""; const connected = !!(provider && oauth?.[provider]?.connected); const startUrl = picked?.connect?.startUrl || ""; const needsTable = !!trigger && "table" in trigger; /** * ⭐⭐ 2026-08-07 — DOES THIS AUTOMATION HAVE TO NAME ITS OWN DATABASE? * * True for a `plain` automation whose trigger carries no table — which INCLUDES the state where * no trigger is stored at all, and that inclusion is the whole fix. `clean_trigger` stores * nothing for `manual`/`schedule` by design, so those automations hold `trigger: null`, `chosen` * is false, and W25/R14's "Configuration does not render until a trigger is picked" hid the * Database picker below from the exact automations that cannot get a database any other way. * The owner hit it twice: *"when the Trigger is Manual, it says that I need to bound it to a * database, how?"* — and the honest answer was that there was no how. * * ⚠ It is the SAME condition the picker itself renders on, named once and used twice, so the * section cannot open without the control or the control appear without its section. */ const needsOwnTable = automation.kind === "plain" && !needsTable; const last = automation.runs?.[0]; /** ITEM 22 / D-70 / R12 — the shared Run guard (see `runBlock`). */ const runState = runBlock(automation); return ( <>

Trigger details

{/* ⭐ WAVE 25 item 5b (C2) — THE NATIVE ` onPatchTrigger({ table: e.target.value })} data-role="trigger-table" > {trigger?.table && !tables.some((t) => t.key === trigger.table) ? ( ) : null} {tables.map((t) => ( ))}
) : null} {/* ⭐⭐ 2026-08-07 (owner report) — THE DATABASE A TABLE-LESS TRIGGER HAS NOWHERE ELSE TO NAME. Owner: *"how come, enrich instagram when standalone 'manual' trigger, doesn't have a database that it should point to? dont make this mistake again."* MEASURED across the trigger vocabulary: `manual`, `schedule` and `email` carry NO `table`, so `needsTable` is false and the picker above never rendered — while `AutomationDetail`'s Properties picker is gated to `scrape_db` / `field_instagram`, BOTH RETIRED KINDS. So **nothing in the client wrote `config.targetTable` for a `plain` automation**, and `run_plain` answered *"no database is bound yet — pick one on the trigger, or in Properties"*: a refusal naming two doors, neither of which existed. Every scheduled or manual flow — the owner's *"on a schedule, enrich these sets of influencer names"* — was unbuildable. ⛔ `plain` ONLY, and that is what keeps it from being a second control for one fact. Every other kind names its database somewhere of its own: an Instagram search through the pinned Create record (W25/R2 made that action authoritative and `targetTable` follows it), and the two retired kinds through their own Properties panels. Widening this would put two pickers on one key and let them disagree, which is the exact defect R2 was written to end. */} {needsOwnTable ? (

The records this automation’s steps walk. A trigger like Manual or a schedule does not name one on its own.

) : null} {triggerKey === "event_field" ? ( <> {/* ⛔ "WATCHED COLUMN" IS GONE (owner item 7, C-TRIG law 4). "When a record matches conditions" is a FILTER, and a watched column was a second, different question answered in the same box — the trigger fired on a column changing AND on the conditions holding, which is two triggers wearing one name. ⚠ THE SERVER WENT FIRST, and that ordering was the point: `clean_trigger` stopped reading `field` (C posted law 4 done) BEFORE this control came out. Deleting the control while the validator still read the key would have left a stored watched column that nothing displays and nothing can clear — and deleting the key while the control still showed it would have made every Save silently drop what the user picked. The CONDITION is what completes this trigger now: with none, it rides `configured:false` and says so. */}

* Conditions

onPatchTrigger({ when: next })} fields={table?.fields || []} ops={ops} nullaryOps={nullaryOps} maxDepth={vocab?.maxCondDepth ?? 3} maxChildren={vocab?.maxCondChildren ?? 12} disabled={busy} /> ) : null} {triggerKey === "record_updated" ? (

Select none to fire on any column.

) : null} {triggerKey === "enters_view" ? (
{/* ⭐ FOUR STATES, AND THREE OF THEM ARE SENTENCES (owner item 8, C-TYPES). `views` now rides `GET /automations/tables`, so this control is live — but "drop the note" would have collapsed it to two states and rebuilt the exact defect the contract forbids. Absent and empty are DIFFERENT FACTS: · no database chosen -> choose one first · `views` ABSENT -> the server offered nothing (a server older than this client). Saying "no views" here would be a claim nobody measured. · `views` present and [] -> this database genuinely has none. That IS measured, and it is the one that tells the reader to go and make a view rather than to go and find an admin. · non-empty -> the picker. */} {!table ? (

Choose a database first.

) : !table.views ? (

This server did not offer a view list for that database.

) : !table.views.length ? (

That database has no saved views yet — make one on its grid and it appears here.

) : ( whose `value` matches no ) : null} {table.views.map((v) => ( ))} )}
) : null} {triggerKey === "email" ? (
onPatchTrigger({ query: e.target.value })} />
) : null} {triggerKey === "webhook" && trigger?.token ? (

Minted once. It survives every other change to this trigger.

) : null} {/* THE SCHEDULE, rendered by the one component that owns the cron round-trip. ⚠ NOT `triggerKey === "schedule"` ANY MORE (item 7, C-TRIG). `ig_profile_match` watches nothing — it MAKES rows, on the cron — so its Configuration carries these controls "always", and the caller says which keys those are. */} {schedules ? scheduleFace : null} {triggerKey === "manual" ? (

It runs when you press Run once now, and nothing else starts it.

) : null} )} {/* ⭐ HOW THIS FETCHES (owner item 5, contract C-CFG) — the machine steps' switches and config bodies, below the trigger's own fields, under ONE sub-heading. ⛔ ONE SECTION PER PANEL, NOT PER NODE (`groupByPanel`, and its note is the reason). Four of `field_instagram`'s nodes share `panel: "capture"` and both of `discover_instagram`'s share `panel: "find"`, so a section per node would print one body four times and mount the discovery filter twice against a single `preds` array. ⛔ AND THE SWITCHES ARE THE POINT, not a leftover. R7: Bright Data buys exact counts with MONEY and Write's switch is the difference between a run that writes rows and one that reads and reports. They were on the cards this wave deleted, so deleting the cards without moving them would have retired two shipped controls silently. Each still posts to the node-toggle door — the server decides what a switch means, this only says which node. `plain` automations have no machine nodes at all, so the whole section is absent for them rather than an empty heading (R6 makes that the common case from now on). ⭐ WAVE 26 · ITEM 17 / R15 — THE PROSE IS GONE AND THE SWITCHES STAYED, which is the whole ruling. The owner quoted this section back verbatim — *"How this fetches / Find profiles / Bio contains skincare… / Collect results / Takes about 20 minutes / Up to 10 profiles · about $0.025"* — and asked for it gone. Every line of that quote is server-composed (`automation_engine.graph`), and it maps EXACTLY onto three renderers, which is why the deletion could be surgical rather than a section removal: · `n.subtitle` -> "Bio contains skincare…" and "Takes about 20 minutes" (`:5030`, `:5036`) · `g.nodes[0].detail` -> "Up to 10 profiles · about $0.025" (`:5032`) — the ESTIMATE LINE · `n.title`/`

` -> "How this fetches", "Find profiles", "Collect results" — KEPT ⛔ THE HEADING WAS A SYMPTOM, NOT THE SUBJECT. Deleting the section would have retired the Bright Data MONEY switch and the write node's DRY RUN with it — the two controls that were moved here precisely so deleting the cards would not retire them silently. They are the `n.toggle` block below and they are untouched. ⚠ `AutomationFind`'s "What it costs" estimate is NOT this line and is NOT in scope: it is the ANSWER to a button a person pressed, and it is the only surface carrying D-23's SPEC-basis caveat. The read-only paragraph went; the control did not. */} {nodes.length ? ( <>

How this fetches

{groupByPanel(nodes).map((g) => (
{g.nodes.map((n) => (
{n.title} {/* ⭐ ITEM 18 / R14 — the per-node status dot stood here and is deleted. The node already carries its own `ActionMark` above; a coloured dot beside it was the second thing on one row claiming to say what this step is. */} {n.toggle ? ( ) : null}
))} {/* ⭐ ITEM 17 / R15 — THE ESTIMATE LINE STOOD HERE. `g.nodes[0].detail` is where "Up to 10 profiles · about $0.025" reached the screen (composed at `automation_engine.py:5032`), and the owner named it. It was the engine's own sentence rather than a client paraphrase, which is why it was defensible and why it still had to go: an accurate paragraph nobody asked for is still the architecture explaining itself (DESIGN.md §4). ⚠ The COST question keeps a home — "What it costs" in the Find panel below, behind a press, carrying its own SPEC caveat. This line stated a price nobody had asked for beside a control that was not about price. */} {renderNodeBody(g.panel)}
))} ) : null}

Test step

{/* ⛔ HONEST TO OUR SEMANTICS, not to Airtable's. Airtable's "Test step" replays one step against a chosen record. Ours has no step-replay: the engine runs a whole automation. So the control says what it actually does — RUN IT — and the results below are the last real run's, from the run log, rather than a rehearsal nobody performed. */} {/* ⭐ ITEM 22 / D-70 / R12 — THE SECOND DOOR ONTO THE SAME MONEY, guarded by the SAME function. It was `!!automation.running`, which is process state and therefore false for the entire 20-30 minute vendor wait; `runBlock` is the one definition both buttons read, so a fix cannot land on one and miss the other. */} {runState.blocked && !automation.running ? (

{runState.why}

) : null} {last ? ( <>

{last.ok ? "Last run succeeded" : "Last run failed"}

{last.ts.replace("T", " ").slice(0, 16)} — {last.summary}

) : (

It has not run yet.

)} ); } /** * ⭐ WAVE 26 · ITEM 9 / R11 — "+ New database", INSIDE the action's own database picker. * * Owner ruling R11, verbatim: *"name it and go. No dialog stack; columns follow what the action * writes (how the IG presets already work)."* So this is a name box and a button, in place, and * it selects what it creates — never a modal over a modal, and never a trip to another surface * that loses the action being configured. * * ⛔ IT DOES NOT INVENT THE ROW IT JUST MADE. `POST /tables` answers `{key}` alone, so the * component asks the caller to RE-LIST and only then selects the key. Splicing a client-built * `UserTable` in would put a guessed `rowCount` and an empty `fields` on screen beside real ones, * and the picker renders `rowCount` — a fabricated measurement, which is the one thing this * codebase refuses everywhere else. * * ⚠ THE REFUSAL IS THE SERVER'S, PRINTED VERBATIM. `POST /tables` has real refusals a person can * hit — an empty name, the `MAX_TABLES` ceiling, an unavailable store — and each answers with its * own sentence. Re-deriving "you have too many databases" here would be a second copy of a rule * that lives on the other side of the wall ([[schema-role-is-not-a-value-wall]]: find the line * that ENFORCES it, and let that line do the talking). */ function NewDatabase({ disabled, onCreated, }: { disabled: boolean; /** * Called with the new key AFTER the caller's table list has been re-read. * ⚠ IT MAY RETURN A PROMISE AND THE CALLER MUST AWAIT IT. Selecting the key before the list * contains it makes the picker's own "stored value is always an option" guard paint * "(not visible to you)" about the database the user just created — the guard doing exactly its * job, on a race, and saying something alarming and false. */ onCreated: (key: string) => Promise | void; }) { const [open, setOpen] = useState(false); const [name, setName] = useState(""); const [busy, setBusy] = useState(false); const [err, setErr] = useState(""); const create = () => { const label = name.trim(); if (!label || busy) return; setBusy(true); setErr(""); createTable(label) .then(async (r) => { setOpen(false); setName(""); // AWAITED: the caller re-reads the table list, and only then may the key be selected. await onCreated(r.key); }) .catch((e) => { // The server's own words. `AutomationError` carries the composed sentence; anything else // is a transport failure and says so rather than blaming the name. setErr( e instanceof AutomationError && e.message ? e.message : "could not create it — the workspace did not answer" ); }) .finally(() => setBusy(false)); }; if (!open) { return ( ); } return (
setName(e.target.value)} // Enter creates, Escape backs out — the two keys a one-field form owes its user. onKeyDown={(e) => { if (e.key === "Enter") { e.preventDefault(); create(); } else if (e.key === "Escape") { setOpen(false); setErr(""); } }} /> {err ?

{err}

: null}
); } /** * ⭐ WAVE 28 — EXPORTED so the include-row render suite can mount the real panel. * * ⛔ THE EXPORT IS THE POINT, not a convenience. R6's three include rows are markup whose defect * modes are invisible to a source grep: a row that renders with no key attached, a Profile * checkbox that paints unchecked, two rows bound to the same key. `ReviewProps` below is already * exported for the same reason, so this is the file's existing shape rather than a new one. * `_test/` never ships (`deploy_web.py` excludes `_test/` and `_`-prefixed files both). */ export function ActionProps({ action, pinned, catalog, tables, onTablesChanged, walkFields, walkTable, ops, nullaryOps, vocab, busy, onEdit, }: { action: Action | null; /** * ⭐ THE PERMANENT STEP 1 OF AN INSTAGRAM SEARCH (owner report, 2026-08-06). It is the ONE * action whose `values` and `uniqueOn` the engine never reads: `apply_actions` drops * `actions[0]` for `discover_instagram` and the runner does the writing itself, upserting the * profile columns on `(handle, created_by)`. * * The card stays — "this search puts what it finds in a database" is true and worth showing — * but a `* Values` editor above `{{column_key}} reads that column off the record walking the * flow` is a required-looking control over a step nothing walks, and the owner spent a session * trying to make sense of it. Worse, it was ANSWERABLE: remapping it to `name: {{handle}}` * saved cleanly, changed nothing, and left the panel describing a write the engine does not * perform. A picture of the engine that disagrees with the engine is the defect this file * refuses in five other places. */ pinned: boolean; catalog: ActionCatalogRow[]; tables: UserTable[]; /** ITEM 9 / R11 — re-read the list after this panel's picker creates one. REQUIRED; see Props. */ onTablesChanged: () => Promise | void; /** * ⛔ THE WALKING RECORD'S COLUMNS — the trigger's database, resolved by the builder. * * These three surfaces were built with `fields={[]}` and it made R3's headline feature * unauthorable: a conditional group's condition, an action's `when`, and `update_record`'s * column picker all offered "Choose a field…" and nothing else. An empty list is not a * neutral default here — it is a picker with no options, which reads as "this database has * no columns". */ walkFields: { key: string; label: string; type: string }[]; /** * ⭐ WAVE 26 · ITEM 5 / R10 — DOES A RECORD WALK THIS FLOW AT ALL? The key of the database it * walks, or `""`. * * ⛔ REQUIRED, and it answers a question `walkFields` structurally cannot. Both a flow with no * walking record and a flow walking an empty database hand this panel `[]`, and R10 wants * OPPOSITE renderings for them: a sentence pointing at the trigger for the first, an ordinary * (empty) picker for the second. * ⚠ VERIFIED AGAINST THE RUNNER, not inferred from the trigger list — which C4 forbids by name * ([[loopable-wave24]]: `CRON_DRIVEN_TRIGGERS` was exactly that mistake and became D-55). * `run_flow` returns immediately on `if not table_key` and otherwise walks that table's rows * evaluating `lane_match(act["when"], row)`, so a non-empty table key is EXACTLY the condition * under which `when` is ever consulted. The builder derives it from `_flow_table`'s own * precedence (`AutomationDetail.tsx`'s `walkTable`, whose comment carries that rule). */ walkTable: string; ops: string[]; nullaryOps: string[]; vocab?: FlowVocab; busy: boolean; onEdit: (change: (a: Action) => Action) => void; }) { if (!action) return

That action is no longer part of this flow.

; const row = catalog.find((c) => c.kind === action.kind); const cfg = action.config || {}; const setCfg = (patch: Record) => onEdit((a) => ({ ...a, config: { ...a.config, ...patch } })); const values = (cfg as { values?: Record }).values || {}; const target = tables.find((t) => t.key === String((cfg as { table?: string }).table || "")); const valueFields = action.kind === "create_record" ? target?.fields || [] : walkFields; /** * The saved views of the database the flow's records WALK — the enrich step's optional filter. * * ⚠ Read off `walkTable`, never off `target`: `target` is the Create-record action's own * destination and answers a different question, and on an Instagram discovery flow the two are * routinely different tables. Same trap `walkFields` carries its own note about. * ⚠ `undefined` is a THIRD STATE and is preserved as one (`UserTable.views` is absent until the * server sends it) — the panel says "no view list was offered" rather than drawing an empty * picker that reads as "this database has no views". */ const walkViews = (tables.find((t) => t.key === walkTable) || null)?.views; return ( <>

{row?.label || action.kind}

{row?.detail ?

{row.detail}

: null}

Configuration

{action.kind === "group" ? ( <> {/* ⭐ ONE CONDITION EDITOR PER BRANCH (C-FORK). The group's own `config.cond` is GONE — a fork has a condition per leg, not one for the whole thing — so an editor bound to `cfg.cond` would now write a key `clean_actions` drops on the floor: the tree would look saved, survive a reload from local state, and be absent the next time anyone opened the automation. THE HEADING IS THE SERVER'S LABEL. The last leg may carry no condition, and the server has already named it "Otherwise" — giving it one here turns it into a lettered branch, which is a real thing to want and needs no separate control. */} {groupBranches(action).map((br, i) => (

{br.label} {br.cond ? " — run these actions if…" : " — everything that reaches here"}

onEdit((a) => ({ ...a, config: { ...a.config, branches: groupBranches(a).map((x) => x.id === br.id ? { ...x, cond: next } : x ), }, })) } fields={walkFields} ops={ops} nullaryOps={nullaryOps} maxDepth={vocab?.maxCondDepth ?? 3} maxChildren={vocab?.maxCondChildren ?? 12} lead="" disabled={busy} />
))}

The first branch whose conditions match is the one that runs — the record does not go down two of them.

) : null} {action.kind === "create_record" ? (
` whose `value` matches no ` ) : null} {tables.map((t) => ( ))} {/* ITEM 9 / R11 — mint one without leaving the action being configured. */} { await onTablesChanged(); setCfg({ table: key }); }} /> {/* ⭐ WAVE 25 item 4 (ruling R2b, contract C1, wiring W25-4) — WHAT POINTING IT HERE DOES. The two lists are the SERVER's (`GET /automations/presets`), diffed against whatever database this action names — R2 makes `config.table` authoritative, so a hand-made one answers exactly like a spawned one. */}
) : null} {/* WHAT THE SEARCH ACTUALLY WRITES, in place of the two controls below that do not apply to it. ⚠ THE LIST IS `_candidate_row`'s, field for field: a shorter "the profile columns" would be safe and useless, and a list that drifts from what the engine writes would be the same lie the value map was. */} {pinned ? (

The search writes one row per profile it finds — handle, profile link, name, followers, following, average engagement, bio, link in bio, verified and category — into that database. It matches on the handle, so a profile found again updates its row instead of adding another. There is nothing to map: the columns come from the search.

) : null} {/* ⭐ WAVE 25 item 2 (ruling R1a, contract C5, wiring W25-5) — KEEP RECORDS UNIQUE. Today's Create record APPENDS FOREVER: `_commit_action_writes` mints `max(id)+1`, so any scheduled flow using it duplicates a row per run — every night, silently, until somebody looks at the table. `uniqueOn` names the column to upsert on instead. ⛔ `""` IS A REAL CHOICE AND IT IS THE DEFAULT, so no stored automation changes meaning the day this ships. That is why the empty option is worded as a behaviour ("Add a new record every time") rather than as an absence ("None"): it describes what will happen, which is the thing the reader is choosing between. ⚠ THE COLUMN LIST IS THE TARGET DATABASE'S, not the walking record's — `valueFields` already resolves that for `create_record`. And the server REFUSES a `uniqueOn` this action does not write ("it writes: …"), so the honest client move is to offer the columns it writes FIRST while still allowing the rest: pre-empting the refusal here would be a second copy of a server rule, and this file's law is that the server owns legality. */} {action.kind === "create_record" && !pinned ? (

{String((cfg as { uniqueOn?: string }).uniqueOn || "") ? "A run that finds a matching record updates it instead of adding another." : "Every run adds a row, even if the same one is already there."}

) : null} {/* ⭐ WAVE 25 item 1 (rulings R3/R4, contract C4) — THE ENRICH ACTION'S CONFIGURATION. It replaces the whole `field_instagram` KIND: enriching a profile is something you do TO a record, not a species of automation. The switches are that kind's, unchanged in meaning, because they are the ones that decide what a run COSTS. ⛔ NO `profileField` PICKER HERE, DELIBERATELY, and it is not an omission. C3's profile FLAG on the column is what binds this action (R7 — one flagged text field per table), and the server resolves it at run time; an empty `profileField` is the A3 stored-inert state, not an error. A second picker would let a reader choose a column the flag does not name, which is two sources of truth for one binding — and the flag is the one the engine reads. */} {isEnrich(action.kind) ? ( <> {/* ⭐⭐ 2026-08-07 (owner ruling) — WHICH RECORDS THIS STEP SPENDS ON. Owner: *"how many records with what sort, based on a Filtered view or maybe top N enrichment sorted by date"*. Every enrichment is a vendor call, so an enrich step without this panel bills for EVERY record in the database on EVERY run — which is why these controls shipped in the same change as the fix that made the action clickable at all, rather than after it. ⛔ THE LIMIT IS A QUOTA OF WORK DONE, NOT A WINDOW OF ROWS READ — the owner's own clarification: *"if a user choose to enrich 30 and from that sorted list of 30, 20 is enriched last 30 days, then it goes to next list"*. The server walks PAST every skipped record until the quota is filled, so the number in this box is a cost ceiling that means the same thing every run. `enrich_selection` owns the rule; this panel never re-implements it. */}

Records to enrich

{/* ⚠ ABSENT vs EMPTY, the `UserTable.views` third state. "This server did not offer a view list" is a different fact from "this database has no views", and rendering an empty picker for the first one is the silent-empty defect wave 23 gated. */} {!walkViews ? (

No view list was offered for that database.

) : null}
setCfg({ limit: Number(e.target.value) || 25 })} />

Records enriched per run, at most 100. Skipped records do not use up the limit — the run keeps going down the list until it has enriched this many.

{/* ⛔ THE DAYS BOX ONLY EXISTS WHILE THE RULE IS ON. A number that configures nothing is worse than a missing one ([[wrong-parent-not-broken-control]]) — and this one would read as a cost guard that is running while it is switched off. */} {(cfg as { skipRecent?: boolean }).skipRecent ? (
setCfg({ skipRecentDays: Number(e.target.value) || 30 })} />

Days. A profile enriched inside this window is passed over, and the run moves on to the next one — so you never pay twice for the same profile, and the history still gains a point once the window closes.

) : null} {/* ⭐⭐ WAVE 28 · R5 / R6 / R7 — THE SOURCE QUESTION IS GONE, AND THREE INCLUDE AXES REPLACE IT. What stood here was a `Source` select writing `config.tier` (Anonymous / Paid provider) plus a sibling `noFallback` checkbox — ONE control in two pieces, asking the user to choose a VENDOR STRATEGY. ⛔ R5 RETIRED THE QUESTION, not just the control. Enrichment routes per capability to the paid providers and reports blocked on a refusal; there is no thin anonymous row to fall back to, so "which source" and "stop if it fails" no longer have answers a person could give. `tier` and `noFallback` are accepted-and-ignored in stored configs (C2, and D-65's law: never 400 a definition that was legal when it was written) — which is why this panel simply stops writing them rather than migrating anything. ⛔ THE ROWS BELOW ARE A TRANSFORM, NOT AN ADDITION, and that distinction is the whole defect risk in this change. `postMetrics` and `commentMetrics` ALREADY had checkboxes 34 lines below this point ("Also capture per-post engagement" / "…per-comment…"). Building three NEW rows and leaving those would have put TWO controls on each key — which compiles, renders, and satisfies any check asking whether a Post-data switch exists. The old pair is deleted; these carry their keys. ⚠ KEYS UNCHANGED ON PURPOSE (C2). Every stored enrich action round-trips untouched; only the labels move. R7: no cost sentence anywhere in this panel — the run log keeps honest spend reporting, and a warning printed permanently is chrome the eye stops reading (DESIGN.md §4). */} {/* ⚠ A GROUP HEADING, NOT A `