15 lines
1.0 KiB
Markdown
15 lines
1.0 KiB
Markdown
|
|
# 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?
|