INT-02 follow-up: `affinescript-dom-loader` satellite shell — scope question (split repo vs fold-into affine-js)

[hyperpolymath]

Spun out of #179 closure 2026-05-31. The INT-02 substrate is shipped + proven; what's not settled is whether the satellite shell repo (hyperpolymath/affinescript-dom-loader) should still be scaffolded as a separate artifact, or whether packages/affine-js has effectively subsumed it.

State today

Piece	Where	Status
Host-agnostic loader substrate	packages/affine-js/loader.js	PROVEN + locked (#250 + #267 → 14 unit tests + real-wasm e2e harness)
Browser/Deno/Node parity	detectHost + readBytes via Deno.readFile / node:fs+fileURLToPath / fetch	✅ in substrate
Multi-namespace import object	buildImportObject (legacy env merge + INT-01 cross-module namespaces)	✅ in substrate
Ownership-section accessor	parseOwnershipSection (round-trips compiler binary format)	✅ in substrate
affinescript-dom-loader satellite repo	nonexistent	open question — this issue
affinescript-dom reconciler	#183, in-repo src/dom.affine, compiles end-to-end, runtime blocked by #255	separate track (INT-08)
INT-05 / INT-08 / INT-11	per ECOSYSTEM	INT-02 dep cleared; reconciler runtime still needs #255

The question

When the satellite registry was reconstructed (#175, 2026-05-19), affinescript-dom-loader was an imaginary downstream shell. The substrate then landed in-tree in packages/affine-js and turned out to be fully host-agnostic — meaning a browser/DOM consumer can already import the loader directly from affine-js without any DOM-specific wrapper.

So: does the satellite repo still earn its keep?

Option A — Fold into affine-js, retire the satellite name (recommended pending owner call)

• packages/affine-js already does Deno/Node/browser parity; there is no DOM-specific behavior the loader needs that isn't already in the substrate.
• INT-11 ("DOM loader + reconciler end-to-end") becomes: affine-js loader + affinescript-dom reconciler, no third repo.
• ECOSYSTEM satellite-registry row gets removed, not just truthed.
• Pros: one fewer repo to maintain, one fewer publish/version surface, matches what the code actually is.
• Cons: loses the symmetry of "one satellite per integration concern"; if a DOM-specific loader surface emerges later (e.g. <script type=\"application/wasm-affine\"> discovery, shadow-DOM-scoped instance roots, MutationObserver-driven re-hydration), it'd have to be re-extracted.

Option B — Scaffold the satellite as a thin re-exporter package

• New repo hyperpolymath/affinescript-dom-loader: deno.json + mod.ts re-exporting from jsr:@hyperpolymath/affine-js plus DOM-side conveniences (mountWasmModule(el, url, opts), <affine-app src> custom element, etc.).
• Pros: clean public dep surface for browser apps ("import { mountWasmModule } from '...'" is more discoverable than "reach into the runtime's loader").
• Cons: real maintenance cost; the DOM-side conveniences don't exist yet, so the repo would be ~empty on day one and would only justify itself once INT-08 wiring is real.

Option C — Defer until INT-08 reconciler runtime is unblocked (#255), then decide

• The DOM-side loader surface is defined by what the reconciler needs from it. With wasm codegen: for-in/while loop bodies never execute in compiled programs (pre-existing, untested) #255 (for-in/while body codegen) still open, the reconciler doesn't actually run end-to-end yet, so we don't know that surface.
• Mark the satellite-registry row as DEFERRED with a back-pointer to wasm codegen: for-in/while loop bodies never execute in compiled programs (pre-existing, untested) #255 + INT-08: DOM reconciler in affinescript-dom #183; re-evaluate when INT-08 runtime turns green.
• Pros: avoids speculative repo creation; matches the "substrate first, satellite second" discipline the rest of the registry follows.
• Cons: leaves an unresolved name in the registry.

Recommendation

Option C for now, with Option A as the likely landing if INT-08 doesn't surface anything DOM-loader-specific. The substrate did its job; creating an empty satellite repo today would be premature and just adds estate surface that has to be maintained, license-audited, hypatia-scanned, etc.

Acceptance criteria for closing this issue

• Owner picks A / B / C (or a fourth option I'm missing)
• ECOSYSTEM.adoc satellite-registry row + INT-11 row updated to reflect the decision (removed / scaffolded / deferred)
• If B: repo created, scaffold PR landed, downstream INT-05/08/11 referenced
• If A: registry row removed, INT-11 description rewritten to omit the third repo
• If C: row marked DEFERRED with pointer to INT-08: DOM reconciler in affinescript-dom #183 + wasm codegen: for-in/while loop bodies never execute in compiled programs (pre-existing, untested) #255; re-evaluation issue auto-filed when INT-08: DOM reconciler in affinescript-dom #183 runtime turns green

Refs: #179 (substrate), #183 (INT-08 reconciler), #255 (wasm loop-codegen blocker), #175 (integration roadmap index).