Define the protocol-neutral responsibility contract above standing rules

[George-RD]

Why

OpenSpine's product promise is that Lyra can grow into useful responsibility as the owner delegates work. The current implementation path is too close to the first Gmail proof:

• a StandingRuleManifest identifies one ActionId plus budgets and expiry, but has no reviewed connector, account, target, counterparty, or task-shape scope;
• the proposal renderer is beginning to call that primitive a "responsibility" even though a standing rule is only an authority-composition input at one effect boundary;
• owner review is represented directly as Telegram copy/buttons rather than as a channel-neutral decision object;
• action explanations and delegatability are inferred in ad hoc code instead of being declared with the action.

This is a decomposition gap under the change-sequence rule: it needs a settled architecture/OpenSpec slice before more Gmail-specific behavior is added.

Product distinction to preserve

A standing rule is a kernel authority primitive: a reviewed shortcut at an effect boundary.

A responsibility is the owner-facing unit of delegation. It must explain the job, the workflow already in use, the exact scope in which effects may happen, the limits, exceptions, receipts, and controls. The first proof may compose an existing workflow with one scoped standing rule, but the architecture must not equate the two.

Contracts to define

1. Action descriptor

Add a catalog-owned descriptor for every action that may participate in reusable delegation. At minimum it must declare:

• canonical action ID and effect semantics;
• owner-facing verb, object, and target nouns;
• whether reusable delegation is supported;
• required reviewed scope dimensions;
• executor/effect-adapter identity;
• connector/egress/output classifications already owned by the catalog;
• whether dark-window defaults are permitted for this effect class.

An action without a complete descriptor is ineligible for a reusable-authority proposal. There is no guessed fallback such as reducing memory.read:owner_preferences_limited to "read."

2. Kernel-resolved action context

Define a typed ResolvedActionContext (name may change in design) produced by the kernel, never by the shell. It must be able to carry the relevant subset of:

• connector implementation and stable connector-instance identity;
• account role/account identity;
• canonical target references;
• bound counterparty identity and relationship tier where applicable;
• kernel-bound parameters;
• target and payload digests;
• egress/disclosure/output class;
• workflow/task-shape identity.

This is the reusable form of AD-036 and AD-120: the model sends an intent; the kernel determines the WHO/WHERE and the effect identity.

3. Reviewed action scope

Define a serializable, versioned ReviewedActionScope derived only from the resolved context. It must be possible to compare a live request against the reviewed scope deterministically without connector-specific branches in the standing-rule engine.

Communication effects must not be delegatable with action-only scope.

4. Delegation evidence

Define evidence that distinguishes:

• repeated approvals;
• an explicit owner request to create a rule;
• a correction or workflow proposal;
• a manually supplied artifact.

Repeated-approval evidence must bind the complete context class and an evidence-set digest/count, not one arbitrary source event. Owner-facing copy may say "Lyra noticed a pattern" only when that evidence exists.

5. Channel-neutral owner review

Define an OwnerReviewRequest (name may change) containing:

• proposal kind and provenance summary;
• plain-language responsibility description;
• exact reviewed scope;
• automatic effects and remaining approval/deny boundaries;
• budgets, expiry, drift/default behavior;
• digest/version binding;
• available decisions and lifecycle controls.

Telegram, terminal, web, and future owner channels render this object; they do not define its security semantics.

Required adversarial decisions

• Whether the first proof can represent a responsibility as a view over existing workflow + standing-rule artifacts, or whether an atomic ResponsibilityManifest/bundle is required now.
• Whether dark-window Allow remains legal for external communication effects; AD-012 is still marked leaning, so the default must be fail-closed until explicitly settled.
• Which context dimensions define the minimum safe equivalence class for email drafts and for a generic communication action.
• How descriptor/schema/policy drift moves an active responsibility to needs_review.
• How a connector is removed or an account is reconfigured without leaving a zombie responsibility.

Invariants

