okengine 0.18.4 → 0.19.0

package/site/content/docs/elements/channel.mdx

@@ -1,346 +0,0 @@
----
-title: "Channel"
-description: "Reaching humans — email, SMS, WhatsApp, and push with consent, locale, receipts, and fallback chains built in."
-icon: "Mail"
-source: "docs/spec/unified-theory.md"
----
-
-Channel is how your app **reaches humans**: the order-confirmation email, the OTP text, the WhatsApp notification. Reaching a person is not the same problem as moving data between machines — it needs consent (did they opt out?), locale (which language?), receipts (did it land?), and fallback (first driver failed, try the next). Those physics are built into the element, so every flow gets them for free.
-
-<Callout title="The one rule">
-  Sends go through `fx.send` and declared templates — never through a raw SMTP or provider client
-  inside a flow. That is what makes consent, locale, and receipts unavoidable rather than optional.
-</Callout>
-
-## Quick start
-
-<Steps>
-
-<Step>
-### Declare a medium and a template
-
-A medium binder carries your defaults; a template names the message and types its data:
-
-```typescript title="src/channels.ts"
-import { channel } from "okengine";
-import { z } from "zod";
-
-export const mail = channel.email({ from: "Provisions <no-reply@provisions.sa>" });
-
-export const orderConfirmed = mail.template("order-confirmed", {
-  schema: z.object({ name: z.string(), orderId: z.string(), total: z.number() }),
-  locales: ["en", "ar"],
-});
-```
-
-</Step>
-
-<Step>
-### Send it from a Flow
-
-One call — consent, locale resolution, and the receipt happen around it:
-
-```typescript title="src/flows/orders/confirm.ts"
-do: async (input, fx) => {
-  await fx.send(orderConfirmed, {
-    to: input.email,
-    data: { name: input.name, orderId: input.id, total: input.total },
-  });
-};
-```
-
-</Step>
-
-<Step>
-### Read it in development
-
-Under `oke test` the `console` driver captures mail into an inbox instead of sending; under `oke
-dev` Compose runs **Mailpit**, a real SMTP catcher with a web UI — so you see the exact rendered
-message without ever touching a real mailbox.
-
-</Step>
-
-</Steps>
-
-## Mediums and templates
-
-| Declaration                    | Produces                                        |
-| ------------------------------ | ----------------------------------------------- |
-| `channel.email({ from })`      | Email binder (default sender)                   |
-| `channel.sms({ sender })`      | SMS binder (sender id)                          |
-| `channel.whatsapp()`           | WhatsApp binder                                 |
-| `channel.push()`               | Push binder                                     |
-| `binder.template(name, opts)`  | Typed template bound to that medium             |
-| `channel.template(name, opts)` | Medium-agnostic template (one body, any medium) |
-
-| Template option | Type                  | Meaning                                                    |
-| --------------- | --------------------- | ---------------------------------------------------------- |
-| `description`   | string                | Human title in the Console (falls back to the template id) |
-| `schema`        | zod / Standard Schema | The data the template may reference — typed sends          |
-| `locales`       | string[]              | Languages this template is rendered in                     |
-
-## The human physics
-
-<ChannelPhysics />
-
-### Consent and hard-bounce suppression
-
-Opt-out is first-class: a subject who opted out of a medium is **suppressed** — the send resolves without contacting the provider, and the receipt status is `suppressed/opted-out`.
-
-Hard bounces are protective too. After a provider outcome of `hard-bounce` is ingested, the address is auto-added to suppression; the **next** send to that address is blocked before any transport runs (`suppressed/prior-bounce`). Soft bounces and complaints do **not** auto-suppress.
-
-```typescript
-// After a provider webhook (or Console ingest):
-runtime.ingestOutcome({
-  messageId,
-  state: "hard-bounce",
-  to: user.email,
-  medium: "email",
-});
-// Next fx.send / runtime.send to that address → ok: false, driverId: "suppression"
-```
-
-**Known limit:** default suppression, consent, and receipt stores are **process-local memory**. Opt-out / hard-bounce / receipt on replica A is invisible to replica B. Boot prints a one-shot warning when those defaults are used.
-
-### Inject shared stores (multi-instance workaround)
-
-Until a durable driver ships, inject your own stores that implement the same surfaces — boot skips the process-local warn when both `suppression` and `receipts` are provided:
-
-```typescript
-import { createConsentStore, createReceiptLedger, createSuppressionStore } from "okengine";
-
-const consent = createConsentStore(); // or a wrapper over shared storage
-const suppression = createSuppressionStore({ consent });
-const receipts = createReceiptLedger();
-
-await app.boot({
-  channel: { suppression, receipts /* templates, catalog, drivers… */ },
-});
-```
-
-`consent` alone is wrapped into the default suppression store when `suppression` is omitted. Prefer passing `suppression` when you share bounce + opt-out state.
-
-### Locale resolves, then the catalog
-
-`fx.send` picks a locale: explicit `locale` → `profileLocale` → first
-`Accept-Language` tag → `defaultLocale`. The body is the catalog entry for
-that exact key, else the default locale, else `en`.
-
-Locales come from `oke.config.ts` `i18n`. Catalog bodies use `{{field}}` — not
-ICU ([i18n](/docs/reference/i18n) / `fx.t` owns flow copy). Pass `locale` /
-`profileLocale` / `acceptLanguage` on `fx.send`, or omit them for `fx.locale`.
-
-```typescript
-// Catalog (template → locale → body)
-{
-  "order-confirmed": {
-    en: { subject: "Order {{orderId}}", text: "Hello {{name}}" },
-    ar: { subject: "طلب {{orderId}}", text: "مرحبًا {{name}}" },
-  },
-}
-// locale: "ar" + data { name: "علي", orderId: "ORD-42" }
-// → subject "طلب ORD-42", text "مرحبًا علي"
-```
-
-**Consequence:** `Accept-Language: ar-SA` does **not** match a catalog key named `ar`. Provide both keys, or send `locale: "ar"`.
-
-### Fallback chains are same-medium
-
-`via` orders **driver ids** for the template's medium — first success wins,
-and **every** attempt is recorded:
-
-```typescript
-await fx.send(orderConfirmed, {
-  to: user.email,
-  data: { name, orderId, total },
-  via: ["smtp", "resend"],
-});
-// smtp provider-error → resend tried → receipt status "fallback"
-```
-
-Permanent client errors do **not** advance the chain (invalid address, HTTP
-400/401/403) — the same distinction OTP cross-medium delivery uses. A provider
-timeout or 5xx does failover.
-
-### Receipt ledger
-
-Each send records attempts — driver, ok/error, timestamp, message id — so "did
-the user get it?" is a Console query. Dry run: kernel records a would-have-fired
-send and never opens a provider — no Channel receipt.
-
-| Status                            | Meaning                                       |
-| --------------------------------- | --------------------------------------------- |
-| `sent`                            | Delivered on the first successful driver      |
-| `fallback`                        | Earlier drivers failed; a later one succeeded |
-| `suppressed/opted-out`            | Consent blocked the send (no provider call)   |
-| `suppressed/prior-bounce`         | Prior hard bounce blocked the send            |
-| `blocked/invalid-address`         | Permanent client error (no useful failover)   |
-| `hard-bounce` / `soft-bounce` / … | Post-send outcomes via `ingestOutcome`        |
-
-### WhatsApp: template vs session (Known gap)
-
-WhatsApp Business allows free-form ("session") messages only inside a
-customer-initiated **24h** window; outside that window you must send a
-pre-approved **template**.
-
-OKE drivers choose payload shape by whether a template name is present on the
-message (`template` / `data.template` → template API; otherwise free text).
-
-There is **no** session-window clock or gate on the Channel runtime today.
-Sending free-form outside the window risks provider rejection or account
-action — handle that yourself until a real design ships.
-
-OTP WhatsApp paths often send free text via provider failover.
-
-## Per-environment drivers
-
-Boot opens the email driver from `drivers.channel.email`, and appends an SMS
-driver when `drivers.channel.sms` is set (other than `console`). WhatsApp and
-push drivers are passed via `BootOptions.channel.drivers` when you need them.
-
-```typescript title="oke.config.ts"
-drivers: {
-  channel: {
-    email: { dev: "smtp", test: "console", prod: "smtp" },
-    // optional — omit until you need SMS at boot
-    sms: { test: "console", prod: "taqnyat" },
-  },
-},
-images: {
-  channel: { email: "axllent/mailpit:v1.30.7" },
-},
-```
-
-| Driver         | Medium   | Behavior                                                            |
-| -------------- | -------- | ------------------------------------------------------------------- |
-| `console`      | any      | Captures into a readable inbox — tests                              |
-| `smtp`         | email    | Real SMTP — Mailpit under `oke dev`, your provider in prod          |
-| `resend`       | email    | Resend HTTP API (`RESEND_API_KEY`)                                  |
-| `sndr`         | email    | SNDR HTTP API (`SNDR_API_KEY`)                                      |
-| `taqnyat-mail` | email    | Taqnyat Mail API (`TAQNYAT_MAIL_TOKEN` + `TAQNYAT_CAMPAIGN`)        |
-| `taqnyat`      | sms      | Taqnyat SMS (`TAQNYAT_BEARER_TOKEN` + `TAQNYAT_SENDER`)             |
-| `msegat`       | sms      | Msegat SMS (`MSEGAT_USERNAME` + `MSEGAT_API_KEY` + `MSEGAT_SENDER`) |
-| `unifonic`     | sms      | Unifonic el.cloud SMS (`UNIFONIC_APPSID`)                           |
-| `wa-cloud`     | whatsapp | Meta WhatsApp Cloud API                                             |
-| `webpush`      | push     | Web Push + VAPID (`createPushSender` → `WebPushTransport`)          |
-| `fcm`          | push     | Firebase Cloud Messaging HTTP v1                                    |
-
-Email fallback uses ordered email transports; SMS with multiple SMS drivers uses
-the same failover path. Credentials for boot-opened drivers are listed under
-[Environment Variables](/docs/reference/environment-variables).
-
-### Provider OTP (`fx.sendOtp` / `fx.verifyOtp`)
-
-Flows can send a provider-generated SMS code with `fx.sendOtp({ to, requestId, lang? })`
-and check it with `fx.verifyOtp({ to, requestId, code })` — Taqnyat's Verify API. Both are
-capability-gated `send` effects and dry-run safe. No `.plug()` required.
-
-They dispatch only when the bound SMS driver supports Verify (`taqnyat`); any other SMS
-driver fails loudly instead of silently falling back to a self-generated code.
-
-[OTP](/docs/plugins/otp) in provider mode is the full auth feature built on this same
-path (routes, sessions, rates). Custom shape? Call `fx.sendOtp` / `fx.verifyOtp` in
-your own flow — skipping the plugin does not drop the provider connection.
-
-`webpush` needs VAPID keys — open it yourself and include it in
-`BootOptions.channel.drivers` (boot does not open push from env):
-
-```typescript
-import { openWebPushChannel } from "okengine/drivers/channel-webpush";
-
-openWebPushChannel({
-  vapidPublicKey: process.env.VAPID_PUBLIC_KEY!,
-  vapidPrivateKey: process.env.VAPID_PRIVATE_KEY!,
-  vapidSubject: process.env.VAPID_SUBJECT,
-});
-```
-
-## Troubleshooting
-
-<Accordions>
-<Accordion title="I sent an email in dev but nothing arrived">
-
-Nothing _should_ arrive — the `console` driver captures mail instead of sending. Read the dev inbox, or run `oke dev` and open Mailpit's web UI to see the rendered message.
-
-</Accordion>
-<Accordion title="A user says they stopped receiving messages">
-
-Check consent first: if they opted out, sends to them are suppressed by design. After a hard bounce, later sends are `suppressed/prior-bounce` without contacting the provider. The Console shows the suppression on the receipt — it is a delivered-as-intended outcome, not a bug.
-
-</Accordion>
-<Accordion title="Opt-out on replica A, still sending on replica B">
-
-Default stores are process-local. Inject shared `suppression` + `receipts` on boot (see above), or run a single Channel consumer, until a durable driver ships.
-
-</Accordion>
-<Accordion title="Primary failed with invalid address and didn't try secondary">
-
-By design. Permanent client errors (invalid address, HTTP 400/401/403) do not failover — every provider would reject the same address. Provider outages and 5xx do advance the chain.
-
-</Accordion>
-<Accordion title="The Arabic version didn't render">
-
-The send still succeeds: the body falls back to your default locale, then `en`, when the catalog misses that exact key. Check that an Arabic entry exists under the same tag you send (`ar` vs `ar-SA`) and that the template lists it in `locales`. Catalog interpolation is `{{field}}` only — ICU plurals live in [i18n](/docs/reference/i18n).
-
-</Accordion>
-<Accordion title="How do I ingest SNDR / Unifonic delivery webhooks?">
-
-```typescript
-import {
-  parseSndrWebhook,
-  verifySndrSignature,
-  parseUnifonicWebhook,
-  toDeliveryEvent,
-} from "okengine/channel";
-```
-
-Verify the signature when the provider sends one, parse the body, then call
-`ingestOutcome` on your channel runtime with the bounce/complaint fields.
-
-Hard bounce auto-adds suppression. Console reads the receipt ledger — never
-raw webhook JSON.
-
-</Accordion>
-<Accordion title="How do I know which driver finally delivered?">
-
-The receipt keeps every attempt in order with its outcome. A send that succeeded on a later driver reports status `fallback` — you can see the full chain in Console → Flows (Traces).
-
-</Accordion>
-<Accordion title="How do I verify Web Push against a real browser?">
-
-Subscribe in a real browser with sently’s `examples/webpush-interop` page
-(paste the same `VAPID_PUBLIC_KEY`), copy the `PushSubscription` JSON, then:
-
-```sh
-export VAPID_PUBLIC_KEY='…'
-export VAPID_PRIVATE_KEY='…'
-bun scripts/webpush-interop.ts /tmp/push-sub.json
-```
-
-That path is Channel → `webpush` → sently `createPushSender` →
-`WebPushTransport`, and it prints the push-service HTTP response.
-
-Confirm a visible OS notification titled `okengine webpush interop`.
-
-</Accordion>
-</Accordions>
-
-## Learn more
-
-- [Project structure](/docs/get-started/project-structure) — `flow({…})` names as `unit.export`; explicit `flow("unit.action")` still wins
-- [Flow](/docs/elements/flow) — `fx.send` inside `do`
-- [Environment Variables](/docs/reference/environment-variables) — Channel boot credentials
-- [Configuration](/docs/reference/configuration) — `drivers.channel.*` maps
-- [i18n](/docs/reference/i18n) — ICU / `fx.t` vs Channel `{{field}}` catalogs
-- [Signal](/docs/elements/signal) — machine-to-machine messaging, the other side of the line
-
-## Next
-
-<Cards>
-  <Card title="AI" description="Continue to AI." href="/docs/elements/ai" />
-  <Card
-    title="Introduction"
-    description="Eight elements overview."
-    href="/docs/get-started/introduction"
-  />
-</Cards>

