Agent View · Agent · Schedules

Schedules — the dynamic schedule surface

Design specification, displayed honestly: UNTRUSTED — routines still run on embedded prompts; replacement prompts are proposed-only files; no versioned operating contract is installed. This site displays the design; it does not claim installation. This page is the site's own schedule surface — what the clock does, what aims it, and the rules that stop blank reports.

Timezone: Europe/London (cron expressions are local-time; intended UTC stored per occurrence so DST cannot shift identity). gap Unproven from platform settings (DV-C4) — recorded as a gap until verified

Master cron table

Anchors kept deliberately: the :55 hour (every artefact is keyed to it), the 17:15 close, the 08:55/14:55 windows with 90-minute deadlines. The rogue :30 momentum clock is eliminated — its work became queue items. One authoritative work clock: fyj-hourly-slot.

R1 · fyj-hourly-slot · 55 * * * *

Purpose. The single authoritative work clock: load state → version check → reconcile in-flight → evaluate windows → select highest-priority authorised work → execute → diff → assess → update → rescore.

Occurrence identity: hourly@{intended UTC instant}
Reads: state snapshot, active schedule, live queue, operating contract version, in-flight runs, window records, steering inbox
Writes: one agent record (always) + exactly one of: new artefact + state diff / blocked record / escalation; queue scores; Activity event; notification intent
Write ownership: owns queue/live.json and the state snapshot (others write via compare-and-swap)

Anti-blank-report rule: At least one of (a) new artefact + semantic diff, (b) blocked record with unblock condition + owner + next evaluation, (c) escalation. 'File written' is not an output class.

R2 · fyj-daily-close · 15 17 * * *

Purpose. Score the half-open period [prev 17:15, this 17:15) — the 24 expected :55 occurrences; answer the two standing questions; record pending work, missed slots, late completions, window outcomes, learning-vs-transfer verdict.

