Design capability-derived tool catalogs

[George-RD]

Part of #182

Question

A session's toolset is fixed by verified role before inference; identity step-up recomputes the catalog; privileged tools are structurally absent from untrusted sessions, never refused (Bell invariant I2). Design, not implementation.

Users: Bell, Lyra. Promises: Immune system, Permissions.

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

Blocked by

• Design the typed owner identity #188
• Research: design inputs for the Immune-system lane #190

[coderabbitai]

Coding Plan

Summary

Treat this as a design deliverable. Follow the handoff shape: grill (Phase 1), domain-model (Phase 2), then to-spec (Phase 3).

Ground the ticket's invented vocabulary ("Bell", "I2", "Immune system", "Permissions", "step-up", "tool catalog") in existing canon (D-006, D-007, D-011, AD-147, authority-equivalence-matcher, persona-binding) before modeling.

Design the tool catalog as a new layer. This layer derives an LLM-facing tool schema from the already-composed TaskGrant before inference. Privileged tools stay structurally absent from untrusted sessions. gate() stays the mandatory fail-closed refusal path.

End the change with strict OpenSpec validation, a decomposition entry, and a linked spec issue, per the repo's design-ticket-to-spec ceremony.

Design Choices

Design Choice 1: Map the invented ticket vocabulary onto existing canon

Options Considered:

1. Adopt the ticket terms verbatim as new canonical terms.
2. Map each ticket term to the closest existing canonical concept and record the mapping in the glossary and an ADR.

Chosen Option: 2

Rationale: The ticket uses terms with no source in this repository: "Bell", "invariant I2", "Immune system"/"Permissions", "identity step-up", and "tool catalog". The design must ground these in real canon to satisfy docs/agents/domain.md (use exact glossary vocabulary; flag gaps for domain-modeling). Grounding the vocabulary in canon (Lyra as the assistant persona, "Bell" as the owner/human principal, "Permissions" as AuthorityClassId/egress-classes, "Immune system" as the "Authority and containment" containment guarantees, "invariant I2" as a named structural-absence corollary of D-006/D-007) keeps the design consistent with the codebase. It avoids self-legitimizing invented terms.

Design Choice 2: Define where the session toolset lives and what "before inference" means given the stateless per-event model

Options Considered:

1. Introduce a new persisted session/verification-state store that caches a tool catalog across turns.
2. Derive the tool catalog per authenticated event from the already-composed TaskGrant, and model "step-up" as a fresh recompute triggered when the event's verification signal rises.

Chosen Option: 2

Rationale: Today authority is recomputed per event. There is no persisted session object. The ticket says the toolset is "fixed before inference" and that "identity step-up recomputes the catalog". Deriving the catalog from the existing TaskGrant composition and treating step-up as a recompute aligns with the existing stateless resolve-then-compose pipeline. It keeps gate() as the single enforcement point. It avoids a new stateful session store that would conflict with D-006. The design should document this as the baseline. It should note the persisted-session alternative as a future extension only if cross-turn caching is later required.

💡 User Tips

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

Implementation Steps

Phase 1: Grill and reconcile the problem with canon

This phase runs the "grill" stage of the handoff. It closes ambiguity before any modeling. It grounds the ticket vocabulary in existing decisions. The output is a short reconciliation note that later artifacts cite.

Task 1: Run a clarification pass on open design questions

Resolve the unknowns that block a coherent design.

• Use the repo-native clarification stance (interview-me / blindspot-pass equivalents in .omp/skills/) to record and answer the blocking questions.
• Confirm the session model decision: per-event recompute of the tool catalog from TaskGrant versus a persisted session store (see Assumption 2).
• Confirm what "identity step-up" raises and lowers: map it onto IdentityResolution.source_verified, ChannelTrust, and RouteWhen.verified_source.
• Record the status of the "Blocked by W6, W8" dependencies. These identifiers are not defined in this repo. Note them as external prerequisites and state what each must deliver before the spec can be implemented.

Task 2: Produce a terminology reconciliation note

Map every invented ticket term to a canonical concept so downstream artifacts use one term per concept.

