Jose Montes de Oca
14e6854dfa
Several docs referenced paths and deployment internals that only exist in our authoring workspace, not in this repo. Clean them up so external readers get a self-contained view. - skills/README.md, skills/open-prose/state/README.md: drop `related:` frontmatter entries that pointed outside the repo tree; refer to "OpenProse Cloud" by name instead of an internal path. - skills/open-prose/agent-onboarding.md: replace a 25-line maintainer comment (infra paths, deploy mechanic) with a single link to the canonical rendering at https://openprose.ai/llms-full.txt. This file is served verbatim as llms-full.txt, so the comment was publicly visible but only meaningful to hosting maintainers. - rfcs/004-composite-instantiation.md: drop two pointers to an external design doc — the RFC is already self-contained (Summary, Problem, Proposal, Architecture, Changes, Prior Art). - rfcs/001/002/003: normalize author line to match rfcs/004's format (`Dan B. (OpenProse)`). Docs only — no behavior changes.
2.9 KiB
RFC 001: Scheduled Execution Syntax
Status: Proposed Date: 2026-04-08 Author: Dan B. (OpenProse)
Problem
Programs declare their intended cadence in comments and documentation (e.g., "Daily (7am)", "Weekly (Monday 8am)"), but there is no formal syntax in the Prose language for expressing execution schedules. The cadence information is scattered across:
- Program descriptions ("runs daily")
- Delivery composite comments ("Cadence: Weekly (Monday 7am)")
- Customer-facing demo pages ("Next radar delivers Friday at 8am")
- Lead planning documents
This means the runtime (Press) cannot automatically schedule programs — scheduling is a manual configuration step outside the language.
Scenarios Where This Matters
-
Customer delivery composites: Every delivery composite we've written (e.g.,
deal-radar-weekly.md,energy-monitor-daily.md,startup-gtm-daily.md) expresses a cadence in its name and description but has no machine-readable schedule. -
Eval cadences: Evals should run after every program run, but the "run eval after program" relationship is implicit.
-
Portfolio monitoring: Programs like
portfolio-pulsethat monitor a set of companies weekly need a formal "run every Monday at 8am" declaration. -
Customer onboarding: When setting up a new customer, the schedule is communicated verbally and configured manually. A
schedule:field in the program frontmatter would make the intended cadence part of the program definition.
Proposed Solution
Add an optional schedule: field to program frontmatter:
---
name: deal-radar-weekly
kind: program
services: [deal-flow-radar, human-gate, slack-notifier]
schedule:
cron: "0 8 * * 5" # Fridays at 8am
timezone: "America/Los_Angeles"
description: "Weekly deal flow radar, delivered Friday mornings"
---
Or with named cadences for common patterns:
schedule:
cadence: daily
at: "07:00"
timezone: "America/New_York"
schedule:
cadence: weekly
day: monday
at: "08:00"
timezone: "America/Los_Angeles"
Design Considerations
- The
schedule:field is metadata for the runtime, not executed by the VM. The VM runs programs when invoked — it doesn't watch clocks. The runtime (Press) reads the schedule from the program definition and manages the cron/trigger. - Programs without
schedule:are on-demand only (e.g., due-diligence-memo runs when a company name is provided). schedule:should coexist with event-driven triggers (future RFC).- The
description:subfield ensures the human-readable cadence stays in sync with the cron expression.
Impact
This would affect:
prose.md— document the schedule field in frontmatterforme.md— Forme should include schedule in the manifest so the runtime can read it- Press runtime — implement cron-based invocation
- All existing delivery composites would benefit from adding
schedule:to their frontmatter