Skip to content

Loop canary: document notification smoke path #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Svaag merged 1 commit into from
Jun 21, 2026
Merged

Loop canary: document notification smoke path #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions docs/engineering-loop/notification-smoke-path.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# Engineering Loop notification smoke path

Each completed daemon cycle reports its outcome through two channels:

1. **Discord webhook** — a short summary showing the run result
(success, stuck, or over-budget), the change class, the risk tier,
and iteration/wall-clock stats.
2. **Icinga passive check** — the daemon submits `loop!engineering-loop`

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 21, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Correct the documented Icinga check name

The daemon does not submit to loop!engineering-loop: notify_icinga defaults HYRULE_ICINGA_CHECK to noc!engineering-loop, and the existing architecture notes describe the same service. When a NOC operator follows this smoke path without overriding that environment variable, they will inspect or configure the wrong Icinga service and miss whether the daemon heartbeat is actually reporting, so this should either use noc!engineering-loop or explicitly document the required override.

Useful? React with 👍 / 👎.

with the corresponding state:
- `OK` when the cycle completed and produced a draft PR
- `WARNING` when the cycle is stuck or exhausted its retry budget
- `CRITICAL` when the cycle failed outright or breached a hard gate

These are the Engineering Loop's own heartbeat/observability channels.
They do not replace the per-repo CI gates or the authoritative role
evaluators; they exist so the NOC can detect a silent or looping
daemon without reading pull-request bodies.