package/site/content/docs/elements/clock.mdx

@@ -1,244 +0,0 @@
----
-title: "Clock"
-description: "Time — recurring schedules, intervals, and durable sleeps as first-class declarations, not a bolted-on cron library."
-icon: "Clock"
-source: "docs/spec/unified-theory.md"
----
-
-Clock is how your app deals with **time**: cleanup jobs that run every hour, reports due at 9am Riyadh time, a flow that pauses for seven days and wakes up even after a deploy. There is no separate scheduler to install — a schedule is a trigger, and the flow it fires is the same species as every other flow.
-
-<Callout title="The one rule">
-  Flow code never calls `Date.now()` — it asks `fx.clock.now()`. Time is injected, which makes it
-  deterministic in tests and auditable in traces.
-</Callout>
-
-## Quick start
-
-<Steps>
-
-<Step>
-### Fire a flow on an interval
-
-The simplest schedule is an anonymous interval trigger:
-
-```typescript title="src/flows/links/purge.ts"
-import { on, flow, every } from "okengine";
-
-export const purgeOld = on(
-  every("1h"),
-  flow("links.purgeOld", {
-    do: async (_, fx) => {
-      const cutoff = fx.clock.ago("30d");
-      await fx.store(db).delete(links).where(lt(links.createdAt, cutoff));
-    },
-  }),
-);
-```
-
-</Step>
-
-<Step>
-### Or declare a named schedule
-
-A named `clock()` shows up in the Console, supports cron expressions and timezones, and can be paused or retuned at runtime:
-
-```typescript title="src/clocks.ts"
-import { clock } from "okengine";
-
-export const dailyReport = clock("daily-report", {
-  cron: "0 9 * * *", // 09:00
-  timezone: "Asia/Riyadh",
-  overridable: true, // the Console may edit this schedule
-});
-```
-
-Import the module before `oke()` — named clocks auto-register. No `oke({ clocks })` list.
-
-```typescript title="src/flows/reports/daily.ts"
-export const sendDaily = on(
-  dailyReport,
-  flow("reports.sendDaily", {
-    do: async (_, fx) => {
-      /* … */
-    },
-  }),
-);
-```
-
-</Step>
-
-<Step>
-### Ask for time inside flows
-
-`fx.clock` is the only clock a flow knows. Instants stay epoch-ms; spans use the same
-duration strings as `every()` and `sleep()`:
-
-```typescript
-do: async (input, fx) => {
-  const cutoff = fx.clock.ago("30d");
-  const expiresAt = fx.clock.fromNow("14d");
-  const window = input.createdAt + fx.clock.duration("7d");
-  await fx.clock.sleep("wait-for-payment", "7d");
-};
-```
-
-</Step>
-
-</Steps>
-
-## Two kinds of schedules
-
-<ClockSchedules />
-
-Both are triggers consumed with the same `on(trigger, flow)` — the flow underneath does not know the
-difference.
-
-### `clock()` options
-
-| Option        | Type    | Default | Meaning                                                                                                                  |
-| ------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------ |
-| `cron`        | string  | —       | Five-field crontab (`m h dom mon dow`), plus steps, ranges, lists, names, `@hourly`, `@daily` (this or `every` required) |
-| `every`       | string  | —       | Fixed interval: `"30s"` · `"10m"` · `"1h"` · `"7d"`                                                                      |
-| `timezone`    | string  | `"UTC"` | IANA timezone for cron evaluation                                                                                        |
-| `overridable` | boolean | `false` | Allow the Console to **edit** the schedule (pause is separate)                                                           |
-| `description` | string  | —       | Human title in the Console (falls back to the clock name)                                                                |
-| `perTenant`   | boolean | `false` | Expand to one `oke_crons` row per tenant (`{name}#{tenantId}`). Prefer `clock.perTenant(name, opts)`                     |
-
-<Callout title="Per-tenant clocks never tick the template">
-  Bind `on(clock.perTenant("invoices", { every: "1h" }), flow(...))`. Rows are `invoices#acme`;
-  tenant create/delete adds or orphans them. Fire stamps `fx.tenant.id`.
-</Callout>
-
-### `fx.clock`
-
-| Call                 | Returns | Meaning                                          |
-| -------------------- | ------- | ------------------------------------------------ |
-| `now()`              | instant | Injected epoch-ms                                |
-| `ago("30d")`         | instant | now − duration                                   |
-| `fromNow("14d")`     | instant | now + duration                                   |
-| `duration("7d")`     | span ms | Offset a stored instant (`createdAt + duration`) |
-| `sleep(label, "7d")` | —       | Durable sleep                                    |
-
-Same duration strings as `every()`: `"200ms"` · `"30s"` · `"2m"` · `"1h"` · `"7d"`. A `"d"` is 86_400_000 ms, not a calendar day. Unknown strings parse as `0`.
-
-## Sleeping inside a flow
-
-<ClockSleep />
-
-`fx.clock.sleep(label, duration)` is a **durable** sleep: in a `durable: true` flow the wake time is
-journaled — with a shared journal (`drivers.journal: "postgres"`) the flow resumes after restarts and
-deploys; the `memory` default resumes within the same process only. The `label` names the step — the Console shows it on sleeping runs.
-
-In a non-durable flow the same call resolves immediately, so code reads identically in tests.
-
-Completed journal steps never re-run on resume — with a shared journal, a process killed mid-flow is
-reclaimed after its lease expires and continues at the next unfinished step.
-
-## What the runtime guarantees
-
-<ClockCatchUp />
-
-| Guarantee          | What it means                                                                                      |
-| ------------------ | -------------------------------------------------------------------------------------------------- |
-| Leader election    | Instances that share one CronStore fire a given tick once (lease TTL, default 30s)                 |
-| Process identity   | Boot mints one `instanceId` (`inst-<okid>`) for Clock, Journal, and the fleet registry             |
-| Catch-up `"one"`   | Health counts every missed slot; the runtime still fires **once** when overdue — not once per miss |
-| Reconciled at boot | Named clocks land in `oke_crons`; the scheduler reads the Store, not the source                    |
-| DST detection      | Ambiguous local times get a Console warning — schedules are not rewritten or blocked               |
-
-**Leader election needs a shared store.** The default in-memory CronStore is per process. Multi-replica
-exclusivity holds when every instance opens the same durable CronStore — `postgres` (SKIP LOCKED +
-lease reclaim, `dev`/`prod` default) or `file` (shared volume, single-host).
-
-**Catch-up example:** an hourly clock down for five hours reports `missedRuns: 5` and
-`catchUp: "one"`, then a single tick runs the handler once.
-
-## DST warnings (detect only)
-
-Simple daily crons (`M H * * *`) in a DST-observing zone can hit a **gap** (spring forward — local time skipped) or an **overlap** (fall back — local time occurs twice).
-
-Detection attaches `dstAmbiguity` on the cron row and the Console shows it. `oke doctor` does not check DST. The scheduler does not rewrite the expression.
-
-**Consequence:** firing follows crontab. A spring gap runs at the next valid instant (shifted). A fall overlap fires **once** (first occurrence). Prefer UTC when a shifted spring fire would hurt.
-
-## Per-environment drivers
-
-```typescript title="oke.config.ts"
-drivers: {
-  clock: { dev: "postgres", test: "frozen", prod: "postgres" },
-},
-```
-
-| Driver     | Behavior                                                                                      |
-| ---------- | --------------------------------------------------------------------------------------------- |
-| `memory`   | In-process CronStore + timers — single process; lost on exit                                  |
-| `postgres` | Postgres CronStore (`oke_crons`) — multi-host leader election via SKIP LOCKED + lease reclaim |
-| `file`     | On-disk CronStore (`.oke/crons.json`) — multi-process on a shared volume (single-host)        |
-| `frozen`   | Deterministic test clock — time advances only when the test says so                           |
-
-`frozen` is why the no-`Date.now()` rule pays off: tests inject time travel through `fx.clock` and every flow obeys it automatically.
-
-## Operating schedules from the Console
-
-The Console (`:6533` → `/flows`) lists clock-triggered flows in the cron / every bands.
-
-Named clocks still carry health — drift, overdue, missed runs + catch-up `"one"`, and the lease holder.
-
-`/observability` adds an Instances chip from `GET /console/instances` (alive ⇔ presence TTL not expired). A cron lease holder is not a fleet census.
-
-From there you can **pause** any cron, **wake early** a sleeping durable run, or **edit the schedule** when `overridable: true`. Edit on a locked clock throws `ScheduleNotOverridableError` (`clock "…" is not overridable`).
-
-## Troubleshooting
-
-<Accordions>
-<Accordion title="I used Date.now() and tests are flaky">
-
-Replace it with `fx.clock.now()`. Direct time calls bypass the injected clock, so the `frozen` test driver cannot control them — that is exactly the class of bug the rule exists to remove.
-
-</Accordion>
-<Accordion title="The server was down and the cron didn't catch up">
-
-That is by design: catch-up policy is `"one"` — the schedule fires a single time after downtime, never a storm of one-run-per-missed-tick. Health still shows how many slots were missed. If you genuinely need backfill, trigger the flow from the Console.
-
-</Accordion>
-<Accordion title="Console won't let me edit a schedule">
-
-The clock was declared without `overridable: true`. Add it and redeploy — the restriction is deliberate, so only schedules you marked as operator-tunable can drift from code. Pause does not require `overridable`.
-
-</Accordion>
-<Accordion title="How do I run something once, later — not recurring?">
-
-Emit it from inside a flow with `fx.clock.sleep(label, duration)` before the work, in a `durable: true` flow. The sleep survives restarts on a shared journal, so "remind me in 7 days" is one line, not a cron row.
-
-</Accordion>
-<Accordion title="Two replicas both ran my cron">
-
-They are not sharing one CronStore. In-memory leases are per process. Point every replica at the same
-`postgres` CronStore (`DATABASE_URL`), or use `file` on a shared volume for single-host multi-process.
-
-</Accordion>
-<Accordion title="Observability says no fleet">
-
-The registry is off in `test` and when there is no shared SQL URL. `dev`/`prod` write `oke_instances` on the same Postgres as Clock. Unbound is empty — not `0 alive`.
-
-</Accordion>
-</Accordions>
-
-## Learn more
-
-- [Project structure](/docs/get-started/project-structure) — clock flows in the tree get a name, never a URL
-- [Flow](/docs/elements/flow) — `on(trigger, flow)` and the `fx` surface
-- [Gate](/docs/elements/gate) — `clock.perTenant` when `gate.auth.tenant` is on
-- [fx · Runs](/docs/reference/fx#runs-observability-read) — native SLO checkers via `on(every(…))` + `fx.runs`
-- [Signal](/docs/elements/signal) — reacting to events instead of time
-
-## Next
-
-<Cards>
-  <Card title="Gate" description="Continue to Gate." href="/docs/elements/gate" />
-  <Card
-    title="Introduction"
-    description="Eight elements overview."
-    href="/docs/get-started/introduction"
-  />
-</Cards>