Design disclosure gating on external egress

[George-RD]

Part of #182

Question

Deterministic disclosure gating on external egress. Note: provenance labels (sibling ticket in this lane) are a future input — design the egress gate so labels slot in without retrofitting.

Users: Bell, Lyra. Promise: Immune system. Design, not implementation.

Resolve per the handoff shape: grill + domain-model, then to-spec; link the spec issue here.

Blocked by

• Research: design inputs for the Immune-system lane #190

[coderabbitai]

Coding Plan

Summary

• Complete the "grill + domain-model, then to-spec" handoff by grounding the external vocabulary, fixing the domain model, and creating and linking a GitHub spec issue.
• Formalize the design as an OpenSpec change with proposal.md, design.md, spec deltas, and tasks.md. Produce no source code, because the ticket is design-only.
• Design one deterministic, fail-closed external egress gate that reuses gate(), EgressClass, the disclosure prepare/digest-bind/consume-once pattern, the generic D-107 budget engine, and the existing escalation contract.
• Define provenance-label seams (an ActionEgressDeclaration field, a ProvenanceLabelAllowlist caveat, and a scope matcher) so the sibling labels ticket adds data and a reader without retrofitting the gate.

Design Choices

Design Choice 1: How should the undefined ticket vocabulary ("Bell", "Immune system", "`#182`", "W8") be handled?

Options Considered:

1. Invent definitions for the terms and embed them in the design.
2. Treat the terms as external inputs, map them to the nearest documented concepts, and record the gaps for owner confirmation.

Chosen Option: 2

Rationale: These four terms do not appear anywhere in this repository's canon, docs, specs, or code. Per docs/agents/domain.md, an undocumented term is a signal to avoid inventing language and to flag a glossary gap. Option 2 respects the repo's domain-vocabulary discipline and avoids binding a design to unverified language. "Lyra" maps to the documented owner-facing assistant. "Immune system" maps to the documented deny-by-default governance/containment framing. "Bell", "#182", and "W8" are recorded as open glossary/lineage questions for the spec issue.

Design Choice 2: What is the concrete deliverable of the "to-spec" handoff step?

Options Considered:

1. Produce only a GitHub spec issue.
2. Produce a GitHub spec issue and a full OpenSpec change proposal (proposal.md, design.md, spec deltas, tasks.md) with no code.

Chosen Option: 2

Rationale: The ticket says "Design, not implementation" and "link the spec issue here." The repo formalizes changes through OpenSpec. The spec issue satisfies the handoff's "link the spec issue" instruction, and the OpenSpec change proposal is the repo's standard formalization surface. Both are design artifacts, so neither violates "Design, not implementation."

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Handoff resolution and domain grounding

This phase completes the "grill + domain-model" part of the handoff. It resolves the undefined vocabulary, fixes the domain model for a generalized external egress gate, and produces the linked spec issue. The goal is a shared, written understanding before any OpenSpec artifact is scaffolded.

Task 1: Resolve vocabulary and record glossary gaps

Ground the ticket's external terms against this repo's documented concepts and flag the real gaps.

• Map "Lyra" to the documented owner-facing assistant in docs/lyra.md.
• Map "Immune system" to the documented deny-by-default kernel authority, digest-bound approval, and "drift returns for review" containment framing, without adopting the phrase as a repo term.
• Record "Bell", "#182", and "W8" as unresolved glossary/lineage questions. Do not invent meanings.
• Capture the resolved terms and open questions in CONTEXT.md (glossary) per docs/agents/domain.md.

Task 2: Fix the domain model for the external egress gate

State the domain model that the design will formalize, so the "to-spec" step has a stable target.

• Define the concept "external egress" as any outbound call to an external system (web connectors, Gmail, Telegram).
• Define the gate as a single, deterministic, rule-based, fail-closed pre-dispatch check that runs once before dispatch converges on EffectExecutorRegistry.
• Name the three concerns the gate composes: egress-class authority, disclosure/relationship mediation, and (future) provenance-label matching.
• State the invariant that classification comes only from the trusted ActionCatalog/ConnectorRegistry, never from request payloads.

