vora-ai 0.1.0

package/docs/automation/index.md

@@ -0,0 +1,69 @@
+---
+summary: "Overview of all automation mechanisms: heartbeat, cron, tasks, hooks, webhooks, and more"
+read_when:
+  - Deciding how to automate work with Vora
+  - Choosing between heartbeat, cron, hooks, and webhooks
+  - Looking for the right automation entry point
+title: "Automation Overview"
+---
+
+# Automation
+
+Vora provides several automation mechanisms, each suited to different use cases. This page helps you choose the right one.
+
+## Quick decision guide
+
+```mermaid
+flowchart TD
+    A{Run on a schedule?} -->|Yes| B{Exact timing needed?}
+    A -->|No| C{React to events?}
+    B -->|Yes| D[Cron]
+    B -->|No| E[Heartbeat]
+    C -->|Yes| F[Hooks]
+    C -->|No| G[Standing Orders]
+```
+
+## Mechanisms at a glance
+
+| Mechanism                                      | What it does                                             | Runs in                  | Creates task record |
+| ---------------------------------------------- | -------------------------------------------------------- | ------------------------ | ------------------- |
+| [Heartbeat](/gateway/heartbeat)                | Periodic main-session turn — batches multiple checks     | Main session             | No                  |
+| [Cron](/automation/cron-jobs)                  | Scheduled jobs with precise timing                       | Main or isolated session | Yes (all types)     |
+| [Background Tasks](/automation/tasks)          | Tracks detached work (cron, ACP, subagents, CLI)         | N/A (ledger)             | N/A                 |
+| [Hooks](/automation/hooks)                     | Event-driven scripts triggered by agent lifecycle events | Hook runner              | No                  |
+| [Standing Orders](/automation/standing-orders) | Persistent instructions injected into the system prompt  | Main session             | No                  |
+| [Webhooks](/automation/webhook)                | Receive inbound HTTP events and route to the agent       | Gateway HTTP             | No                  |
+
+### Specialized automation
+
+| Mechanism                                      | What it does                                    |
+| ---------------------------------------------- | ----------------------------------------------- |
+| [Gmail PubSub](/automation/gmail-pubsub)       | Real-time Gmail notifications via Google PubSub |
+| [Polling](/automation/poll)                    | Periodic data source checks (RSS, APIs, etc.)   |
+| [Auth Monitoring](/automation/auth-monitoring) | Credential health and expiry alerts             |
+
+## How they work together
+
+The most effective setups combine multiple mechanisms:
+
+1. **Heartbeat** handles routine monitoring (inbox, calendar, notifications) in one batched turn every 30 minutes.
+2. **Cron** handles precise schedules (daily reports, weekly reviews) and one-shot reminders.
+3. **Hooks** react to specific events (tool calls, session resets, compaction) with custom scripts.
+4. **Standing Orders** give the agent persistent context ("always check the project board before replying").
+5. **Background Tasks** automatically track all detached work so you can inspect and audit it.
+6. **ClawFlow** groups related detached tasks into a single flow when the work needs a higher-level job view.
+
+See [Cron vs Heartbeat](/automation/cron-vs-heartbeat) for a detailed comparison of the two scheduling mechanisms.
+
+## ClawFlow
+
+ClawFlow sits above [Background Tasks](/automation/tasks). Tasks still track the detached runs, while ClawFlow groups related task runs into one job that you can inspect or cancel from the CLI.
+
+See [ClawFlow](/automation/clawflow) for the flow overview and [CLI: flows](/cli/flows) for the command surface.
+
+## Related
+
+- [Cron vs Heartbeat](/automation/cron-vs-heartbeat) — detailed comparison guide
+- [ClawFlow](/automation/clawflow) — flow-level orchestration above tasks
+- [Troubleshooting](/automation/troubleshooting) — debugging automation issues
+- [Configuration Reference](/gateway/configuration-reference) — all config keys

package/docs/automation/poll.md

