[leggetter]

Fixes #117, and the issue-trigger half of #28.

evals-ci had no delivery issue trigger from 19 August, so alerting-001 has been measuring "create an alert from nothing" instead of what it was designed around. The cause is in the reset: the pristine snapshot records trigger ids and only deletes, so it:

• adopted a rewritten default as pristine (an early run rewrote the delivery default on 7 August, before the snapshot was taken)
• never recreated a deleted one (that rewrite was deleted by hand on 19 August as an orphan, A leftover from a crashed run becomes permanent project state #28)
• in CI, adopts whatever the last job left, because each fresh checkout takes a new snapshot

What changes

• DEFAULT_ISSUE_TRIGGERS declares the four triggers project creation makes, by content, read from the Event Gateway implementation. They carry channels: {}, per Mute issue trigger notifications on every reset #116.
• resetIssueTriggersToDefaults keeps the oldest trigger of each type and rewrites it to that content (configs, channels, name, enabled), creates any type that is missing, and deletes every other trigger.
• The gateway project's reset skips triggers in the id-based pass and runs this afterwards, on acquire and on release. A failure fails the acquire, like the rest of the reset; release stays best effort, and the Mute issue trigger notifications on every reset #116 mute still runs after it.
• The Outpost gateway guard now also checks the gateway key's live ids, because restored triggers get ids a persisted snapshot does not have.
• Tests that used issue triggers as a stand-in for "any snapshotted resource" now use sources; trigger behaviour has its own suite.

Verified against evals-ci

• Missing default: the delivery trigger was created (it_IEjWYWmhlQUMPd, first_attempt, *, channels: {}).
• Rewritten default: renamed, switched to final_attempt and disabled by hand, then restored in place by one reset.
• No churn: a second pass wrote nothing each time, so the comparison agrees with what the API returns.

The project now holds exactly the four defaults, muted.

This is an instrument change for alerting-001

The agent now starts from an enabled, wildcard delivery trigger with no channel: configured and silent, which is the failure the scenario exists to catch. Before 19 August it started from a rewritten trigger, and since then from none. Results either side are not comparable. It needs a three-attempt re-run across all six experiments before anything about it is published.

Review

An independent review found nothing blocking, and confirmed the declared configs field for field against the Event Gateway implementation. Fixed from it:

• the oldest-wins sort was untested: the API lists newest first and every fixture listed oldest first, so removing the sort passed; a fixture now lists newest first and fails without it
• a trigger type the list does not declare is most likely a new default, so deleting one now warns
• a test for the guard's live-id path, and its warning text and AGENTS.md now say "snapshot or live state"
• README no longer says triggers stay as they were

Checks

• pnpm -r test: all pass (hookdeck 70)
• pnpm typecheck, pnpm -r build, biome check .: clean

🤖 Generated with Claude Code