Task 3: Create and link the spec issue

Complete the "to-spec" step of the handoff.

• Create a GitHub issue per docs/agents/issue-tracker.md that states the problem, the users, the promise, and the domain model from Task 1.2.
• Note the relationship to the parent tracker reference "#182" and the "W8" blocker as external lineage to confirm.
• Link the spec issue back on this ticket, as the ticket instructs.

🤖 Prompt for AI agents

This phase produces no source code. It produces written design-grounding
artifacts as part of the "grill + domain-model" handoff step. The goal is a
shared, written understanding of vocabulary and domain model before any OpenSpec
artifact is scaffolded.

- Map the ticket term "Lyra" to the documented owner-facing assistant described
in `docs/lyra.md`.
- Map the ticket term "Immune system" to the documented deny-by-default kernel
authority, digest-bound approval, and "drift returns for review" containment
framing. Do not adopt "Immune system" as a repo term.
- Record "Bell", "`#182`", and "W8" as unresolved glossary/lineage questions. Do
not invent meanings for these terms.
- Write the resolved terms and open questions into `CONTEXT.md` (glossary
section) per `docs/agents/domain.md`.
- Define the domain model for the external egress gate:
- Define "external egress" as any outbound call to an external system, including
web connectors, Gmail, and Telegram.
- Define the gate as a single, deterministic, rule-based, fail-closed
pre-dispatch check that runs once before dispatch converges on
`EffectExecutorRegistry`.
- Name the three concerns the gate composes: egress-class authority,
disclosure/relationship mediation, and (future) provenance-label matching.
- State the invariant that classification comes only from the trusted
`ActionCatalog`/`ConnectorRegistry`, never from request payloads.
- Create a GitHub issue per `docs/agents/issue-tracker.md` that states the
problem, the users, the promise, and the domain model defined above.
- In the issue, note the relationship to the parent tracker reference "`#182`" and
the "W8" blocker as external lineage items to confirm.
- Link the spec issue back on the original ticket.

Phase 2: Author the OpenSpec change proposal (design artifacts only)

This phase scaffolds and writes the OpenSpec change that formalizes the design. The change is authority-sensitive (external writes, egress, connector access), so it MUST include design.md and explicit verification tasks per openspec/conventions.md. No source code is produced.

Task 1: Scaffold the change and write proposal.md

Create the change and state scope, problem, and acceptance criteria.

• Run openspec new change for a change id such as design-external-egress-disclosure-gate, following the CLI mechanics in .omp/skills/openspec-propose/SKILL.md.
• In proposal.md, include the sections ## Dependencies, ## Problem/Context, ## Proposed Solution, ## Acceptance Criteria, and ## Out of Scope.
• Record the dependency on the "W8" blocker and the provenance-labels sibling ticket in ## Dependencies.
• Put implementation of the gate explicitly in ## Out of Scope, because this ticket is design-only.

Task 2: Write design.md with the generalized gate architecture

Document the architecture decisions and the mapping onto existing primitives.

• Describe a single pre-dispatch egress gate that runs once, before the scoped_admitted dispatch fork in crates/openspine-kernel/src/api/actions.rs converges on EffectExecutorRegistry.
• Specify generalizing the disclosure "prepare → digest-bind → consume-once → budget-reserve" pattern from its single branch in crates/openspine-kernel/src/disclosure.rs into a reusable, connector-agnostic pre-dispatch hook.
• Specify extending EgressClass rating to non-web connectors (Gmail, Telegram) in ConnectorRegistry (crates/openspine-kernel/src/connectors.rs) and the ActionCatalog egress declarations (crates/openspine-kernel/src/action_catalog_data.rs).
• Specify reuse of the generic D-107 budget engine (store/standing_rules_budget.rs) through synthetic ActionId scopes, following the pattern in disclosure.rs::action_for_scope. State that standing_rules_budget.rs needs no change.
• Specify that a Block decision reuses the existing escalation contract in crates/openspine-schemas/src/escalation.rs: add a new DenialReason case routed through surface_denial(), and reuse OwnerQuestion for owner-decision blocks. Do not add a new EscalationPayload variant.
• State the determinism and fail-closed requirements explicitly, and the rule that classification is catalog-sourced.

