Module context_injection 

BP-4 (catalog:91 “Synthetic context-injection blocks”, design §1.4: “harness-spliced reminders/nudges … the ambient nudge class is core”): the injection REGISTRY behind core.context_injections.

Before BP-4 the key gated exactly one thing — a static, caller-populated ContextInjectionBlock list appended once at construction — so a preset turning it on got nothing, because no preset (and nothing in the product) ever populated the list. Neither parity preset set the key at all, which made the gap invisible.

The registry has three sources, spliced in this order:

1. Built-in blocks (builtin_blocks) — derived from the RESOLVED config, so a block only appears when the capability it talks about is actually armed. This is the “~25 block types” class cx’s own context/ library and cc’s <system-reminder> blocks occupy: ambient statements about the harness the model is running inside, which no instruction file can know.
2. User blocks — crate::Config::context_injection_blocks, the pre-existing embedder-populated list, unchanged.
3. Spliced blocks — crate::Agent::inject_context_block, added mid-session (a hook’s additionalContext, a frontend’s nudge, an orchestrator’s brief). This is the half that makes the mechanism a SEAM rather than a startup constant.

Everything here is a no-op when core.context_injections is false (the default): assemble returns an empty string and nothing is read.

Functions

assemble

blocks + render — the whole injection contribution to a system prompt.

blocks

Every block a system prompt should carry, in splice order: built-ins, then the config’s own list, then anything spliced in at runtime. Empty (and free of any work) when core.context_injections is off.

builtin_blocks

The built-in ambient blocks armed by config, in a stable order.

render

Render blocks as the \n\n# {name}\n{content} sections the assembly site appends to the system prompt — the exact shape P4e’s static list used, so a config that only set context_injection_blocks renders identically.