== Changelog ==

= 1.6.0 =
* Two new database tables backing the Pro add-on's Inbox and Connection Health screens: an audit ledger of human decisions on a dead-lettered or uncertain run, written only by the Pro Inbox; and a ledger of connection test results, which the free runner itself writes to whenever any step's access is revoked, Pro or not. A free-only install has no screen that shows either table. The connection-health ledger has no pre-flight check that acts on what it stores at all; the decision ledger does — an uncertain run's own free "Retry" now needs a decision recorded in it first, and only the Pro Inbox can record one, so the free Failed view explains that instead of offering a retry it is guaranteed to refuse.
* A Pro connector step whose credential is already known to be revoked — from a manual connection test, or from an earlier run that hit the same 401/403 — now refuses to start the run at all, before any step of it executes, instead of being discovered mid-run.

= 1.5.0 =
* The end of the JSON boxes. Every trigger and every step now draws its own form from the parameters it declares — a labelled field with the right control instead of a textarea you had to know the shape of. Conditions are rows: field, operator, value, with the operator list read from the engine itself so it can never offer one the engine does not implement.
* Next to every text field, an "Insert field" menu carrying the trigger's own values — `{{event.order.email}}` and the like — each shown with a real example from that trigger's sample payload. A placeholder in a numeric field stays a placeholder instead of being coerced to zero.
* The JSON is still there, under an "Advanced" toggle, and the builder refuses to redraw anything it cannot draw honestly: a nested condition group, a parameter no schema knows about, or an OR group on a site without the add-on opens as JSON with a note saying why. Without JavaScript the screen falls back to the previous editor, and nothing is lost either way.
* A library of ready-made flows. Twenty of them, grouped by the plugin they lean on — a form submission into Slack and a CRM, an order into a webhook, a locked-out IP to your team. Every trigger and action in the library is a real id in Cascade Forge's catalogue, not an invented one — and a recipe this site cannot run yet names the plugin it needs.
* Import lands a draft, never a live automation, and leaves credentials blank on purpose. A recipe this site cannot run — because a step belongs to the add-on, or the neighbouring plugin is not active — says so in words and offers no button, instead of a greyed-out one with no explanation.
* The AI "Draft the flow" button now quotes its price before the click: it spends 3 Forge credits, and the number comes from the shared price map rather than being typed into the screen. The recipe library next to it costs nothing.
* A human in the middle of a flow. The Pro add-on gains a "Wait for approval" step: the run pauses, one person gets an e-mail with an Approve link and a Reject link, and the flow continues from exactly where it paused as soon as they click. Later steps can read the decision, who made it and when.
* The links work once and stop working when the request expires. Only a hash of the link's token is ever stored, so the database never holds a working approve-this-run link.
* You choose what silence means. If nobody answers before the timeout — 24 hours unless you say otherwise — the run is rejected, approved or stopped, whichever the step was set to. The default is rejection: silence is not consent.
* A run can never get past an approval step without a decision. If something wakes a paused run early, it stops instead of walking through a gate nobody opened.
* A Failed view on the Runs screen, in the free plugin. A run that has used up its retries now shows the step it stopped on, the error, and a preview of the payload it was carrying — with anything that looks like a token, key or password blanked out, the same way the "Test this flow" report blanks them.
* "Retry from failed step", per run and free. It writes a new run that starts on the step that failed, with the original payload, so the steps that already succeeded are not run a second time. The failed run is kept exactly as it was, and the new one records which run it came from.
* A retry is refused if the flow has been edited since the run failed, because the step it stopped on is then no longer that step. The add-on adds "retry all failed runs of this flow" for when an API was down all night.
* New trigger: "a run was dead-lettered". A flow of your own can now react when another flow gives up — page someone, open a ticket, post to a channel. It carries the run, the flow, the step and the error, it fires once per failed run, and a flow can never be started by its own failure.
* A step whose HTTP response is 401 or 403 always dead-letters the run now, even one set to continue past a failure — the credential is what needs fixing, and continuing anyway used to read as though nothing had gone wrong.