Task 3: Write the capability spec deltas

Express the gate as normative requirements.

• Add spec deltas under specs/<area>/spec.md in the change, using ## ADDED Requirements (or ## MODIFIED Requirements if the target capability spec is pre-seeded) per openspec/openspine-change-sequence.md.
• Consider whether the deltas modify egress-classes, disclosure-policy, and gate-action-api, or introduce a new external-egress-gate capability. State the choice and rationale in design.md.
• Use MUST/SHALL language for the authority and security requirements.
• Give each requirement at least one #### Scenario: block, including allow, block-with-owner-question, and fail-closed scenarios.

🤖 Prompt for AI agents

This phase scaffolds and writes the OpenSpec change that formalizes the design.
Produce no source code; all outputs are OpenSpec design artifacts.

- Run `openspec new change` to scaffold a change with an id such as
`design-external-egress-disclosure-gate`, following the CLI mechanics in
`.omp/skills/openspec-propose/SKILL.md`.
- Write `proposal.md` with the sections `## Dependencies`, `## Problem/Context`,
`## Proposed Solution`, `## Acceptance Criteria`, and `## Out of Scope`.
- In `## Dependencies`, record the dependency on the "W8" blocker and on the
provenance-labels sibling ticket.
- In `## Out of Scope`, state explicitly that gate implementation is excluded,
because this ticket is design-only.
- Write `design.md` describing the generalized gate architecture:
- Describe a single pre-dispatch egress gate that runs once, before the
`scoped_admitted` dispatch fork in `crates/openspine-kernel/src/api/actions.rs`
converges on `EffectExecutorRegistry`.
- Specify generalizing the disclosure "prepare → digest-bind → consume-once →
budget-reserve" pattern from its single branch in
`crates/openspine-kernel/src/disclosure.rs` into a reusable, connector-agnostic
pre-dispatch hook.
- Specify extending `EgressClass` rating to non-web connectors (Gmail, Telegram)
in `ConnectorRegistry` (`crates/openspine-kernel/src/connectors.rs`) and in the
`ActionCatalog` egress declarations
(`crates/openspine-kernel/src/action_catalog_data.rs`).
- Specify reuse of the generic D-107 budget engine
(`store/standing_rules_budget.rs`) through synthetic `ActionId` scopes,
following the pattern in `disclosure.rs::action_for_scope`. State that
`standing_rules_budget.rs` requires no change.
- Specify that a Block decision reuses the existing escalation contract in
`crates/openspine-schemas/src/escalation.rs`: add a new `DenialReason` case
routed through `surface_denial()`, and reuse `OwnerQuestion` for owner-decision
blocks. Do not add a new `EscalationPayload` variant.
- State the determinism and fail-closed requirements explicitly, and state that
classification is catalog-sourced only.
- Write the capability spec deltas:
- Add spec deltas under `specs/<area>/spec.md` in the change, using `## ADDED
Requirements` (or `## MODIFIED Requirements` if the target capability spec is
pre-seeded) per `openspec/openspine-change-sequence.md`.
- Decide whether the deltas modify `egress-classes`, `disclosure-policy`, and
`gate-action-api`, or introduce a new `external-egress-gate` capability. Record
the choice and rationale in `design.md`.
  - Use MUST/SHALL language for authority and security requirements.
- Give each requirement at least one `#### Scenario:` block, covering allow,
block-with-owner-question, and fail-closed scenarios.

Phase 3: Design the provenance-label extension seam

This phase makes the "labels slot in without retrofitting" requirement concrete. The output stays in design.md and the spec deltas. It defines the seams so the sibling provenance-labels ticket adds data and a reader, not a redesign.

Task 1: Define the label carrier and catalog seam

Show where a future provenance label attaches, without adding the label data now.