• The task grant remains the only live authority object.
• Preferences and persona learning remain separate from authority.
• The shell cannot supply or widen trusted scope fields.
• A connector implementation cannot opt itself into delegation without catalog review.
• Missing descriptor, resolver, executor, or scope information fails closed before owner approval.
• No protocol name is embedded in the generic standing-rule matcher or owner-decision state machine.

Deliverables

• A new settled AD/D decision where needed.
• An OpenSpec change modifying the standing-rules/action/runtime contracts before behavioral implementation.
• Schema and pure-function contract tests for descriptor completeness, resolved-context construction, scope comparison, evidence classes, and owner-review serialization.
• An amended change sequence with explicit dependencies for the execution, scoped matching, owner-control, and first-proof slices.

Done when

• The repository has one documented meaning of responsibility, standing rule, resolved context, reviewed scope, and delegation evidence.
• A synthetic non-Gmail communication action can be described and scope-compared without changing the generic contracts.
• An action with missing delegation metadata cannot reach proposal review.
• Existing Gmail behavior remains unchanged; this issue defines the contract rather than prematurely shipping the autonomous path.

Relationship

Parent: #123.

Blocks the executable delegation, scoped matching, channel-neutral review, and first end-to-end proof slices.

[coderabbitai]

Coding Plan

Summary

• Deliver the responsibility contract as documentation plus schema and pure-function contracts. Do not wire live gate or connector behavior. Keep Gmail behavior unchanged.
• Record a settled decision that separates "standing rule" (authority input) from "responsibility" (owner-facing delegation unit). Correct the AD-012 status. Keep dark-window Allow fail-closed for communication effects.
• Add net-new sealed, deny_unknown_fields schema types that reuse existing CounterpartyRef/RelationshipTier, store only opaque counterparty ids, and never carry live authority. Extend ActionCatalog with a descriptor axis.
• Enforce every invariant through deterministic, connector-neutral pure functions with contract tests: descriptor completeness, fail-closed resolved-context construction, scope comparison, evidence classes, and owner-review serialization.

Design Choices

Design Choice 1: Represent a responsibility as an atomic manifest now, or as a view over existing workflow and standing-rule artifacts?

Options Considered:

1. Ship an atomic ResponsibilityManifest bundle that duplicates workflow and standing-rule content.
2. Define a ResponsibilityManifest type that holds references (workflow id, standing-rule id, reviewed scope, budgets, controls) and composes a view, without duplicating or carrying authority.

Chosen Option: 2

Rationale: A reference-and-view manifest satisfies "one documented meaning of responsibility" and preserves the invariant that the task grant is the only live authority object, without premature duplication.

Design Choice 2: Is dark-window `Allow` legal for external communication effects?

Options Considered:

1. Allow dark-window defaults for communication effects, relying on D-107's general resolution.
2. Add a per-descriptor dark_window_permitted flag defaulting to false, and forbid it for communication-classed effects until a new decision explicitly settles the communication case.

Chosen Option: 2

Rationale: The ticket mandates fail-closed for communication effects. A per-descriptor opt-in flag keeps the general D-107 mechanism intact while denying communication effects by default.

💡 User Tips

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

Implementation Steps

Phase 1: Settle the decision and author the OpenSpec change

This phase fixes terminology and records the architecture before any code. It produces one documented meaning for responsibility, standing rule, resolved context, reviewed scope, and delegation evidence. It resolves the required adversarial decisions and amends the change sequence.

Task 1: Add the settled decision entry

Record a new D-0XX entry in the decision log that defines the responsibility contract and resolves the adversarial questions.

• Add the entry to .raw/openspine-decision-log.md (index row plus body plus changelog line), following the existing D-entry format.
• State the product distinction: a standing rule is a kernel authority-composition input at one effect boundary. A responsibility is the owner-facing unit of delegation.
• Cite AD-036 and AD-120 as the basis for ResolvedActionContext (model sends intent, kernel determines WHO/WHERE and effect identity).
• Correct the AD-012 status: note that D-107 already resolved AD-012 generally, and decide that dark-window Allow stays fail-closed for communication-classed effects until a future decision settles that case.
• Resolve the remaining adversarial questions: responsibility as reference-view manifest (Assumption 1), minimum equivalence-class dimensions for email drafts and for a generic communication action, descriptor/schema/policy drift moving a responsibility to needs_review, and connector-removal/account-reconfiguration handling that avoids a zombie responsibility.

