@@ -38,8 +38,7 @@ metadata:
 
 ## Flows — Visual Logic Orchestration
 
-A **Flow** is a directed graph of nodes that execute sequentially or in
-parallel. Flows are the primary automation building block in ObjectStack.
+A **Flow** is a directed graph of nodes — the primary automation building block.
 
 ### Flow Types
 
@@ -53,8 +52,8 @@ parallel. Flows are the primary automation building block in ObjectStack.
 
 ### Flow Node Types
 
-Flows are built from **20 built-in node types** (the `FlowNodeAction` seed set —
-plugins register more via `registerNodeExecutor`, e.g. `approval` below):
+Flows are built from **20 built-in node types** (plugins register more via
+`registerNodeExecutor`, e.g. `approval` below):
 
 #### Control Flow
 
@@ -85,7 +84,7 @@ plugins register more via `registerNodeExecutor`, e.g. `approval` below):
 
 | Node | Purpose |
 |:-----|:--------|
-| `http` | Call an external HTTP API — canonical since protocol 11.0; `http_request` survives only as a deprecation-window alias |
+| `http` | Call an external HTTP API — always set `timeoutMs` (unset = no timeout). `url` and `headers` are served as written with the definition to every member who can read flows — only `signingSecret` and a start node's `secret` are withheld — so never a credential there. Route by shape — a header credential → a declarative connector (`bearer` / `basic` / `api-key`) with `auth.credentialRef`; a query-string key → `api-key` with `paramName`; a path-secret webhook url → a token-authenticated connector such as `slack` — called via `connector_action` |
 | `notify` | Send a notification through the messaging service (inbox channel by default) |
 | `connector_action` | Invoke a pre-built integration connector |
 | `script` | Call a **registered** function named by `config.function` (see *Valid-but-silently-wrong* #3) |
@@ -140,7 +139,7 @@ variables: [
 ],
 ```
 
-→ Moved verbatim to [references/examples-flows.md](./references/examples-flows.md) § Flow Example — Auto-Escalate Overdue Cases.
+→ Moved to [references/examples-flows.md](./references/examples-flows.md) § Flow Example — Auto-Escalate Overdue Cases.
 
 ### Failure routing & `runAs`
 
@@ -154,8 +153,6 @@ variables: [
 > replays the flow from the start — prefer a fault edge when the failure is
 > local. The handler reads `{<nodeId>.error}` (or run-wide `{$error}`). The run
 > then reports success, and the failed step stays in the trace.
->
-> **It is not a way past a guardrail.**
 
 | ROUTES (runtime failure) | Does NOT route (fatal either way) |
 |:--|:--|
@@ -221,9 +218,8 @@ a query instead of narrowing it.
 
 ## Valid-but-silently-wrong (passes build, fails at runtime)
 
-These are *legal* metadata that authors — AI especially — get wrong. Most are now
-caught by `objectstack build` (a hard error, or an advisory warning), but write
-them right the first time:
+Legal metadata that authors — AI especially — get wrong; most are caught by
+`objectstack build`, but write them right the first time:
 
 1. **Flow node VALUE interpolation uses SINGLE braces.** Value fields on a node's
    `config` (`fields`, `inputs`, notify `message`/`title`, …) interpolate
@@ -256,7 +252,7 @@ them right the first time:
    function fails loudly.
 
    There is no other dispatch form: use **`notify`** for delivery, a
-   **`connector_action`** or `http` webhook for Slack, a function for logic.
+   **`connector_action`** on the `slack` connector for Slack, a function for logic.
 
    **A flow `function` is a PURE compute step — it does NOT read/write the
    database.** It receives `ctx.input` and **returns** a value; `config.outputVariable`
@@ -309,17 +305,15 @@ them right the first time:
 
 ---
 
-→ State Machines & Approvals moved verbatim to [references/state-machines-and-approvals.md](./references/state-machines-and-approvals.md) (State Machine — a `state_machine` validation rule · Approvals (Flow Nodes) · Send-back for revision · Recording a decision · Approver Types · Dynamic approvers (`type: 'expression'`) · Node Config (`ApprovalNodeConfigSchema`) · Branching, side-effects & rejection · Approval Best Practices) — its state-introspection route is `GET /api/v1/meta/object/:name/state/:field?from=:state`.
+→ State Machines & Approvals moved to [references/state-machines-and-approvals.md](./references/state-machines-and-approvals.md) (State Machine — a `state_machine` validation rule · Approvals (Flow Nodes) · Send-back for revision · Recording a decision · Approver Types · Dynamic approvers (`type: 'expression'`) · Node Config (`ApprovalNodeConfigSchema`) · Branching, side-effects & rejection · Approval Best Practices) — its state-introspection route is `GET /api/v1/meta/object/:name/state/:field?from=:state`.
 
 ---
 
 ## Triggers — Event-Driven Automation
 
 A `record_change` flow fires automatically on a data event. There is **no
 standalone trigger object and no top-level `trigger` / `event` key** — the
-binding lives entirely in the flow's **`start` node `config`**, which the
-automation engine parses (`resolveTriggerBinding`) and wires to the matching
-ObjectQL lifecycle hook.
+binding lives entirely in the flow's **`start` node `config`**.
 
 ### Prerequisite — declare the capabilities your nodes need
 
@@ -396,27 +390,25 @@ owns `label`, `type`, `nodes` and the `edges` `FlowSchema` requires):
 > `record-before-*` flow that throws silently blocks the write — give it a
 > user-facing message.
 
-> **`previous`** and **`record`** are the CEL variables available in update
-> triggers — `previous.x` is the value before the change, `record.x` is the
-> value after. See [objectstack-formula](../objectstack-formula/SKILL.md).
+> `previous` (before the change) vs `record` (after) in an update trigger's
+> condition: see [objectstack-formula](../objectstack-formula/SKILL.md) §5.
 
-→ Moved verbatim to [references/examples-flows.md](./references/examples-flows.md) § Time-relative triggers — scheduled per-record date sweep.
+→ Moved to [references/examples-flows.md](./references/examples-flows.md) § Time-relative triggers — scheduled per-record date sweep.
 
 ---
 
 ## CRM Automation Blueprint
 
-For enterprise automation design, align with this CRM-style structure:
+Default approach for metadata apps — model the business lifecycle in
+Flow/Approval metadata first, reserve custom code for edge-case integrations —
+in this CRM-style structure:
 
 | Automation Type | Typical Location | Pattern |
 |:--|:--|:--|
 | Screen flow | `src/flows/*.flow.ts` | Use explicit `variables`, node graph (`nodes` + `edges`), and decision branches |
 | Approval flow | `src/flows/*.flow.ts` | A flow with `approval` node(s); set `approvers` / `behavior` / `lockRecord` / `approvalStatusField` in node `config`, branch on `approve` / `reject` edges |
 | Flow registry | `src/flows/index.ts` | Export `allFlows: Flow[]` and register centrally in `defineStack({ flows })` |
 
-Default approach for metadata apps: model business lifecycle in Flow/Approval
-metadata first; reserve custom code for edge-case integrations.
-
 ---
 
 ## Verify your work
@@ -432,7 +424,7 @@ os validate     # CEL/predicate validation (record.<field> existence) + schema
 ```
 
 It runs the ADR-0032 gate over every condition, edge guard, validation and
-sharing rule, exiting non-zero. In a scaffolded project: `npm run validate`.
+sharing rule. In a scaffolded project: `npm run validate`.
 
 ---
 
@@ -441,8 +433,7 @@ sharing rule, exiting non-zero. In a scaffolded project: `npm run validate`.
 The send-back shape has a graded eval at
 [evals/approvals/test-revise-loop.md](./evals/approvals/test-revise-loop.md).
 
-See [references/_index.md](./references/_index.md) for the full list of Zod
-schemas (with one-line descriptions) — pointers into
-`node_modules/@objectstack/spec/src/`. Always `Read` the source for exact field
-shapes; do not rely on memory of property names.
+See [references/_index.md](./references/_index.md) for the Zod schemas (one-line
+descriptions, pointers into `node_modules/@objectstack/spec/src/`). Always `Read`
+the source for exact field shapes; do not rely on memory of property names.
 
@@ -26,10 +26,8 @@ export const EscalateOverdueCasesFlow = defineFlow({
       id: 'start',
       type: 'start',
       label: 'Daily at 09:00',
-      // The cadence lives HERE, on the start node's config — FlowSchema has NO
-      // top-level `schedule` key (one there is a named parse error, not a silent
-      // strip). A bare cron string also works: schedule: '0 9 * * *'. Do NOT use
-      // the cron`…` tagged template — its envelope is not a recognized shape.
+      // The cadence lives HERE — FlowSchema has NO top-level `schedule` key (a
+      // named parse error). A bare cron string also works; a cron`…` tag does not.
       config: { schedule: { type: 'cron', expression: '0 9 * * *' } },
     },
     {
@@ -38,7 +36,6 @@ export const EscalateOverdueCasesFlow = defineFlow({
       label: 'Escalate Overdue Cases',
       config: {
         objectName: 'support_case',
-        // which rows to update — `filter` is a `where` map, not filter triples
         filter: {
           status: { $in: ['new', 'open'] },
           due_date: { $lt: '{TODAY()}' },   // template token → today's date at run time
@@ -49,13 +46,15 @@ export const EscalateOverdueCasesFlow = defineFlow({
     },
     {
       id: 'notify_manager',
-      type: 'http',
+      type: 'connector_action',
       label: 'Notify Manager',
-      config: {
-        url: 'https://hooks.slack.com/services/...',
-        method: 'POST',
-        body: { text: 'Escalated overdue support cases.' },
-        timeoutMs: 10000,   // unset = NO timeout at all — always set one
+      // NOT an `http` node with a Slack webhook url: the definition (`url` and
+      // `headers` included) is served to every member who can read flows. The
+      // `slack` connector (@objectstack/connector-slack) holds the bot token.
+      connectorConfig: {
+        connectorId: 'slack',
+        actionId: 'chat.postMessage',
+        input: { channel: '#support-leads', text: 'Escalated overdue support cases.' },
       },
     },
     { id: 'end', type: 'end', label: 'End' },