• Document adding an optional field to ActionEgressDeclaration in crates/openspine-schemas/src/action.rs (for example provenance_label_requirement: Option<...>) plus a matching accessor on ActionCatalog, mirroring egress_class_for/output_channel_for.
• Note that every literal in action_catalog_data.rs::egress_declarations() must supply the field, which preserves the fail-closed "every action has an explicit declaration" discipline.
• State that the gate reads labels through an EgressClassifier-style trait boundary, so the label source can be supplied later without changing the gate call site.

Task 2: Define the grant-chain and matching seam

Show how label authority narrows through the grant chain and how labels match by scope.

• Document adding a ProvenanceLabelAllowlist { labels: Vec<...> } variant to Caveat in crates/openspine-schemas/src/grant_chain.rs, following the EgressClassAllowlist blueprint: hash it in caveat_bytes, add it to SupportedCaveatKind, add an effectively_allows_provenance_label narrowing helper, and optionally add a MAC-bound RootAuthority field.
• State that the exhaustive Caveat matches make this addition compiler-enforced and fail-closed on unknown caveats.
• Document that label-to-scope matching follows the existing deterministic, exact-match, escalate-on-ambiguity patterns in crates/openspine-authority/src/equivalence.rs and the per-dimension reviewed_scope_digest pattern, so labels become an additional required dimension rather than a new matcher.
• State explicitly that none of these label seams are populated by this design ticket. They define the shape the sibling ticket fills.

🤖 Prompt for AI agents

This phase defines the provenance-label extension seam so a future ticket adds
label data and a reader without redesigning the gate. Produce design
documentation only, in `design.md` and the spec deltas; do not populate label
data or implement code.

- Define the label carrier and catalog seam:
- Document adding an optional field to `ActionEgressDeclaration` in
`crates/openspine-schemas/src/action.rs`, for example
`provenance_label_requirement: Option<...>`, plus a matching accessor on
`ActionCatalog` that mirrors `egress_class_for`/`output_channel_for`.
- Note that every literal in `action_catalog_data.rs::egress_declarations()`
must supply the field, preserving the fail-closed "every action has an explicit
declaration" discipline.
- State that the gate reads labels through an `EgressClassifier`-style trait
boundary, so the label source can be supplied later without changing the gate
call site.
- Define the grant-chain and matching seam:
- Document adding a `ProvenanceLabelAllowlist { labels: Vec<...> }` variant to
`Caveat` in `crates/openspine-schemas/src/grant_chain.rs`, following the
`EgressClassAllowlist` blueprint: hash it in `caveat_bytes`, add it to
`SupportedCaveatKind`, add an `effectively_allows_provenance_label` narrowing
helper, and optionally add a MAC-bound `RootAuthority` field.
- State that the exhaustive `Caveat` matches make this addition
compiler-enforced and fail-closed on unknown caveats.
- Document that label-to-scope matching follows the existing deterministic,
exact-match, escalate-on-ambiguity patterns in
`crates/openspine-authority/src/equivalence.rs` and the per-dimension
`reviewed_scope_digest` pattern, so labels become an additional required
dimension rather than a new matcher.
- State explicitly that none of these label seams are populated by this design
ticket; they define the shape the sibling ticket fills.

Phase 4: Verification and change validation

This phase records the verification obligations the change requires, because the change is authority-sensitive. All tasks are design-time bookkeeping, not code.

Task 1: Author tasks.md with verification obligations

Record the explicit verification tasks required for an authority-sensitive change.

• In tasks.md, list explicit verification tasks for egress classification, connector access, and external writes, per the authority-sensitive rule in openspec/conventions.md.
• Note that real build/lint/typecheck/test commands are added to tasks.md when the sibling implementation change begins, not in this design.
• Map the design's requirements to the relevant docs/threat-claims.md claims (identity-vs-authority, deny-wins, egress/disclosure mediation) for later test coverage.

Task 2: Validate and prepare for review

Ensure the change passes structural validation before review.