= 1.4.0 =
* Flows that start on a clock. "Schedule — every N seconds" runs a flow on an interval; "Schedule — at a time of day" runs it at, say, 09:00 on Monday, Wednesday and Friday. Times are read in the site's own timezone, not UTC, so 09:00 means 09:00 where the site is.
* Missed schedules do not pile up. If wp-cron has been down for a week, a daily flow runs once when it comes back, not seven times, and an occurrence that a whole period has already passed over is abandoned rather than delivered late. On a site whose wp-cron does not run at all, a fallback catches up on ordinary page loads.
* Enabling a scheduled flow after today's time has passed waits for the next occurrence instead of firing immediately.
* A trigger for any WordPress hook. Settings gains an allow-list: write the hook name a plugin fires, give it a label, and it appears in the trigger picker like any other event. The hook's arguments arrive in the payload — objects are recorded as their class and id only, never unpacked, so a hook that happens to carry a user or an order cannot write private data into a run.
* Hooks that fire on every page load are refused, a watched hook can start at most twenty runs per request, and the list holds at most twenty hooks. Watching `init` should not be able to take a site down.
* Both are Cascade Forge Pro triggers and require the add-on, version 1.3.0 or newer. Older add-ons keep working; they simply do not offer them.
* Run history is pruned at last. The Log retention setting has been on the Settings screen since the first release and nothing enforced it, so every run and every run step Cascade Forge had ever written was still in the database. A daily clean-up now removes finished runs older than the retention window, along with their step detail, in batches — a site with years of history catches up over a few nights instead of timing out and never finishing.
* Nothing the clean-up could damage is touched: a run still executing, and a run parked on a Wait step, are kept however old they are, and so is the most recent run of every flow — a scheduled flow uses that row to know it has already fired, and removing it would send the same digest twice.
* Deleting a flow now removes the canvas layout that was saved with it, instead of leaving one unreadable row behind per deleted flow.

= 1.3.0 =
* Flow history and rollback. Every save of a flow — from the form editor, from the canvas, or from an AI recipe — records what the flow's definition was at that moment: its trigger, the trigger parameters, the conditions and the ordered steps. A History screen on each flow lists them with who saved each one and when, and one button puts any of them back.
* Restoring is never destructive. The definition you are replacing is written to the history first, so a rollback can itself be rolled back. The flow's name and its enabled/disabled state are deliberately left alone — restoring an old draft must not switch off an automation that is live now.
* The Runs screen now shows which version of a flow each run actually executed, linked to that stored definition. A run that was queued before an edit and executed after it records the version whose steps it really ran, not the one it was queued under.
* The fifty most recent versions of a flow are kept. Sites that want a different depth can change it with the `flowforge/flow_version_history` filter.
* Test this flow. A button on the flow editor and on the flows list walks a saved flow against the trigger's sample payload — or one you paste — and reports which condition rules matched and what value each of them actually saw, then, step by step, the exact request, message, option, meta, term or user each step would produce. Nothing is sent, written or created and no run is recorded.
* The preview runs the real step handlers, not a description of them, so what it reports is what a live run does. Every side effect is held back at a single gateway rather than being simulated in a second copy of the engine that could drift.
* A step is only ever previewed if the plugin that provides it has said its effects can be held back. Steps from other plugins are reported as not previewable and are never called — a step your site's own developer wrote can opt in by adding `'simulatable' => true` to its registration once every side effect it causes goes through FLOWFORGE_Effects.
* Credentials are masked in the report, including where they sit inside a URL or a request body.
* Requires Cascade Forge Pro 1.2.0 or newer. An older add-on's steps still work; they are reported as not previewable in a test.

= 1.2.0 =
* The Pro catalogue is no longer part of this download. Every Pro step and Pro event now ships in the Cascade Forge Pro add-on and registers itself when that add-on is installed — nothing here is a switched-off copy waiting for a licence.
* All seven WooCommerce triggers and the outbound webhook action are Free. They used to require Pro while their code shipped here anyway.
* The numeric caps are gone: no 3-flow limit, no 100-row history limit. How long run history is kept is the Settings → Log retention option, as before.
* FieldForge triggers, at last: "custom fields updated on a post" and "field group saved". FieldForge has emitted both since 1.0; this catalogue never listened. The first is deliberately per post, not per field — FieldForge fires once for every field written, and a post with a dozen fields would otherwise start a dozen flow runs for one save.
* Sibling events fixed: LangForge translations and QA failures listen on the hooks LangForge actually emits, and the RankForge triggers use the `rankforge.` ids (flows saved under the old `seoforge.` ids keep working). The FormForge submission trigger fires on a submission instead of on a form being saved.
* One FormForge submission trigger, not two. The event briefly had a second name while its original trigger was on the wrong hook; the trigger list now offers a single entry, and saved flows are moved onto it on upgrade. A flow the upgrade could not move keeps firing either way.
* "Run a shell command" is removed from the action catalogue.
* Requires Cascade Forge Pro 1.1.0 or newer. An older add-on registers no steps; Cascade Forge now says so instead of failing the flow silently.

= 1.1.0 =
* Wait / delay steps now really wait. A flow paused on a wait step keeps a resume cursor, shows as "waiting" in Runs with the time it comes back, and continues from the next step when the pause is over — previously the step after a wait fired immediately.
* A run parked on a wait step is abandoned instead of resumed if its flow is edited meanwhile, so an edited flow can never make a half-finished run send the wrong message.
* Database upgrade to 1.1.0 (two new columns on the runs table). The upgrade is verified before it is recorded, so a migration that could not run is retried instead of being skipped forever.

= 1.0.1 =
* AI recipes: describe an automation and get a draft flow, validated against the triggers and actions this site actually has.

= 1.0.0 =
* Initial public release. WordPress.org Free core; Pro features delivered by the separate Cascade Forge Pro add-on.