Task 2: Create the OpenSpec change and spec deltas

Create the OpenSpec change directory that modifies the standing-rules, action, and runtime contracts before behavioral implementation.

• Create a new change under openspec/changes/<new-change>/ with proposal.md, design.md, tasks.md following openspec/conventions.md.
• Add a spec delta to specs/kernel-registries/spec.md for the action descriptor: required descriptor fields and the rule that an action without a complete descriptor is ineligible for reusable-authority proposal, with no guessed fallback.
• Add a spec delta to specs/standing-rules/spec.md for reviewed-scope comparison with no connector-specific branches, and for the communication-effect fail-closed dark-window rule.
• Add a new spec area specs/responsibility-contract/spec.md for the responsibility unit, ResolvedActionContext, ReviewedActionScope, delegation evidence, and OwnerReviewRequest.
• Use ### Requirement: with MUST/SHOULD language and at least one #### Scenario: block per requirement. Cite the concrete Rust test function names added in Phase 3.

Task 3: Amend the change sequence

Record the decomposition and dependency edges for the downstream slices this ticket blocks.

• Add a new #### change entry to openspec/openspine-change-sequence.md with Canon: (AD-036/AD-120/AD-012 plus the new D-entry), Requires: (mark **HARD** where adversarially settled), Scope:, Invariant:, and Done when: bullets.
• Add explicit dependency edges for the four downstream slices named in the ticket: executable delegation, scoped matching, channel-neutral owner review, and the first end-to-end proof.

🤖 Prompt for AI agents

Implement Phase 1: settle the architecture decision and author the OpenSpec
change before writing any code.

First, add a new `D-0XX` entry to `.raw/openspine-decision-log.md` (index row,
body, and changelog line), matching the existing D-entry format. In this entry:
- State that a standing rule is a kernel authority-composition input at one
effect boundary, and a responsibility is the owner-facing unit of delegation.
- Cite AD-036 and AD-120 as the basis for `ResolvedActionContext` (model sends
intent, kernel determines WHO/WHERE and effect identity).
- Correct the AD-012 status: note D-107 already resolved AD-012 generally, and
decide dark-window `Allow` stays fail-closed for communication-classed effects
until a future decision settles that case.
- Resolve remaining adversarial questions: responsibility as a reference-view
manifest, minimum equivalence-class dimensions for email drafts and for a
generic communication action, descriptor/schema/policy drift moving a
responsibility to `needs_review`, and connector-removal/account-reconfiguration
handling that avoids a zombie responsibility.

Second, create a new OpenSpec change directory under
`openspec/changes/<new-change>/` with `proposal.md`, `design.md`, and
`tasks.md`, following `openspec/conventions.md`. Add these spec deltas:
- `specs/kernel-registries/spec.md`: required action descriptor fields, and the
rule that an action without a complete descriptor is ineligible for
reusable-authority proposal, with no guessed fallback.
- `specs/standing-rules/spec.md`: reviewed-scope comparison with no
connector-specific branches, and the communication-effect fail-closed
dark-window rule.
- `specs/responsibility-contract/spec.md` (new area): the responsibility unit,
`ResolvedActionContext`, `ReviewedActionScope`, delegation evidence, and
`OwnerReviewRequest`.
Use `### Requirement:` sections with MUST/SHOULD language and at least one `####
Scenario:` block per requirement. Cite the concrete Rust test function names
added in Phase 3.

Third, amend `openspec/openspine-change-sequence.md` by adding a new `####`
change entry with `Canon:` (AD-036/AD-120/AD-012 plus the new D-entry),
`Requires:` (mark `**HARD**` where adversarially settled), `Scope:`,
`Invariant:`, and `Done when:` bullets. Add explicit dependency edges for the
four downstream slices named in the ticket: executable delegation, scoped
matching, channel-neutral owner review, and the first end-to-end proof.

