Auto-discover new modules in a configured plugin repo and start syncing them — a per-repo setting, no per-Space interaction #833

The problem this solves

On our instances modules arrive through per-Space {Space}/_GitSync entries, not the plugin catalog: memex.meshweaver.cloud carries 37 sync configs and zero install records. The consequence is that a module with no entry is simply not on the mesh — and nothing says so. Two live examples today: Planning (merged this morning) and Ifrs17 are both absent from memex purely because nobody created their entries, while their nine sibling modules from the same repo are present.

Worse, the entry cannot be made by hand: a _GitSync needs its Space to exist, and creating a Space makes the creator Admin on a system-owned partition — forbidden by the access rules, and re-minted by every human-run sync. So today "add a module to an instance" has no safe self-service path at all.

Requested feature (maintainer, 2026-08-06)

Detect new plugins on git automatically and start syncing without any interaction — as a setting on the plugin repo, in settings.

Make the repo the unit of configuration instead of the Space:

Plugin repo setting (per configured source)
  ├─ repo + branch                     (exists today as a catalog source)
  ├─ ☑ auto-discover new modules       ← new
  └─ ☑ auto-sync discovered modules    ← new

When enabled, on each build event (or poll) for that repo:

1. Discover its top-level modules — the same node-repo layout the catalog already understands (a module folder with a root node; manifest.lock gives its content identity).
2. For any module with no Space yet, provision it as SYSTEM through the existing install/provision path — never as the acting user, so no personal grant is minted.
3. Write its {Space}/_GitSync (repo + subdirectory + branch) and run the first update.
4. Recompile the affected types, in dependency order, exactly as the existing update path does.
5. Record what was created, so an instance can answer "what appeared, and when?".

Removed modules should not be auto-deleted — surface them as orphaned rather than destroying content.

Interactions to respect

• Permissions: gate discovery/creation by the free-vs-commercial rule in Commercial packages must require Global Admin to access/sync; free packages sync without special permission #830 — an unpriced module may be auto-provisioned; a priced one must not appear without an entitled admin.
• Update policy: newly created records inherit the instance default (auto), with the per-record Auto/OnDemand/Ignore override.
• Idempotence: re-running must be a no-op; the module's content hash is the identity.
• Config durability: the catalog source list itself is not in this repo today (it comes from the deployment's Helm values — see feat(deploy): make the plugin catalog configurable from the chart, and skill the deployment ramp-up #829, which makes it chart-configurable). The new flags belong in the same place.

Tests

A repo source with auto-discovery on and one module that has no Space: run the build event ⇒ Space provisioned by SYSTEM (no creator grant — assert _Access holds only system-security), _GitSync written, content imported, affected types compile Ok; re-run ⇒ no-op. With a priced module ⇒ not auto-provisioned. With the setting off ⇒ nothing happens.

Context

Documented in Doc/Architecture/ReleaseToProductionPipeline (#832): "a module with no sync entry is simply not on the mesh".

🤖 Generated with Claude Code