Architecture: Wasm/WIT + Signal IR + Capability Runtime

[Sportinger]

Context

This follows the Pandino-SCR architecture discussion in #133.

Thanks @fayakun-it-consulting for pushing this topic so persistently. That pressure made us look past the narrow question of a service registry and examine the deeper extensibility problem in MasterSelects.

Direction

We are going to move the architecture work toward a broader runtime foundation:

• Signal IR for imported and generated media/data
• content-addressed artifacts
• explicit extension/provider manifests
• capability-based execution policy
• Worker isolation for JS/TS providers
• Wasm/WIT ABI for portable importers, analyzers, operators and future render/export adapters

Pandino-SCR may still become useful later as a bundle/service registry on top of this provider architecture, but it should not be the core primitive we build around first.

Plan

Local plan document:

docs/plans/wasm-wit-signal-ir-worker-runtime-plan.md

Planned development branch:

architecture/wasm-wit-signal-runtime

First execution slices

1. Signal IR contracts and type migration surface
2. Content-addressed Artifact Store
3. Extension Registry and Capability Policy
4. Worker Runtime
5. Wasm/WIT Host and ABI
6. Universal Import Orchestrator with real file verticals

Review flow

After the first six implementation streams, run three reviews:

• API/contract review
• Runtime/security review
• Integration/performance review

Then write a consensus document before merging the first architecture slice.

[Sportinger]

Plan is now committed on the linked development branch, and the English translation is available on the issue branch for #135:

• Architecture branch: architecture/wasm-wit-signal-runtime
• Original plan commit: 6163d01
• Translation branch: issue-135-translate-runtime-plan
• Translation commit: 47094df
• English plan: https://github.com/Sportinger/MasterSelects/blob/issue-135-translate-runtime-plan/docs/plans/wasm-wit-signal-ir-worker-runtime-plan.md

[fayakun-it-consulting]

Pandino-SCR may still become useful later as a bundle/service registry on top of this provider architecture, but it should not be the core primitive we build around first.

Can you explain to me the logic behind the decision for not using an IoC with an SCR as the foundation for MS? What kind of architecture design choice other than IoC are you implementing right now or planning to do so?

I would like to know why an IoC & SCR is not good as the base of this project.

Kind Regards

[Sportinger]

Hey @fayakun-it-consulting, fair question. Let me explain the reasoning more directly.

The decision is not that IoC or SCR is bad. The decision is that IoC/SCR is not the first missing foundation in MasterSelects.

An IoC/SCR layer mainly answers this question:

How do components/services discover each other, get wired, activated, replaced and ranked?

That is useful, especially for plugins. But the current architecture work has to answer a lower-level question first:

What is a MasterSelects extension actually allowed to be and do?

For example, before we wire providers dynamically, we need stable answers for:

• what any imported file becomes inside the app
• how imported/generated artifacts are stored and identified
• how provider outputs are persisted in project files
• what capabilities a provider may request
• how generated/custom/provider code runs outside the main thread
• how non-TypeScript providers can participate through a stable ABI

That is why the current plan starts with:

Signal IR -> Artifact Store -> Provider Manifest -> Capability Policy -> Worker Runtime -> Wasm/WIT ABI

This is still declarative architecture. The metadata just lives in explicit manifests, capability declarations, signal schemas and WIT contracts instead of being primarily decorator/container metadata.

The risk with making SCR the root first is that we would get better service wiring before the real media/runtime contracts are stable. We could end up dynamically registering the current coupling instead of defining the stable boundary that importers, analyzers, operators, render adapters and exporters must follow.

So the architecture choice is not "IoC vs no IoC." It is "runtime/data contract first, service registry later."