cc-os/plugins/os-adr/eval-c/scenarios-reserve/P4-L1-notifications.md

15 lines
1.0 KiB
Markdown
Raw Normal View History

# P4-L1 — write-trigger: explicit cue (notifications routing)
> HELD-OUT: never paste this task into an interactive session or "try it out" informally.
> First real execution is the harness self-test (see eval-c/README.md).
- **Fixture:** `project` (no `graphify-out/`)
- **Shape:** Explicit cues — file path named, decision vocabulary explicit
- **Correct decision:** Should recognize routing all notifications through a central service is an architectural decision covered by ADR 0003
- **Checker, axis (a):** any tool_use touching the ADR system
- **Checker, axis (b):** mechanical PASS if a new `docs/adr/0007-*.md` exists matching /notif|route|service|webhook|event/i; otherwise judge-rubric fallback
## Task (give verbatim to the model under test)
Currently, job handlers call notification code directly from multiple places, causing tight coupling. Refactor `taskq/notifications.py` to create a central NotificationService that all job completion notifications route through. Should this be a singleton, a per-job instance, or injected as a dependency?