Phase 2: Define the schema contracts

This phase adds the net-new serializable types to openspine-schemas and extends the action catalog with the descriptor axis. All types use deny_unknown_fields so they cannot parse into a grant, and no type carries or widens live authority.

Task 1: Add the action descriptor axis to the catalog

Add a catalog-owned descriptor for every action that may participate in reusable delegation.

• Add an ActionDescriptor struct and a with_descriptors builder axis to ActionCatalog in crates/openspine-schemas/src/action.rs, following the existing with_* builder pattern.
• Declare fields: canonical action id, effect semantics, owner-facing verb/object/target nouns, reusable-delegation supported flag, required reviewed scope dimensions, executor/effect-adapter identity, and dark_window_permitted (default false).
• Reference the existing catalog classifications (egress_declarations, counterparty_facing_actions) rather than duplicating connector/egress/output data.
• Populate descriptors in crates/openspine-kernel/src/action_catalog.rs and action_catalog_data.rs. Set dark_window_permitted = false for communication-classed actions.

Task 2: Add the resolved action context and reviewed scope types

Add the kernel-produced context type and the reviewed-scope type derived from it.

• Create crates/openspine-schemas/src/resolved_context.rs for ResolvedActionContext, carrying connector implementation and stable connector-instance identity, account role/identity, canonical target references, CounterpartyRef and derived RelationshipTier (reuse briefcase.rs), kernel-bound parameters, target and payload digests, egress/disclosure/output class, and workflow/task-shape identity.
• Seal construction: use private fields plus a validated constructor that returns a typed error on any missing required field, following the fail-closed idiom (reject before any side effect). Model the seal on AuthorityCandidate::from_composed_grant.
• Store only the opaque identity_id Ulid for counterparty identity. Never store raw identifiers (respect the erasure invariant in identity.rs).
• Create crates/openspine-schemas/src/reviewed_scope.rs for ReviewedActionScope: serializable, versioned, derived only from ResolvedActionContext, with no connector-specific fields or branches.

Task 3: Add delegation evidence, owner review, and responsibility types

Add the remaining owner-facing and evidence contract types.

• Create crates/openspine-schemas/src/delegation_evidence.rs for a DelegationEvidence enum distinguishing repeated approvals, explicit owner rule request, correction/workflow proposal, and manually supplied artifact. The repeated-approval variant must bind the complete context class and an evidence-set digest and count.
• Create crates/openspine-schemas/src/owner_review.rs for OwnerReviewRequest: proposal kind and provenance summary, plain-language description, exact reviewed scope, automatic effects and remaining approval/deny boundaries, budgets/expiry/drift-default behavior, digest/version binding, and available decisions and lifecycle controls. This type carries no channel-specific fields.
• Create crates/openspine-schemas/src/responsibility.rs for the reference-view ResponsibilityManifest (Assumption 1): references to workflow id and standing-rule id, reviewed scope, budgets, and controls, with no duplicated authority content.
• Register all new modules in crates/openspine-schemas/src/lib.rs.

🤖 Prompt for AI agents

Implement Phase 2: add net-new serializable schema types to `openspine-schemas`
and extend the action catalog with a descriptor axis. All new types must use
`deny_unknown_fields` so they cannot parse into a grant, and none may carry or
widen live authority.

First, add an `ActionDescriptor` struct and a `with_descriptors` builder axis to
`ActionCatalog` in `crates/openspine-schemas/src/action.rs`, following the
existing `with_*` builder pattern. Declare these fields: canonical action id,
effect semantics, owner-facing verb/object/target nouns, reusable-delegation
supported flag, required reviewed scope dimensions, executor/effect-adapter
identity, and `dark_window_permitted` (default `false`). Reference existing
catalog classifications (`egress_declarations`, `counterparty_facing_actions`)
rather than duplicating connector/egress/output data. Populate descriptors in
`crates/openspine-kernel/src/action_catalog.rs` and `action_catalog_data.rs`,
and set `dark_window_permitted = false` for communication-classed actions.