@@ -0,0 +1,86 @@
+---
+summary: "Poll sending via gateway + CLI"
+read_when:
+  - Adding or modifying poll support
+  - Debugging poll sends from the CLI or gateway
+title: "Polls"
+---
+
+# Polls
+
+## Supported channels
+
+- Telegram
+- WhatsApp (web channel)
+- Discord
+- Microsoft Teams (Adaptive Cards)
+
+## CLI
+
+```bash
+# Telegram
+vora message poll --channel telegram --target 123456789 \
+  --poll-question "Ship it?" --poll-option "Yes" --poll-option "No"
+vora message poll --channel telegram --target -1001234567890:topic:42 \
+  --poll-question "Pick a time" --poll-option "10am" --poll-option "2pm" \
+  --poll-duration-seconds 300
+
+# WhatsApp
+vora message poll --target +15555550123 \
+  --poll-question "Lunch today?" --poll-option "Yes" --poll-option "No" --poll-option "Maybe"
+vora message poll --target 123456789@g.us \
+  --poll-question "Meeting time?" --poll-option "10am" --poll-option "2pm" --poll-option "4pm" --poll-multi
+
+# Discord
+vora message poll --channel discord --target channel:123456789 \
+  --poll-question "Snack?" --poll-option "Pizza" --poll-option "Sushi"
+vora message poll --channel discord --target channel:123456789 \
+  --poll-question "Plan?" --poll-option "A" --poll-option "B" --poll-duration-hours 48
+
+# Microsoft Teams
+vora message poll --channel msteams --target conversation:19:abc@thread.tacv2 \
+  --poll-question "Lunch?" --poll-option "Pizza" --poll-option "Sushi"
+```
+
+Options:
+
+- `--channel`: `whatsapp` (default), `telegram`, `discord`, or `msteams`
+- `--poll-multi`: allow selecting multiple options
+- `--poll-duration-hours`: Discord-only (defaults to 24 when omitted)
+- `--poll-duration-seconds`: Telegram-only (5-600 seconds)
+- `--poll-anonymous` / `--poll-public`: Telegram-only poll visibility
+
+## Gateway RPC
+
+Method: `poll`
+
+Params:
+
+- `to` (string, required)
+- `question` (string, required)
+- `options` (string[], required)
+- `maxSelections` (number, optional)
+- `durationHours` (number, optional)
+- `durationSeconds` (number, optional, Telegram-only)
+- `isAnonymous` (boolean, optional, Telegram-only)
+- `channel` (string, optional, default: `whatsapp`)
+- `idempotencyKey` (string, required)
+
+## Channel differences
+
+- Telegram: 2-10 options. Supports forum topics via `threadId` or `:topic:` targets. Uses `durationSeconds` instead of `durationHours`, limited to 5-600 seconds. Supports anonymous and public polls.
+- WhatsApp: 2-12 options, `maxSelections` must be within option count, ignores `durationHours`.
+- Discord: 2-10 options, `durationHours` clamped to 1-768 hours (default 24). `maxSelections > 1` enables multi-select; Discord does not support a strict selection count.
+- Microsoft Teams: Adaptive Card polls (Vora-managed). No native poll API; `durationHours` is ignored.
+
+## Agent tool (Message)
+
+Use the `message` tool with `poll` action (`to`, `pollQuestion`, `pollOption`, optional `pollMulti`, `pollDurationHours`, `channel`).
+
+For Telegram, the tool also accepts `pollDurationSeconds`, `pollAnonymous`, and `pollPublic`.
+
+Use `action: "poll"` for poll creation. Poll fields passed with `action: "send"` are rejected.
+
+Note: Discord has no “pick exactly N” mode; `pollMulti` maps to multi-select.
+Teams polls are rendered as Adaptive Cards and require the gateway to stay online
+to record votes in `~/.vora/msteams-polls.json`.

package/docs/automation/standing-orders.md

