An extension point (§5.5) marks a module name a node offers for descendants
to provide/override — resolved dynamically against the inheriting app rather
than lexically sealed. Lay the storage:
- migration 0051: owner-polymorphic `extension_points(id, group_id?, app_id?,
name)` marker table — exactly-one CHECK + per-owner partial-unique LOWER(name)
indexes + lookup indexes (mirrors 0050). ON DELETE CASCADE (a marker is
config, not code). No default-body column — the optional default body is a
co-located kind=module script (Phase 4b stores/resolves/caches those).
- extension_point_repo: `list_for_owner` + idempotent `insert_extension_point_tx`
/ `delete_extension_point_tx`, keyed by the shared `ScriptOwner` (mirrors the
var/secret tx-fn style).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
8b68a7d7e8