[FEATURE] Schedule verification-goal proof runs through generic Triggers

[Joncallim]

Parent tracking issue: #187
Parent programme: #184 / #333
Execution mode: implementation
Depends on: #341, #355
Spec references: SPEC-0009 (Trigger/Event envelope — downstream consumer of generic Trigger substrate), SPEC-0002 (Execution lifecycle), SPEC-0008 (conformance)
Consumed by: #190, #191

Problem Statement

Verification goals need recurring proof runs, but schedule ownership cannot live inside the goal registry/runner. The stale pre-VNext #187 branch designed project-specific scheduling machinery before Forge had persistent Missions and a generic Trigger/Event runtime. Merging that scheduler would create a second scheduling source of truth and weaken zero-token idle/dedupe/causality guarantees.

Desired Outcome

A verification goal can declare cadence/policy that is materialized as a generic #341 schedule Trigger bound to a persistent proof Mission/Workflow. Each eligible occurrence requests the existing #355 on-demand proof Execution. Schedule restart, catch-up, dedupe, disabled state and retries use Trigger semantics; the verification-goal domain owns proof meaning only.

User Story

As the Forge operator,
I want critical “what still works” assertions proven on a controlled cadence,
So that regressions are detected early without an LLM polling loop or a verification-specific scheduler.

Requirements

