Mine and match reusable authority by kernel-resolved scope

[George-RD]

What to build

Deepen action mediation per the architecture review: mine and match reusable authority by kernel-resolved scope. This is T17-T18 work building on the Effect Truth settlement (T3).

Acceptance criteria

1. Implement scoped authority matching logic. 2. Add tests covering scope overlap, drift, and resolution. 3. Document the matching algorithm and failure modes.

Blocked by

T3 (Effect Truth settlement, epic #198); Bell fit review

Fence: Do not start before the Bell fit review lands on build-on. Route through delivery vehicle in DIRECTION.md.

Original report

Why

The current standing-rule and reflection-miner path identifies reusable authority too coarsely:

• live standing-rule lookup matches only ActionId;
• the scheduled miner groups approvals by (artifact_id, action_id);
• repeated approvals across different mailboxes, recipients, conversations, connector instances, or counterparties can therefore look like one pattern;
• the proposal carries one source event rather than a complete evidence-set binding;
• generic action mediation currently constructs requests with no trusted target reference or target digest and derives string parameters from the shell payload;
• scope mismatch is therefore impossible to evaluate before budget reservation or dark-window scheduling;
• the store currently keeps effectively one active rule per action and activation revokes other active rules for that action, which cannot represent separate reviewed responsibilities for different accounts/relationships.

OpenSpine must learn the smallest safe repeatable context class, not merely that the same verb was approved twice.

Scope

1. Build the resolved context at the kernel boundary

For every delegatable action, the kernel must construct the ResolvedActionContext defined in #126 before reusable-authority consultation. The shell may provide an intent/reference token, but it cannot select trusted connector, account, target, counterparty, or bound parameter values.

For the Gmail draft proof, context must include at least:

• canonical action email.create_draft;
• stable Gmail connector-instance identity;
• owner-mailbox account identity/role;
• selected conversation/thread target;
• kernel-resolved recipient/counterparty identity;
• workflow/task-shape identity;
• immutable target and payload digests.

The exact reviewed scope may intentionally be broader than one thread (for example one mailbox + one bound relationship), but that widening must be explicit in the proposal and owner decision. It cannot be inferred from two unrelated approvals.

2. Evidence-class mining

Replace (artifact_id, action_id) counting with deterministic context-class grouping. Repeated approval evidence must prove:

• the same executable action descriptor/version;
• the same required scope dimensions;
• compatible workflow/task shape;
• at least the configured number of distinct owner approvals;
• an evidence-set digest and bounded list of encrypted source references.

If approvals differ on a required dimension, the miner must either produce separate narrow candidates or no authority proposal. It must never silently compute a wider least-common scope.

The candidate artifact identity must be scope-safe. Reusing the workflow/artifact ID for every candidate cannot represent multiple relationships/accounts and causes duplicate/version collisions. Define a stable logical responsibility/rule identity derived from reviewed semantics while keeping owner-readable names separate from digests.

3. Reviewed scope in standing-rule artifacts

Extend the standing-rule schema/store with the reviewed scope or a digest-bound reference to it. The serialized artifact must remain versioned, diffable, exportable, and re-confirmable.

The runtime row must index the dimensions needed for deterministic lookup without making the standing rule a second live authority object.

4. Multiple scoped rules and conflict resolution

Replace the current one-active-rule-per-action assumption.

• Multiple active rules for the same canonical action MUST be allowed when their reviewed scopes are disjoint or deterministically distinguishable.
• Activating a rule for relationship/account A MUST NOT revoke the independent rule for relationship/account B.
• Version replacement applies to the same logical scoped rule, not every rule sharing the action ID.
• If more than one active rule matches a live context, the kernel must use a settled deterministic rule: preferably exact/single match; any specificity ordering must be formally defined and proven non-widening.
• Ambiguous overlapping matches MUST fail closed to ordinary approval/needs_review rather than picking by insertion order/version alone.
• Budgets from multiple rules MUST NOT be summed, pooled, or opportunistically selected to extend authority.
• Scope amendment/widening creates a new reviewed version and conflict evaluation; it never silently merges active rules.

5. Match before reserve

On every live request:

1. run the normal grant/policy gate;
2. resolve trusted action context;
3. find exactly one compatible rule whose action descriptor and reviewed scope match;
4. only then reserve quota/rate or schedule a dark-window decision;
5. execute through Unify approved and delegated effect execution; fail closed on missing executors #127's shared effect executor.

A missing, changed, unresolved, stale, incompatible, or ambiguous scope must leave ApprovalRequired unchanged. It must consume no standing-rule budget and create no dark-window pending row.

6. Drift and invalidation

Move a rule to needs_review when any bound semantic dependency changes, including:

• action descriptor or executor version changes incompatibly;
• connector instance/account is removed or reconfigured;
• target/counterparty identity becomes unresolved, erased, or re-bound;
• workflow/task-shape authority changes;
• active policy newly denies the action;
• another activation creates an ambiguous overlap;
• repeated saturation or existing expiry triggers fire.

The normal gate must still deny immediately even before the lifecycle row is reconciled.

7. Dark-window restraint

Until #126 settles AD-012 for communication effects, scope mismatch, ambiguous overlap, and unresolved context must never schedule an Allow default. The first Gmail proof should ship with no dark-window Allow unless separately justified and tested.

TDD matrix

• Same action, same connector instance, same mailbox, same bound relationship: candidate may be proposed and matched.
• Same action, different mailbox: separate/no candidate; live reuse falls back before reserve.
• Gmail vs a second email connector implementing email.create_draft: no cross-connector reuse.
• Same mailbox, different recipient identity: separate scoped rules may coexist; neither revokes or consumes the other's budget.
• Two disjoint rules for the same action match their own contexts independently.
• Overlapping rules that both match one context fail closed and create no usage/timer row.
• Version bump replaces only the same logical scoped rule.
• Changed thread within an owner-approved relationship scope: matches only when that is the declared scope.
• Missing/expired/foreign selection token: no context and no consultation.
• Counterparty erasure/rebinding: dependent rule becomes unusable and enters review without affecting other scoped rules.
• Policy change between proposal and activation: activation fails or moves to review.
• Policy change after activation: gate denies immediately and reconciliation marks review.
• Scope mismatch with exhausted budget/dark-window configuration: no usage and no timer row.
• Concurrent final budget unit remains atomic after scope filtering.

Invariants

• No fuzzy model judgment in scope comparison or rule selection.
• Identity remains separate from authority; a bound identity is only one reviewed scope dimension.
• Context fields are kernel-derived and content-addressed where appropriate.
• Existing digest-bound per-instance approval remains valid and does not become broader automatically.
• The task grant remains the live authority object.
• Multiple responsibilities cannot pool authority merely because they share an action ID.

Done when

• The miner cannot call two different targets/accounts one repeated approval pattern.
• Every active communication standing rule carries reviewed non-action scope.
• Multiple disjoint scoped rules for one action coexist safely.
• Ambiguous overlaps fail closed without budget use.
• Live scope matching occurs before budget reservation and dark-window scheduling.
• Changed context reliably falls back to ordinary approval without leakage or budget use.
• Scope/evidence/conflict behavior is covered by protocol-neutral tests plus the Gmail matrix.

Relationship

Parent: #123.

Requires: #126 and #127.

Provides the context/evidence inputs required by #133.

Blocks the first complete Gmail delegation proof.

[George-RD]

Additional adversarial acceptance criteria

The existing miner slice currently has one important invariant worth preserving: load_owner_miner_audit_slice admits only GateDecision::Allow events whose reason is exactly OWNER_APPROVAL_GATE_REASON. Standing-rule effective allows and dark-window defaults therefore do not recursively count as new owner approvals today.

Make this explicit in the scoped-evidence design and tests:

• only distinct, principal-authenticated owner decisions may contribute to repeated-approval evidence;
• standing-rule auto-allows, fired defaults, workflow/model/worker allows, retries, and receipts never increase the approval count;
• one owner approval cannot be counted twice through multiple audit rows or replay;
• an approval must bind the exact resolved-context/effect digest used for the evidence class;
• evidence consumption/proposal generation must be idempotent across scheduled miner ticks.

Also replace the current dark-window fingerprint (action, grant, chat, payload) with one bound to the canonical resolved action context and target digest. The present fingerprint is request-specific but does not establish that the pending default belongs to the reviewed scope.

[coderabbitai]

Coding Plan

Summary

• Define ResolvedActionContext and a canonical, comparable ReviewedScope in schemas, composing existing identity types and adding an action-descriptor version and a bounded evidence set.
• Resolve the trusted context at the generic mediation boundary in api/actions.rs, route dispatch through a formalized shared effect executor, and populate target and payload digests generically.
• Persist reviewed scope on the standing-rule artifact and runtime row, and match the reviewed scope exactly before any budget reservation or dark-window scheduling.
• Replace coarse miner grouping with deterministic context-class grouping and evidence-set digests, add drift-to-needs_review triggers for bound-dependency changes, and enforce dark-window restraint for the first Gmail proof.

Design Choices

Design Choice 1: Ticket requires `#126` (`ResolvedActionContext`) and `#127` (shared effect executor), but neither exists in the codebase.

Options Considered:

1. Treat #126/Unify approved and delegated effect execution; fail closed on missing executors #127 as external prerequisites and only wire against assumed types.
2. Define minimal ResolvedActionContext and formalize a shared effect executor as part of this work.

Chosen Option: 2

Rationale: The ticket blocks the Gmail proof and both types are absent, so this plan must create them to deliver an end-to-end result.

Design Choice 2: How the reviewed scope is stored on the standing-rule artifact and runtime row.

Options Considered:

1. Store the full reviewed scope inline in the manifest YAML and store only a scope digest on the runtime row.
2. Store the reviewed scope only as a digest on both artifact and row.

Chosen Option: 1

Rationale: Inline scope in the YAML keeps the artifact diffable, versioned, exportable, and re-confirmable. A derived scope digest plus a small set of indexed columns on the runtime row supports deterministic lookup without duplicating full scope into SQLite.

Design Choice 3: How the "action descriptor/version" dimension is represented, since no per-action version exists today.

Options Considered:

1. Add an action-descriptor version to the ActionCatalog and record it on the resolved context and reviewed scope.
2. Reuse ActionRequest.schema_version as a proxy.

Chosen Option: 1

Rationale: The ticket needs incompatible-descriptor drift detection. This requires a version owned by the catalog descriptor, not the request envelope.

💡 User Tips

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

Implementation Steps

Phase 1: Define resolved context and canonical reviewed scope (schemas)

This phase adds the data model that all later phases consume. It defines ResolvedActionContext, a canonical ReviewedScope identity type, an action-descriptor version, and an evidence-set type. It keeps identity separate from authority and makes scope fields content-addressed.

Task 1: Define `ResolvedActionContext`

Create the kernel-resolved context that represents a single delegatable action at the mediation boundary.

• Add a ResolvedActionContext struct in crates/openspine-schemas/src/ (new module, for example resolved_action_context.rs).
• Compose existing identity types rather than reinventing them: canonical ActionId plus an action-descriptor version; connector instance identity as the Connector enum plus channel_account; account role from the existing AccountRole; the selected target from TargetRef; the counterparty from CounterpartyRef; the workflow/task shape from TaskShape; immutable target_digest and payload digest.
• Mark shell-supplied fields as untrusted intent only. The struct must be constructible only by kernel code. Keep its fields kernel-derived and document that the shell provides at most a reference token.

Task 2: Define the canonical `ReviewedScope` identity

Create the deterministic, comparable scope identity used for mining and matching.

• Add a ReviewedScope struct in crates/openspine-schemas/src/ next to ResolvedActionContext.
• Follow the AuthorityClassId pattern in crates/openspine-authority/src/equivalence.rs: implement Eq/Ord, use a sealed constructor, and derive a stable scope digest with digest::digest_of over a canonical encoding.
• Include exactly the required scope dimensions from the ticket: action descriptor and version, connector instance identity, account role, target/counterparty dimension, and workflow/task-shape identity.
• Provide a projection from a ResolvedActionContext to a ReviewedScope and an exact-match comparison. Do not compute a least-common wider scope.

Task 3: Add action-descriptor version and evidence-set types

Add supporting model elements the later phases require.

• Add an action-descriptor version to the ActionCatalog descriptor in crates/openspine-schemas/src/action.rs and populate it in crates/openspine-kernel/src/action_catalog_data.rs.
• Replace the single ReflectionProvenance with a bounded EvidenceSet in crates/openspine-schemas/src/reflection_miner.rs: a bounded Vec of {event_id, exchange} references plus a digest over the sorted set. Enforce a maximum set size, following the grant.limits.max_artifacts bound precedent.

🤖 Prompt for AI agents

Implement the data model foundation for reusable-authority scoping. Goal: define
`ResolvedActionContext`, a canonical `ReviewedScope` identity, an
action-descriptor version, and an evidence-set type in the schemas crate.

- Add a `ResolvedActionContext` struct in a new module under
`crates/openspine-schemas/src/` (for example `resolved_action_context.rs`).
Compose it from existing identity types instead of creating new ones: canonical
`ActionId` plus an action-descriptor version; connector instance identity as the
`Connector` enum plus `channel_account`; account role from the existing
`AccountRole`; the selected target from `TargetRef`; the counterparty from
`CounterpartyRef`; workflow/task shape from `TaskShape`; and immutable
`target_digest` and payload digest fields. Ensure the struct is constructible
only by kernel code. Document that shell-supplied fields are untrusted intent
only, and that the shell can supply at most a reference token.

- Add a `ReviewedScope` struct next to `ResolvedActionContext`, following the
`AuthorityClassId` equivalence pattern in
`crates/openspine-authority/src/equivalence.rs`: implement `Eq`/`Ord`, use a
sealed constructor, and derive a stable scope digest with `digest::digest_of`
over a canonical encoding. Include exactly these scope dimensions: action
descriptor and version, connector instance identity, account role,
target/counterparty dimension, and workflow/task-shape identity. Provide a
projection function from `ResolvedActionContext` to `ReviewedScope` and an
exact-match comparison function. Do not implement any least-common wider scope
computation.

- Add an action-descriptor version field to the `ActionCatalog` descriptor in
`crates/openspine-schemas/src/action.rs`, and populate it in
`crates/openspine-kernel/src/action_catalog_data.rs`.

- Replace the single `ReflectionProvenance` type with a bounded `EvidenceSet` in
`crates/openspine-schemas/src/reflection_miner.rs`. The `EvidenceSet` holds a
bounded `Vec` of `{event_id, exchange}` references plus a digest over the sorted
set. Enforce a maximum set size, following the precedent set by
`grant.limits.max_artifacts`.

Phase 2: Resolve context and route through a shared effect executor (kernel)

This phase builds the resolved context at the generic mediation boundary and formalizes the shared effect executor. It removes the current gap where target_ref and target_digest are always None and where non-string payload values are dropped.

Task 1: Add a context-resolution step at the mediation boundary

Resolve the trusted action context after the pure gate decision and before reusable-authority consultation.

• Create a new kernel module (for example crates/openspine-kernel/src/resolved_context.rs), following the sibling pattern of standing_rules_gate.rs, so gate() stays pure and its call sites stay unchanged.
• Resolve connector instance identity through ConnectorRegistry in crates/openspine-kernel/src/connectors.rs, account role and target from the kernel-minted SelectionToken in crates/openspine-kernel/src/pipeline/selection.rs, counterparty identity from the store, and workflow/task shape from the grant's route_id/workflow_id.
• Compute immutable target and payload digests here, not in the shell.
• Invoke this step in mediate_and_dispatch_action_with_attribution_and_token in crates/openspine-kernel/src/api/actions.rs, right after gate() returns and before the standing-rule branch.
• Return an unresolved outcome when any required dimension cannot be resolved. An unresolved context must leave the decision at ApprovalRequired.

Task 2: Formalize the shared effect executor

Route dispatch through one executor that carries the resolved context.

• Formalize the mediate_and_dispatch_action* family in crates/openspine-kernel/src/api/actions.rs as the shared effect executor described in #127.
• Pass the ResolvedActionContext into the executor and use it to populate ActionRequest.target_ref and ActionRequest.target_digest generically, instead of the current hard-coded None.
• Keep the existing email.create_draft digest binding in crates/openspine-kernel/src/api/proposal.rs and crates/openspine-kernel/src/pipeline/approval_draft.rs behavior-compatible. The executor must produce the same digest shape so existing digest-bound per-instance approval stays valid and does not widen.

Task 3: Wire the Gmail draft context

Build the concrete resolved context for the first Gmail proof.

• Populate ResolvedActionContext for email.create_draft with the stable Gmail connector-instance identity, owner-mailbox account role, selected thread target, kernel-resolved recipient/counterparty identity, workflow/task-shape identity, and immutable target and payload digests.
• Reuse the recipient resolution in crates/openspine-kernel/src/gmail.rs (newest_non_owner_recipient) so the counterparty dimension is kernel-derived, not shell-selected.

🤖 Prompt for AI agents

Implement the resolved-context step at the mediation boundary and formalize the
shared effect executor. Goal: build a trusted, kernel-derived
`ResolvedActionContext` for each action and route dispatch through it, replacing
the current always-`None` `target_ref`/`target_digest` gap.

- Create a new kernel module (for example
`crates/openspine-kernel/src/resolved_context.rs`), following the sibling
pattern of `standing_rules_gate.rs`, so that `gate()` in
`crates/openspine-gate/src/gate.rs` stays pure and unchanged. In this module,
resolve: connector instance identity through `ConnectorRegistry` in
`crates/openspine-kernel/src/connectors.rs`; account role and target from the
kernel-minted `SelectionToken` in
`crates/openspine-kernel/src/pipeline/selection.rs`; counterparty identity from
the store; and workflow/task shape from the grant's `route_id`/`workflow_id`.
Compute immutable target and payload digests in this kernel step, not in the
shell.

- Invoke the context-resolution step inside
`mediate_and_dispatch_action_with_attribution_and_token` in
`crates/openspine-kernel/src/api/actions.rs`, immediately after `gate()` returns
and before the standing-rule branch executes. If any required dimension cannot
be resolved, return an unresolved outcome and keep the decision at
`ApprovalRequired`.

- Formalize the `mediate_and_dispatch_action*` function family in
`crates/openspine-kernel/src/api/actions.rs` as the shared effect executor. Pass
the `ResolvedActionContext` into the executor and use it to populate
`ActionRequest.target_ref` and `ActionRequest.target_digest` generically,
replacing the current hard-coded `None`. Keep the existing `email.create_draft`
digest binding in `crates/openspine-kernel/src/api/proposal.rs` and
`crates/openspine-kernel/src/pipeline/approval_draft.rs` behavior-compatible:
the executor must produce the same digest shape so existing digest-bound
per-instance approval stays valid and does not widen.

- Wire the concrete Gmail draft context: populate `ResolvedActionContext` for
`email.create_draft` with the stable Gmail connector-instance identity,
owner-mailbox account role, selected thread target, kernel-resolved
recipient/counterparty identity, workflow/task-shape identity, and immutable
target and payload digests. Reuse the recipient resolution function
`newest_non_owner_recipient` in `crates/openspine-kernel/src/gmail.rs` so the
counterparty dimension is kernel-derived, not shell-selected.

Phase 3: Reviewed scope in the standing-rule artifact and store, matched before reserve (kernel + schemas + store)

This phase persists the reviewed scope and enforces exact scope matching before any budget reservation or dark-window scheduling.

Task 1: Add reviewed scope to the standing-rule artifact

Extend the manifest while preserving versioning, diffability, export, and re-confirmation.

• Add an optional reviewed_scope field to StandingRuleManifest in crates/openspine-schemas/src/standing_rule.rs, following the additive dark_window precedent (#[serde(default)], keep deny_unknown_fields, do not bump schema_version for the additive shape).
• Extend StandingRuleManifest::validate() to require a reviewed scope for communication actions, so every active communication rule carries reviewed non-action scope.
• Confirm no changes are needed in overlay_export_restore/bundle.rs or pipeline/artifact_reconfirmation.rs, because both are kind-generic over the YAML file.

Task 2: Persist and index reviewed scope on the runtime row

Store the scope digest and the minimal dimensions needed for deterministic lookup.

• Extend the StandingRule row and the standing_rules table in crates/openspine-kernel/src/store/standing_rules.rs with a scope_digest column and the small set of indexed dimension columns needed for lookup (for example connector instance, account role, counterparty, workflow/task shape).
• Add a store migration in crates/openspine-kernel/src/store/migrations.rs, following the additive ALTER TABLE ... ADD COLUMN precedent used for skills.
• Update the activation path (activate_standing_rule_in_tx) to populate these columns from the manifest reviewed scope. Keep the superseding-revoke behavior, but partition it by the reviewed scope, not by action_id alone.

Task 3: Match reviewed scope exactly before reserving

Enforce the match-before-reserve ordering.

• Change consult_and_reserve_standing_rule in crates/openspine-kernel/src/store/standing_rules_budget.rs to filter on the action descriptor and the scope digest, and to compare the reviewed scope exactly, before any usage-row reservation or dark-window scheduling.
• Split the lookup/expiry phase from the reservation phase inside the same BEGIN IMMEDIATE transaction, so the match is a distinct checkpoint that preserves the existing atomic quota/rate guarantee.
• Thread the ResolvedActionContext (or its ReviewedScope) through consult_standing_rule_gate in crates/openspine-kernel/src/standing_rules_gate.rs and its call in crates/openspine-kernel/src/api/actions.rs.
• Guarantee that a missing, changed, unresolved, stale, or incompatible scope returns no match. A non-match must consume no budget, create no dark-window pending row, and leave the decision at ApprovalRequired.

🤖 Prompt for AI agents

Implement reviewed-scope persistence on the standing-rule artifact and runtime
row, and enforce exact scope matching before any budget reservation or
dark-window scheduling. Goal: make the standing-rule match dependent on the
reviewed scope, not on `ActionId` alone.

- Add an optional `reviewed_scope` field to `StandingRuleManifest` in
`crates/openspine-schemas/src/standing_rule.rs`. Follow the additive
`dark_window` precedent: use `#[serde(default)]`, keep `deny_unknown_fields`,
and do not bump `schema_version` for this additive shape. Extend
`StandingRuleManifest::validate()` to require a reviewed scope for communication
actions, so every active communication rule carries a reviewed non-action scope.
Confirm that no changes are needed in `overlay_export_restore/bundle.rs` or
`pipeline/artifact_reconfirmation.rs`, since both are kind-generic over the YAML
file.

- Extend the `StandingRule` row and the `standing_rules` table in
`crates/openspine-kernel/src/store/standing_rules.rs` with a `scope_digest`
column and a small set of indexed dimension columns needed for lookup (for
example connector instance, account role, counterparty, workflow/task shape).
Add a store migration in `crates/openspine-kernel/src/store/migrations.rs`,
following the additive `ALTER TABLE ... ADD COLUMN` precedent used for skills.
Update the activation path `activate_standing_rule_in_tx` to populate these
columns from the manifest reviewed scope. Keep the superseding-revoke behavior,
but partition it by the reviewed scope instead of by `action_id` alone.

- Change `consult_and_reserve_standing_rule` in
`crates/openspine-kernel/src/store/standing_rules_budget.rs` to filter on the
action descriptor and the scope digest, and to compare the reviewed scope
exactly, before any usage-row reservation or dark-window scheduling. Split the
lookup/expiry phase from the reservation phase inside the same `BEGIN IMMEDIATE`
transaction, so the match is a distinct checkpoint. Preserve the existing atomic
quota/rate guarantee.

- Thread the `ResolvedActionContext` (or its `ReviewedScope`) through
`consult_standing_rule_gate` in
`crates/openspine-kernel/src/standing_rules_gate.rs` and its call site in
`crates/openspine-kernel/src/api/actions.rs`.

- Guarantee that a missing, changed, unresolved, stale, or incompatible scope
results in no match. A non-match must consume no budget, must create no
dark-window pending row, and must leave the decision at `ApprovalRequired`.

Phase 4: Evidence-class mining (kernel + schemas)

This phase replaces coarse (artifact_id, action_id) counting with deterministic context-class grouping and a complete evidence-set binding.

Task 1: Group approvals by context class

Derive candidates from a canonical scope key.

• Change derive_repeated_approval_observation in crates/openspine-kernel/src/reflection_miner_runtime/scheduled.rs to group audit entries by a context-class key derived from the same reviewed scope dimensions (action descriptor and version, required scope dimensions, and compatible workflow/task shape), instead of (artifact_id, action_id).
• Require at least the configured number of distinct owner approvals within one context class.
• When approvals differ on a required dimension, produce separate narrow candidates or no candidate. Never compute a wider least-common scope.

Task 2: Carry an evidence-set digest and bounded source references

Bind the full evidence set into the proposal.

• Update ApprovalObservation and the EvidenceSet usage in crates/openspine-schemas/src/reflection_miner.rs to carry the bounded set of encrypted source references and the evidence-set digest.
• Update OrdinaryMinerGrant::provenance_in_briefcase and audit_entries_for so both operate over the same context-class key and verify that every evidence member is present in the briefcase.
• Update dispatch_reflection_proposal in crates/openspine-kernel/src/reflection_miner_runtime.rs to write all evidence exchanges as target_refs on the reflection.miner.provenance audit row, instead of a single reference.

Task 3: Emit reviewed scope in the proposed artifact

Carry the learned scope into the standing-rule proposal.

• Update ReflectionProposal::to_proposal_payload() in crates/openspine-schemas/src/reflection_miner_payload.rs to serialize the mined reviewed_scope into the StandingRuleManifest YAML, so the widening is explicit in the proposal and the owner decision.

🤖 Prompt for AI agents

Implement deterministic context-class grouping for the reflection miner and bind
full evidence sets into proposals. Goal: replace coarse `(artifact_id,
action_id)` counting with grouping by reviewed-scope dimensions, and carry a
complete, digest-bound evidence set.

- Change `derive_repeated_approval_observation` in
`crates/openspine-kernel/src/reflection_miner_runtime/scheduled.rs` to group
audit entries by a context-class key derived from the reviewed scope dimensions:
action descriptor and version, required scope dimensions, and compatible
workflow/task shape. Remove the `(artifact_id, action_id)` grouping. Require at
least the configured number of distinct owner approvals within one context
class. When approvals differ on a required dimension, produce separate narrow
candidates, or no candidate. Do not compute a wider least-common scope under any
circumstance.

- Update `ApprovalObservation` and the `EvidenceSet` usage in
`crates/openspine-schemas/src/reflection_miner.rs` to carry the bounded set of
encrypted source references plus the evidence-set digest. Update
`OrdinaryMinerGrant::provenance_in_briefcase` and `audit_entries_for` so both
operate over the same context-class key and verify that every evidence member is
present in the briefcase.

- Update `dispatch_reflection_proposal` in
`crates/openspine-kernel/src/reflection_miner_runtime.rs` to write all evidence
exchanges as `target_refs` on the `reflection.miner.provenance` audit row,
replacing the single-reference behavior.

- Update `ReflectionProposal::to_proposal_payload()` in
`crates/openspine-schemas/src/reflection_miner_payload.rs` to serialize the
mined `reviewed_scope` into the `StandingRuleManifest` YAML, so scope widening
is explicit in the proposal presented for owner decision.

Phase 5: Drift, invalidation, and dark-window restraint (kernel)

This phase adds the drift triggers and enforces dark-window restraint for communication effects.

Task 1: Move rules to `needs_review` on bound-dependency drift

Reconcile the lifecycle row when a bound scope dimension changes.

• Extend the standing-rule lifecycle handling in crates/openspine-kernel/src/store/standing_rules.rs and standing_rules_budget.rs to flip status to needs_review (and set needs_review_since) on: incompatible action-descriptor or executor version change; connector instance or account removal or reconfiguration; counterparty identity becoming unresolved, erased, or re-bound; workflow/task-shape authority change; and active policy newly denying the action. Preserve the existing saturation and expiry triggers.
• Subscribe drift reconciliation to existing signals: the counterparty.erased audit event and closure marker in crates/openspine-kernel/src/counterparty_erasure.rs, and the connector health state in crates/openspine-kernel/src/connectors.rs and connector_reality.rs.
• Keep the normal gate authoritative. The gate must deny immediately even before the lifecycle row is reconciled.

Task 2: Enforce policy re-check at activation

Fail closed on policy change between proposal and activation.

• In the standing-rule activation path (activate_standing_rule / activate_standing_rule_in_tx in crates/openspine-kernel/src/store/standing_rules.rs), re-check the active policy for the reviewed scope. If the active policy denies the action, fail activation or move the row to needs_review.

Task 3: Apply dark-window restraint for communication effects

Prevent an Allow default on unresolved or mismatched scope.

• In consult_standing_rule_gate in crates/openspine-kernel/src/standing_rules_gate.rs, ensure that scope mismatch or unresolved context never schedules an Allow default and never creates a dark-window pending row.
• Ship the first Gmail proof with no dark-window Allow for email.create_draft unless separately justified.

🤖 Prompt for AI agents

Implement drift-to-`needs_review` triggers, policy re-check at activation, and
dark-window restraint. Goal: keep standing rules aligned with their bound scope
dimensions and prevent silent widening through dark-window Allow defaults.

- Extend the standing-rule lifecycle handling in
`crates/openspine-kernel/src/store/standing_rules.rs` and
`standing_rules_budget.rs` to flip a rule's status to `needs_review` and set
`needs_review_since` on any of these events: incompatible action-descriptor or
executor version change; connector instance or account removal or
reconfiguration; counterparty identity becoming unresolved, erased, or re-bound;
workflow/task-shape authority change; or active policy newly denying the action.
Preserve the existing saturation and expiry triggers unchanged.

- Subscribe drift reconciliation to existing signals: the `counterparty.erased`
audit event and closure marker in
`crates/openspine-kernel/src/counterparty_erasure.rs`, and the connector health
state exposed by `crates/openspine-kernel/src/connectors.rs` and
`connector_reality.rs`. Keep the normal gate authoritative at all times: the
gate must deny immediately, even before the lifecycle row has been reconciled to
`needs_review`.

- In the standing-rule activation path (`activate_standing_rule` and
`activate_standing_rule_in_tx` in
`crates/openspine-kernel/src/store/standing_rules.rs`), re-check the active
policy for the reviewed scope. If the active policy denies the action, fail
activation, or move the row to `needs_review`.

- In `consult_standing_rule_gate` in
`crates/openspine-kernel/src/standing_rules_gate.rs`, ensure a scope mismatch or
an unresolved context never schedules an Allow default and never creates a
dark-window pending row. Ship the first Gmail proof with no dark-window Allow
for `email.create_draft`, unless separately justified.

Phase 6: Tests (protocol-neutral matrix plus Gmail matrix)

This phase adds the coverage the ticket lists as done-when conditions.

Task 1: Protocol-neutral scope-matching and mining tests

Cover grouping, matching, and fallback.

• Add mining tests near crates/openspine-schemas/src/reflection_miner_tests.rs and crates/openspine-kernel/src/store/reflection_miner_support.rs for: same-context-class candidate creation, dimension-mismatch producing separate or no candidate, distinct-approval counting, and evidence-set digest binding.
• Add match-before-reserve tests near crates/openspine-kernel/src/store/standing_rule_scheduling_tests.rs and crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs for: no-match leaving ApprovalRequired with no budget and no timer row, and concurrent final budget unit remaining atomic after scope filtering.
• Add drift tests for counterparty erasure and post-activation policy change moving the rule to needs_review while the gate denies immediately.

Task 2: Gmail matrix tests

Cover the ticket TDD matrix for email.create_draft.

• Add Gmail-path tests covering: same connector, mailbox, and bound relationship matching; different mailbox not reusing; a second email connector not reusing; different recipient not reusing without explicit broader scope; changed thread within an approved relationship scope; and missing, expired, or foreign selection token producing no context and no consultation.

🤖 Prompt for AI agents

Implement the test coverage required by the ticket's done-when conditions, split
into a protocol-neutral matrix and a Gmail-specific matrix.

- Add mining tests near `crates/openspine-schemas/src/reflection_miner_tests.rs`
and `crates/openspine-kernel/src/store/reflection_miner_support.rs` covering:
same-context-class candidate creation; dimension-mismatch producing separate
candidates or no candidate; distinct-approval counting; and evidence-set digest
binding.

- Add match-before-reserve tests near
`crates/openspine-kernel/src/store/standing_rule_scheduling_tests.rs` and
`crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs` covering: a
no-match case that leaves the decision at `ApprovalRequired` with no budget
consumed and no timer row created; and a concurrent scenario where the final
budget unit remains atomic after scope filtering.

- Add drift tests for counterparty erasure and for a post-activation policy
change, verifying the rule moves to `needs_review` while the gate denies
immediately, independent of when the lifecycle row is reconciled.

- Add Gmail-path tests for `email.create_draft` covering: same connector, same
mailbox, and bound relationship matching; different mailbox not reusing
authority; a second email connector not reusing authority; different recipient
not reusing authority without an explicit broader scope; a changed thread within
an already-approved relationship scope; and a missing, expired, or foreign
selection token producing no resolved context and no standing-rule consultation.

Research

The kernel mediates every delegatable action through mediate_and_dispatch_action_with_attribution_and_token in crates/openspine-kernel/src/api/actions.rs. This function calls the pure gate() in crates/openspine-gate/src/gate.rs, then consults standing rules through consult_standing_rule_gate in crates/openspine-kernel/src/standing_rules_gate.rs, which calls store.consult_and_reserve_standing_rule in crates/openspine-kernel/src/store/standing_rules_budget.rs. Today the standing-rule match uses WHERE action_id = ?1 AND status = 'active' only. The StandingRuleManifest in crates/openspine-schemas/src/standing_rule.rs carries action_id, budgets, expiry, and dark_window, but no scope. The reflection miner groups approvals by (artifact_id, action_id) in crates/openspine-kernel/src/reflection_miner_runtime/scheduled.rs and carries one source event as ReflectionProvenance. Neither ResolvedActionContext nor a formal shared effect executor exists. Related identity building blocks exist and can be composed: CounterpartyRef and TaskShape in crates/openspine-schemas/src/briefcase.rs, the Connector enum and channel_account in crates/openspine-schemas/src/event.rs, and the AuthorityClassId equivalence pattern in crates/openspine-authority/src/equivalence.rs.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the data model foundation for reusable-authority scoping. Goal: define
`ResolvedActionContext`, a canonical `ReviewedScope` identity, an
action-descriptor version, and an evidence-set type in the schemas crate.

- Add a `ResolvedActionContext` struct in a new module under
`crates/openspine-schemas/src/` (for example `resolved_action_context.rs`).
Compose it from existing identity types instead of creating new ones: canonical
`ActionId` plus an action-descriptor version; connector instance identity as the
`Connector` enum plus `channel_account`; account role from the existing
`AccountRole`; the selected target from `TargetRef`; the counterparty from
`CounterpartyRef`; workflow/task shape from `TaskShape`; and immutable
`target_digest` and payload digest fields. Ensure the struct is constructible
only by kernel code. Document that shell-supplied fields are untrusted intent
only, and that the shell can supply at most a reference token.

- Add a `ReviewedScope` struct next to `ResolvedActionContext`, following the
`AuthorityClassId` equivalence pattern in
`crates/openspine-authority/src/equivalence.rs`: implement `Eq`/`Ord`, use a
sealed constructor, and derive a stable scope digest with `digest::digest_of`
over a canonical encoding. Include exactly these scope dimensions: action
descriptor and version, connector instance identity, account role,
target/counterparty dimension, and workflow/task-shape identity. Provide a
projection function from `ResolvedActionContext` to `ReviewedScope` and an
exact-match comparison function. Do not implement any least-common wider scope
computation.

- Add an action-descriptor version field to the `ActionCatalog` descriptor in
`crates/openspine-schemas/src/action.rs`, and populate it in
`crates/openspine-kernel/src/action_catalog_data.rs`.

- Replace the single `ReflectionProvenance` type with a bounded `EvidenceSet` in
`crates/openspine-schemas/src/reflection_miner.rs`. The `EvidenceSet` holds a
bounded `Vec` of `{event_id, exchange}` references plus a digest over the sorted
set. Enforce a maximum set size, following the precedent set by
`grant.limits.max_artifacts`.
===============================================================================

Task: 2

Implement the resolved-context step at the mediation boundary and formalize the
shared effect executor. Goal: build a trusted, kernel-derived
`ResolvedActionContext` for each action and route dispatch through it, replacing
the current always-`None` `target_ref`/`target_digest` gap.

- Create a new kernel module (for example
`crates/openspine-kernel/src/resolved_context.rs`), following the sibling
pattern of `standing_rules_gate.rs`, so that `gate()` in
`crates/openspine-gate/src/gate.rs` stays pure and unchanged. In this module,
resolve: connector instance identity through `ConnectorRegistry` in
`crates/openspine-kernel/src/connectors.rs`; account role and target from the
kernel-minted `SelectionToken` in
`crates/openspine-kernel/src/pipeline/selection.rs`; counterparty identity from
the store; and workflow/task shape from the grant's `route_id`/`workflow_id`.
Compute immutable target and payload digests in this kernel step, not in the
shell.

- Invoke the context-resolution step inside
`mediate_and_dispatch_action_with_attribution_and_token` in
`crates/openspine-kernel/src/api/actions.rs`, immediately after `gate()` returns
and before the standing-rule branch executes. If any required dimension cannot
be resolved, return an unresolved outcome and keep the decision at
`ApprovalRequired`.

- Formalize the `mediate_and_dispatch_action*` function family in
`crates/openspine-kernel/src/api/actions.rs` as the shared effect executor. Pass
the `ResolvedActionContext` into the executor and use it to populate
`ActionRequest.target_ref` and `ActionRequest.target_digest` generically,
replacing the current hard-coded `None`. Keep the existing `email.create_draft`
digest binding in `crates/openspine-kernel/src/api/proposal.rs` and
`crates/openspine-kernel/src/pipeline/approval_draft.rs` behavior-compatible:
the executor must produce the same digest shape so existing digest-bound
per-instance approval stays valid and does not widen.

- Wire the concrete Gmail draft context: populate `ResolvedActionContext` for
`email.create_draft` with the stable Gmail connector-instance identity,
owner-mailbox account role, selected thread target, kernel-resolved
recipient/counterparty identity, workflow/task-shape identity, and immutable
target and payload digests. Reuse the recipient resolution function
`newest_non_owner_recipient` in `crates/openspine-kernel/src/gmail.rs` so the
counterparty dimension is kernel-derived, not shell-selected.
===============================================================================

Task: 3

Implement reviewed-scope persistence on the standing-rule artifact and runtime
row, and enforce exact scope matching before any budget reservation or
dark-window scheduling. Goal: make the standing-rule match dependent on the
reviewed scope, not on `ActionId` alone.

- Add an optional `reviewed_scope` field to `StandingRuleManifest` in
`crates/openspine-schemas/src/standing_rule.rs`. Follow the additive
`dark_window` precedent: use `#[serde(default)]`, keep `deny_unknown_fields`,
and do not bump `schema_version` for this additive shape. Extend
`StandingRuleManifest::validate()` to require a reviewed scope for communication
actions, so every active communication rule carries a reviewed non-action scope.
Confirm that no changes are needed in `overlay_export_restore/bundle.rs` or
`pipeline/artifact_reconfirmation.rs`, since both are kind-generic over the YAML
file.

- Extend the `StandingRule` row and the `standing_rules` table in
`crates/openspine-kernel/src/store/standing_rules.rs` with a `scope_digest`
column and a small set of indexed dimension columns needed for lookup (for
example connector instance, account role, counterparty, workflow/task shape).
Add a store migration in `crates/openspine-kernel/src/store/migrations.rs`,
following the additive `ALTER TABLE ... ADD COLUMN` precedent used for skills.
Update the activation path `activate_standing_rule_in_tx` to populate these
columns from the manifest reviewed scope. Keep the superseding-revoke behavior,
but partition it by the reviewed scope instead of by `action_id` alone.

- Change `consult_and_reserve_standing_rule` in
`crates/openspine-kernel/src/store/standing_rules_budget.rs` to filter on the
action descriptor and the scope digest, and to compare the reviewed scope
exactly, before any usage-row reservation or dark-window scheduling. Split the
lookup/expiry phase from the reservation phase inside the same `BEGIN IMMEDIATE`
transaction, so the match is a distinct checkpoint. Preserve the existing atomic
quota/rate guarantee.

- Thread the `ResolvedActionContext` (or its `ReviewedScope`) through
`consult_standing_rule_gate` in
`crates/openspine-kernel/src/standing_rules_gate.rs` and its call site in
`crates/openspine-kernel/src/api/actions.rs`.

- Guarantee that a missing, changed, unresolved, stale, or incompatible scope
results in no match. A non-match must consume no budget, must create no
dark-window pending row, and must leave the decision at `ApprovalRequired`.
===============================================================================

Task: 4

Implement deterministic context-class grouping for the reflection miner and bind
full evidence sets into proposals. Goal: replace coarse `(artifact_id,
action_id)` counting with grouping by reviewed-scope dimensions, and carry a
complete, digest-bound evidence set.

- Change `derive_repeated_approval_observation` in
`crates/openspine-kernel/src/reflection_miner_runtime/scheduled.rs` to group
audit entries by a context-class key derived from the reviewed scope dimensions:
action descriptor and version, required scope dimensions, and compatible
workflow/task shape. Remove the `(artifact_id, action_id)` grouping. Require at
least the configured number of distinct owner approvals within one context
class. When approvals differ on a required dimension, produce separate narrow
candidates, or no candidate. Do not compute a wider least-common scope under any
circumstance.

- Update `ApprovalObservation` and the `EvidenceSet` usage in
`crates/openspine-schemas/src/reflection_miner.rs` to carry the bounded set of
encrypted source references plus the evidence-set digest. Update
`OrdinaryMinerGrant::provenance_in_briefcase` and `audit_entries_for` so both
operate over the same context-class key and verify that every evidence member is
present in the briefcase.

- Update `dispatch_reflection_proposal` in
`crates/openspine-kernel/src/reflection_miner_runtime.rs` to write all evidence
exchanges as `target_refs` on the `reflection.miner.provenance` audit row,
replacing the single-reference behavior.

- Update `ReflectionProposal::to_proposal_payload()` in
`crates/openspine-schemas/src/reflection_miner_payload.rs` to serialize the
mined `reviewed_scope` into the `StandingRuleManifest` YAML, so scope widening
is explicit in the proposal presented for owner decision.
===============================================================================

Task: 5

Implement drift-to-`needs_review` triggers, policy re-check at activation, and
dark-window restraint. Goal: keep standing rules aligned with their bound scope
dimensions and prevent silent widening through dark-window Allow defaults.

- Extend the standing-rule lifecycle handling in
`crates/openspine-kernel/src/store/standing_rules.rs` and
`standing_rules_budget.rs` to flip a rule's status to `needs_review` and set
`needs_review_since` on any of these events: incompatible action-descriptor or
executor version change; connector instance or account removal or
reconfiguration; counterparty identity becoming unresolved, erased, or re-bound;
workflow/task-shape authority change; or active policy newly denying the action.
Preserve the existing saturation and expiry triggers unchanged.

- Subscribe drift reconciliation to existing signals: the `counterparty.erased`
audit event and closure marker in
`crates/openspine-kernel/src/counterparty_erasure.rs`, and the connector health
state exposed by `crates/openspine-kernel/src/connectors.rs` and
`connector_reality.rs`. Keep the normal gate authoritative at all times: the
gate must deny immediately, even before the lifecycle row has been reconciled to
`needs_review`.

- In the standing-rule activation path (`activate_standing_rule` and
`activate_standing_rule_in_tx` in
`crates/openspine-kernel/src/store/standing_rules.rs`), re-check the active
policy for the reviewed scope. If the active policy denies the action, fail
activation, or move the row to `needs_review`.

- In `consult_standing_rule_gate` in
`crates/openspine-kernel/src/standing_rules_gate.rs`, ensure a scope mismatch or
an unresolved context never schedules an Allow default and never creates a
dark-window pending row. Ship the first Gmail proof with no dark-window Allow
for `email.create_draft`, unless separately justified.
===============================================================================

Task: 6

Implement the test coverage required by the ticket's done-when conditions, split
into a protocol-neutral matrix and a Gmail-specific matrix.

- Add mining tests near `crates/openspine-schemas/src/reflection_miner_tests.rs`
and `crates/openspine-kernel/src/store/reflection_miner_support.rs` covering:
same-context-class candidate creation; dimension-mismatch producing separate
candidates or no candidate; distinct-approval counting; and evidence-set digest
binding.

- Add match-before-reserve tests near
`crates/openspine-kernel/src/store/standing_rule_scheduling_tests.rs` and
`crates/openspine-kernel/src/api/standing_rule_mediation_tests.rs` covering: a
no-match case that leaves the decision at `ApprovalRequired` with no budget
consumed and no timer row created; and a concurrent scenario where the final
budget unit remains atomic after scope filtering.

- Add drift tests for counterparty erasure and for a post-activation policy
change, verifying the rule moves to `needs_review` while the gate denies
immediately, independent of when the lifecycle row is reconciled.

- Add Gmail-path tests for `email.create_draft` covering: same connector, same
mailbox, and bound relationship matching; different mailbox not reusing
authority; a second email connector not reusing authority; different recipient
not reusing authority without an explicit broader scope; a changed thread within
an already-approved relationship scope; and a missing, expired, or foreign
selection token producing no resolved context and no standing-rule consultation.

💡 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!

[coderabbitai]

🔗 Related PRs

#14 - Implement harden-approval-and-budgets: WYSIWYS, grant budgets, token hashing (Step 7) [merged]
#19 - Implement implement-artifact-lifecycle-slice: propose/approve/activate (PR-5) [merged]
#95 - feat(kernel): standing rules (AD-010/106/013/012, D-107) [merged]
#107 - chore(openspec): archive wire-authority-equivalence-selection [merged]
#108 - feat(kernel): implement reflection miner [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[George-RD]

Precise current miner failure mode

The current approval callback appends the owner-approved action.gated event with an empty target-ref list and only the approved payload ArtifactRef. load_owner_miner_audit_slice therefore chooses that payload ref, and derive_repeated_approval_observation groups by (payload_digest, action_id).

Consequences:

• two approvals of identical draft text for different recipients, threads, mailboxes, or connector instances can be grouped as one repeated pattern because the approved target digest is absent from the miner slice;
• normal recurring work for the same relationship usually produces different draft text, so it will not group at all;
• the candidate artifact ID becomes an opaque payload digest, not a stable logical responsibility/scope identity;
• the miner cannot explain which target dimensions were repeated because they are not in the evidence.

TDD should pin both sides before redesign:

1. identical payload + different approved target MUST NOT form one evidence class;
2. different payloads + same complete reviewed context MAY form one class when the action descriptor defines that context as equivalent;
3. every evidence entry must bind both approved payload and target digests plus the kernel-resolved action context;
4. provenance/evidence serialization must retain all contributing approval IDs, not select one arbitrary event from the winning count.

[George-RD]

Evidence lifecycle and proposal fairness

The current scheduled miner scans the complete owner approval history on every tick, selects only the maximum-count class, and suppresses a candidate when the same artifact/version exists in either proposals or the live registry. The redesigned evidence path needs durable lifecycle semantics, not just a safer grouping key:

• define a bounded freshness window or evidence epoch; ancient approvals must not justify authority after policy/workflow/relationship context has changed;
• assign each distinct owner approval a stable evidence ID and record which evidence-set digest produced a proposal;
• miner ticks must be idempotent: the same evidence set cannot produce duplicate proposals after restart;
• new approvals can extend a class and create a new proposal version only under explicit policy;
• owner Reject must suppress the same semantic proposal/evidence class until materially new evidence or an explicit retry request exists; it must not reappear every tick;
• ignored/expired reviews need a bounded cooldown and clear product semantics;
• one high-frequency class must not starve other eligible context classes: produce a deterministic bounded queue/batch rather than only one global maximum forever;
• policy/descriptor/executor/scope epoch changes invalidate old evidence classes or force reclassification before reuse;
• proposal/version identity must distinguish semantic amendments from a repeated submission of the same evidence.

These are learning/product controls only; they never grant authority. #129 should surface reject/snooze outcomes, while #133 evaluates each newly material evidence-set/version.