[FEATURE] VNext Phase 7 — Trigger/Event runtime with dedupe, causality, and zero-token idle

[Joncallim]

Parent: #333
Execution mode: implementation
Depends on: #340, #347
Downstream consumers: #356, #190
Spec references: SPEC-0009 (Trigger/Event Envelope — CloudEvents compatibility, causality, loop prevention, deduplication, granular concurrency per dedupe identity), SPEC-0002 (Mission lifecycle, waiting state), SPEC-0004 (Operation identity, side-effect lifecycle), SPEC-0008 (conformance)

Problem Statement

Persistent Missions need deterministic wakeups, but implementing schedules/webhooks independently inside verification goals, Sentinel, HearthBot or each Workforce would recreate multiple scheduler truths and ambient LLM polling. Forge must have one Trigger/occurrence substrate that provides source authentication, dedupe, replay protection, causality, retry and zero-token irrelevant-event handling before recurring/autonomous features expand.

Desired Outcome

Missions can be awakened by manual actions, schedules and supported signed webhooks/events through one durable Trigger contract. Duplicate/replayed/self-induced events do not create duplicate Executions, disabled/revoked Missions do not wake, and deterministic filters terminate unchanged events with zero model calls.

Verification-goal scheduling (#356) and Sentinel scheduling (#190) are downstream consumers of this substrate. Phase 7 defines and proves the stable generic ports they need, but does not implement either downstream product feature and does not depend on either issue closing.

User Story

As the Forge operator,
I want ongoing Missions to wake only from authenticated, deduplicated and policy-admitted events,
So that monitoring and recurring work remain cheap, explainable and restart-safe without a permanent LLM poller.

Requirements

A. Trigger definition

Persist/version Trigger definitions with stable id/version/type, Mission binding, source/principal policy, Resource scope/classification, schedule or adapter configuration as data, dedupe/replay/debounce policy, deterministic prefilter policy, enabled/disabled state, inherited budget/authority constraints and actor/evidence.

A Trigger never owns broader authority than its Mission.

B. Occurrence contract

Every observed delivery creates or deterministically maps to a durable occurrence containing Trigger id/version, source/authentication state, external occurrence identity where available, observed time, stable dedupe/replay identity + policy window, causal parent event/Operation, Mission correlation, input Resource refs/safe metadata, lifecycle and attempt/error evidence.

Use PostgreSQL as occurrence truth; Redis is delivery/wakeup transport through #347.

C. Manual + schedule first

• Manual Trigger is the baseline.
• Add one replaceable schedule-engine adapter; product semantics live in Trigger definitions, not cron/systemd syntax.
• Restart/missed schedule follows explicit catch-up policy (skip, latest, or bounded occurrences); never silently burst replay.
• Clock/timezone/cadence calculations are deterministic/testable.

D. Webhook/event adapters

For supported signed sources validate signature/source identity, timestamp/replay window, body/header bounds and schema. Persist only policy-approved/redacted evidence. Unverifiable sources are explicitly lower-trust; endpoint arrival is not authentication.

E. Dedupe/debounce/coalescing

Same occurrence identity creates at most one eligible Execution under policy. Equivalent high-frequency observations may debounce/coalesce deterministically. Restart/ambiguous processing cannot become duplicate side effects. Replay windows/state are durable and bounded.

F. Causality/loop prevention

Per SPEC-0009 R8, loop prevention MUST detect multi-Trigger cycles (A→Operation→B→Operation→A) through bounded causal ancestry chains, not just same-Trigger self-loops. Trigger occurrence identity prevents duplicate execution intent; Operation identity separately prevents duplicate side effects.

G. Concurrency (per SPEC-0009 concurrency semantics)

Occurrence admission and deduplication are serialized per dedupe identity, NOT per Trigger definition. Independent occurrences for unrelated Resources MAY proceed concurrently within Mission/Execution/budget limits. Conflicting Resource mutation lanes MUST be serialized per Resource identity.

Record Forge-authored external Operation causal identities. Default policy prevents side-effect -> inbound-event recursive loops. Explicit causal chains are bounded by depth/count policy.

G. Deterministic prefilters

Cheap deterministic states such as unchanged, irrelevant, duplicate, outside-window, disabled, revoked or budget-blocked terminate without a model call and with stable reason/evidence.

H. Mission wake admission

Before requesting Execution re-check Mission state/lease, Grant/autonomy, Resource scope/version, budget, Trigger/source policy and egress/model policy only if cognition is needed. A stale queued occurrence cannot wake a cancelled/revoked Mission.

I. Downstream consumer contracts

Phase 7 owns only generic integration contracts and conformance fixtures:

• define a stable schedule-Trigger/occurrence -> admitted Execution request seam sufficient for [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 to bind verification-goal cadence and invoke [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 later;
• define a stable Trigger/occurrence -> bounded detector-run request seam sufficient for [FEATURE] Add Project Sentinel detection and escalation flow #190 to run Sentinel detectors later;
• prove both seams with generic fakes/stubs or synthetic consumers only;
• do not import, implement, or require production code from [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 or [FEATURE] Add Project Sentinel detection and escalation flow #190;
• on-demand proof/Sentinel-style fixtures may use Manual Trigger/Execution semantics only to prove generic behavior, never product-specific orchestration.

J. Operator surface

Expose Trigger health, next/last schedule, last occurrence, auth state, ignore/dedupe/block reason, retry/dead state, linked Execution and recovery action without log spelunking.

Implementation Sequence

1. Trigger/occurrence schemas + lifecycle invariants.
2. Manual Trigger -> Mission Execution with durable occurrence/dedupe/authority/budget recheck.
3. Schedule adapter with cadence/catch-up/timezone/restart semantics and zero-token deterministic runs.
4. Occurrence retry/dead-letter using [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 durable wakeup.
5. Signed webhook fixture with auth/replay/body bounds and lower-trust unsigned state.
6. Causality/loop prevention fixture and bounded explicit chain.
7. Deterministic prefilter framework.
8. Verification-style consumer conformance fixture — a synthetic schedule consumer proves the generic occurrence/Execution seam [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 will consume; no [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 module or goal scheduler is implemented.
9. Sentinel-style consumer conformance fixture — a synthetic detector consumer proves the generic occurrence/detector-run seam [FEATURE] Add Project Sentinel detection and escalation flow #190 will consume; no [FEATURE] Add Project Sentinel detection and escalation flow #190 finding/detector product code is implemented.
10. Operator APIs/UI + event-storm/restart/disabled-Mission/zero-token E2E.

Primary Code Seams To Inspect First

• [FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340 Mission/Execution lifecycle and leases
• [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 durable continuation/outbox
• queue/event/SSE infrastructure
• generic Execution/admission interfaces that [FEATURE] Complete verification-goal on-demand proof execution through VNext #355 and later consumers use
• provider/model broker only after cognition is actually required

Do not import future #356 or #190 modules to make Phase 7 tests pass.

Orthogonal Checkpoints

1. Occurrence identity: duplicate, replay, ambiguous delivery, DB/Redis restart.
2. Authentication/security: forged signatures, stale timestamps, oversized input, credential/Resource confusion.
3. Time/scheduling: timezone/DST, missed ticks, restart, burst catch-up, disabled state.
4. Causality: self-loop, mutual loop, bounded explicit chains, event storms.
5. Zero-token behavior: unchanged schedule windows and irrelevant events produce no model call.
6. Authority: stale queued occurrence vs cancelled/revoked/demoted Mission.
7. Consumer-contract isolation: synthetic verification/Sentinel consumers can use the generic seams, while Phase 7 has no dependency/import on [FEATURE] Schedule verification-goal proof runs through generic Triggers #356/[FEATURE] Add Project Sentinel detection and escalation flow #190 and no product-specific scheduler/detector truth.
8. Final dependency review: repository/code search proves Phase 7 can close with [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 and [FEATURE] Add Project Sentinel detection and escalation flow #190 still open.

Acceptance Criteria

• [FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340 and [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 are closed before Phase 7 starts.
• Manual, schedule and one signed-webhook fixture use the same durable occurrence contract.
• A repeated deterministic proof-like/health-like schedule can run through a meaningful unchanged window with zero model calls using synthetic generic consumers.
• Invalid/stale webhook signatures/replays cannot create eligible Executions.
• Unverifiable sources are explicitly constrained rather than treated as authenticated.
• Duplicate/event-storm deliveries create at most the policy-allowed Execution set.
• Restart/replay cannot duplicate confirmed side effects.
• Forge-authored side effects do not create an infinite inbound Trigger loop.
• Trigger retry/dead state is reconstructable from PostgreSQL and recoverable without model reasoning.
• Cancelled/revoked/disabled Missions do not wake from stale/new occurrences.
• Trigger/package content cannot widen Mission Grants/budget/egress policy.
• Generic conformance fixtures prove the exact downstream seams needed by [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 and [FEATURE] Add Project Sentinel detection and escalation flow #190 without importing or implementing either downstream issue.
• Phase 7 can close while [FEATURE] Schedule verification-goal proof runs through generic Triggers #356 and [FEATURE] Add Project Sentinel detection and escalation flow #190 remain open; their later implementations must consume this substrate and may not create independent scheduler truth.
• Operator surfaces explain run/ignore/dedupe/auth/block/recovery state.

Out of Scope

• Verification-goal cadence binding/product integration ([FEATURE] Schedule verification-goal proof runs through generic Triggers #356).
• Sentinel finding/detector product integration ([FEATURE] Add Project Sentinel detection and escalation flow #190).
• LLM polling loops.
• Permanent product dependence on cron/systemd.
• General adapter ecosystem ([FEATURE] VNext Phase 8 — general Resource/Capability adapter ecosystem #342).
• Model ensembles.

Implementation Scope

Very Large - durable event/scheduling/security integration, expected as 6-9 small PRs.

Technical Notes

Keep occurrences small/evidence-oriented; do not store arbitrary webhook bodies indefinitely. Event source authentication and Mission execution authorization are distinct checks and both are required. The key closure invariant is that Phase 7 proves a generic Trigger substrate; downstream consumers prove their own product integration later.

[github-actions]

FORGE issue validation

This Feature issue now matches the required FORGE template structure.
The validator applied ready-for-agent and removed needs-clarification if it was present.

[Joncallim]

Hostile Trigger/Event addendum — authenticate raw delivery, fence causal identity, and atomically bind one occurrence to one Execution request

A fresh pass against SPEC-0009 plus #340/#347 and the hardened authority/evidence contracts found several gaps that matter before any recurring product consumes this substrate.

1. Distinguish raw ingress attempts from durable Trigger occurrences

The issue currently says every observed delivery creates/maps to a durable occurrence. Do not interpret that as “every arbitrary HTTP request gets a permanent DB row.” That creates a storage-amplification/DoS primitive before authentication.

Use two layers:

1. bounded ingress/auth attempt — size/rate/source endpoint controls, raw-signature verification, safe security telemetry/audit as policy permits;
2. Trigger occurrence — a schema-valid delivery mapped to a configured Trigger/source contract with an explicit authentication state/source identity and bounded policy-approved data/evidence.

For a source configured as signed/authenticated, a forged/invalid signature request is rejected before eligible occurrence creation. Keep only bounded/rate-limited security audit metadata necessary to diagnose attacks; never persist attacker bodies indefinitely just to prove they arrived.

For a deliberately supported lower-trust/unsigned source, unverified is an explicit source-auth result allowed by that Trigger's policy; it is not a fallback used when verification of a signed source fails.

2. Verify webhook authentication over the exact bytes/protocol the source signs, before semantic parsing

For HMAC-style fixtures:

• impose request/body/header size limits before buffering unbounded input;
• preserve exact raw bytes required by the signature scheme;
• verify algorithm/key id/timestamp/signature with constant-time comparison where applicable;
• only after authentication parse JSON/CloudEvents/source payload into typed data;
• do not parse/re-serialize JSON then HMAC the canonicalized form unless the source protocol explicitly defines that;
• duplicate headers, ambiguous encodings/content types and invalid timestamp formats fail closed;
• never include secrets/signing keys in model context, occurrence payloads, logs or errors.

For mTLS/OAuth sources, the authenticated source identity comes from the trusted transport/auth adapter, not payload claims.

3. Key rotation is versioned source-auth evidence

Webhook/source credentials rotate independently of Trigger behavior.

• source auth configuration has explicit key/credential generation or key id;
• bounded overlap may accept current + explicitly retained previous key generations according to policy;
• occurrence records which credential generation/source identity authenticated it, never the secret;
• retiring/revoking a generation immediately prevents new admission under it;
• an in-flight occurrence authenticated before rotation still faces current Mission/security/Trigger authorization before Execution creation;
• payload cannot choose arbitrary key material/credential audience.

Hostile fixture: rotate key between receipt and Mission wake; old-auth occurrence remains historical authenticated evidence but cannot bypass current revoke/policy.

4. Replay protection and business dedupe are separate controls

Do not make one dedupe_key carry both meanings.

Authentication replay protection asks: is this signed/authenticated delivery still valid under its source timestamp/nonce/event-id/replay-window contract?

Trigger dedupe/coalescing asks: should a valid occurrence create new execution intent under this Trigger policy?

Required:

• source replay state is durable for the entire authentication replay window;
• expiry of a business dedupe window must not make an already-too-old signed request authentic again;
• replay rejection is recorded with a stable reason but never creates an eligible Execution;
• source-specific sequence/nonce semantics are handled by the auth adapter, not inferred from generic timestamps.

5. Dedupe identity has an explicit collision domain

A raw string dedupe key is insufficient.

Canonical dedupe identity should bind something equivalent to:

stable logical Trigger identity
+ authenticated source Principal/source namespace
+ event/subject Resource identity where policy requires
+ dedupe strategy/schema version
+ source occurrence identity or deterministic policy-derived key

Trigger revision updates explicitly declare whether they retain or reset the logical dedupe namespace. Do not accidentally replay an external event merely because the Trigger config got a new row/version, and do not dedupe unrelated sources that happen to use the same external id.

Use an exact DB unique/CAS constraint for the dedupe domain/window admission; application SELECT then INSERT is not sufficient under concurrency.

6. latest_only / coalescing must not trust attacker-controlled event time

Source time is evidence metadata, not automatically the ordering authority.

For ordering/coalescing choose one declared policy source:

• Forge DB received_at/admission sequence; or
• an authenticated source sequence/version only when the source contract guarantees its semantics.

Do not let an event with a forged far-future CloudEvents time permanently win latest_only and suppress legitimate later observations.

Coalesced occurrences preserve immutable membership/provenance of the source occurrence IDs and use a deterministic aggregation rule. A model does not decide which event “matters most” before the deterministic filter/admission boundary.

7. Inbound payload cannot choose Forge authority/correlation fields

External event contents are untrusted per SPEC-0005.

Do not trust payload-provided:

• Mission id;
• Trigger id/version;
• Principal/Grant;
• forgeexecutionid;
• Forge causation/Operation ids;
• Resource scope;
• budget/autonomy/policy revisions;
• classification lowering.

The endpoint/adapter resolves the configured Trigger and authenticated source Principal from trusted server-side state. Payload subject/ids are source data validated against that mapping, not authority.

CloudEvents-compatible Forge extensions generated by Forge are outputs/interchange fields; an arbitrary inbound client cannot mint internal causal authority merely by supplying those names.

8. Forge causality requires a trusted linkage path; external callers cannot spoof loop ancestry

For Forge-authored Operations that are expected to produce callback/events:

• store an internal causal token/expected external correlation identity at the Operation/adapter boundary where the external service supports it;
• on inbound event, the trusted adapter maps authenticated external correlation evidence back to the Operation/occurrence identity;
• only that trusted mapping may populate caused_by_operation_id / internal causal ancestry as authoritative;
• attacker-supplied internal UUIDs are ignored/rejected as causal claims.

Where an external service cannot echo a trustworthy causal identifier, record ancestry as unknown rather than inventing it. Rely additionally on Operation idempotency, dedupe, rate/budget ceilings and conservative loop policy; do not claim perfect loop detection from spoofable payload metadata.

9. Causal chain storage is immutable, bounded and digest/reference based

A new occurrence records a bounded immutable ancestry representation sufficient for loop policy—do not recursively materialize unbounded full payload chains.

• max depth/count are hard policy bounds;
• ancestry references only existing trusted occurrence/Operation IDs;
• cycle detection uses the stored immutable lineage, not model/context prose;
• exceeding ancestry bound maps to stable loop/limit block, never truncation that then allows a cycle through;
• explicit approved recursive flows pin their own tighter depth/count/budget/wall-clock envelope and cannot self-raise it.

10. Trigger definition revision and enabled state are fenced through occurrence → Execution admission

Every occurrence binds the exact Trigger definition revision that interpreted it.

Before creating/waking an Execution, re-check:

• Trigger logical identity still exists;
• bound revision is still eligible or policy explicitly allows already-authenticated old-revision occurrences;
• Trigger enabled/current state revision;
• Mission non-terminal/not-paused according to [FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340;
• current autonomy/security/Grant ceiling;
• Resource binding/classification;
• budget/concurrency.

Disable/revoke/config-change races therefore cannot be defeated by an occurrence already sitting in PostgreSQL/Redis.

A stale queued occurrence becomes ignored/superseded/blocked with reason; it never silently rebinds itself to the newest Trigger revision.

11. Occurrence → Execution request is one atomic PostgreSQL business transition

For an eligible occurrence, create the business Execution request exactly once.

Preferred transaction:

1. lock/CAS occurrence dedupe/admission state;
2. re-evaluate current Mission/Trigger/security/autonomy/budget/concurrency policy;
3. create one Execution identity/request under [FEATURE] VNext Phase 6 — persistent Missions, checkpoints, leases, and bounded autonomy #340;
4. bind occurrence.execution_id (or normalized join) immutably/currently according to schema;
5. append authoritative occurrence/Mission/Execution audit;
6. insert [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 durable continuation/outbox intent for that exact Execution/generation;
7. commit;
8. Redis delivery happens later and may retry without creating a second business Execution.

A crash after DB commit/before Redis cannot lose the wakeup; a duplicate webhook/delivery cannot create another Execution from the same admitted occurrence.

If policy intentionally allows one coalesced occurrence group to create multiple child Executions later, that is a separate bounded explicit contract—not accidental retry behavior.

12. Schedule occurrence identity is deterministic and independent of scheduler process

Multiple scheduler workers/restarts must converge on the same logical schedule occurrence.

A schedule definition pins:

• IANA timezone;
• closed schedule expression/schema revision;
• catch-up policy/bounds;
• start/end/anchor semantics;
• DST ambiguous/nonexistent-time policy;
• schedule definition revision.

Each intended fire has a deterministic logical identity derived from the stable Trigger/schedule revision + canonical scheduled instant/ordinal—not process.pid or wall-clock callback identity. DB uniqueness makes two schedulers race to one occurrence.

Persist separately:

• scheduled_for (canonical intended instant);
• DB received/created_at;
• source/local display timezone metadata.

Host clock jumps do not duplicate/skip authority; schedule calculation uses DB-authoritative now or an equally trusted persisted clock boundary.

13. DST and calendar semantics must be explicit fixtures, not library defaults

For named-local schedules test:

• spring-forward nonexistent local time;
• fall-back repeated local time;
• timezone database update/change;
• leap day/month-end where supported;
• process down across several missed instants;
• restart exactly at fire boundary.

skip/latest/bounded applies to the canonical missed occurrence set after schedule calculation. bounded processing order is deterministic. No unlimited burst.

Do not persist host-local cron interpretation as canonical schedule truth.

14. Ingress/event storms need pre-model and pre-database backpressure

Budgeting only model calls is too late.

Bound per installation/Trigger/source as appropriate:

• inbound request rate;
• authentication work;
• durable invalid-attempt audit rate/storage;
• occurrence creation rate;
• outstanding unprocessed occurrences;
• payload/resource bytes;
• [BUG][P0] Make Postgres-to-Redis wakeups durable, idempotent, and recoverable #347 wakeup backlog;
• downstream concurrent Executions.

When limits hit, fail with stable machine reasons and source-appropriate retry/backpressure response. The model is never invoked to decide whether the event flood is excessive.

15. Occurrence data is a classified Resource/evidence object, not a dumping ground for webhook bodies

Persist only bounded policy-approved data/envelope fields needed for deterministic processing/reconstruction.

• classify before model/provider egress;
• secrets/auth headers/signatures are never retained in normal occurrence data;
• large/raw payloads, when retention is genuinely required, use a separately classified Resource/Artifact store with digest/ref and retention policy rather than unbounded JSONB;
• unknown classification is SECRET-equivalent for egress;
• model/source content cannot lower its own classification.

16. Manual Trigger has replay/idempotency semantics too

An authenticated operator/API manual wake should accept a durable request/idempotency identity so a client/network retry does not create two Executions accidentally.

A second deliberate manual run uses a new request identity and can create another Execution according to Mission concurrency/budget policy.

Do not special-case manual triggers into direct createExecution() bypassing occurrence/audit/dedupe.

17. Deterministic prefilter evidence is version-bound

An “unchanged/irrelevant” decision pins:

• occurrence/Resource version;
• filter definition/version;
• comparison baseline/ref;
• policy revision;
• stable reason code.

If filter evaluation errors or required baseline is missing, do not treat it as unchanged. Return blocked/inconclusive/processing failure according to the contract. Unknown never becomes zero-token success by optimism.

18. Hostile conformance expansion

Add:

• oversized forged signed-source request -> rejected before durable occurrence/body storage amplification;
• invalid signature cannot fall back to unsigned source mode;
• raw JSON signature valid but parse/re-serialization differs -> raw-byte verification still succeeds correctly;
• key rotates between auth and wake -> current authorization still applies;
• authenticated replay after business dedupe window expired but auth replay window invalid -> rejected;
• same external id from two distinct sources -> no accidental cross-source dedupe;
• Trigger revision changes -> explicitly retained/reset dedupe semantics, never accidental replay;
• future forged event time cannot dominate latest_only ordering;
• payload supplies forged Mission/Grant/Operation causation IDs -> cannot affect authority/loop detection;
• Forge Operation callback with valid trusted correlation -> ancestry linked; spoofed correlation rejected;
• disable Trigger after occurrence persistence before wake -> no Execution;
• two schedulers race same fire instant -> one occurrence;
• DST repeated/nonexistent time + restart/catch-up fixtures;
• crash after occurrence+Execution+outbox commit before Redis -> one Execution eventually delivered;
• duplicate Redis/outbox delivery -> no second Execution;
• unauthenticated event storm bounded before DB/model exhaustion;
• deterministic filter missing baseline -> not silently unchanged;
• manual Trigger HTTP retry same idempotency identity -> one Execution; new deliberate identity -> separate Execution if policy permits.

The strengthened invariant is:

A Trigger occurrence is authenticated, bounded event evidence tied to one exact Trigger/Mission policy revision. It becomes execution intent once, transactionally; Redis, retries, payload timestamps and caller-supplied Forge IDs can never create or redirect authority.

[Joncallim]

Architecture reconciliation — acknowledgement, recovery and event semantics

Reviewed 1 October 2026 against this issue and the existing Trigger/Event addendum. Keep the current source-authentication, atomic occurrence→Execution, causal lineage, calendar and consumer-isolation contracts. The earlier bot “ready-for-agent” comment is a historical projection, not evidence that #340/#347 are complete.

Remaining protocol decisions

1. Acknowledge only the durable boundary actually reached. For a supported webhook, successful HTTP acknowledgement should mean the authenticated bounded event is durably accepted, deduplicated or deliberately terminally ignored under recorded policy. It must not be returned after merely enqueueing an in-memory task. If persistence failed, use the source's supported retry response; duplicate delivery is then handled by the durable identity. Never keep an HTTP connection open through model execution.
2. Authentication is source-specific. Preserve the signed fixture, but do not assume all later providers sign a timestamp plus body. A reviewed source may use a secret header or another supported protocol. Its exact verification/replay guarantees and residual limits must be declared by [FEATURE] VNext Phase 8 — general Resource/Capability adapter ecosystem #342's protocol helper. A failed signed check still cannot downgrade to an unsigned mode.
3. Internal replay is not a fresh external delivery. Retrying an already authenticated stored occurrence after a transient internal failure references that immutable occurrence and original auth evidence, then rechecks current authority. It must not forge a new provider timestamp/signature or bypass expired policy by pretending to be a new event. Manual dead-letter recovery creates an audited recovery intent, not an untracked direct Execution.
4. Coalescing must preserve transitions that matter. “Latest state” is suitable only for sources whose declared semantics permit dropping intermediate observations. An outage/recovery pair, stop/revoke, approval or non-idempotent command cannot be collapsed like repeated identical health samples. Specify allowed aggregation per event class, retain causal membership, and prioritize cancellation/revocation so ordinary floods cannot indefinitely delay their authoritative handling.
5. Replay/dedupe retention needs a safe expiry rule. Garbage-collecting an occurrence receipt must not make a provider retry eligible again. Tie retention/tombstones/source epochs to the actual provider retry/replay window and business policy; where the window is unknown, document a conservative bound/reconciliation rule rather than claiming permanent exactly-once delivery. No receipt GC may resurrect an already consumed one-time approval.
6. Pin scheduling interpretation as well as expression. Include the schedule-engine/timezone-rules compatibility identity needed to explain calculated instants. A timezone database or parser update must not silently reinterpret already materialized occurrences. Future recalculation follows an explicit definition/migration policy, retaining the old scheduled instants and catch-up boundary.

Additional fixtures

• Crash after auth but before durable receipt: no false accepted response; provider retry admits once.
• Crash after durable receipt before response: repeated delivery resolves to the same occurrence.
• Delayed internal retry after the original external auth window: uses stored identity, but current disable/revoke still blocks.
• Flapping or revoke event arrives amid coalescible healthy updates: semantic transition is not discarded.
• Receipt/tombstone expires and an old callback is replayed: no new action authority.
• Schedule rules update after future instants are materialized: old identities do not silently duplicate or move.
• Dead-letter replay of an uncertain-effect workflow respects [FEATURE] VNext Phase 2 — secure generic execution envelope and side-effect recovery #336 reconciliation and cannot simply start the side effect again.

Next step

Implement the generic fixture seams first, including durable acknowledgement and cancellation under load. Keep #356/#190 production code absent from Phase7 tests. No new scheduler, listener, channel setup, model call, implementation or issue-state change was performed in this review.