Can a prompt replace Integrately?

Build an automation runner whose unit of work is a declarative recipe file, not a visual canvas.

Recipe format: a YAML file, versioned and readable, declaring:

- a trigger: a service, an event, and a polling interval or a webhook path
- a filter: an optional condition on the trigger payload
- a mapping: target fields to expressions over the trigger payload, using a small, safe expression language (field access, string concatenation, a handful of functions like lower, trim, date format). No arbitrary code evaluation.
- an action: a service, an operation, and the mapped fields
- an idempotency key expression, so the same trigger event cannot produce two actions

A recipe is a file in a directory. Importing one is copying it in; sharing one is sending it. This is what replaces a catalogue at personal scale, and it is why the format has to be readable by a human, not generated.

Services: each is an adapter module with credentials stored encrypted, exposing the operations it supports and a JSON schema for each operation's inputs. Implement two services fully to prove the shape, and document adding a third in the README with a worked example. Validate a recipe against the declared schemas at load time, so a typo in a field name fails on import rather than at 3am.

Execution: poll triggers on their interval, or accept webhooks at a per-recipe path with a shared secret. For each event, evaluate the filter, build the mapping, check the idempotency key against the executions table, and call the action. Record every execution: the trigger payload, the evaluated mapping, the action request and response, the outcome, and the duration.

Failure handling: retry with exponential backoff on transient errors, stop and mark failed on a 4xx that is not a rate limit, and place permanently failed executions in a dead-letter list. Every dead-lettered execution can be replayed after fixing the recipe, using its stored trigger payload — this is the feature that makes a self-hosted automation trustworthy, because the alternative is losing the events that arrived while it was broken.

Dry run: execute a recipe against the last N real trigger events, showing every mapping and every intended action without performing any of them. Require a dry run to pass before a new recipe can be enabled.

Out of scope: a visual builder, branching or looping control flow, more than one action per recipe, and any hosted multi-tenant deployment. If a task needs branching, it is two recipes.