Introduce InterceptorOverrides in the chain execution model to separate
interceptor capability (server-declared) from execution policy
(invoker-declared).
## Why
The SEP currently locks all execution policy (failOpen, priorityHint,
mode) into the interceptor's own definition. This means:
- If an interceptor declares `failOpen: false` but is known to be flaky
in your deployment, you can't make it fail-open without changing the
server
- If you want the same interceptor in audit mode in staging but active
in production, there's no mechanism
- If you want to restrict an interceptor to only `tools/call` even
though it declares support for `tools/call` + `llm/completion`, you have
to invoke it and hope the chain filters correctly
- Priority is fixed by the author, so platform teams can't reorder
interceptors for their deployment topology
In short: the chain interface had no policy layer, making it impractical
for real-world multi-environment deployments.
## Changes
1. New "Capability vs Policy" subsection explaining the two-layer model
2. New `InterceptorOverrides` interface (failOpen, priorityHint, mode,
timeoutMs, hooks)
3. ChainEntry gains `overrides?: InterceptorOverrides`
4. `resolvePriority()` updated to check overrides first
5. Orchestration steps updated — new step 2 "Resolve Policy"
6. New example showing overrides in action (priority override, mode
promotion, fail-open for fragile interceptor)
7. New rationale entry (Design Decision 4) explaining why both layers
exist
Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
Co-authored-by: Kurt Degiorgio <Degiorgio@users.noreply.github.com>
eebd2ac6a2