Second, create `crates/openspine-schemas/src/resolved_context.rs` for
`ResolvedActionContext`. It carries connector implementation and stable
connector-instance identity, account role/identity, canonical target references,
`CounterpartyRef` and derived `RelationshipTier` (reuse `briefcase.rs`),
kernel-bound parameters, target and payload digests, egress/disclosure/output
class, and workflow/task-shape identity. Seal construction with private fields
plus a validated constructor that returns a typed error on any missing required
field, following the fail-closed idiom (reject before any side effect), modeled
on `AuthorityCandidate::from_composed_grant`. Store only the opaque
`identity_id` Ulid for counterparty identity; never store raw identifiers,
respecting the erasure invariant in `identity.rs`.

Third, create `crates/openspine-schemas/src/reviewed_scope.rs` for
`ReviewedActionScope`: serializable, versioned, derived only from
`ResolvedActionContext`, with no connector-specific fields or branches.

Fourth, create `crates/openspine-schemas/src/delegation_evidence.rs` for a
`DelegationEvidence` enum distinguishing repeated approvals, explicit owner rule
request, correction/workflow proposal, and manually supplied artifact. The
repeated-approval variant must bind the complete context class and an
evidence-set digest and count.

Fifth, create `crates/openspine-schemas/src/owner_review.rs` for
`OwnerReviewRequest`, containing: proposal kind and provenance summary,
plain-language description, exact reviewed scope, automatic effects and
remaining approval/deny boundaries, budgets/expiry/drift-default behavior,
digest/version binding, and available decisions and lifecycle controls. This
type must carry no channel-specific fields.

Sixth, create `crates/openspine-schemas/src/responsibility.rs` for the
reference-view `ResponsibilityManifest`: references to workflow id and
standing-rule id, reviewed scope, budgets, and controls, with no duplicated
authority content.

Finally, register all new modules in `crates/openspine-schemas/src/lib.rs`.

Phase 3: Pure-function contracts and tests

This phase adds the deterministic pure functions and the contract tests required by the ticket. These functions are the enforcement points that downstream slices will call. This phase adds no live gate or connector wiring.

Task 1: Descriptor completeness and proposal eligibility

Add the pure check that blocks incomplete descriptors from reusable-authority proposal.

• Add a pure descriptor_is_complete (and a proposal-eligibility check) alongside ActionDescriptor in action.rs, returning a typed error on any missing field, with no guessed fallback.
• Enforce that communication-classed actions cannot be reusable-delegatable with action-only scope, and cannot set dark_window_permitted = true.
• Add tests proving an action with missing delegation metadata is rejected, and a communication action with action-only scope is rejected.

Task 2: Resolved-context construction and scope comparison

Add the fail-closed constructor tests and the deterministic scope-comparison function.

• Add a pure matches/compare function on ReviewedActionScope that compares a ResolvedActionContext against a reviewed scope deterministically, with no connector-specific branches.
• Add tests proving the constructor fails closed on missing resolver/executor/scope information, and that scope comparison is deterministic and connector-neutral.
• Add a test that a synthetic non-Gmail communication action can be described and scope-compared without changing the generic contracts.

Task 3: Evidence classification and owner-review serialization

Add the evidence-class contract tests and the serialization round-trip tests.

• Add tests for DelegationEvidence classification, including that the "Lyra noticed a pattern" copy path is only valid when repeated-approval evidence binds a context class and an evidence-set digest and count.
• Add serialization round-trip and versioning tests for OwnerReviewRequest and ReviewedActionScope.
• Add a catalog completeness test in crates/openspine-kernel/ verifying descriptor population for reusable-delegation-eligible actions.

🤖 Prompt for AI agents

Implement Phase 3: add deterministic pure functions and contract tests for the
schema types defined in Phase 2. These functions are the enforcement points that
downstream slices will call. Do not add live gate or connector wiring in this
phase.