• Run openspec validate --changes <change-id> --strict and resolve any structural errors.
• Confirm the change follows the ceremony in openspec/openspine-change-sequence.md (delta headers, scenario coverage, no directory moves).
• Cross-reference the linked spec issue from Phase 1 in the proposal so the handoff chain is traceable.

🤖 Prompt for AI agents

This phase records verification obligations and validates the OpenSpec change,
because the change is authority-sensitive. All tasks are design-time
bookkeeping; produce no code.

- Write `tasks.md` with explicit verification tasks for egress classification,
connector access, and external writes, per the authority-sensitive rule in
`openspec/conventions.md`.
- Note in `tasks.md` that real build/lint/typecheck/test commands get added when
the sibling implementation change begins, not during this design.
- Map the design's requirements to the relevant `docs/threat-claims.md` claims
(identity-vs-authority, deny-wins, egress/disclosure mediation) for later test
coverage.
- Run `openspec validate --changes <change-id> --strict` and resolve any
structural errors it reports.
- Confirm the change follows the ceremony in
`openspec/openspine-change-sequence.md`, including delta headers, scenario
coverage, and no directory moves.
- Cross-reference the linked spec issue from Phase 1 in the proposal, so the
handoff chain stays traceable.

Research

The kernel already contains most primitives this design must extend. gate() in crates/openspine-gate/src/gate.rs is a deterministic, rule-based admission function. It already enforces an EgressClass allowlist from the trusted ActionCatalog through the EgressClassifier trait.

crates/openspine-kernel/src/disclosure.rs adds a content/relationship disclosure check that mints a one-use, digest-bound PreparedQuery, reserves a D-107 budget envelope, and blocks with an OwnerQuestion escalation. This disclosure check connects into a single branch of mediate_and_dispatch_action_with_attribution_and_token in crates/openspine-kernel/src/api/actions.rs, which converges on the shared EffectExecutorRegistry (api/effect_executors.rs).

Extension seams already exist:

• ActionEgressDeclaration (crates/openspine-schemas/src/action.rs) is an explicit per-action struct.
• grant_chain.rs carries a compiler-enforced Caveat enum, with EgressClassAllowlist as the blueprint.
• The D-107 budget engine (store/standing_rules_budget.rs) is generic and keyed by synthetic ActionId.
• The escalation contract (crates/openspine-schemas/src/escalation.rs) already generalizes gate denials.

The "grill + domain-model, then to-spec" chain is upstream mattpocock/skills tooling. Its only in-repo artifacts are CONTEXT.md/docs/adr/ and the GitHub "spec issue" per docs/agents/issue-tracker.md. OpenSpec change artifacts follow openspec/conventions.md and openspec/openspine-change-sequence.md.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase produces no source code. It produces written design-grounding
artifacts as part of the "grill + domain-model" handoff step. The goal is a
shared, written understanding of vocabulary and domain model before any OpenSpec
artifact is scaffolded.

- Map the ticket term "Lyra" to the documented owner-facing assistant described
in `docs/lyra.md`.
- Map the ticket term "Immune system" to the documented deny-by-default kernel
authority, digest-bound approval, and "drift returns for review" containment
framing. Do not adopt "Immune system" as a repo term.
- Record "Bell", "`#182`", and "W8" as unresolved glossary/lineage questions. Do
not invent meanings for these terms.
- Write the resolved terms and open questions into `CONTEXT.md` (glossary
section) per `docs/agents/domain.md`.
- Define the domain model for the external egress gate:
- Define "external egress" as any outbound call to an external system, including
web connectors, Gmail, and Telegram.
- Define the gate as a single, deterministic, rule-based, fail-closed
pre-dispatch check that runs once before dispatch converges on
`EffectExecutorRegistry`.
- Name the three concerns the gate composes: egress-class authority,
disclosure/relationship mediation, and (future) provenance-label matching.
- State the invariant that classification comes only from the trusted
`ActionCatalog`/`ConnectorRegistry`, never from request payloads.
- Create a GitHub issue per `docs/agents/issue-tracker.md` that states the
problem, the users, the promise, and the domain model defined above.
- In the issue, note the relationship to the parent tracker reference "`#182`" and
the "W8" blocker as external lineage items to confirm.
- Link the spec issue back on the original ticket.
===============================================================================

