Decide: keep the in-memory hosted engine and napi addon as a supported product, or delete them

This is a design decision for a project owner, not a code change to start from. Read the hosted in-memory engine in crates/socket-patch-core/src/hosted/memory/mod.rs and the contract line at crates/socket-patch-cli/CLI_CONTRACT.md#L670. Done means an owner has chosen option A, B or C and stated whether that contract line stands, and the follow-up issues are filed.

[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: discussion #560 register.

Kind: decision. Source: review §6 Q1 and Part 3.7 #6 (recommendation 5 in the summary); register E44.

Question

Is the in-memory hosted engine (hosted/memory/), with its napi addon (crates/socket-patch-node) and the hidden hosted-bundle harness, a product socket-patch supports? The answer decides how the hosted orchestrator gets unified (E32), and about 4.5K production lines.

A note on the current state: since #1029, the contract says "N-API and the hosted in-memory engine remain supported for callers such as the future GitHub App" (CLI_CONTRACT.md#L670). The review predates that line, and it asked whether depscan would adopt the engine. This issue asks an owner to confirm or overturn the line, and to choose what "supported" means.

Options

• A. Keep it, as a supported engine with the disk engine's coverage. The in-memory path becomes the one hosted pipeline: disk runs build a DiskSnapshot → MemoryProject and call one redirect_root(view, selected, api, hooks), with host-only effects as hooks (apply lock, takeover, online vlt preflight, pipenv probe, write-back, VEX). The parity suites become ordinary tests. The coverage gaps listed below become bugs to close, or documented tier cuts. Estimated −700 to −900 production lines (E32), done in several PRs.
• B. Keep it as it is today: a private, partial engine for one future caller. The gaps stay documented. Both orchestrators and the parity suites stay, and each new hosted feature is written twice or refused in memory.
• C. Delete it. Remove hosted/memory/, the addon, hosted-bundle, the ProjectView::Memory arms and the parity suites. If a future GitHub App needs an engine, it starts from the disk engine over a checkout. That is −4.5K production and −4.7K test lines, plus a CI job.

The audit recommends A if the GitHub App is a committed consumer, and C otherwise. B is the most expensive option in the long run, because every hosted change pays for two orchestrators.

Facts (main @ 03b9418)

• Size. Production code before #[cfg(test)]:
  • hosted/memory/*.rs: 3,660 lines (mod.rs 1,350, types.rs 549, select.rs 462, discover.rs 411, stages.rs 360, limits.rs 345, roots.rs 183);
  • crates/socket-patch-node/src: 649 lines;
  • commands/hosted_bundle.rs: 183 lines;
  • 75 ProjectView::Memory arms outside hosted/memory/: 27 in hosted/engine.rs, 27 in lock_inventory/view.rs, and the rest in the crawlers, sbt_reads and vlt.
• Tests. hosted_memory_engine.rs (1,337), hosted_memory_parity.rs (1,228), hosted_memory_rollout.rs (702) and hosted_memory_common (473), plus about 950 inline test lines.
• Distribution. @socketsecurity/socket-patch-node is "private": true and has never been released. CI builds the addon and smoke-tests it on every PR (ci.yml#L115-L122).
• What the memory engine can't do today, each documented in the module header (memory/mod.rs#L8-L18) or the contract:
  • Maven and NuGet files raise ecosystem_unsupported_in_memory (roots.rs#L17-L25).``
  • sbt always answers redirect_sbt_no_resolution_evidence (contract L170).
  • vlt is preflighted offline, without registry metadata (stages.rs#L180-L198).``
  • Vendored→hosted takeovers are refused (refuse_takeovers).``
  • The npm allow-remote planner sees no user or global npm config.
• Orchestration written twice. The disk path is run_redirect_selected in the CLI, and the memory path is engine / stages / discover. The step-by-step table is in the living document, Part 3.3: reference fetch, vlt preflight, wheel metadata, rollout second pass, selection, concurrency and warning order. #1058 already moved "is this pinned" into one shared gate for both, which shows how A would proceed.

Symptoms

None filed against the memory engine itself. The cost is structural: every hosted change in the past month (#1029, #1039, #1058) touched both orchestrators and the parity suites.

Size and scope

This is a decision only. After the decision:

• A is the E32 tracking work, filed as separate issues;
• C is roughly two mechanical PRs: the addon, hosted-bundle and the parity suites first, then the ProjectView::Memory arms.

Depscan and the GitHub App are out of scope for this repository; only their need for the engine matters here.

Acceptance criteria

• An owner picks A, B or C, and says whether the contract line at L670 stands.
• Under A: the audit files the E32 tracking issue, with the first child (DiskSnapshot → MemoryProject for one ecosystem), and states which coverage gaps are bugs and which are tier cuts.
• Under C: the audit files the deletion issues, and the contract line and hosted-bundle paragraph (L41) are removed with the code.

Dependencies

Blocks E32 (one hosted pipeline). It is independent of #1130 (hosted rollback), but under A, any originals sidecar chosen there must also work in memory.