[alex-clickhouse]

What

Nerve records who answered, snoozed or dismissed a notification, who created a silence rule, and who wrote and who reviewed a plan. Approval dispatchers get the person who decided. Plan decisions that change a plan's status become atomic.

How

• Migration v055 adds eight nullable foreign keys to actor_refs. Old rows stay empty, and the attribution column registry lists the new columns:
  • notifications.answered_by_actor_id, notifications.dismissed_by_actor_id;
  • notification_silences.created_by_actor_id, notification_silences.caused_by_actor_id;
  • plans.reviewed_by_actor_id, plans.reviewed_caused_by_actor_id, plans.created_by_actor_id, plans.caused_by_actor_id.
• Atomic decisions. A plan decision that changes the plan's status applies only while the plan still has the status that the decision read. This covers approve, decline, PATCH, and the planner replacing its plan. Of two such decisions, one applies and the other gets 409. So a plan starts one implementation, and a decline cannot overwrite an approval.
• Revisions. A revision request leaves the plan pending, as before. A revision and an approval of the same plan can still both proceed. This is existing behaviour and stays a follow-up.
• Plan authors. plan_propose and plan_update record the system actor and the session's cause as the writer of the new version.
• Approvals.
  • The person who decides an approval is written in the same update that claims it, so an approval that expires during its decision still names who decided.
  • A web snooze records who snoozed.
• Web routes. Answer, dismiss, dismiss-all and the silence routes record the signed-in person. Nerve relays the answer into the asking session as a message written by that person. The agent's work in that turn has the session's cause, like all its work in that session.
• Channel answers. Answers through Telegram, Slack or a hosted channel keep the provider user ID in metadata and record no person.
• Approval dispatchers receive the person who answered as the keyword argument actor (None for a channel answer). The mechanical-action audit log names the person's actor ID.
• Plan decisions through REST record the person as the reviewer, also on the task status change that an approval or a decline makes, and on the task note of a revision request. Plan tools and the silence tool record the system actor and the session's cause, so a plan that the agent approves in a session Alice started shows "Nerve for Alice".
• Implementation session. Its cause is the approver (REST) or the approving session's cause (tool).
• The WebSocket events notification_answered and answer_injected carry actor_id.
• UI. The notifications page shows who answered, who snoozed, who dismissed and who created each silence. The plan view shows who wrote and who reviewed the plan, also right after a decision in the same tab.

Why

These decisions start or stop work: an implementation session, a mechanical action, a review-loop leg. Recording the person completes the audit trail and gives that work the right cause, which is also the principal on its model requests (#516).

Behaviour changes

• Approve and PATCH return 409 when another status-changing decision changed the plan first.
• REST plan approval and decline record the task status change with the origin web instead of system.
• A relayed channel answer runs with no actor instead of the system actor.
• request_plan_revision takes a required actor argument. Every approval dispatcher must accept the actor keyword argument.
• Plan statuses and the plan pages are as on main, plus the reviewer and author labels.

Testing

• New tests for every path, including concurrent decisions and an approval that expires during its decision. External-mode tests check the principal on implementation and planner sessions.
• Full suite on this branch: 5879 passed, 39 skipped. Web: build ok, 732 tests passed.

Stack

1. Record each session's cause and who changes a task #515 Actor and cause plumbing; task attribution (base main)
2. Name the session's cause on each model request in external mode #516 Model requests name the session's cause
3. Record who changes a session, and who deletes it #517 Session change attribution
4. Record who answers notifications and reviews plans #518 (this PR): Notification answers, plan reviews and approval decisions
5. Record who starts, kills and decides workflow runs and review loops #519 Workflow runs and review loops
6. Record who schedules wakeups and starts cron runs, and run them for that person #520 Schedules: run-now, run-later and wakeups

🤖 Generated with Claude Code