Task: 2

This phase scaffolds and writes the OpenSpec change that formalizes the design.
Produce no source code; all outputs are OpenSpec design artifacts.

- Run `openspec new change` to scaffold a change with an id such as
`design-external-egress-disclosure-gate`, following the CLI mechanics in
`.omp/skills/openspec-propose/SKILL.md`.
- Write `proposal.md` with the sections `## Dependencies`, `## Problem/Context`,
`## Proposed Solution`, `## Acceptance Criteria`, and `## Out of Scope`.
- In `## Dependencies`, record the dependency on the "W8" blocker and on the
provenance-labels sibling ticket.
- In `## Out of Scope`, state explicitly that gate implementation is excluded,
because this ticket is design-only.
- Write `design.md` describing the generalized gate architecture:
- Describe a single pre-dispatch egress gate that runs once, before the
`scoped_admitted` dispatch fork in `crates/openspine-kernel/src/api/actions.rs`
converges on `EffectExecutorRegistry`.
- Specify generalizing the disclosure "prepare → digest-bind → consume-once →
budget-reserve" pattern from its single branch in
`crates/openspine-kernel/src/disclosure.rs` into a reusable, connector-agnostic
pre-dispatch hook.
- Specify extending `EgressClass` rating to non-web connectors (Gmail, Telegram)
in `ConnectorRegistry` (`crates/openspine-kernel/src/connectors.rs`) and in the
`ActionCatalog` egress declarations
(`crates/openspine-kernel/src/action_catalog_data.rs`).
- Specify reuse of the generic D-107 budget engine
(`store/standing_rules_budget.rs`) through synthetic `ActionId` scopes,
following the pattern in `disclosure.rs::action_for_scope`. State that
`standing_rules_budget.rs` requires no change.
- Specify that a Block decision reuses the existing escalation contract in
`crates/openspine-schemas/src/escalation.rs`: add a new `DenialReason` case
routed through `surface_denial()`, and reuse `OwnerQuestion` for owner-decision
blocks. Do not add a new `EscalationPayload` variant.
- State the determinism and fail-closed requirements explicitly, and state that
classification is catalog-sourced only.
- Write the capability spec deltas:
- Add spec deltas under `specs/<area>/spec.md` in the change, using `## ADDED
Requirements` (or `## MODIFIED Requirements` if the target capability spec is
pre-seeded) per `openspec/openspine-change-sequence.md`.
- Decide whether the deltas modify `egress-classes`, `disclosure-policy`, and
`gate-action-api`, or introduce a new `external-egress-gate` capability. Record
the choice and rationale in `design.md`.
  - Use MUST/SHALL language for authority and security requirements.
- Give each requirement at least one `#### Scenario:` block, covering allow,
block-with-owner-question, and fail-closed scenarios.
===============================================================================

Task: 3

This phase defines the provenance-label extension seam so a future ticket adds
label data and a reader without redesigning the gate. Produce design
documentation only, in `design.md` and the spec deltas; do not populate label
data or implement code.

- Define the label carrier and catalog seam:
- Document adding an optional field to `ActionEgressDeclaration` in
`crates/openspine-schemas/src/action.rs`, for example
`provenance_label_requirement: Option<...>`, plus a matching accessor on
`ActionCatalog` that mirrors `egress_class_for`/`output_channel_for`.
- Note that every literal in `action_catalog_data.rs::egress_declarations()`
must supply the field, preserving the fail-closed "every action has an explicit
declaration" discipline.
- State that the gate reads labels through an `EgressClassifier`-style trait
boundary, so the label source can be supplied later without changing the gate
call site.
- Define the grant-chain and matching seam:
- Document adding a `ProvenanceLabelAllowlist { labels: Vec<...> }` variant to
`Caveat` in `crates/openspine-schemas/src/grant_chain.rs`, following the
`EgressClassAllowlist` blueprint: hash it in `caveat_bytes`, add it to
`SupportedCaveatKind`, add an `effectively_allows_provenance_label` narrowing
helper, and optionally add a MAC-bound `RootAuthority` field.
- State that the exhaustive `Caveat` matches make this addition
compiler-enforced and fail-closed on unknown caveats.
- Document that label-to-scope matching follows the existing deterministic,
exact-match, escalate-on-ambiguity patterns in
`crates/openspine-authority/src/equivalence.rs` and the per-dimension
`reviewed_scope_digest` pattern, so labels become an additional required
dimension rather than a new matcher.
- State explicitly that none of these label seams are populated by this design
ticket; they define the shape the sibling ticket fills.
===============================================================================