@@ -0,0 +1,254 @@
+---
+summary: "Define permanent operating authority for autonomous agent programs"
+read_when:
+  - Setting up autonomous agent workflows that run without per-task prompting
+  - Defining what the agent can do independently vs. what needs human approval
+  - Structuring multi-program agents with clear boundaries and escalation rules
+title: "Standing Orders"
+---
+
+# Standing Orders
+
+Standing orders grant your agent **permanent operating authority** for defined programs. Instead of giving individual task instructions each time, you define programs with clear scope, triggers, and escalation rules — and the agent executes autonomously within those boundaries.
+
+This is the difference between telling your assistant "send the weekly report" every Friday vs. granting standing authority: "You own the weekly report. Compile it every Friday, send it, and only escalate if something looks wrong."
+
+## Why Standing Orders?
+
+**Without standing orders:**
+
+- You must prompt the agent for every task
+- The agent sits idle between requests
+- Routine work gets forgotten or delayed
+- You become the bottleneck
+
+**With standing orders:**
+
+- The agent executes autonomously within defined boundaries
+- Routine work happens on schedule without prompting
+- You only get involved for exceptions and approvals
+- The agent fills idle time productively
+
+## How They Work
+
+Standing orders are defined in your [agent workspace](/concepts/agent-workspace) files. The recommended approach is to include them directly in `AGENTS.md` (which is auto-injected every session) so the agent always has them in context. For larger configurations, you can also place them in a dedicated file like `standing-orders.md` and reference it from `AGENTS.md`.
+
+Each program specifies:
+
+1. **Scope** — what the agent is authorized to do
+2. **Triggers** — when to execute (schedule, event, or condition)
+3. **Approval gates** — what requires human sign-off before acting
+4. **Escalation rules** — when to stop and ask for help
+
+The agent loads these instructions every session via the workspace bootstrap files (see [Agent Workspace](/concepts/agent-workspace) for the full list of auto-injected files) and executes against them, combined with [cron jobs](/automation/cron-jobs) for time-based enforcement.
+
+<Tip>
+Put standing orders in `AGENTS.md` to guarantee they're loaded every session. The workspace bootstrap automatically injects `AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md`, and `MEMORY.md` — but not arbitrary files in subdirectories.
+</Tip>
+
+## Anatomy of a Standing Order
+
+```markdown
+## Program: Weekly Status Report
+
+**Authority:** Compile data, generate report, deliver to stakeholders
+**Trigger:** Every Friday at 4 PM (enforced via cron job)
+**Approval gate:** None for standard reports. Flag anomalies for human review.
+**Escalation:** If data source is unavailable or metrics look unusual (>2σ from norm)
+
+### Execution Steps
+
+1. Pull metrics from configured sources
+2. Compare to prior week and targets
+3. Generate report in Reports/weekly/YYYY-MM-DD.md
+4. Deliver summary via configured channel
+5. Log completion to Agent/Logs/
+
+### What NOT to Do
+
+- Do not send reports to external parties
+- Do not modify source data
+- Do not skip delivery if metrics look bad — report accurately
+```
+
+## Standing Orders + Cron Jobs
+
+Standing orders define **what** the agent is authorized to do. [Cron jobs](/automation/cron-jobs) define **when** it happens. They work together:
+
+```
+Standing Order: "You own the daily inbox triage"
+    ↓
+Cron Job (8 AM daily): "Execute inbox triage per standing orders"
+    ↓
+Agent: Reads standing orders → executes steps → reports results
+```
+
+The cron job prompt should reference the standing order rather than duplicating it:
+
+```bash
+vora cron add \
+  --name daily-inbox-triage \
+  --cron "0 8 * * 1-5" \
+  --tz America/New_York \
+  --timeout-seconds 300 \
+  --announce \
+  --channel bluebubbles \
+  --to "+1XXXXXXXXXX" \
+  --message "Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns."
+```
+
+## Examples
+
+### Example 1: Content & Social Media (Weekly Cycle)
+
+```markdown
+## Program: Content & Social Media
+
+**Authority:** Draft content, schedule posts, compile engagement reports
+**Approval gate:** All posts require owner review for first 30 days, then standing approval
+**Trigger:** Weekly cycle (Monday review → mid-week drafts → Friday brief)
+
+### Weekly Cycle
+
+- **Monday:** Review platform metrics and audience engagement
+- **Tuesday–Thursday:** Draft social posts, create blog content
+- **Friday:** Compile weekly marketing brief → deliver to owner
+
+### Content Rules
+
+- Voice must match the brand (see SOUL.md or brand voice guide)
+- Never identify as AI in public-facing content
+- Include metrics when available
+- Focus on value to audience, not self-promotion
+```
+
+### Example 2: Finance Operations (Event-Triggered)
+
+```markdown
+## Program: Financial Processing
+
+**Authority:** Process transaction data, generate reports, send summaries
+**Approval gate:** None for analysis. Recommendations require owner approval.
+**Trigger:** New data file detected OR scheduled monthly cycle
+
+### When New Data Arrives
+
+1. Detect new file in designated input directory
+2. Parse and categorize all transactions
+3. Compare against budget targets
+4. Flag: unusual items, threshold breaches, new recurring charges
+5. Generate report in designated output directory
+6. Deliver summary to owner via configured channel
+
+### Escalation Rules
+
+- Single item > $500: immediate alert
+- Category > budget by 20%: flag in report
+- Unrecognizable transaction: ask owner for categorization
+- Failed processing after 2 retries: report failure, do not guess
+```
+
+### Example 3: Monitoring & Alerts (Continuous)
+
+```markdown
+## Program: System Monitoring
+
+**Authority:** Check system health, restart services, send alerts
+**Approval gate:** Restart services automatically. Escalate if restart fails twice.
+**Trigger:** Every heartbeat cycle
+
+### Checks
+
+- Service health endpoints responding
+- Disk space above threshold
+- Pending tasks not stale (>24 hours)
+- Delivery channels operational
+
+### Response Matrix
+
+| Condition        | Action                   | Escalate?                |
+| ---------------- | ------------------------ | ------------------------ |
+| Service down     | Restart automatically    | Only if restart fails 2x |
+| Disk space < 10% | Alert owner              | Yes                      |
+| Stale task > 24h | Remind owner             | No                       |
+| Channel offline  | Log and retry next cycle | If offline > 2 hours     |
+```
+
+## The Execute-Verify-Report Pattern
+
+Standing orders work best when combined with strict execution discipline. Every task in a standing order should follow this loop:
+
+1. **Execute** — Do the actual work (don't just acknowledge the instruction)
+2. **Verify** — Confirm the result is correct (file exists, message delivered, data parsed)
+3. **Report** — Tell the owner what was done and what was verified
+
+```markdown
+### Execution Rules
+
+- Every task follows Execute-Verify-Report. No exceptions.
+- "I'll do that" is not execution. Do it, then report.
+- "Done" without verification is not acceptable. Prove it.
+- If execution fails: retry once with adjusted approach.
+- If still fails: report failure with diagnosis. Never silently fail.
+- Never retry indefinitely — 3 attempts max, then escalate.
+```
+
+This pattern prevents the most common agent failure mode: acknowledging a task without completing it.
+
+## Multi-Program Architecture
+
+For agents managing multiple concerns, organize standing orders as separate programs with clear boundaries:
+
+```markdown
+# Standing Orders
+
+## Program 1: [Domain A] (Weekly)
+
+...
+
+## Program 2: [Domain B] (Monthly + On-Demand)
+
+...
+
+## Program 3: [Domain C] (As-Needed)
+
+...
+
+## Escalation Rules (All Programs)
+
+- [Common escalation criteria]
+- [Approval gates that apply across programs]
+```
+
+Each program should have:
+
+- Its own **trigger cadence** (weekly, monthly, event-driven, continuous)
+- Its own **approval gates** (some programs need more oversight than others)
+- Clear **boundaries** (the agent should know where one program ends and another begins)
+
+## Best Practices
+
+### Do
+
+- Start with narrow authority and expand as trust builds
+- Define explicit approval gates for high-risk actions
+- Include "What NOT to do" sections — boundaries matter as much as permissions
+- Combine with cron jobs for reliable time-based execution
+- Review agent logs weekly to verify standing orders are being followed
+- Update standing orders as your needs evolve — they're living documents
+
+### Avoid
+
+- Grant broad authority on day one ("do whatever you think is best")
+- Skip escalation rules — every program needs a "when to stop and ask" clause
+- Assume the agent will remember verbal instructions — put everything in the file
+- Mix concerns in a single program — separate programs for separate domains
+- Forget to enforce with cron jobs — standing orders without triggers become suggestions
+
+## Related
+
+- [Automation Overview](/automation) — all automation mechanisms at a glance
+- [Cron Jobs](/automation/cron-jobs) — schedule enforcement for standing orders
+- [Hooks](/automation/hooks) — event-driven scripts for agent lifecycle events
+- [Webhooks](/automation/webhook) — inbound HTTP event triggers
+- [Agent Workspace](/concepts/agent-workspace) — where standing orders live, including the full list of auto-injected bootstrap files (AGENTS.md, SOUL.md, etc.)

package/docs/automation/tasks.md

@@ -0,0 +1,247 @@
+---
+summary: "Background task tracking for ACP runs, subagents, isolated cron jobs, and CLI operations"
+read_when:
+  - Inspecting background work in progress or recently completed
+  - Debugging delivery failures for detached agent runs
+  - Understanding how background runs relate to sessions, cron, and heartbeat
+title: "Background Tasks"
+---
+
+# Background Tasks
+
+> **Cron vs Heartbeat vs Tasks?** See [Cron vs Heartbeat](/automation/cron-vs-heartbeat) for choosing the right scheduling mechanism. This page covers **tracking** background work, not scheduling it.
+
+Background tasks track work that runs **outside your main conversation session**:
+ACP runs, subagent spawns, isolated cron job executions, and CLI-initiated operations.
+
+Tasks do **not** replace sessions, cron jobs, or heartbeats — they are the **activity ledger** that records what detached work happened, when, and whether it succeeded.
+
+<Note>
+Not every agent run creates a task. Heartbeat turns and normal interactive chat do not. All cron executions, ACP spawns, subagent spawns, and CLI agent commands do.
+</Note>
+
+## TL;DR
+
+- Tasks are **records**, not schedulers — cron and heartbeat decide _when_ work runs, tasks track _what happened_.
+- ACP, subagents, all cron jobs, and CLI operations create tasks. Heartbeat turns do not.
+- Each task moves through `queued → running → terminal` (succeeded, failed, timed_out, cancelled, or lost).
+- Completion notifications are delivered directly to a channel or queued for the next heartbeat.
+- `vora tasks list` shows all tasks; `vora tasks audit` surfaces issues.
+- Terminal records are kept for 7 days, then automatically pruned.
+
+## Quick start
+
+```bash
+# List all tasks (newest first)
+vora tasks list
+
+# Filter by runtime or status
+vora tasks list --runtime acp
+vora tasks list --status running
+
+# Show details for a specific task (by ID, run ID, or session key)
+vora tasks show <lookup>
+
+# Cancel a running task (kills the child session)
+vora tasks cancel <lookup>
+
+# Change notification policy for a task
+vora tasks notify <lookup> state_changes
+
+# Run a health audit
+vora tasks audit
+```
+
+## What creates a task
+
+| Source                 | Runtime type | When a task record is created                          | Default notify policy |
+| ---------------------- | ------------ | ------------------------------------------------------ | --------------------- |
+| ACP background runs    | `acp`        | Spawning a child ACP session                           | `done_only`           |
+| Subagent orchestration | `subagent`   | Spawning a subagent via `sessions_spawn`               | `done_only`           |
+| Cron jobs (all types)  | `cron`       | Every cron execution (main-session and isolated)       | `silent`              |
+| CLI operations         | `cli`        | `vora agent` commands that run through the gateway | `done_only`           |
+
+Main-session cron tasks use `silent` notify policy by default — they create records for tracking but do not generate notifications. Isolated cron tasks also default to `silent` but are more visible because they run in their own session.
+
+**What does not create tasks:**
+
+- Heartbeat turns — main-session; see [Heartbeat](/gateway/heartbeat)
+- Normal interactive chat turns
+- Direct `/command` responses
+
+## Task lifecycle
+
+```mermaid
+stateDiagram-v2
+    [*] --> queued
+    queued --> running : agent starts
+    running --> succeeded : completes ok
+    running --> failed : error
+    running --> timed_out : timeout exceeded
+    running --> cancelled : operator cancels
+    queued --> lost : session gone > 5 min
+    running --> lost : session gone > 5 min
+```
+
+| Status      | What it means                                                              |
+| ----------- | -------------------------------------------------------------------------- |
+| `queued`    | Created, waiting for the agent to start                                    |
+| `running`   | Agent turn is actively executing                                           |
+| `succeeded` | Completed successfully                                                     |
+| `failed`    | Completed with an error                                                    |
+| `timed_out` | Exceeded the configured timeout                                            |
+| `cancelled` | Stopped by the operator via `vora tasks cancel`                        |
+| `lost`      | Backing child session disappeared (detected after a 5-minute grace period) |
+
+Transitions happen automatically — when the associated agent run ends, the task status updates to match.
+
+## Delivery and notifications
+
+When a task reaches a terminal state, Vora notifies you. There are two delivery paths:
+
+**Direct delivery** — if the task has a channel target (the `requesterOrigin`), the completion message goes straight to that channel (Telegram, Discord, Slack, etc.).
+
+**Session-queued delivery** — if direct delivery fails or no origin is set, the update is queued as a system event in the requester's session and surfaces on the next heartbeat.
+
+<Tip>
+Task completion triggers an immediate heartbeat wake so you see the result quickly — you do not have to wait for the next scheduled heartbeat tick.
+</Tip>
+
+### Notification policies
+
+Control how much you hear about each task:
+
+| Policy                | What is delivered                                                       |
+| --------------------- | ----------------------------------------------------------------------- |
+| `done_only` (default) | Only terminal state (succeeded, failed, etc.) — **this is the default** |
+| `state_changes`       | Every state transition and progress update                              |
+| `silent`              | Nothing at all                                                          |
+
+Change the policy while a task is running:
+
+```bash
+vora tasks notify <lookup> state_changes
+```
+
+## CLI reference
+
+### `tasks list`
+
+```bash
+vora tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]
+```
+
+Output columns: Task ID, Kind, Status, Delivery, Run ID, Child Session, Summary.
+
+### `tasks show`
+
+```bash
+vora tasks show <lookup>
+```
+
+The lookup token accepts a task ID, run ID, or session key. Shows the full record including timing, delivery state, error, and terminal summary.
+
+### `tasks cancel`
+
+```bash
+vora tasks cancel <lookup>
+```
+
+For ACP and subagent tasks, this kills the child session. Status transitions to `cancelled` and a delivery notification is sent.
+
+### `tasks notify`
+
+```bash
+vora tasks notify <lookup> <done_only|state_changes|silent>
+```
+
+### `tasks audit`
+
+```bash
+vora tasks audit [--json]
+```
+
+Surfaces operational issues. Findings also appear in `vora status` when issues are detected.
+
+| Finding                   | Severity | Trigger                                               |
+| ------------------------- | -------- | ----------------------------------------------------- |
+| `stale_queued`            | warn     | Queued for more than 10 minutes                       |
+| `stale_running`           | error    | Running for more than 30 minutes                      |
+| `lost`                    | error    | Backing session is gone                               |
+| `delivery_failed`         | warn     | Delivery failed and notify policy is not `silent`     |
+| `missing_cleanup`         | warn     | Terminal task with no cleanup timestamp               |
+| `inconsistent_timestamps` | warn     | Timeline violation (for example ended before started) |
+
+## Status integration (task pressure)
+
+`vora status` includes an at-a-glance task summary:
+
+```
+Tasks: 3 queued · 2 running · 1 issues
+```
+
+The summary reports:
+
+- **active** — count of `queued` + `running`
+- **failures** — count of `failed` + `timed_out` + `lost`
+- **byRuntime** — breakdown by `acp`, `subagent`, `cron`, `cli`
+
+## Storage and maintenance
+
+### Where tasks live
+
+Task records persist in SQLite at:
+
+```
+$VORA_STATE_DIR/tasks/runs.sqlite
+```
+
+The registry loads into memory at gateway start and syncs writes to SQLite for durability across restarts.
+
+### Automatic maintenance
+
+A sweeper runs every **60 seconds** and handles three things:
+
+1. **Reconciliation** — checks if active tasks' backing sessions still exist. If a child session has been gone for more than 5 minutes, the task is marked `lost`.
+2. **Cleanup stamping** — sets a `cleanupAfter` timestamp on terminal tasks (endedAt + 7 days).
+3. **Pruning** — deletes records past their `cleanupAfter` date.
+
+**Retention**: terminal task records are kept for **7 days**, then automatically pruned. No configuration needed.
+
+## How tasks relate to other systems
+
+### Tasks and ClawFlow
+
+ClawFlow is the flow layer above tasks. A flow groups one or more task runs into a single job, owns the parent session context, and gives you a higher-level control surface for blocked or multi-step work.
+
+See [ClawFlow](/automation/clawflow) for the flow overview and [CLI: flows](/cli/flows) for the command surface.
+
+### Tasks and cron
+
+A cron job **definition** lives in `~/.vora/cron/jobs.json`. **Every** cron execution creates a task record — both main-session and isolated. Main-session cron tasks default to `silent` notify policy so they track without generating notifications.
+
+See [Cron Jobs](/automation/cron-jobs).
+
+### Tasks and heartbeat
+
+Heartbeat runs are main-session turns — they do not create task records. When a task completes, it can trigger a heartbeat wake so you see the result promptly.
+
+See [Heartbeat](/gateway/heartbeat).
+
+### Tasks and sessions
+
+A task may reference a `childSessionKey` (where work runs) and a `requesterSessionKey` (who started it). Sessions are conversation context; tasks are activity tracking on top of that.
+
+### Tasks and agent runs
+
+A task's `runId` links to the agent run doing the work. Agent lifecycle events (start, end, error) automatically update the task status — you do not need to manage the lifecycle manually.
+
+## Related
+
+- [Automation Overview](/automation) — all automation mechanisms at a glance
+- [ClawFlow](/automation/clawflow) — job-level orchestration above tasks
+- [Cron Jobs](/automation/cron-jobs) — scheduling background work
+- [Cron vs Heartbeat](/automation/cron-vs-heartbeat) — choosing the right mechanism
+- [Heartbeat](/gateway/heartbeat) — periodic main-session turns
+- [CLI: flows](/cli/flows) — flow inspection and control commands
+- [CLI: Tasks](/cli/index#tasks) — CLI command reference