• Create a short note (working file under .raw/ or the change folder scratch area) that maps: "Lyra" to assistant package; "Bell" to owner/human principal; "Permissions" promise to AuthorityClassId (AD-147) and egress-classes; "Immune system" promise to "Authority and containment" structural guarantees; "invariant I2" to a named structural-absence corollary of D-006 (identity-is-not-authority) and D-007 (task-grant-only-authority).
• State clearly that no LLM-facing tool catalog exists today. This design introduces a new derivation layer and does not modify gate()'s role.
• Cite the real decision IDs (D-006, D-007, D-011, D-077/D-078, AD-147) instead of the ticket's unattested I1/I2 scheme.

🤖 Prompt for AI agents

Implement Phase 1, the "grill" stage: close design ambiguity and ground ticket
vocabulary in existing canon before any modeling work begins. Produce a short
reconciliation note that later artifacts (Phase 2 and Phase 3) cite.

For the clarification pass:
- Use the repo-native clarification stance (`interview-me` / `blindspot-pass`
equivalents in `.omp/skills/`) to record and answer blocking questions.
- Confirm the session model decision: derive the tool catalog per-event from
`TaskGrant` (not a persisted session store).
- Map "identity step-up" onto `IdentityResolution.source_verified`,
`ChannelTrust`, and `RouteWhen.verified_source`, and state what it raises and
lowers.
- Record the status of the "Blocked by W6, W8" dependencies as external
prerequisites not defined in this repo. State what each must deliver before the
spec can be implemented.

For the terminology note:
- Create a working file under `.raw/` or the change folder scratch area.
- Map each invented ticket term to its canonical counterpart: "Lyra" to
assistant package; "Bell" to owner/human principal; "Permissions" promise to
`AuthorityClassId` (AD-147) and egress-classes; "Immune system" promise to
"Authority and containment" structural guarantees; "invariant I2" to a named
structural-absence corollary of D-006 and D-007.
- State explicitly that no LLM-facing tool catalog exists today, and that this
design introduces a new derivation layer without modifying `gate()`'s role.
- Cite real decision IDs (D-006, D-007, D-011, D-077/D-078, AD-147) instead of
the ticket's unattested I1/I2 scheme.

Phase 2: Domain modeling artifacts

This phase runs the "domain-model" stage. It creates the glossary and decision records that docs/agents/domain.md expects the domain-modeling skill to produce. These artifacts define the new terms once, so the spec can reference them.

Task 1: Create the glossary entries for the new domain terms

Define the capability-derived tool catalog vocabulary in a durable glossary.

