fengming 0.3.9 → 0.3.11

package/docs/automation/standing-orders.md

@@ -1,250 +0,0 @@
----
-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 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 plus 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
-fengming cron add \
-  --name daily-inbox-triage \
-  --cron "0 8 * * 1-5" \
-  --tz America/New_York \
-  --timeout-seconds 300 \
-  --announce \
-  --channel imessage \
-  --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 and 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 and 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     |
-```
-
-## 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
-## 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](/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/cron-jobs#webhooks): 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/taskflow.md

@@ -1,155 +0,0 @@
----
-summary: "Task Flow orchestration layer above background tasks"
-read_when:
-  - You want to understand how Task Flow relates to background tasks
-  - You encounter Task Flow or fengming tasks flow in release notes or docs
-  - You want to inspect or manage durable flow state
-title: "Task flow"
----
-
-Task Flow is the flow orchestration substrate that sits above [background tasks](/automation/tasks). It manages durable multi-step flows with their own state, revision tracking, and sync semantics while individual tasks remain the unit of detached work.
-
-## When to use Task Flow
-
-Use Task Flow when work spans multiple sequential or branching steps and you need durable progress tracking across gateway restarts. For single background operations, a plain [task](/automation/tasks) is sufficient.
-
-| Scenario                              | Use                  |
-| ------------------------------------- | -------------------- |
-| Single background job                 | Plain task           |
-| Multi-step pipeline (A then B then C) | Task Flow (managed)  |
-| Observe externally created tasks      | Task Flow (mirrored) |
-| One-shot reminder                     | Cron job             |
-
-## Reliable scheduled workflow pattern
-
-For recurring workflows such as market intelligence briefings, treat the schedule, orchestration, and reliability checks as separate layers:
-
-1. Use [Scheduled Tasks](/automation/cron-jobs) for timing.
-2. Use a persistent cron session when the workflow should build on prior context.
-3. Use [Lobster](/tools/lobster) for deterministic steps, approval gates, and resume tokens.
-4. Use Task Flow to track the multi-step run across child tasks, waits, retries, and gateway restarts.
-
-Example cron shape:
-
-```bash
-fengming cron add \
-  --name "Market intelligence brief" \
-  --cron "0 7 * * 1-5" \
-  --tz "America/New_York" \
-  --session session:market-intel \
-  --message "Run the market-intel Lobster workflow. Verify source freshness before summarizing." \
-  --announce \
-  --channel slack \
-  --to "channel:C1234567890"
-```
-
-Use `session:<id>` instead of `isolated` when the recurring workflow needs deliberate history, previous run summaries, or standing context. Use `isolated` when each run should start fresh and all required state is explicit in the workflow.
-
-Inside the workflow, put reliability checks before the LLM summary step:
-
-```yaml
-name: market-intel-brief
-steps:
-  - id: preflight
-    command: market-intel check --json
-  - id: collect
-    command: market-intel collect --json
-    stdin: $preflight.json
-  - id: summarize
-    command: market-intel summarize --json
-    stdin: $collect.json
-  - id: approve
-    command: market-intel deliver --preview
-    stdin: $summarize.json
-    approval: required
-  - id: deliver
-    command: market-intel deliver --execute
-    stdin: $summarize.json
-    condition: $approve.approved
-```
-
-Recommended preflight checks:
-
-- Browser availability and profile choice, for example `fengming` for managed state or `user` when a signed-in Chrome session is required. See [Browser](/tools/browser).
-- API credentials and quota for each source.
-- Network reachability for required endpoints.
-- Required tools enabled for the agent, such as `lobster`, `browser`, and `llm-task`.
-- Failure destination configured for cron so preflight failures are visible. See [Scheduled Tasks](/automation/cron-jobs#delivery-and-output).
-
-Recommended data provenance fields for every collected item:
-
-```json
-{
-  "sourceUrl": "https://example.com/report",
-  "retrievedAt": "2026-04-24T12:00:00Z",
-  "asOf": "2026-04-24",
-  "title": "Example report",
-  "content": "..."
-}
-```
-
-Have the workflow reject or mark stale items before summarization. The LLM step should receive only structured JSON and should be asked to preserve `sourceUrl`, `retrievedAt`, and `asOf` in its output. Use [LLM Task](/tools/llm-task) when you need a schema-validated model step inside the workflow.
-
-For reusable team or community workflows, package the CLI, `.lobster` files, and any setup notes as a skill or plugin and publish it through [ClawHub](/clawhub). Keep workflow-specific guardrails in that package unless the plugin API is missing a needed generic capability.
-
-## Sync modes
-
-### Managed mode
-
-Task Flow owns the lifecycle end-to-end. It creates tasks as flow steps, drives them to completion, and advances the flow state automatically.
-
-Example: a weekly report flow that (1) gathers data, (2) generates the report, and (3) delivers it. Task Flow creates each step as a background task, waits for completion, then moves to the next step.
-
-```
-Flow: weekly-report
-  Step 1: gather-data     → task created → succeeded
-  Step 2: generate-report → task created → succeeded
-  Step 3: deliver         → task created → running
-```
-
-### Mirrored mode
-
-Task Flow observes externally created tasks and keeps flow state in sync without taking ownership of task creation. This is useful when tasks originate from cron jobs, CLI commands, or other sources and you want a unified view of their progress as a flow.
-
-Example: three independent cron jobs that together form a "morning ops" routine. A mirrored flow tracks their collective progress without controlling when or how they run.
-
-## Durable state and revision tracking
-
-Each flow persists its own state and tracks revisions so progress survives gateway restarts. Revision tracking enables conflict detection when multiple sources attempt to advance the same flow concurrently.
-The flow registry uses SQLite with bounded write-ahead-log maintenance, including
-periodic and shutdown checkpoints, so long-running gateways do not retain
-unbounded `registry.sqlite-wal` sidecar files.
-
-## Cancel behavior
-
-`fengming tasks flow cancel` sets a sticky cancel intent on the flow. Active tasks within the flow are cancelled, and no new steps are started. The cancel intent persists across restarts, so a cancelled flow stays cancelled even if the gateway restarts before all child tasks have terminated.
-
-## CLI commands
-
-```bash
-# List active and recent flows
-fengming tasks flow list
-
-# Show details for a specific flow
-fengming tasks flow show <lookup>
-
-# Cancel a running flow and its active tasks
-fengming tasks flow cancel <lookup>
-```
-
-| Command                           | Description                                   |
-| --------------------------------- | --------------------------------------------- |
-| `fengming tasks flow list`        | Shows tracked flows with status and sync mode |
-| `fengming tasks flow show <id>`   | Inspect one flow by flow id or lookup key     |
-| `fengming tasks flow cancel <id>` | Cancel a running flow and its active tasks    |
-
-## How flows relate to tasks
-
-Flows coordinate tasks, not replace them. A single flow may drive multiple background tasks over its lifetime. Use `fengming tasks` to inspect individual task records and `fengming tasks flow` to inspect the orchestrating flow.
-
-## Related
-
-- [Background Tasks](/automation/tasks) — the detached work ledger that flows coordinate
-- [CLI: tasks](/cli/tasks) — CLI command reference for `fengming tasks flow`
-- [Automation Overview](/automation) — all automation mechanisms at a glance
-- [Cron Jobs](/automation/cron-jobs) — scheduled jobs that may feed into flows