docs(deploy): record candidate dependency closure gap

2026-08-31 14:13:40 +03:00
parent 2f085858db
commit d1710907ec
3 changed files with 74 additions and 14 deletions
@@ -0,0 +1,60 @@
+# GEN2-DEPLOY-004 r2 — candidate dependency-closure finding
+
+## Decision and graph evidence
+
+The owner-approved r2 rule requires every versioned Assistant runtime reached
+by normal candidate operation to be in the candidate ReleaseSet. Static
+runtime configuration establishes this candidate closure:
+
+```text
+creator-web -> core-runtime, continuity-runtime, commit-runtime,
+               cognitive-worker, agent-worker
+core-runtime -> cognitive-worker, research-runtime, continuity-runtime,
+                commit-runtime
+commit-runtime -> core-runtime, continuity-runtime
+continuity-runtime -> core-runtime, commit-runtime
+agent-worker -> task-verifier, agent-execution-bridge
+agent-execution-bridge -> cognitive-worker, work-graph-runtime, task-verifier
+work-graph-runtime -> core-runtime
+```
+
+Therefore the static closure is: Creator Web, Core Runtime, Cognitive Worker,
+Research Runtime, Commit Runtime, Continuity Runtime, Agent Worker, Agent
+Execution Bridge, Work Graph Runtime, and Task Verifier.
+
+PostgreSQL, protected secret volumes, the local model gateway/lifeboat, and
+the configured web-search endpoint are classified as shared durable
+infrastructure or shared external services. They do not contain an Assistant
+semantic/runtime release revision.
+
+## Blocking dynamic dependency
+
+Commit's normal prospective-notification operation obtains the exact active
+notification Capability binding from Core. The binding's immutable
+`HTTPSOrigin`, delivery path, and revision select the receiver. This is not a
+Compose environment URL and cannot be safely redirected by a container alias.
+
+Consequently, with the existing active binding, a candidate Commit executing a
+normal notification operation would call the stable notification receiver. A
+candidate notification-receiver container alone does not solve the problem:
+the candidate would still resolve the stable binding. Reusing the stable name
+would create ambiguous network routing, and changing the active binding would
+mutate Capability-owned canonical state.
+
+No runtime, Capability state, migration, secret, or production container was
+changed while establishing this finding.
+
+## Required owner decision
+
+Choose one governed boundary before DEPLOY-004 implementation can prove full
+dependency isolation:
+
+1. authorize a bounded Capability-owned candidate binding/shadow-binding
+   lifecycle, including its authority, rollback and selection semantics; or
+2. explicitly classify the notification receiver as a shared external service
+   for this ReleaseSet, despite it being an Assistant-managed runtime.
+
+The first option requires a new packet revision with the exact Capability
+contract/owner paths. The second changes the release-boundary policy and must
+be accepted explicitly. No direct binding update, stable alias reuse, or
+candidate-to-stable shortcut is an acceptable substitute.