Content packs compose at campaign granularity, but dynamic content injection needs node granularity

[The-Running-Dev]

Content packs compose at campaign granularity, but dynamic content injection needs node granularity

A design handoff proposing "dynamic campaign content" — side quests injected into an existing scene, content composed across campaigns, campaigns published without an engine rebuild — was evaluated against this codebase. Most of what it proposed to prove is already decided and exported. One thing it wants is genuinely not expressible today, and that is the only open question worth spiking.

Already settled, and the proposal did not know it. resolvePacks, applyExperimentGates, computeResolutionId, ContentPack and PackRef are contract exports from the package root, specced in 11-content-packs.md, with src/engine/src/index.ts stating outright that the composition they serve is host-side. ContentRegistry.resolution is already a digest over the ordered pack set, and §6 of that spec is "Identity, and Why Determinism Needs It." The proposal's central thesis — content resolution belongs above the engine, the engine consumes resolved content — is the architecture this package already contracts for.

What is not expressible. resolvePacks replaces campaigns wholesale by id and strings per key. It cannot express "this scene gains one additional choice." Injecting a side quest into an existing node today means republishing an entire replacement campaign, which is not composition in any useful sense — the delta is the whole document. That is the real gap, and it is narrow enough to answer against the existing contract rather than by building anything.

Three things constrain any answer:

• Choice labels are AuthoredText, resolved through registry.strings, which is built once when the registry is built. A node-granular delta has to carry loc keys and string-table entries, not raw display text — the shape composition already uses per key, but at a different level.
• Injected content is by definition outside the validated set. A choice whose target does not resolve reaches requireNode, which throws — on the read path, not at build time. Whatever expresses a delta has to be validatable by the same tiered pipeline a folded registry already goes through, or it moves a build-time failure to runtime.
• Whatever a delta is, folding it must still produce a stable ResolutionId. That identity is what makes replay reproducible across a composed content set; a composition mechanism that cannot be digested deterministically is not usable here regardless of how convenient its authoring shape is.

The narrow question this issue exists to answer: can a side quest be expressed within the current pack contract, and if not, what is the minimal extension that makes a node-granular delta expressible while keeping validation and ResolutionId intact?

If the answer is that packs already suffice via some composition of existing primitives, this is configuration and there is nothing to build. If it is not, the extension is a contract change and belongs in the design pipeline before any code.

Done when

• There is a recorded answer to whether a node-granular delta is expressible under the current 11-content-packs.md contract
• If it is not, the minimal contract extension is described — covering how a delta carries string-table entries, how it is validated, and how it folds into a deterministic ResolutionId
• The answer is recorded where the design pipeline can act on it, not only in this issue

---

Agent instructions

Origin: an external design handoff ("Dynamic Campaign Content — Revised Design Handoff & Spike Proposal") evaluated against this repository. That document is not authoritative here and several of its premises about this codebase are wrong — see #293 for the session-identity half. Only the question stated above survived evaluation.

Read first: design/11-content-packs.md (§3 resolution, §6 identity, §7 validation), src/engine/src/core/registry/packs.ts, and src/engine/src/index.ts's comment on why the pack exports are host-facing.

Do not design a plugin framework, a middleware pipeline, a runtime graph-merge subsystem, or a persistence model in response to this. The question is whether an existing contract can express one thing.

Stop if: answering this requires changing ContentRegistry, the pack fold, or the export surface — that is a contract change and goes through design/ (brief → design → contract → slices), not an unattended implementation.

Note on determinism: Engine.scene(state) and availableActions(state) are pure and synchronous by contract (04 §1). Any proposal that resolves content during a scene read, rather than before the engine is constructed, breaks that and should be rejected on sight.

[The-Running-Dev]

Disposition of the source handoff document

Recording this here so the document that prompted this issue has a landing place, and nobody starts on its Step 1 without seeing what survived evaluation. Section-by-section, against this repository as it actually stands:

Moot — the premise is already false.

• §1 (content is packed into the engine artifact and pinned to the engine version), §4 and §10 (prove content can load from remote JSON), §24's "runtime side" diagram. Campaign content is already decoupled: fromPortable/Portable* export it as JSON, the downstream host fetches or reads it at runtime, and its source is already injectable there. The document describes this repository's authoring path — TypeScript campaign builders under src/engine/src/campaigns/ — as though it were the runtime path. Spike Steps 1 through 3 would re-prove something that shipped.
• §12 (webhook-triggered reconciliation). Content delivery is decided downstream in The API only picks up new campaign content through a full image rebuild and redeploy SubZeroDev.Adventures#25 — scheduled pull, bind-mounted volume, restart. The document's semantic point that a webhook means "content changed, reconcile it" rather than "this content is live" is correct and was reached independently there. Nothing left for this repo.

Already contracted — the document proposes building what exists.

