[mp-blurify]

Summary

createApp applies SERVICE_MANIFEST to whatever plugin list it is given and names everything a manifest leaves out in one error with one manifest line that boots, refuses to boot a split that would skip a money, compliance or authorization control, logs each other optional port it leaves unbound, and a new JOB_WORKERS env var picks the job queues a process consumes. Also fixes the create:service scaffold and records a follow-up ADR.

Why

• The manifest only worked through loadExtensions(). createApp read SERVICE_MANIFEST just to require SERVICE_NAME, so a host that passes its own plugin list (the downstream guide shows exactly that) booted every module under the split service's own consumer group: every broker event was handled once more across the cluster. Verified on a real consumer: the "split" process loaded every module and created its group on ~150 streams.
• What a manifest missed surfaced one kind per boot, and the rule that a manifest lists its modules' dependencies had been dropped from the docs. Dependencies, the modules that bind required ports, the modules behind controls and AdminGuard's modules now fail the boot once, in one error naming each, with one manifest line that also adds what those modules need in turn (transitively, infra overlays' dependencies included). SERVICE_MANIFEST=wallet gets a line that boots on its first boot.
• A split service lost controls silently. Modules resolve some ports with c.has(), so wallet,identity,mail,audit took deposits and bets past the RG limits, signed players in without the country check and sent regulatory mails without an audit record, and its admin routes fell back to static grants without iam - an admin whose role was revoked could still approve a withdrawal. The boot said nothing. Now a manifest boot fails closed: a plugin lists a port that backs a money, compliance, authorization or audit control in controlPorts, with the module that binds it, and the boot refuses while one is unbound and the plugin list has that module, printing the manifest line to paste. AdminGuard holds ADMIN_PERMISSION_RESOLVER (iam) and ADMIN_SECURITY_POLICY (identity) to the same rule on every manifest boot, admin routes or not, and a manifest boot builds the guard before it serves. Declared: RG_LIMITS (wallet, gaming), GAME_GEO_CHECK (gaming), GEO_CHECK_COMMANDS (identity, bonus, notifications), MCP_TOKEN_REVOCATION (identity), AUDIT_WRITER (mail). A full boot, and an install whose list lacks the binding module, only log them, as before. A port whose absence only degrades a feature or already fails closed (no KYC policy, no risk tags) is not a control port.
• Every process consumed every queue. A job that runs for minutes and mostly waits on an outside service (an agent run waiting on a model) took a share of every API replica. It cannot move to a manifest service: that gets its own copy of every event, and the in-process MCP kernel needs every module that contributes tools. JOB_WORKERS (names, prefix*, ! exclusions; unset = all) lets one more full instance with the same SERVICE_NAME take such queues while the replicas skip them. A malformed value or an inclusion that matches no queue fails the boot; the boot log lists consumed and skipped queues. ADR-0046 (Proposed).
• pnpm create:service generated a host that could not boot: no SERVICE_NAME, and an example manifest that left out what its modules need. Its example is now the line the first boot of SERVICE_MANIFEST=wallet suggests, which an E2E boots. It now also warns that a module two services load handles each event in both, until ADR-0047 lands.
• ADR-0047 (Proposed, not implemented): modules a split service loads only as dependencies still wire their handlers under the service's own group (audit, for one, would write each row once per service); the proposal is that only selected modules consume. It is a follow-up outside this PR.

Alternatives considered

• Consumers call loadExtensions(): it rewrites relative paths, so it breaks hosts that list bare package specifiers.
• A process role (SERVICE_ROLE=api|worker): fixes one topology and cannot name queues. Role metadata per worker registration: a module cannot know how it is deployed. A worker-only process without routers: router factories are boot hooks workers rely on (ADR-0038). Details in ADR-0046.

Risks

• Behaviour change (!): a process that sets SERVICE_MANIFEST with a static plugin list now boots that subset, or refuses to boot over missing dependencies or a skipped control. With the shipped modules every split carries iam, identity, audit, mail, compliance, wallet, gaming, player-management, exchange-rate and chat, and until ADR-0047 lands their handlers run in the split and again in the rest of the install. When a manifest boot fails, each listed plugin the boot had not registered runs its register() once, into a container of its own that is then dropped, to learn which module binds which port; register() must only declare (documented on Plugin.register), and the failed boot disposes its container. Consumer groups the old full boot created under a split SERVICE_NAME are stale (XGROUP DESTROY). Merges to dev publish a canary immediately.
• JOB_WORKERS needs operator care: every queue needs a consumer somewhere, and processes that share a SERVICE_NAME must load the same modules; core cannot check either across processes. Unset changes nothing.
• Overlapped with feat(core): opt-out anonymous usage telemetry #295 and fix(core): deliver domain events at least once #297 in create-app.ts, ADR-0017 and the messaging rule. Both have merged and dev is merged here; they took ADR-0044 and ADR-0045, so this PR's ADRs are ADR-0046 (job worker selection) and ADR-0047 (dependency-only modules).

[zaxovaiko]

Looks good to me. Traced every createApp caller and every ctx.jobs.worker registration (core plus the betfeel overlays), all of them go through the new selection, and schedules still land after it. Minor:

• create:service accounts identity,mail still double-handles: the monolith boots identity too, so its 3 session handlers run twice, and the suggested audit override writes every audit row twice. Maybe worth a warning in the scaffold output until ADR-0045 lands?
• Let's give the agent-hub queues one shared prefix, so the split is JOB_WORKERS=agent-hub* on the worker and !agent-hub* on the API without listing each queue.
• Nothing checks across processes, so a dead worker means a queue that silently backs up. We'll need a queue-depth alert next to the deploy change. But that's for later.
• ADR-0044 collides with #295 and #297.

[mp-blurify]

Thanks, @zaxovaiko.

• Scaffold: it now warns after generating that a module two services load handles each event in both (audit writes every row twice), points at the boot's optional-port warnings, and no longer suggests adding audit (beea7f2).
• Shared prefix: agreed. That's a rename in the overlay that registers those queues; JOB_WORKERS already takes prefix*.
• Queue-depth alert: agreed, with the deploy change. ADR-0044 lists it.
• ADR-0044: feat(core): opt-out anonymous usage telemetry #295 and fix(core): deliver domain events at least once #297 are still open, so whichever lands later renumbers.

[zaxovaiko]

/codex all

[blurify-codex]

Blocker: a service manifest can boot money and admin routes without their compliance and permission controls. Blocker: split services can duplicate audit records when they load shared dependency modules.

Reviewed security, compliance, conventions, performance, reliability, rollout, spec, the whole change.

[zaxovaiko]

LGTM

[zaxovaiko]

Not quite yet - the scaffold example still doesn't boot, and fixing a manifest takes up to three boots. The AI side looks right to me: core gets no runtime or model code, and JOB_WORKERS is a generic seam the hub can use. Minor:

• The MCP_TOKEN_REVOCATION control also refuses a split while agents.mcp.enabled is off. Admin routes need iam anyway, so that's for later.

[jakubfilinger-b]

Overall the manifest/JOB_WORKERS logic reads correct to me (parser edge cases look handled). Two notes inline/below: the double register() and the ADR-0044 number clash with #297.

[jakubfilinger-b]

Heads-up: this and #297 both claim ADR-0044 (as the description notes), so whichever merges second needs to renumber its ADRs.

[mp-blurify]

@jakubfilinger-b on the ADR numbers: agreed. #297 is still open and dev's latest is 0043, so I'm leaving them as they are for now. Whichever merges second renumbers. If #297 lands first, this PR's 0044 and 0045 become 0045 and 0046, and every cross-reference moves with them: the ADRs themselves, the messaging rule and AGENTS.md, the docs, and the plugin-host and scaffold notes that cite ADR-0044.

[mp-blurify]

Merged dev into this branch, so it now builds on #297's at-least-once event delivery. #297 took ADR-0045, so this PR's ADRs are renumbered to ADR-0046 (per-process job worker selection) and ADR-0047 (dependency-only modules provide but do not consume), with every cross-reference updated. The only conflicts were ADR-0017's update notes (both kept) and the imports in create-app.test.ts; the merge also left the audit plugin's logger unused, so it is removed.

[jakubfilinger-b]

Heads-up: this PR and #372 both introduce an ADR numbered 0049. Whichever merges second will need to renumber its ADR and update its references.

[jakubfilinger-b]

Re-reviewed. The only change of its own since my approval is 8bd1962 (boot check reads the flagged manifest entries, tests set REALTIME_NAMESPACE), which looks right; the rest is merges of dev. The ADR numbers are settled now.