Skip to content

Latest commit

 

History

History
82 lines (64 loc) · 3.72 KB

File metadata and controls

82 lines (64 loc) · 3.72 KB

The pipeline spec

One document declares a whole pipeline. It is safe to commit, paste into a ticket, or store in shared memory — because it never contains a secret, only vault references.

Schema

topic: competitor-launches        # kebab-case, one thread — the join point
goal: |                           # why this exists, in the user's own words
  Know within a day when a named competitor changes pricing or ships a feature,
  so positioning can respond in the same news cycle.

researchers:                      # 1..n, each blind to the others
  - id: pricing                   # kebab-case, unique within the topic
    runtime: hermes               # hermes | openclaw-hosted | claude-code | codex
    schedule: 24h                 # 15m | 1h | 6h | 24h | 7d
    sources: [competitor pricing pages, changelogs]
    lens: |                       # what this agent looks at, and how it judges
      Watch published pricing and packaging for the named competitors. Report only
      changes against the last note: what moved, by how much, effective when.

  - id: launches
    runtime: openclaw-hosted
    schedule: 24h
    sources: [company blog, release notes, press]
    lens: |
      Watch shipped-feature announcements. Report what shipped, who it targets, and
      which of our claims it weakens.

archiver:
  runtime: openclaw-hosted
  schedule: 24h
  offset: 30m                     # behind the researchers, so it has notes to merge
  validate: |                     # what counts as load-bearing
    Keep a finding only if it cites a primary source (vendor page, release note, filing).
    Drop anything sourced solely to commentary. Flag contradictions rather than resolving
    them silently.

storage:
  chain: 314159                   # Calibration testnet. 314 is mainnet — a deliberate act.
  copies: 1

Validation — all of it, before creating anything

Rule Why
topic is kebab-case and not already owned by another live spec Two pipelines on one topic corrupt each other's consolidation lineage
At least one researcher, and every id unique Cron names derive from <topic>-<id>
Every runtime is a registered agent (clawdi doctor Environments line) A spec naming an unregistered runtime creates a cron nothing will run
Every lens is specific enough to act on A vague lens files vague notes a hundred times
Researcher lenses are materially different from one another Identical lenses duplicate cost and produce no disagreement
archiver.offset is greater than zero An archiver that fires with the researchers merges nothing
storage.chain is 314159 unless a human explicitly confirmed mainnet Mainnet spends real USDFC
No key, token, or credential anywhere in the document The spec goes into shared memory

Report every failure at once. Create nothing until all of them pass.

The memory record

Instantiation stores the spec so the fleet is self-describing — any agent can answer "what is running?" without a filesystem.

PIPELINE-SPEC | topic: <topic> | tags: pipeline-spec,topic:<topic>,status:<live|retired> | created: <YYYY-MM-DD> | runtimes: <r1,r2,...> | schedules: <researchers=24h,archiver=24h+30m> | crons: <topic>-<id>,<topic>-archiver | goal: <one line> | spec: <the YAML above, inline>

Query it with clawdi memory search "PIPELINE-SPEC" --json.

Derived cron names

Names are derived, never invented — that is what makes instantiation idempotent and teardown possible:

<topic>-<researcher-id>     e.g. competitor-launches-pricing
<topic>-archiver            e.g. competitor-launches-archiver

Before creating, list existing crons and skip any name already present. Re-running an instantiate must be a no-op, not a duplicate.