• §2, §3, §5, §9 (content resolution as the extensibility boundary; a future resolver pipeline). resolvePacks, applyExperimentGates, computeResolutionId, ContentPack and PackRef are contract exports, specced in design/11-content-packs.md, and src/engine/src/index.ts states outright that the composition they serve is host-side. ContentRegistry.resolution is already a digest over the ordered pack set.
• §11, §21 (persistence stays replaceable behind the boundary). Already true.

Rejected on contract grounds.

• §5's GetScene(campaign, version, scene, sessionContext) as the resolution seam. No such function exists. Engine.scene(state) is synchronous and pure with no I/O by contract (04 §1); SessionStore.getScene(sessionId) is async only because storage is; TextClient.getScene(sessionId) is a render wrapper. None takes a campaign or scene id, because content does not enter through a scene read — it is injected at construction as ContentRegistry. Resolving content inside a scene read would make the engine async and I/O-capable, which is the precise opposite of the document's own "keep the engine boring" instruction.

Survived — this issue.

• §6, §7, §8 (dynamic content without graph mutation; side quests; extensions as content rather than engine primitives). The genuine gap: packs replace campaigns wholesale by id and strings per key, so a side quest cannot be expressed as a delta. See this issue.

Survived — #293.

• §7's deliberately-undecided cross-campaign traversal semantics. The document defers them; its own first experiment hits them immediately, and the shared variable names across adventure-builder.ts campaigns make the failure silent rather than loud.

Understated.

• §13 (replay/determinism as deferrable, and as purely a host-layer concern). availableActions(state) is pure and the action log records ids, so content that resolves differently at different times diverges on replay. ResolutionId exists for exactly this. The document's Step 6 would hit it, not a later phase.
• §19 (validation out of scope). Injected content is by construction outside the validated set, and an unresolvable target reaches requireNode, which throws on the read path. Not a call to design a validation subsystem — just a consequence that has to be designed for rather than deferred.

Procedural.

The document is headed for this repository, but the "API/business layer" it assigns most of the work to lives in the downstream host, across a submodule boundary, leaning on exports this repo marks non-contract (#285). And anything touching ContentRegistry semantics is a contract change that belongs in design/ — brief, design, contract, slices — not a standalone handoff.

[The-Running-Dev]

Answer: no for structure, already yes for text.

The fold in resolvePacks is two Map.set loops:

for (const { campaign } of pack.campaigns) campaigns.set(campaign.id, campaign);
for (const [key, text] of pack.strings)    strings.set(key, text);

Campaigns are replaced as whole objects keyed by campaign.id. There is no content merge, and the core cannot have one: Campaign.content is unknown to the core by design (04 §2), and the dependency-arrow rule forbids core/ importing a kind, so nothing in the fold is able to interpret content well enough to merge it. The smallest expressible structural delta is therefore an entire replacement Campaign.

But strings fold per key, which means half of what "dynamic content" was reaching for already works. A pack supplying driving.repair_route_1.text overrides exactly that node's prose, no campaign republished, no engine change. That is the designed culture-pack mechanism — 10-design.md §4a: the voice lives entirely in the string table, so a pack changes tone by changing content rather than code.

So the real boundary is: text is delta-able today; structure is not. Worth stating plainly because those are usually conflated, and the common cases (fix a typo, retune prose, change voice for a locale) fall entirely on the supported side.

The minimal extension, if structural deltas are ever wanted

It has to be kind-owned, not core-owned — that is forced by the same rule that blocks it today. Kind already carries every operation that needs to interpret opaque content or state: validateCampaign, migrateState?, outcome, advance. A merge is the same shape:

mergeContent?(base: unknown, delta: unknown): CommandResult<unknown>

dispatched from the fold when a pack declares a delta rather than a replacement. Checked against the three constraints in the issue:

• Identity — computeResolutionId digests the ordered {id, version} list and never touches content, so a delta pack digests exactly like any other. Determinism holds as long as the merge is pure, which a kind-owned fold is by construction.
• Validation — already handled, and this is the part that makes the extension attractive rather than risky. packs.ts's own header records that the fold "leaves per-campaign Tier 1/2 content validation to the same pipeline a single-campaign registry already goes through (validation/tiered.ts), now over the folded result." Merge before validate, and a merged campaign is validated identically to an authored one — which closes the "injected content is outside the validated set" hole by construction rather than by adding a check.
• Strings — a structural delta adding a choice carries its label LocKey in the same pack's strings, which the fold already merges per key. Nothing new needed.

That is one optional Kind method, dispatched at an existing fold, validated by an existing pipeline, digested by an existing identity function. Small — but it is a contract change to Kind, so per this issue's own escalation rule it belongs in design/ before any implementation.

Recommendation

Don't build it yet. Text deltas already cover the frequent cases. Structural deltas only matter once a side quest is actually wanted, and #293 — what a session is when content spans two campaigns — is a harder blocker for that than the merge mechanism is. Answering #293 first may well change what a delta needs to express.