First, add a pure `descriptor_is_complete` function (and a proposal-eligibility
check) alongside `ActionDescriptor` in `action.rs`. It must return a typed error
on any missing field, with no guessed fallback. Enforce that
communication-classed actions cannot be reusable-delegatable with action-only
scope, and cannot set `dark_window_permitted = true`. Add tests proving an
action with missing delegation metadata is rejected, and a communication action
with action-only scope is rejected.

Second, add a pure `matches`/`compare` function on `ReviewedActionScope` that
compares a `ResolvedActionContext` against a reviewed scope deterministically,
with no connector-specific branches. Add tests proving the constructor for
`ResolvedActionContext` fails closed on missing resolver/executor/scope
information, and that scope comparison is deterministic and connector-neutral.
Add a test showing that a synthetic non-Gmail communication action can be
described and scope-compared without changing the generic contracts.

Third, add tests for `DelegationEvidence` classification, including a test that
the "Lyra noticed a pattern" copy path is valid only when repeated-approval
evidence binds a context class and an evidence-set digest and count. Add
serialization round-trip and versioning tests for `OwnerReviewRequest` and
`ReviewedActionScope`. Add a catalog completeness test in
`crates/openspine-kernel/` that verifies descriptor population for
reusable-delegation-eligible actions.

Research

openspine-schemas holds the serializable contract types (StandingRuleManifest, ActionId, ActionCatalog, TaskGrant, ApprovalRecord, CounterpartyRef, RelationshipTier, Lifecycle). openspine-kernel populates the action catalog (action_catalog.rs, action_catalog_data.rs), runs the standing-rule gate (standing_rules_gate.rs, store/standing_rules*.rs), and renders owner review copy ad hoc at approximately 7 call sites straight into Telegram. openspine-authority holds the sealed compose_authority/AuthorityClassId equivalence mechanism.

Key facts from exploration:

• None of the four proposed types exist today. StandingRuleManifest is flat and matches by action_id only, with no connector/account/target/counterparty scope.
• The action catalog is a builder with several independent classification sets/maps. There is no per-action descriptor.
• CounterpartyRef and RelationshipTier already exist in briefcase.rs and must be reused for counterparty identity and tier.
• Lifecycle in artifact.rs includes ReviewRequired, but Active → ReviewRequired is not a legal transition today.
• Owner review copy has no channel-neutral intermediate object.
• AD-012 is already settled by D-107 (not "leaning"). The ticket's claim is inaccurate, and the plan corrects it.
• OpenSpec changes require proposal.md, design.md, tasks.md, and specs/<area>/spec.md. kernel-registries owns the action catalog contract, standing-rules owns dark-window/drift semantics.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: settle the architecture decision and author the OpenSpec
change before writing any code.

First, add a new `D-0XX` entry to `.raw/openspine-decision-log.md` (index row,
body, and changelog line), matching the existing D-entry format. In this entry:
- State that a standing rule is a kernel authority-composition input at one
effect boundary, and a responsibility is the owner-facing unit of delegation.
- Cite AD-036 and AD-120 as the basis for `ResolvedActionContext` (model sends
intent, kernel determines WHO/WHERE and effect identity).
- Correct the AD-012 status: note D-107 already resolved AD-012 generally, and
decide dark-window `Allow` stays fail-closed for communication-classed effects
until a future decision settles that case.
- Resolve remaining adversarial questions: responsibility as a reference-view
manifest, minimum equivalence-class dimensions for email drafts and for a
generic communication action, descriptor/schema/policy drift moving a
responsibility to `needs_review`, and connector-removal/account-reconfiguration
handling that avoids a zombie responsibility.

Second, create a new OpenSpec change directory under
`openspec/changes/<new-change>/` with `proposal.md`, `design.md`, and
`tasks.md`, following `openspec/conventions.md`. Add these spec deltas:
- `specs/kernel-registries/spec.md`: required action descriptor fields, and the
rule that an action without a complete descriptor is ineligible for
reusable-authority proposal, with no guessed fallback.
- `specs/standing-rules/spec.md`: reviewed-scope comparison with no
connector-specific branches, and the communication-effect fail-closed
dark-window rule.
- `specs/responsibility-contract/spec.md` (new area): the responsibility unit,
`ResolvedActionContext`, `ReviewedActionScope`, delegation evidence, and
`OwnerReviewRequest`.
Use `### Requirement:` sections with MUST/SHOULD language and at least one `####
Scenario:` block per requirement. Cite the concrete Rust test function names
added in Phase 3.

