From 4e9bbd34c03aa679c4510ab34da75754a2c78aa9 Mon Sep 17 00:00:00 2001 From: Dotta Date: Sun, 25 Oct 2026 23:10:34 -0500 Subject: [PATCH] docs: identify response reactivation notification boundary Co-Authored-By: Paperclip --- ...6-10-25-native-response-presentation-sleep-audit.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/doc/plans/2026-10-25-native-response-presentation-sleep-audit.md b/doc/plans/2026-10-25-native-response-presentation-sleep-audit.md index a0d3a1138e6..018667c0df5 100644 --- a/doc/plans/2026-10-25-native-response-presentation-sleep-audit.md +++ b/doc/plans/2026-10-25-native-response-presentation-sleep-audit.md @@ -123,3 +123,13 @@ assertions that the new entry point rejects under actual source-action lock contention and returns false for the existing authorization/binding fences. The server typecheck passes (`/tmp/sleep48-contract-typecheck.log`). Worker discovery, producer notifications, startup wiring, and periodic removal are not implemented. + +## Existing notification boundary to reuse + +The current `notifyChatRunMilestones` boundary already covers 102 production call +sites and fans out lineage/authority changes to native progress, inbound notices, +confirmations, and GitHub work. Its scope is company plus optional issue because +source changes can authorize descendants. Audit its coverage for this duty before +adding caller wrappers. It already reaches status-decision settlement and run +projection, but raw coordinator-store/session release and accepted-turn journal +writers need individual inspection. Reuse is not proof that all producers exist.