What @evanion/feature does not do

To help you decide if this library fits your architecture before you write any code, it is important to understand its boundaries. The @evanion/feature library evaluates the definitions it was handed, for the context it was handed, in the process that asks.

Nine specific capabilities sit outside that scope, and no release adds one.

Left to you	What fixes it	What you use
No transport. The package declares no runtime dependency and opens no socket.	libs/feature/src/lib/core-boundary.spec.ts (“declares no runtime dependency”, “starts no timer and opens no socket”); decision 13 of docs/specs/2026-09-23-feature-config-distribution.md	Fetch the document with your own HTTP client, database driver or file read and pass it to createFeatures, hydrateFeatures or reload.
No scheduler. Nothing polls and nothing reloads on a timer.	libs/feature/src/lib/core-boundary.spec.ts; decision 2 of docs/specs/2026-09-23-feature-hydration.md	The platform binding decides when to refetch and when to reload. Call reload from your own interval, webhook or stream.
No administration surface. The package ships no interface that writes a definition.	Decision 2 of docs/specs/2026-09-23-feature-config-distribution.md	The control plane owns where the document came from and who receives it. Write the document in your own control plane or in a TypeScript file, and use serializeConfig to write it out.
No decision endpoint. No call answers which variant a subject gets over the network.	Decision 15 of docs/specs/2026-09-23-feature-config-distribution.md	A control plane serves a version probe and the two documents a changed version points at (the configuration and the schema). Every process holds the rules and decides locally. A server that wants the client to see its answer ships a snapshot.
No clock authority. The package reads the clock only when a context leaves now out, and it keeps no clock of its own that it could correct.	Decision 2 of docs/specs/2026-09-23-feature-config-distribution.md; libs/feature/src/lib/core-boundary.spec.ts (“starts no timer”)	The party that fetches knows the fetch instant. Pass now when a tree must agree with another process.
No freshness policy. The maxStale member of the envelope is advisory. No entry point reads it and no decision depends on it.	Decision 3 of docs/specs/2026-09-23-feature-config-distribution.md; decision 2 of docs/specs/2026-09-23-feature-hydration.md	A store never answers off because a document is old. Read maxStale in the code that fetches and decide there.
No upward blocking. A child that is off never switches its parent off.	Decision 3 of docs/specs/2026-09-11-feature-toggles.md	Dependencies cascade one way only, from a parent that is off to its dependants.
No exposure counting. No event records that a subject saw a variant.	Decision 15 of docs/specs/2026-09-23-feature-variants.md; decision 1 of docs/specs/2026-09-23-feature-observation-seam.md	resolve decides every configured feature, so a count made at resolve time counts variants nobody rendered. Record the exposure where the component renders, reading the decision it already holds. The Observing page argues the point.
No framework package beyond React. @evanion/react-feature is the only adapter.	Decision 6 and the “Every feature adapter” section of docs/specs/2026-09-16-framework-adapters.md	A second framework would need a demand that does not exist yet. Call createFeatures and resolve directly from Vue, Svelte, Angular or any server code, because the core imports no framework (libs/feature/src/lib/core-boundary.spec.ts, “imports no module outside itself”).

What changes if you need one

If you find yourself needing a capability listed above, read the file referenced in the “What fixes it” column before opening an issue. Any change to one of these nine boundaries requires a change to a spec decision first.