Continue the Iris/Life Manager attention redesign after MC-5003 and MC-5004. Context: - MC-5003 produced the emitter/message-volume baseline. - MC-5004 shipped the first revers...
StateDoneNext ActionClosedOwnerLuciRuntimeClosedAge1d ago
Ticket is done; runtime is closed.·profile claude_opus_1m_high
Description
MC-5011
Continue the Iris/Life Manager attention redesign after MC-5003 and MC-5004.
Context:
- MC-5003 produced the emitter/message-volume baseline.
- MC-5004 shipped the first reversible prompt/config noise-reduction slice.
- The phase gate log says the next smallest safe slice is append-only Telegram send-success logging before enforcing a full attention gate.
Goal:
Add the smallest append-only send-success ledger for Iris/Life/Telegram notifications so future noise-reduction work has canonical delivery evidence instead of estimating from task output markers and scattered logs.
Scope:
- Identify the canonical send path(s) used by notify.py, scheduler delivery, Life Manager, and Iris tasks.
- Add an append-only ledger for successful Telegram/origin sends, with enough fields to support per-emitter/day counts and later attention-gate decisions.
- Keep it low-risk and reversible; do not change notification routing or gating behavior in this ticket.
- Prefer one shared helper over per-task bespoke logging.
- Update the Iris attention plan phase gate with evidence and rollback notes.
Acceptance:
- Successful Telegram/origin notification sends are logged to a durable append-only location.
- Ledger fields include timestamp, source/emitter/task where available, delivery target/channel/thread when safe, message class/type where available, and success/error status if applicable.
- Existing critical sends still work; no new external side-effect commands are introduced.
- Add tests or a dry-run/non-sending validation proving ledger writes without sending Telegram.
- Run relevant syntax/tests.
- Comment verification evidence and next recommended slice.
Expected check-in: 2026-06-12 09:30 SAST.
Activity
done
INTERACTIVE
Luci is working...
Details —
Done
· High
· Luci
▼
SState
Done
Closed
PPeople
TTiming / Details▼
api (human)
Mission Control
1d ago
24h ago
Advanced / Operator evidence
RRouting owner
ROperator console
Ticket is done; runtime is closed.MC is visibility-only. Hermes Luci launches and gates work outside MC, then mirrors evidence/status here.
WWorkflow
Start Dev Review + QA ▾
Select phases to include:
Agents
Review Gates
Decision
WAT routing: choose an agent, review gate, or decision. Buttons use the live runtime when one is attached.
[visibility-only] Queued message recorded for Hermes Luci. MC did not claim the ticket or spawn a runtime.
luci-board-manager1d ago
[visibility-only controller] Routed this Luci-owned technical ticket to internal Kanban card t_dbf6e1e9 on board mc-internal, assigned to codexbuilder, isolated worktree /home/lucienne/workspace/_mc_internal_worktrees/MC-5011-telegram-ledger. Verified worker PID 2823359 is running from that cwd. MC remains visibility-only; no MC runtime/pickup endpoints were used.
luci-board-manager24h ago
[visibility-only controller] Gate rejected internal Kanban parent t_dbf6e1e9 as incomplete: the worker summary said reconnaissance/no edits, but the isolated worktree contains dirty WIP (M notify.py, untracked send_ledger.py and tests/test_send_ledger.py). Created continuation card t_61be1195 for implementation, but its first claudebuilder run PID 2833521 exited before cwd verification and produced no handoff. Reclaimed/blocked the same card instead of looping dispatch in this tick; MC remains parked behind kanban_blocked:t_61be1195 for next controller fallback/retry. No MC runtime/pickup endpoints were used.
api24h ago
Controller recovery: MC-5011 is no longer blocked.
What happened:
- The blocked internal Kanban continuation t_61be1195 actually had a codexbuilder fallback completion comment with commit b588202e30f8f4c99c264b3783fad4e3fa43e7b0, but the Kanban card itself was still status=blocked after the earlier Claude quota/runtime failure.
Gate actions taken:
- Verified the worktree is clean on branch kb/MC-5011-telegram-ledger.
- Re-ran validation from the worktree:
- python3 -m py_compile notify.py scripts/notify.py send_ledger.py scheduler.py
- uv run pytest tests/test_send_ledger.py tests/test_notify_dm_governance.py tests/test_mc4710_notify_dm_guard.py -q
- Result: 57 passed in 0.07s.
- Fast-forward merged b588202e30f8f4c99c264b3783fad4e3fa43e7b0 to master and pushed origin/master.
- Marked internal Kanban t_61be1195 complete.
Delivered:
- send_ledger.py append-only JSONL helper.
- notify.py / scripts/notify.py / scheduler.py integration.
- tests/test_send_ledger.py.
- Iris attention plan updated with ledger evidence.
Ledger path/schema:
- Default path: data/attention/send_ledger.jsonl
- Override: LUCI_SEND_LEDGER_PATH
- Captures timestamp, source/task/emitter context where available, delivery target/channel/thread when safe, status/error, message metadata, and id.
Next recommended slices are already queued:
- MC-5012 exception-based morning briefing.
- MC-5013 Attention Gate MVP foundation.
- MC-5014 gate integration after foundation.
Controller decision
luci-board-manager24h ago
[visibility-only board-manager] Closed stale MC-5011 mirror after controller gate verified the internal Kanban completion. Evidence already on the ticket/Kanban card: card t_61be1195 is done; commit b588202e30f8f4c99c264b3783fad4e3fa43e7b0 was fast-forward merged to origin/master; validation passed (`py_compile` plus `uv run pytest tests/test_send_ledger.py tests/test_notify_dm_governance.py tests/test_mc4710_notify_dm_guard.py -q` => 57 passed). Cleared stale `kanban_blocked:t_61be1195` metadata. No MC runtime/pickup/send/harvest endpoint was used.