• Keep verification-goal/revision records as proof-definition truth and cadence as requested policy metadata.
• Translate enabled schedule policy into one versioned [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 Trigger binding; no independent cron/timer/queue scheduler in verification-goal code.
• Trigger occurrence identity + goal revision + Resource/ref fingerprint deterministically identify a proof request.
• Invoke [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 through normal Mission/Execution admission; do not duplicate runner logic.
• Deduplicate overlapping occurrences for the same effective goal/ref according to explicit policy.
• Support explicit downtime catch-up policy (skip, latest, or bounded scheduled occurrences); never silently burst-run.
• Disabled/archived/revised goals stop old Trigger eligibility; stale queued occurrences fail current revision/state checks.
• Goal cadence/revision changes create/update versioned Trigger bindings without rewriting historical occurrence/run identity.
• Scheduling itself never invokes a model; deterministic proof runs retain [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 zero-model default.
• Persist links from Trigger occurrence -> proof Execution/run -> [FEATURE] Normalize execution outcomes and stop reasons #185 outcome/[FEATURE] Add capability reliability ledger #186 evidence.
• Failed proof may create downstream evidence/findings, but this issue does not launch speculative repair.
• Operator can inspect next/last occurrence, last run, dedupe/skip/block reason and recovery action.
• Preserve human-vs-browser verification lane distinctions defined by the goal contract where relevant.

Implementation Sequence

1. Cadence-to-Trigger binding contract — versioned mapping from exact goal revision/cadence policy to one [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 Trigger definition/binding with stable identity and no scheduler code inside goal modules.
2. Lifecycle synchronization — create/update/disable Trigger binding when current goal revision/cadence/enabled/archive state changes; preserve old binding/occurrence history.
3. Occurrence -> proof request bridge — validate current goal revision/Resource/ref state, derive deterministic effective proof identity and request [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 through the standard Execution path.
4. Overlap/dedupe policy — define same-goal/ref overlap behavior, active-run collision and equivalent occurrence handling using [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 occurrence identity rather than ad hoc locks.
5. Catch-up/time semantics — map goal cadence policy to [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 timezone/DST/restart/catch-up contracts; bound missed-run recovery and prohibit silent burst replay.
6. Stale-state fencing — disabled/archived/revised goal or Resource version conflict makes old queued occurrence ignored/blocked with stable reason; no proof execution starts.
7. Evidence linkage/projections — occurrence, goal revision, proof Execution/run, canonical outcome/reliability and next/last schedule state remain reconstructable.
8. Operator status/recovery — minimal schedule state, next/last occurrence/run, skip/dedupe/block/failure reason and allowed manual proof/retry action.
9. PR331 schedule-test port — review stale branch only for useful time/dedupe/restart test cases; reimplement through [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341, never copy project scheduler architecture.

Primary Code Seams To Inspect First

• verification-goal registry/revision/cadence fields and APIs
• [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 on-demand proof service/API
• [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 Trigger definition/occurrence/schedule/catch-up services
• [FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340 Mission/Execution identity where proof responsibility is bound
• [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 durable continuation/retry transport as used by [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341
• goal/proof current-state projections and reporting inputs
• stale PR feat: implement project verification goals and proof runs (#187) #331 scheduling tests/design notes only as historical evidence

Orthogonal Checkpoints

1. Ownership: no timer/cron/schedule queue/domain state added inside verification-goal runner; [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 is sole delivery authority.
2. Revision races: cadence/revision/enabled/archive change while occurrence is queued/claimed/Execution starts.
3. Time correctness: timezone/DST, leap/calendar boundaries as supported, long downtime, restart, clock skew assumptions and catch-up limits.
4. Dedupe/concurrency: duplicate occurrences, overlap with active proof run, delayed retries, event storm and dispatcher restart.
5. Zero-token: scheduler/cadence/skip/unchanged handling cannot invoke a model; [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 proof stays deterministic by default.
6. Evidence lineage: old Trigger/goal revision history immutable, current projection rebuildable, no run attributed to wrong revision/ref.
7. Failure separation: Trigger delivery/bridge failure vs proof runner failure vs proof assertion failure remain distinct.
8. Stale authority: disabled/revised goal and cancelled/revoked Mission block old occurrence despite Redis/stale label state.
9. Scope/regression: [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 runner code is reused, not forked; merged PR328-330 goal behavior remains green.

Acceptance Criteria

• [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 and [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 are closed before implementation starts.
• An enabled goal cadence is delivered through a [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 Trigger, not a verification-specific scheduler loop.
• A Trigger occurrence invokes the [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 runner without duplicating proof execution logic.
• Overlapping/duplicate occurrences do not create duplicate proof runs for the same effective identity beyond explicit policy.
• Restart/missed schedules follow the configured bounded catch-up policy.
• Disabled/archived/revised goals cannot be run by stale queued occurrences.
• Schedule/goal revision history remains reconstructable and prior runs retain exact Trigger/goal revision identity.
• An unchanged healthy proof schedule operates over a meaningful window with zero model calls.
• Trigger/bridge/runner/proof assertion failures are distinct with actionable recovery state.
• Trigger occurrence, Execution, proof run, canonical outcome and reliability evidence are durably linked.
• No speculative code repair is triggered directly by a failed proof.
• Useful schedule/dedupe/restart edge cases from PR feat: implement project verification goals and proof runs (#187) #331 are ported or dispositioned without reusing its scheduler implementation.

Out of Scope

• The on-demand proof runner ([FEATURE] Complete verification-goal on-demand proof execution through VNext #355).
• Sentinel finding/detection behavior ([FEATURE] Add Project Sentinel detection and escalation flow #190).
• General Trigger runtime ([FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341).
• Reporting/dashboard beyond minimal schedule/run state ([FEATURE] Add reliability, autonomy, and regression reporting #191).
• LLM polling.

Implementation Scope

Medium to Large - expected as 2-4 small PRs: binding/lifecycle; occurrence bridge+dedupe/catch-up; evidence/operator status; final adversarial time/restart gate.

Technical Notes

The core review question at every checkpoint is: “Could this feature still work if all verification-goal-specific scheduler code were deleted?” The answer must be yes because #341 owns delivery.

[Joncallim]

Hostile scheduling addendum — recurring proof identity is occurrence-scoped, catch-up cannot fabricate historical verification, and binding updates are transactional

A fresh schedule/proof-lineage pass found several semantic traps between #341 and #355. The most important: repeated scheduled proofs of an unchanged Resource are deliberately new observations, not duplicates merely because goal/ref content is unchanged.

1. Separate schedule-occurrence identity, proof request identity and proof subject identity

Use three concepts:

• schedule Trigger occurrence — one intended fire instant under one exact Trigger/schedule revision;
• proof request — one logical request to run [FEATURE] Complete verification-goal on-demand proof execution through VNext #355, normally derived one-to-one from an eligible schedule occurrence;
• proof subject — exact goal revision + Resource/content/runtime inputs being tested.

Duplicate Redis/web delivery of the same occurrence maps to one proof request. But tomorrow's schedule occurrence against the same unchanged commit is a new proof request/attempt because it provides new time/environment health evidence.

Therefore do not use (goal_revision, Resource fingerprint) as a forever-idempotency key. Include the exact schedule occurrence/request identity. Overlap policy may skip/coalesce a later scheduled request while one is still active, but that is an explicit scheduling decision with evidence—not deduplication of all same-subject future proofs.

2. Overlap policy is explicit and distinct from #341 delivery dedupe

For each scheduled goal declare behavior when a new eligible occurrence arrives while a proof request/run for that goal/Resource scope is still non-terminal, e.g.:

• skip_while_running;
• latest_after_running;
• bounded queue/count where genuinely required.

Initial default should be conservative and prevent unbounded pile-up.

Record every occurrence disposition (proof_requested, overlap_skipped, coalesced_to_occurrence, blocked, etc.) with stable reason. A skipped overlap is not a successful proof.

Two different Resource subjects may run concurrently only within Mission/#335/#341 policy; do not globally serialize the whole verification-goal subsystem.

3. Missed schedule catch-up cannot retroactively prove historical state unless that historical subject is preserved

This is critical.

If Forge was down yesterday and the goal targets mutable main, running the proof today against today's main cannot be labelled “proof for yesterday's scheduled state.”

For catch-up:

• skip -> no proof for missed instants;
• latest -> one current proof request associated with the latest missed/catch-up occurrence, clearly observed now against the current admitted subject;
• bounded historical replay is only semantically historical if the exact Resource revision/snapshot for each missed occurrence is durably known/addressable and policy explicitly requests that; otherwise each catch-up proof is a current observation, not fabricated past evidence.

Store scheduled_for, requested_at/observed_at, and exact tested Resource revision separately. Reporting must not interpret schedule timestamp as proof observation time.

4. Mutable Resource binding is snapshotted at occurrence→proof admission, not at future execution time

When an occurrence becomes eligible:

1. re-check current goal revision/enabled state;
2. resolve/admit the exact Resource/ref revision intended by policy at that moment;
3. persist proof request subject identity;
4. create [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 Execution/request through the normal path;
5. worker later executes that exact subject or fails stale/unavailable—it does not silently retarget to whatever main is when it finally starts.

If policy explicitly means “test latest when worker begins,” model that as a different binding policy with clear evidence; default should favor exact admitted subject reproducibility.

5. Goal cadence metadata and Trigger binding update are one consistent lifecycle transition

Avoid a state where UI says “goal scheduled daily” while the old Trigger still fires hourly or no Trigger exists.

Treat current schedule binding as a protected versioned relationship:

• goal revision/requested cadence metadata;
• current Trigger logical identity/revision;
• binding generation/state (pending | active | disabled | error or equivalent);
• exact activation boundary.

Where both live in PostgreSQL, update/create/disable the binding under one transaction/CAS or a durable reconciliation state that fails safely until complete.

A schedule configuration API does not report success/current active cadence until the Trigger binding is durably in the corresponding authoritative state.

If Trigger materialization fails, expose schedule_binding_failed/pending; do not keep silently running the old cadence unless policy explicitly chooses that rollback behavior and the UI says so.

6. Revision changes never mutate historical Trigger/occurrence/proof identity

When goal/cadence changes:

• old goal revision + Trigger revision + occurrences remain immutable history;
• new current binding gets a new Trigger definition revision (or new logical binding according to [FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle #341 contract) with explicit activation instant;
• pending old occurrence rechecks and is superseded/blocked unless policy explicitly permits it;
• old proof already running remains pinned to old goal/resource subject and its result is historical for that revision;
• current projections never relabel the old run as satisfying the new revision.

7. Manual proof and scheduled proof are separate request origins

A manual operator #355 run does not consume/dedupe the next scheduled occurrence by default. Likewise, a scheduled run does not make a later deliberate manual run disappear.

Both may test the same subject but have distinct causal/request identities and can be compared by #186 according to policy.

If policy deliberately suppresses a scheduled run because a sufficiently fresh equivalent manual proof already exists, make that an explicit deterministic freshness/coalescing policy with evidence—not accidental idempotency-key collision.

8. Failure domains remain four-way separate

At minimum distinguish:

1. schedule calculation/Trigger failure;
2. occurrence→proof bridge/admission failure;
3. proof runner/infrastructure failure;
4. proof assertion result (passed/failed/inconclusive/blocked).

A Trigger delivery failure is not “verification failed.” A proof assertion failure does not cause Trigger retry of the same business proof unless explicit policy says to schedule a new proof request. Redis duplicate/retry never creates a second logical proof.

Reporting/#190 consume the exact causal class so operators know whether the product regressed or the monitoring system failed.

9. Repeated failed assertions do not create retry storms

A scheduled assertion failure is valid evidence. It should flow to #190/#189 and then await the next normal occurrence or an explicitly bounded recheck policy.

Do not automatically retry a deterministic failing test at transport-backoff cadence and count each failure as new independent reliability evidence.

If policy allows confirmatory rerun for flaky detection:

• bounded count;
• separate rerun reason/identity;
• reliability selector knows the attempts are correlated;
• no model call unless independently admitted;
• cooldown/budget enforced.

10. Schedule currentness uses #341 canonical time, proof evidence uses #355 execution time

Expose separately:

• next canonical scheduled instant;
• last Trigger occurrence scheduled/received time;
• last proof request/admission time;
• last proof execution/terminal time;
• exact Resource revision tested;
• freshness policy result.

Do not use “last scheduled at” as “last verified at.”

A proof queued for hours may be stale by the time it completes; #186/#189 freshness uses the correct evidence/subject policy.

11. Trigger disable/archive and Mission pause/cancel semantics are exact

• goal disabled/archived -> current Trigger binding disabled and future schedule occurrences ineligible;
• proof Mission paused -> occurrence may remain recorded but cannot start new Execution until policy/resume says; catch-up behavior explicit;
• Mission cancelled/terminal -> no future proof Execution under it;
• re-enabling creates/activates a current schedule boundary without replaying the whole disabled interval unless explicit catch-up policy;
• old Redis occurrences cannot wake after generation/revision mismatch.

12. Projection ordering handles out-of-order completion

Use #355's subject/request generation semantics.

A slow proof for older occurrence A that finishes after newer occurrence B must not become “latest current proof” merely by completed_at. Current goal/proof projection orders by schedule/proof request semantics + exact subject revision as defined, while preserving all history.

If A/B test different Resource commits, current result is explicitly commit-scoped; do not collapse to timeless red/green.

13. Hostile fixtures

Add:

• same unchanged commit scheduled on two consecutive days -> two deliberate proof requests, not deduped as one;
• duplicate Redis delivery of day-1 occurrence -> one proof request;
• long-running day-1 proof when day-2 occurs -> explicit overlap disposition, bounded queue/skip;
• downtime then latest catch-up -> current proof observed now, not falsely timestamped historical proof;
• bounded catch-up without historical Resource snapshots -> no claim of historical state;
• main advances after occurrence admission before worker run -> worker tests admitted revision or fails, never silently latest;
• cadence update transaction fails halfway -> schedule binding shows failed/pending, no false UI success/ambiguous two cadences;
• old occurrence arrives after goal revision -> blocked/superseded;
• manual proof immediately before schedule -> both distinct unless explicit freshness-coalescing policy;
• assertion fails -> no transport-style repeated proof storm/sample inflation;
• Trigger failure vs runner failure vs assertion failure displayed distinctly;
• slow old proof completes after newer proof -> current projection remains correctly ordered/subject-scoped;
• disable/re-enable across several scheduled instants -> catch-up exactly policy, no unbounded replay.

The strengthened invariant is:

Scheduling answers “when should a new observation be requested?” It does not redefine proof identity, historical Resource state, or assertion semantics. Every schedule occurrence is a distinct causal observation opportunity, while duplicate delivery of that occurrence remains exactly-once business intent.

[Joncallim]

Architecture reconciliation — keep cadence outside the current v1 goal document

Reviewed 1 October 2026 against this issue, its occurrence-scoped scheduling addendum, and the merged v1 goal contract. No recurring task or proof was started.

Confirmed plan alignment

The later addendum correctly resolves the body's potentially overbroad “same effective goal/ref” dedupe: duplicate delivery of one occurrence is deduplicated; a later scheduled observation of unchanged content remains a distinct intentional request. Keep its explicit overlap, four-way failure and no-fabricated-history rules.

Implementation clarifications

1. There is no cadence field in merged v1 goal JSON. That parser accepts an exact key set and rejects unknown fields. Store requested cadence in a separate authorised versioned schedule-binding contract linked to the goal revision, or explicitly version/migrate the goal schema. Do not quietly add cadence fields to v1 or assume existing imports already persist them.
2. An unchanged commit does not mean a scheduled proof is unnecessary. Environment, dependencies, service availability or time-sensitive assertions can change. Only an explicit goal policy may reuse a sufficiently fresh equivalent result; reuse records an evidence-based skip, not a fresh executed pass. Content-cache hits must not refresh observation timestamps.
3. Human/browser lanes are evidence types, not cosmetic badges. A scheduled automated/browser run cannot satisfy a criterion requiring an actual human observation. If required human evidence is absent, expose it as pending/not-tested under policy. No scheduler may fabricate or infer acceptance from prior green automation.
4. An unresolved effect can constrain overlap beyond “running.” If a previous proof's Operation may have produced a consequential effect, a terminal-indeterminate row is not necessarily safe permission for the next occurrence to repeat it. Apply [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336/[FEATURE] Complete verification-goal on-demand proof execution through VNext #355 recovery and Resource constraints before a new proof request is admitted.
5. Materialise cadence with an explicit active-generation fence. The issue already calls for transactional binding updates. Also prove stale scheduler workers cannot create eligible occurrences under an old cadence after a successful update, even if both old/new definitions remain for history.
6. Monitoring gaps remain visible. Skipped overlap, disabled periods, unmet human evidence and failed bridge delivery are not verified coverage. Reporting should state the last actual verified subject/time and missed or unobserved interval, without replacing those gaps with green schedule health.

Acceptance additions

• Attempt to append cadence to strict v1 JSON fails; supported binding setup succeeds without weakening the parser.
• Unchanged repository plus changed runtime/service condition still receives the scheduled observation.
• Cached evidence reuse shows a skip with original observed time, never a new proof execution.
• Human-required criterion receives only automated evidence: no human pass.
• Prior indeterminate proof with possible side effect blocks unsafe overlapping replay.
• Old scheduler emits after cadence-generation update: occurrence cannot execute.
• Long overlap/disabled window produces honest coverage gaps.

Next step

Implement the narrow binding and bridge after #341/#355, preserving the merged registry and reusing all schedule/recovery machinery. No verification-specific timer, speculative repair or new model path belongs here. Issue state and dependencies are unchanged.