Third, amend `openspec/openspine-change-sequence.md` by adding a new `####`
change entry with `Canon:` (AD-036/AD-120/AD-012 plus the new D-entry),
`Requires:` (mark `**HARD**` where adversarially settled), `Scope:`,
`Invariant:`, and `Done when:` bullets. Add explicit dependency edges for the
four downstream slices named in the ticket: executable delegation, scoped
matching, channel-neutral owner review, and the first end-to-end proof.
===============================================================================

Task: 2

Implement Phase 2: add net-new serializable schema types to `openspine-schemas`
and extend the action catalog with a descriptor axis. All new types must use
`deny_unknown_fields` so they cannot parse into a grant, and none may carry or
widen live authority.

First, add an `ActionDescriptor` struct and a `with_descriptors` builder axis to
`ActionCatalog` in `crates/openspine-schemas/src/action.rs`, following the
existing `with_*` builder pattern. Declare these fields: canonical action id,
effect semantics, owner-facing verb/object/target nouns, reusable-delegation
supported flag, required reviewed scope dimensions, executor/effect-adapter
identity, and `dark_window_permitted` (default `false`). Reference existing
catalog classifications (`egress_declarations`, `counterparty_facing_actions`)
rather than duplicating connector/egress/output data. Populate descriptors in
`crates/openspine-kernel/src/action_catalog.rs` and `action_catalog_data.rs`,
and set `dark_window_permitted = false` for communication-classed actions.

Second, create `crates/openspine-schemas/src/resolved_context.rs` for
`ResolvedActionContext`. It carries connector implementation and stable
connector-instance identity, account role/identity, canonical target references,
`CounterpartyRef` and derived `RelationshipTier` (reuse `briefcase.rs`),
kernel-bound parameters, target and payload digests, egress/disclosure/output
class, and workflow/task-shape identity. Seal construction with private fields
plus a validated constructor that returns a typed error on any missing required
field, following the fail-closed idiom (reject before any side effect), modeled
on `AuthorityCandidate::from_composed_grant`. Store only the opaque
`identity_id` Ulid for counterparty identity; never store raw identifiers,
respecting the erasure invariant in `identity.rs`.

Third, create `crates/openspine-schemas/src/reviewed_scope.rs` for
`ReviewedActionScope`: serializable, versioned, derived only from
`ResolvedActionContext`, with no connector-specific fields or branches.

Fourth, create `crates/openspine-schemas/src/delegation_evidence.rs` for a
`DelegationEvidence` enum distinguishing repeated approvals, explicit owner rule
request, correction/workflow proposal, and manually supplied artifact. The
repeated-approval variant must bind the complete context class and an
evidence-set digest and count.

Fifth, create `crates/openspine-schemas/src/owner_review.rs` for
`OwnerReviewRequest`, containing: proposal kind and provenance summary,
plain-language description, exact reviewed scope, automatic effects and
remaining approval/deny boundaries, budgets/expiry/drift-default behavior,
digest/version binding, and available decisions and lifecycle controls. This
type must carry no channel-specific fields.

Sixth, create `crates/openspine-schemas/src/responsibility.rs` for the
reference-view `ResponsibilityManifest`: references to workflow id and
standing-rule id, reviewed scope, budgets, and controls, with no duplicated
authority content.

Finally, register all new modules in `crates/openspine-schemas/src/lib.rs`.
===============================================================================

Task: 3

Implement Phase 3: add deterministic pure functions and contract tests for the
schema types defined in Phase 2. These functions are the enforcement points that
downstream slices will call. Do not add live gate or connector wiring in this
phase.