Occurrence identity: close@{intended local date}
Reads: the 24 occurrence records, contribution assessments, window records, queue, snapshot
Writes: one immutable dated close record per intended period + latest pointer; per-slot dispositions; Activity event; close notification decision
Write ownership: owns closes/* only; reads hourly outputs, never writes them

Anti-blank-report rule: A close record for its own intended period even if the content is 'all 24 slots missed'. A close that silently merges two periods is a failed close.

R3 · fyj-decision-window-open · 55 8,14 * * *

Purpose. Open the founder decision window: one question, sent once, with sent-time and 90-minute deadline recorded.

Occurrence identity: decision-open@{date}-{morning|afternoon}
Reads: snapshot, last cycle outcomes, open steering objects
Writes: durable window record; notification (decision requests are never deduped); Founder-input update
Write ownership: owns decisions/windows/* with R4

Anti-blank-report rule: The window record itself; idempotent on occurrence identity — re-fire updates, never duplicates.

R4 · fyj-decision-window-deadline · 25 10,16 * * *

Purpose. Scheduler-driven deadline evaluation (replaces in-prompt 90-minute sleeping): accept reply, or record proceeded-without-input; a reply after the deadline applies at the next planning boundary — never a retroactive rewrite.

Occurrence identity: decision-deadline@{date}-{morning|afternoon}
Reads: the matching window record; reply channel state
Writes: resolved window record (evaluation time distinguished from deadline); queue hold released; Activity event; notification decision
Write ownership: owns decisions/windows/* with R3

Anti-blank-report rule: An explicit evaluation record per window: answered / proceeded-without-input / answered-after-deadline. 'No evaluation ran' is itself a defect surfaced at close.

R5 · fyj-overnight-record · (phase of the 07:55 R1 occurrence — not a separate cron)

Purpose. Produce the dated Overnight page for the night that just ended: listed / expected / ran / missed / backfilled separated; useful learning distinguished from volume.

Occurrence identity: overnight@{night-of date}
Reads: the night's occurrence records + contribution assessments
Writes: dated Overnight page + index update; missed hours become recoverable dependency states; Activity event. Backfill path: the next slot writes the page marked with intended AND actual times.
Write ownership: the 07:55 R1 occurrence

Anti-blank-report rule: One dated page per night including quiet nights; a hole in the record is a defect, never silently skipped (c0cbf4d7).

R6 · fyj-meta-scheduler · 30 17 * * * + inline at the end of any slot that fires a replanning trigger + on founder-steering receipt

Purpose. The schedule that updates the schedules: reads close findings, trigger evidence and scores; rewrites the schedule manifest and queue order toward the current highest-priority work.

Occurrence identity: meta@{close date} or meta@{triggering occurrence}
Reads: close record, trigger records (T1–T4), queue scores, snapshot, steering, contract version
Writes: new versioned schedules/active.json + queue (with diff + reason in Activity); meta-run receipt
Write ownership: owns schedules/active.json only; may never create a new clock

Anti-blank-report rule: A manifest version + diff, or an explicit 'no change justified' receipt naming the scores that did not move. Never a silent pass.

The current priority queue — scores computed, not asserted

score = w1·unmet-requirement + w2·uncertainty-reduction + w3·founder-steering + w4·staleness − w5·blocked-dependency − w6·saturation. Weights: w1=1, w2=1, w3=1, w4=1, w5=1, w6=1. Initial weights equal (schedule spec §7: start equal; tuned only by the meta-scheduler with logged reasons). Scores on the schedules page are computed at build time from these weights and the per-item components below.

score 8 Reassess held Vision information against the three named gaps (who pays / why / how reach)

Question: Which of the three gaps can the held evidence already answer, and which need Janhavi?
Source basis: The 5 Sep 00:55 gap analysis + the 196-page dated corpus
Expected result: Each gap mapped to answerable work or founder-only input
Completion test: Every gap has a disposition
Status: done — executed 5 Sep 19:50; dispositions published

components: unmet-req 3 · uncertainty 3 · steering 2 · staleness 0 · blocked −0 · saturation −0 — unmet_requirement_weight: Addresses three missing/partial current-layer requirements; founder_steering_boost: Directly serves the 5 Sep Vision-first steer

score 5 Apply Janhavi's answers to who / why / optional channel when they arrive

Question: Have Janhavi's answers to the focused request arrived?
Source basis: Focused request published 5 Sep 19:55; replanning outcome 3 (justified blocked state) until reply
Expected result: Requirements updated from her words; reach next-test unblocked if who is named
Completion test: Her reply logged on Founder input with resulting change refs
Status: visibly blocked — waits on Janhavi's answers to the focused request

components: unmet-req 3 · uncertainty 3 · steering 2 · staleness 0 · blocked −3 · saturation −0 — blocked_dependency_penalty: Unblock condition: Janhavi answers steer-vision-gaps (who required; why required; channel optional). Owner: Janhavi. Next evaluation: next decision window (08:55 / 14:55) or on chat reply.

score 2 Prepare the focused founder-context request for the gaps only Janhavi can answer

Question: Exactly what is missing, why evidence cannot answer it, what changes per answer?
Source basis: WP5 replanning outcome 2; the 07:55 diagnosis
Expected result: One focused request on the Founder input page
Completion test: Request published with what-changes-per-answer
Status: done — executed 5 Sep 19:55; focused request published with what-changes-per-answer

components: unmet-req 0 · uncertainty 0 · steering 2 · staleness 0 · blocked −0 · saturation −0 — completion: Request published; asks only what evidence cannot; what-changes-per-answer on the dated page and Founder input card.

score 2 Produce the dated Overnight page at the morning boundary (07:55 phase)

Question: What did the night actually contribute?
Source basis: Cadence rule c0cbf4d7
Expected result: One dated page per night incl. quiet nights
Completion test: Page exists at the morning boundary, not backfilled
Status: standing obligation

components: unmet-req 1 · uncertainty 1 · steering 0 · staleness 0 · blocked −0 · saturation −0

score 0 Cuts↔working-set refresh (legacy queue item 6)

Question: Has the board changed enough to justify the refresh?
Source basis: Legacy queue item 6
Expected result: Refresh only when boards change
Completion test: Board diff non-empty
Status: visibly blocked — waits for board change since 04:55 5 Sep

components: unmet-req 1 · uncertainty 1 · steering 0 · staleness 1 · blocked −3 · saturation −0 — blocked_dependency_penalty: Blocked dependency: boards unchanged; unblock condition recorded, not deleted

score -1 Keep the standing live-picture board current (state maintenance)

Question: Did anything material change?
Source basis: Vision-first Job 1
Expected result: Standing page current; log entries only
Completion test: No new dated page unless the diff is non-empty
Status: maintenance — saturation-marked after six no-change hours

components: unmet-req 0 · uncertainty 0 · steering 1 · staleness 1 · blocked −0 · saturation −3 — saturation_penalty: N=6 consecutive no-material-change updates on 5 Sep → saturation rule

The meta-scheduler loop

The schedule that updates the schedules — at 17:30 after each close, inline at the end of any slot that fires a replanning trigger, and on founder-steering receipt:

LOAD close + trigger evidence
READ queue scores incl. saturation and blocked registers
APPLY founder steering overrides (recorded with reasons)
RE-SCORE every item (weights within contract bounds)
WRITE new manifest version with diff + reason to Activity
EMIT receipt — always

It may never change:

founder-layer transitions (founder-confirmed only)
parked-customer release
hiring / team assembly
notification obligation floor
timezone + occurrence identity scheme
the cron anchors (a founder-visible configuration change)
the one-authoritative-clock invariant
historical records (immutable; corrections are new versions)

Replanning triggers

	Trigger	Detection rule
T1	Queue exhausted with unmet requirements	No authorised item scores above the minimum-useful threshold while any current-layer requirement is missing/partial/unresolved.
T2	Attempted direction rejected	A result classifies as rejection-or-negative-learning for an active provisional direction.
T3	New information gap identified	A run produces a gap analysis naming missing information no queued item addresses (the 00:55 pattern).
T4	Repeated results not reducing uncertainty	≥3 consecutive occurrences with empty diffs on the same line of work (the 05:55→07:55→09:55 pattern).

Exactly one of three outcomes per trigger:

1. Next evidence-backed task — question, source basis, expected useful result, completion test.
2. Specific founder-context request — what is missing, why evidence cannot answer it, what changes per answer, what work continues meanwhile.
3. Justified blocked state — explicit unblock condition + owner + next evaluation time.

Anti-blank-report rules

Every run ends in exactly one of: (a) artefact + semantic state diff, (b) blocked record {what, unblock condition, owner, next evaluation}, (c) escalation.
Not legal: 'a file was published', 'the same state still holds', a timestamp-only update, a mechanism receipt, an ordinal-incremented repeat.
Dedup compares (underlying event, outcome class, action-need) — never text or timestamp. A rephrased duplicate is still a duplicate.
Never suppressed: a genuine new failure, a changed/new deadline, a fresh decision request, a new founder-context need. Mandatory obligations are reconciled BEFORE dedup.
Every notification decision (send / suppress / digest) is recorded durably with event, publication version, reason and delivery result.

Peer: Contract — the rules these routines run under · decisions with reasons: Notifications