From af35cd5be5f26ff8239fe2192c97582742fe8888 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Sat, 10 Oct 2026 08:59:14 +0000
Subject: [PATCH] docs(adr-0043,skill-automation): open-time notification is
 approval.requested; one-tap links stay remind()-only

ADR-0043's Issue bullet said open-time notification remained the flow
author's notify node. Since openNodeRequest publishes approval.requested
to each concrete approver on the slate the request opens on, that
sentence is false. The Status line carries the dated amendment marker and
the parenthesis carries the correction; the token table and every
decision are unchanged.

The automation skill's best practice 5 keeps the decision half (notify
the submitter of the outcome from the approve/reject edges), drops "the
node does not send", and names the double-notify trap: the opening
already tells each resolved approver, so no notify node for the opening.
The reference file sits at its token ceiling; the duplicated
approval_revise comment (it restated the "no config, no signal" sentence
above it) pays for the new text.

Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RdnZdPZH9ByduzPRWuH9tN
---
 docs/adr/0043-actionable-approval-links.md             | 10 ++++++----
 .../references/state-machines-and-approvals.md         |  8 ++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/docs/adr/0043-actionable-approval-links.md b/docs/adr/0043-actionable-approval-links.md
index 0b314126962..9ded55e1417 100644
--- a/docs/adr/0043-actionable-approval-links.md
+++ b/docs/adr/0043-actionable-approval-links.md
@@ -1,6 +1,6 @@
 # ADR-0043: Actionable approval links — single-use tokens with a session-less confirm page
 
-**Status**: Accepted — implemented (proposed 2026-06-12 · calibrated 2026-06-12)
+**Status**: Accepted — implemented (proposed 2026-06-12 · calibrated 2026-06-12) · **Amended** (2026-10-10, #22631 — open-time notification is the approvals service's own `approval.requested` topic, not a flow-authored `notify` node; see the Issue bullet under Mechanics. One-tap links stay `remind()`-only; the token table and every decision below are unchanged)
 **Deciders**: ObjectStack Protocol Architects
 **Builds on**: [ADR-0042](./0042-approval-sla-escalation.md) (reserved system actors, audit-first discipline), thread interactions (#1740), [ADR-0012/0030](./0030-notification-platform-convergence.md) (messaging + outbox)
 **Closes**: [#1743](https://github.com/objectstack-ai/objectstack/issues/1743)
@@ -37,9 +37,11 @@ GET-executes design gets requests approved by robots.
 - **Issue** (`issueActionTokens`): 256-bit random raw tokens, returned
   once, hashes stored. Wired into `remind()` — each pending approver with
   a concrete identity (not `role:*` literals) gets their **own**
-  notification carrying their own approve/reject links. (Open-time
-  notification remains the flow author's `notify` node; templates there
-  can adopt the same links later.)
+  notification carrying their own approve/reject links. (Amended
+  2026-10-10, #22631: open-time notification is the approvals service's
+  `approval.requested` topic, published by `openNodeRequest` to each
+  concrete approver on the slate the request opens on — PR #22625; it
+  carries no links, and one-tap links remain `remind()`-only.)
 - **Confirm page** (`GET /api/v1/approvals/act?token=…`): session-less
   minimal HTML rendered by the plugin on the host Hono app — request
   summary (flow label, record title, action) + a POST form. Invalid /
diff --git a/skills/objectstack-automation/references/state-machines-and-approvals.md b/skills/objectstack-automation/references/state-machines-and-approvals.md
index 575b0dad681..61e5f2d78fe 100644
--- a/skills/objectstack-automation/references/state-machines-and-approvals.md
+++ b/skills/objectstack-automation/references/state-machines-and-approvals.md
@@ -180,8 +180,6 @@ Three pieces author it:
   id: 'manager_review', type: 'approval', label: 'Manager Review',
   config: { approvers: [{ type: 'position', value: 'manager' }], lockRecord: true, maxRevisions: 2 },
 },
-// No config and no `waitEventConfig`: the window ends on the submitter's
-// explicit resubmit, not on a signal or a timer.
 { id: 'wait_revision', type: 'approval_revise', label: 'Awaiting Revision' },
 // …among the approval's edges…
 { id: 'rev',  source: 'manager_review', target: 'wait_revision',  label: 'revise' },
@@ -379,5 +377,7 @@ These are wired on the **graph**, not in node config:
    edits while pending — otherwise approvers chase a moving target.
 4. **Model rejection as a visible branch** — a back-edge to revise, or an `end`
    node to terminate. The path is on the diagram, not hidden in config.
-5. **Notify from downstream nodes** wired to the `approve` / `reject` edges
-   rather than expecting the node to send mail itself.
+5. **Notify the submitter from downstream nodes** wired to the `approve` /
+   `reject` edges. Opening already tells each resolved approver
+   (`approval.requested`); ⛔ no `notify` node for the opening: it tells
+   them twice.