• Create CONTEXT.md (and CONTEXT-MAP.md if more than one bounded context is needed) at the repo root, following the convention described in docs/agents/domain.md.
• Define these terms with their exact meanings: "capability-derived tool catalog", "verified role", "identity step-up", "structural absence" (versus runtime refusal), and "untrusted session".
• Anchor each definition to its enforcement seam: TaskGrant.allowed_actions/approval_required_actions/denied_actions, IdentityResolution.source_verified/ChannelTrust, and gate().
• Reuse existing vocabulary from openspec/specs/** where a concept already exists. Do not invent a synonym for an existing term.

Task 2: Record the key architectural decisions as ADRs

Capture the design decisions and their rationale so the spec can cite stable decision records.

• Create docs/adr/ and add ADR entries for: (a) deriving the LLM-facing tool catalog from the composed TaskGrant before inference; (b) the structural-absence invariant (privileged tools are omitted from untrusted sessions, never offered then refused); (c) identity step-up as a recompute of the catalog triggered by a rise in the verification signal.
• In the structural-absence ADR, cite the existing structural-impossibility patterns as precedent: the authority-equivalence-matcher's type-level "cannot express a cross-class pick" (openspec/specs/authority-equivalence-matcher/spec.md) and persona-binding's route-resolved-only persona selection (openspec/specs/persona-binding/spec.md).
• State explicitly that structural absence complements, and does not replace, gate(). gate() stays the mandatory fail-closed refusal path for any action that is still attempted (D-007).
• Model "identity step-up" on the existing digest-bound reconfirmation mechanism (D-011 WYSIWYS, D-077/D-078) rather than introducing a generic elevated-trust flag.

🤖 Prompt for AI agents

Implement Phase 2, the "domain-model" stage: produce the glossary and ADR
artifacts that `docs/agents/domain.md` expects, defining the new terms once so
later spec artifacts can reference them.

For the glossary:
- Create `CONTEXT.md` at the repo root (and `CONTEXT-MAP.md` if more than one
bounded context is needed), following the convention in `docs/agents/domain.md`.
- Define these terms with exact meanings: "capability-derived tool catalog",
"verified role", "identity step-up", "structural absence" (versus runtime
refusal), and "untrusted session".
- Anchor each definition to its enforcement seam:
`TaskGrant.allowed_actions`/`approval_required_actions`/`denied_actions`,
`IdentityResolution.source_verified`/`ChannelTrust`, and `gate()`.
- Reuse existing vocabulary from `openspec/specs/**` where a concept already
exists; do not invent a synonym for an existing term.

For the ADRs:
- Create `docs/adr/` and add entries for: deriving the LLM-facing tool catalog
from the composed `TaskGrant` before inference; the structural-absence invariant
(privileged tools are omitted from untrusted sessions, never offered then
refused); and identity step-up as a recompute of the catalog triggered by a rise
in the verification signal.
- In the structural-absence ADR, cite as precedent the
authority-equivalence-matcher's type-level "cannot express a cross-class pick"
(`openspec/specs/authority-equivalence-matcher/spec.md`) and persona-binding's
route-resolved-only persona selection
(`openspec/specs/persona-binding/spec.md`).
- State explicitly that structural absence complements `gate()` and does not
replace it; `gate()` remains the mandatory fail-closed refusal path for any
action that is still attempted (D-007).
- Model "identity step-up" on the existing digest-bound reconfirmation mechanism
(D-011 WYSIWYS, D-077/D-078), not a generic elevated-trust flag.

Phase 3: To-spec and hand-off

This phase runs the "to-spec" stage. It converts the resolved model into an OpenSpec change with the required artifacts, validates it, and links the spec issue back to the ticket.

Task 1: Create the OpenSpec change and proposal

Formalize the design as an OpenSpec change.

• Create a new change directory under openspec/changes/ (for example design-capability-derived-tool-catalogs/) using the openspec-propose flow.
• Write proposal.md with the sections required by openspec/conventions.md: ## Dependencies (name W6, W8, and the internal building blocks below), ## Problem/Context, ## Proposed Solution, ## Acceptance Criteria, and ## Out of Scope.
• In ## Out of Scope, state that implementation, model_gateway tool-schema wiring, and any persisted session store are excluded from this design change.
• In ## Dependencies, reference the reusable building blocks: the validated action catalog (crates/openspine-kernel/src/action_catalog*.rs), TaskGrant composition (crates/openspine-authority/src/compose.rs), skill.context scoping (crates/openspine-kernel/src/api/skill_context.rs), and OwnerSurfaceRef from the archived channel-neutral review change.

Task 2: Write the design document

Record the architecture-level design and the authority-sensitivity analysis.

• Write design.md describing the new derivation layer that turns TaskGrant.allowed_actions (and, where relevant, skill.context's grant-scoped skills) into an LLM-facing tool schema, computed once per authenticated event before the model runs.
• Describe the structural-absence rule: privileged tools are absent from the schema for untrusted sessions, so the model cannot name them.
• Describe identity step-up as a recompute: a rise in source_verified/ChannelTrust re-runs composition and re-derives the catalog, adding tools that the higher verification permits.
• Complete the openspec/conventions.md authority-sensitivity checklist. Identity resolution, task grants, and gate-mediated actions are all touched, so add explicit verification requirements for each.
• Follow openspec/config.yaml: state OpenSpine-core versus Lyra-product scope, and confirm that runtime authority stays expressed only through task grants and gate-mediated actions.

Task 3: Write the delta specs and tasks

Express the design as normative requirements and reviewable work items.

• Create specs/<capability>/spec.md delta files with requirement headers ## ADDED Requirements and RFC language (MUST/SHALL for the authority-sensitive rules).
• Add requirements for: the catalog is derived from the composed grant before inference; privileged tools are structurally absent from untrusted sessions (MUST); step-up recomputes the catalog; gate() remains the single enforcement point for any attempted action.
• Give every requirement at least one #### Scenario: block, including a scenario where an untrusted session cannot name a privileged tool and a scenario where step-up adds tools after re-verification.
• Write tasks.md as the ordered, reviewable milestones for the future implementation change, marking this change as design-only.

Task 4: Validate, register, and link the spec issue

Close the ceremony and hand off.

• Run openspec validate --changes <change-id> --strict and fix any validation errors.
• Add a decomposition entry for this topic to openspec/openspine-change-sequence.md, since no entry for it exists yet, and record its dependency on W6 and W8.
• If the design changes what Lyra can promise the owner, add or update the relevant entry in capabilities/capability-map.json (map "Permissions"/"Immune system" to real owner_outcome text) and run scripts/capability-map.mjs.
• Create the spec issue with gh following docs/agents/issue-tracker.md, link it to part-of #182, add the correct wayfinder/triage labels, and post the spec issue link back on this ticket.

🤖 Prompt for AI agents

Implement Phase 3, the "to-spec" stage: convert the resolved domain model into a
formal OpenSpec change, validate it, and hand it off with a linked spec issue.

For the OpenSpec change and proposal:
- Create a new change directory under `openspec/changes/` (for example
`design-capability-derived-tool-catalogs/`) using the `openspec-propose` flow.
- Write `proposal.md` with sections required by `openspec/conventions.md`: `##
Dependencies` (name W6, W8, and internal building blocks), `## Problem/Context`,
`## Proposed Solution`, `## Acceptance Criteria`, and `## Out of Scope`.
- In `## Out of Scope`, exclude implementation, `model_gateway` tool-schema
wiring, and any persisted session store.
- In `## Dependencies`, reference the validated action catalog
(`crates/openspine-kernel/src/action_catalog*.rs`), `TaskGrant` composition
(`crates/openspine-authority/src/compose.rs`), `skill.context` scoping
(`crates/openspine-kernel/src/api/skill_context.rs`), and `OwnerSurfaceRef` from
the archived channel-neutral review change.

For the design document:
- Write `design.md` describing the new derivation layer that turns
`TaskGrant.allowed_actions` (and, where relevant, `skill.context`'s grant-scoped
skills) into an LLM-facing tool schema, computed once per authenticated event
before the model runs.
- Describe the structural-absence rule: privileged tools are absent from the
schema for untrusted sessions.
- Describe identity step-up as a recompute triggered by a rise in
`source_verified`/`ChannelTrust`, re-running composition and re-deriving the
catalog.
- Complete the `openspec/conventions.md` authority-sensitivity checklist, adding
explicit verification requirements for identity resolution, task grants, and
gate-mediated actions.
- Follow `openspec/config.yaml`: state OpenSpine-core versus Lyra-product scope,
and confirm runtime authority stays expressed only through task grants and
gate-mediated actions.

For the delta specs and tasks:
- Create `specs/<capability>/spec.md` delta files with `## ADDED Requirements`
headers and RFC language (MUST/SHALL) for authority-sensitive rules.
- Add requirements: catalog derived from composed grant before inference;
privileged tools structurally absent from untrusted sessions (MUST); step-up
recomputes the catalog; `gate()` remains the single enforcement point for any
attempted action.
- Give every requirement at least one `#### Scenario:` block, including an
untrusted-session scenario and a step-up scenario.
- Write `tasks.md` as ordered, reviewable milestones for the future
implementation change, marked design-only.

For validation and hand-off:
- Run `openspec validate --changes <change-id> --strict` and fix any errors.
- Add a decomposition entry to `openspec/openspine-change-sequence.md`,
recording dependency on W6 and W8.
- If the design changes owner-facing promises, update
`capabilities/capability-map.json` (map "Permissions"/"Immune system" to real
`owner_outcome` text) and run `scripts/capability-map.mjs`.
- Create the spec issue with `gh` per `docs/agents/issue-tracker.md`, link it to
part-of `#182`, add correct wayfinder/triage labels, and post the spec issue link
back on the ticket.

Research

OpenSpine composes authority per event into a short-lived TaskGrant. The system enforces every effectful action at a single mediation point, gate() (crates/openspine-gate/src/gate.rs). The kernel holds an internal, curated action catalog (crates/openspine-kernel/src/action_catalog*.rs), but no model can see it. The model gateway (crates/openspine-kernel/src/model_gateway/*) sends plain prompts. It never sends a tool or function schema.

Identity is deliberately not authority (D-006). Grants are stateless per event. No persistent session, verified-role object, or step-up concept exists today. The nearest per-grant filtered surface is skill.context (crates/openspine-kernel/src/api/skill_context.rs). This surface returns untrusted competence prose, not invokable tools.

The repo has no CONTEXT.md, CONTEXT-MAP.md, or docs/adr/ yet. docs/agents/domain.md states that these are created lazily by domain modeling. The design-ticket-to-spec ceremony lives in openspec/conventions.md, openspec/config.yaml, and openspec/openspine-change-sequence.md.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1, the "grill" stage: close design ambiguity and ground ticket
vocabulary in existing canon before any modeling work begins. Produce a short
reconciliation note that later artifacts (Phase 2 and Phase 3) cite.

For the clarification pass:
- Use the repo-native clarification stance (`interview-me` / `blindspot-pass`
equivalents in `.omp/skills/`) to record and answer blocking questions.
- Confirm the session model decision: derive the tool catalog per-event from
`TaskGrant` (not a persisted session store).
- Map "identity step-up" onto `IdentityResolution.source_verified`,
`ChannelTrust`, and `RouteWhen.verified_source`, and state what it raises and
lowers.
- Record the status of the "Blocked by W6, W8" dependencies as external
prerequisites not defined in this repo. State what each must deliver before the
spec can be implemented.

For the terminology note:
- Create a working file under `.raw/` or the change folder scratch area.
- Map each invented ticket term to its canonical counterpart: "Lyra" to
assistant package; "Bell" to owner/human principal; "Permissions" promise to
`AuthorityClassId` (AD-147) and egress-classes; "Immune system" promise to
"Authority and containment" structural guarantees; "invariant I2" to a named
structural-absence corollary of D-006 and D-007.
- State explicitly that no LLM-facing tool catalog exists today, and that this
design introduces a new derivation layer without modifying `gate()`'s role.
- Cite real decision IDs (D-006, D-007, D-011, D-077/D-078, AD-147) instead of
the ticket's unattested I1/I2 scheme.
===============================================================================

Task: 2

Implement Phase 2, the "domain-model" stage: produce the glossary and ADR
artifacts that `docs/agents/domain.md` expects, defining the new terms once so
later spec artifacts can reference them.

For the glossary:
- Create `CONTEXT.md` at the repo root (and `CONTEXT-MAP.md` if more than one
bounded context is needed), following the convention in `docs/agents/domain.md`.
- Define these terms with exact meanings: "capability-derived tool catalog",
"verified role", "identity step-up", "structural absence" (versus runtime
refusal), and "untrusted session".
- Anchor each definition to its enforcement seam:
`TaskGrant.allowed_actions`/`approval_required_actions`/`denied_actions`,
`IdentityResolution.source_verified`/`ChannelTrust`, and `gate()`.
- Reuse existing vocabulary from `openspec/specs/**` where a concept already
exists; do not invent a synonym for an existing term.

For the ADRs:
- Create `docs/adr/` and add entries for: deriving the LLM-facing tool catalog
from the composed `TaskGrant` before inference; the structural-absence invariant
(privileged tools are omitted from untrusted sessions, never offered then
refused); and identity step-up as a recompute of the catalog triggered by a rise
in the verification signal.
- In the structural-absence ADR, cite as precedent the
authority-equivalence-matcher's type-level "cannot express a cross-class pick"
(`openspec/specs/authority-equivalence-matcher/spec.md`) and persona-binding's
route-resolved-only persona selection
(`openspec/specs/persona-binding/spec.md`).
- State explicitly that structural absence complements `gate()` and does not
replace it; `gate()` remains the mandatory fail-closed refusal path for any
action that is still attempted (D-007).
- Model "identity step-up" on the existing digest-bound reconfirmation mechanism
(D-011 WYSIWYS, D-077/D-078), not a generic elevated-trust flag.
===============================================================================

Task: 3

Implement Phase 3, the "to-spec" stage: convert the resolved domain model into a
formal OpenSpec change, validate it, and hand it off with a linked spec issue.

For the OpenSpec change and proposal:
- Create a new change directory under `openspec/changes/` (for example
`design-capability-derived-tool-catalogs/`) using the `openspec-propose` flow.
- Write `proposal.md` with sections required by `openspec/conventions.md`: `##
Dependencies` (name W6, W8, and internal building blocks), `## Problem/Context`,
`## Proposed Solution`, `## Acceptance Criteria`, and `## Out of Scope`.
- In `## Out of Scope`, exclude implementation, `model_gateway` tool-schema
wiring, and any persisted session store.
- In `## Dependencies`, reference the validated action catalog
(`crates/openspine-kernel/src/action_catalog*.rs`), `TaskGrant` composition
(`crates/openspine-authority/src/compose.rs`), `skill.context` scoping
(`crates/openspine-kernel/src/api/skill_context.rs`), and `OwnerSurfaceRef` from
the archived channel-neutral review change.

For the design document:
- Write `design.md` describing the new derivation layer that turns
`TaskGrant.allowed_actions` (and, where relevant, `skill.context`'s grant-scoped
skills) into an LLM-facing tool schema, computed once per authenticated event
before the model runs.
- Describe the structural-absence rule: privileged tools are absent from the
schema for untrusted sessions.
- Describe identity step-up as a recompute triggered by a rise in
`source_verified`/`ChannelTrust`, re-running composition and re-deriving the
catalog.
- Complete the `openspec/conventions.md` authority-sensitivity checklist, adding
explicit verification requirements for identity resolution, task grants, and
gate-mediated actions.
- Follow `openspec/config.yaml`: state OpenSpine-core versus Lyra-product scope,
and confirm runtime authority stays expressed only through task grants and
gate-mediated actions.

For the delta specs and tasks:
- Create `specs/<capability>/spec.md` delta files with `## ADDED Requirements`
headers and RFC language (MUST/SHALL) for authority-sensitive rules.
- Add requirements: catalog derived from composed grant before inference;
privileged tools structurally absent from untrusted sessions (MUST); step-up
recomputes the catalog; `gate()` remains the single enforcement point for any
attempted action.
- Give every requirement at least one `#### Scenario:` block, including an
untrusted-session scenario and a step-up scenario.
- Write `tasks.md` as ordered, reviewable milestones for the future
implementation change, marked design-only.

For validation and hand-off:
- Run `openspec validate --changes <change-id> --strict` and fix any errors.
- Add a decomposition entry to `openspec/openspine-change-sequence.md`,
recording dependency on W6 and W8.
- If the design changes owner-facing promises, update
`capabilities/capability-map.json` (map "Permissions"/"Immune system" to real
`owner_outcome` text) and run `scripts/capability-map.mjs`.
- Create the spec issue with `gh` per `docs/agents/issue-tracker.md`, link it to
part-of `#182`, add correct wayfinder/triage labels, and post the spec issue link
back on the ticket.

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

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

---

💬 Have feedback or questions? Drop into our discord!

[George-RD]

Resolution. Grilled with the owner (orchestration coordinator, per the #182 owner ruling); design decided and specced.

Decision. Capability-derived tool catalogs are a pure, pre-inference projection: openspine-authority projects a CatalogView from the already-composed TaskGrant + a new kernel ActionCatalog tool-descriptor axis, served through the existing GET /v1/task seam (no new endpoint, compose()/gate() decision logic untouched). Three-list rule: allowed_actions -> callable; approval_required_actions -> present + annotated; denied_actions and any ungranted id -> structurally absent (Bell invariant I2). Structural absence is attenuation; gate() remains the sole fail-closed enforcement. Identity step-up is a recompute (no persisted session / verified-role object; would conflict with D-006). Projection is policy-free (one policy point = compose). Role/identity vocabulary binds to sibling spec #197 (PrincipalId/OwnerPrincipal); no new role type. Grounded in #190's research ruling (CaMeL pre-inference attenuation).

Facts that shaped it: no LLM-facing tool catalog exists today (the model gateway sends no tools); /v1/task already ships the bare grant lists to the untrusted shell; the kernel catalog has no per-action parameter schema yet.

Spec: #209 (ready-for-agent).
Implementation tickets (dependency order, native edges wired): #210 (tool-descriptor axis + failing completeness gate test) -> #211 (pure projection fn) -> #212 (serve over /v1/task, prove the I2 boundary + step-up + gate-remains-enforcement end to end).

Closing per the handoff shape (DIRECTION.md): decision recorded + spec issue exists and is linked.