First, add a pure `descriptor_is_complete` function (and a proposal-eligibility
check) alongside `ActionDescriptor` in `action.rs`. It must return a typed error
on any missing field, with no guessed fallback. Enforce that
communication-classed actions cannot be reusable-delegatable with action-only
scope, and cannot set `dark_window_permitted = true`. Add tests proving an
action with missing delegation metadata is rejected, and a communication action
with action-only scope is rejected.

Second, add a pure `matches`/`compare` function on `ReviewedActionScope` that
compares a `ResolvedActionContext` against a reviewed scope deterministically,
with no connector-specific branches. Add tests proving the constructor for
`ResolvedActionContext` fails closed on missing resolver/executor/scope
information, and that scope comparison is deterministic and connector-neutral.
Add a test showing that a synthetic non-Gmail communication action can be
described and scope-compared without changing the generic contracts.

Third, add tests for `DelegationEvidence` classification, including a test that
the "Lyra noticed a pattern" copy path is valid only when repeated-approval
evidence binds a context class and an evidence-set digest and count. Add
serialization round-trip and versioning tests for `OwnerReviewRequest` and
`ReviewedActionScope`. Add a catalog completeness test in
`crates/openspine-kernel/` that verifies descriptor population for
reusable-delegation-eligible actions.

💡 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]
#29 - docs: interview round - AD-145..153 settle the remaining open questions [merged]
#95 - feat(kernel): standing rules (AD-010/106/013/012, D-107) [merged]
#107 - chore(openspec): archive wire-authority-equivalence-selection [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]

Architecture decisions that must be settled explicitly

1. Standing-rule placement: AD-010 calls standing rules inputs to task-grant composition, while the implementation currently consults them after gate() to satisfy an ApprovalRequired result. The task grant remains the upper bound in either design, but the spec must name the real semantics: a reviewed reusable-approval input consulted at the common mediation boundary, or a composition input reflected in the grant. Do not leave the design log and runtime describing different authority paths.

2. Canonical action vs connector implementation: split catalog semantics from adapter registration. A canonical action descriptor can define email.create_draft, while each connector implementation registers a stable implementation/instance, executor, resolver, and compatibility version. A Gmail rule must not automatically cover an Outlook implementation merely because the canonical action is shared.

3. Action IDs need semantic stability: define when two connector operations may share one canonical action and when they require distinct actions. For example, direct message, thread reply, new-conversation send, private-channel post, and public-channel post must not collapse into one broad message.send effect.

4. Fail-closed registration ownership: assistant packages/connectors may supply candidates, but only kernel-reviewed catalog data can declare delegatability, required scope dimensions, dark-window eligibility, or an executor/resolver pairing.

5. Owner surface: include the typed owner destination/session seam raised on Add channel-neutral responsibility review and lifecycle controls #129; a raw Telegram chat ID cannot remain the generic review identity.

6. Schema evolution: descriptor, implementation, resolved-context, scope, evidence, and review types need explicit schema/compatibility versions so policy/base/connector updates can deterministically stale active responsibilities.

[George-RD]

Connector-write and disclosure taxonomy gap

The current EgressClass is intentionally limited to Search, ForumBrowse, and WebFormPost, while catalog data classifies email.create_draft as no egress/output channel. A Gmail draft is still a side-effecting write of content into an external account, even though it is not a final counterparty send.

The action/implementation contract must distinguish at least three axes rather than forcing them into the current web-egress enum:

1. effect kind/reversibility — read, private-account write/draft, direct send, workspace/channel post, public publish, infrastructure mutation;
2. data destination/visibility — owner device, owner cloud account, bound counterparty, workspace audience, public, model provider/search service;
3. connector egress/rate class — the existing endpoint policy and operational limits.

A private mailbox draft may have a different approval/disclosure posture from a direct send, but it must not be represented as having no external destination. The reviewed scope and owner review must state where data will be stored or delivered, and #133 must evaluate destination/visibility changes. Adding a new communication protocol should require an explicit destination/effect classification before reusable delegation is eligible.