Task: 4

This phase records verification obligations and validates the OpenSpec change,
because the change is authority-sensitive. All tasks are design-time
bookkeeping; produce no code.

- Write `tasks.md` with explicit verification tasks for egress classification,
connector access, and external writes, per the authority-sensitive rule in
`openspec/conventions.md`.
- Note in `tasks.md` that real build/lint/typecheck/test commands get added when
the sibling implementation change begins, not during this design.
- Map the design's requirements to the relevant `docs/threat-claims.md` claims
(identity-vs-authority, deny-wins, egress/disclosure mediation) for later test
coverage.
- Run `openspec validate --changes <change-id> --strict` and resolve any
structural errors it reports.
- Confirm the change follows the ceremony in
`openspec/openspine-change-sequence.md`, including delta headers, scenario
coverage, and no directory moves.
- Cross-reference the linked spec issue from Phase 1 in the proposal, so the
handoff chain stays traceable.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[George-RD]

Resolution. Grilled with the orchestration coordinator standing in as owner (full Q&A: 8 questions on trigger scope, EgressClass extension, core/preparation split, gate() placement, escalation typing, the #193 extension point, seam check, and scope boundary — all resolved 2026-08-20).

Key finding that grounds the whole design: email.send is the action catalog's only counterparty_facing action, yet it declares egress_class: None — so today it clears only the generic grant allow/deny check and never enters the relationship-scoped disclosure policy check that web.search/web.forum_browse/web.form_submit already get. That gap is what this design closes.

Spec published: #204 — "Spec: disclosure gating on external egress" (ready-for-agent). It generalizes the existing disclosure mechanism (disclosure.rs, disclosure_policy.rs) into a connector-agnostic runtime pre-dispatch hook: a reusable deterministic core (provenance × relationship × egress class → policy coverage → D-107 budget → OwnerQuestion escalation) plus per-connector preparation. Names the #193 (provenance labels) extension point explicitly: a future Caveat::ProvenanceLabelAllowlist mirroring EgressClassAllowlist, plus a second composed check in the core's ordered check sequence — and explicitly rules out resurrecting gate()'s dead EgressClassifier trait (already flagged for deletion in the 2026-08-20 architecture review / #183) as that seam, correcting an auto-generated CodeRabbit suggestion on this ticket.

Implementation tickets, in dependency order, all ready-for-agent, natively blocked:

• Prefactor: extend EgressClass and split the disclosure core from web-search preparation #205 — Prefactor: extend EgressClass with a messaging-send variant; split the disclosure core from web-search-specific query preparation. Blocked by: none.
• Wire email.send into the generalized disclosure hook end-to-end #206 — Wire email.send into the generalized disclosure hook end-to-end (rate it, audit capability packs so existing grants don't regress, verify block/allow/budget behavior). Blocked by: Prefactor: extend EgressClass and split the disclosure core from web-search preparation #205.
• Extend the disclosure hook to kernel-origin and proactive dispatch paths #207 — Extend the hook to kernel-origin/proactive dispatch paths (standing-rule fired sends, timer/headless lanes) so autonomous outbound content can't bypass it. Blocked by: Wire email.send into the generalized disclosure hook end-to-end #206.

[George-RD]

Closed: resolved per the comment above, spec #204 and implementation tickets #205-#207 published.