Modules Roadmap — deferred work after 2026-05-21 rework

Related documentation: Backend modules · Data ownership · Permissions blueprint · Permissions catalog

Why this page exists

The 2026-05-21 Base/Addon Modules Rework introduced four base modules (promoter, venue, artist, vendor) and four addons (finance, touring, ai, venue_marketplace), wiped the legacy 44-row permission catalog, and reseeded ~105 properly-namespaced rows. Some modules were created with intent to ship later — their module rows + per-persona base packages already exist in Core, but the consumer apps and/or the matching permission catalog entries are deferred.

This page lists what was deliberately punted to a future workstream so future agents (and humans) don’t accidentally re-discover the gap or, worse, re-implement it the wrong way.

Permission catalogs deferred

The Auth permissions table currently holds ~105 rows after the rework. Three modules are present in Core but seed zero permission rows in Auth:

Module key	Type	Why deferred	Where to look when implementing
`vendor`	base	Vendor consumer app not designed yet; we don’t know the per-screen permission surface.	When the vendor product team locks the screen list, add rows to `Backend-Kisum-Auth/cmd/migrate-permissions/seed.go` under a `// ----- module: vendor -----` block (mirror the `promoter` / `venue` / `artist` blocks). Re-run the CLI.
`touring`	addon	Touring backend hasn’t been built (`Backend-Kisum-Touring` does not exist).	Same as above — add a `// ----- module: touring -----` block once the routing / scheduling screens are defined.
`venue_marketplace`	addon	The promoter→venue booking flow has scaffolded UI but no dedicated permission slice yet. Promoter-side keys today live under `promoter.venue.*`.	When the cross-persona booking flow is finalized, decide whether keys live on `promoter.venue.` (existing) or on a new `venue_marketplace.` namespace; if the latter, add a block to the seed file.
`ticketing`	~~addon~~ → standalone platform	Resolved (2026-06-15): NOT a Kisum module. `Backend-Nextkt` became an independent ticketing platform with its own auth + tenancy (orgs, operator users + roles, buyers, per-org API keys). It is deliberately not a Core taxonomy row and seeds zero rows in Auth.	Nothing to seed. Kisum integrates as a white-label partner (provision org + per-org API key) and as a read-only venue/artist data source. Canonical doc: Ticketing Addon Backend.

Each block in seed.go must conform to the normalizePermissionKey rule (3+ dot-separated parts, lowercase, first part equals module_key). See Backend-Kisum-Auth/internal/service/permission_catalog.go L22-42.

Consumer frontends deferred

Audience	Consumer frontend	Status
`promoter`	`Frontend-Kisum`	Live — rewired to `promoter.*` keys 2026-05-21.
`venue`	`Frontend-Kisum-Venues`	Live (scaffolding) — `VENUE_PERMISSIONS` const realigned to `venue.*` keys 2026-05-21.
`artist`	`Frontend-Kisum-Artists` (not yet started)	Deferred. Permission catalog (`artist.*`) is seeded and ready. When the app is built, point its `requirePermission(...)` calls at those keys.
`vendor`	`Frontend-Kisum-Vendors` (not yet started)	Deferred. Catalog rows must be added (see above) before the app can use them.

For Checkout’s per-audience hand-off see the new PRODUCT_LOGIN_URL_PROMOTER / _VENUE / _ARTIST / _VENDOR env vars in System-Kisum-Checkout/.env.example. Until the artist/vendor frontends exist, those URLs default to PRODUCT_LOGIN_URL so signups still land somewhere intentional.

Per-persona base package pricing

Set by product decision on 2026-05-21:

Package key	Price	Trial
`basic_promoter`	$199 / month	7 days
`basic_venue`	$299 / month	7 days
`basic_artist`	$99 / month	7 days
`basic_vendor`	$19 / month	7 days

Platform admins can edit these in Frontend Admin — see 7.2 Trial + Audience controls.

Known risk: Core migration runner is home-grown

Backend-Kisum-Core/internal/repository/postgres/migrate.go is not golang-migrate. It re-executes every .sql file in migrations/ on every Core boot, with no schema_migrations tracking table.

This works today because all Core migrations are hand-written to be idempotent (CREATE TABLE IF NOT EXISTS, ADD COLUMN IF NOT EXISTS, ON CONFLICT DO NOTHING, ALTER TABLE … DROP CONSTRAINT IF EXISTS). But a future migration that forgets idempotency will crash Core’s boot loop in production.

Specific trap: renaming a seeded key

The 2026-05-21 rework hit this in production-like dev: when a migration renames a key that an earlier 00004_seed.sql re-inserts on every boot (e.g. modules.key='basic' → 'promoter'), the second boot fails because:

00004_seed.sql runs first and re-inserts the legacy key with a fresh UUID (its ON CONFLICT (key) DO NOTHING is a no-op only when the key still exists — after a rename it doesn’t, so the row gets inserted fresh).
The renamer migration then tries to UPDATE … SET key='<new>' WHERE key='<old>', which collides with the row from the first boot that already holds the new key.

Mitigation pattern (used in 00013 + 00014): add an idempotency guard at the top of the renamer that DELETEs any re-inserted legacy row when the renamed target already exists. The fresh-UUID re-inserted row has no foreign references, so dropping it is safe.

Recommended fix (separate workstream): swap Core’s runner to golang-migrate (the same library Auth uses in Backend-Kisum-Auth/internal/dbmigrate/dbmigrate.go). Backfill a schema_migrations table with all existing file names marked applied, then ship the swap as a single PR. After that, no migration ever runs twice and the trap above can’t happen.

Deploy checklist for the rework itself

For posterity (the 2026-05-21 rework deploy):

Deploy Backend-Kisum-Core — migrations 00013_module_rework.sql + 00014_base_packages_per_persona.sql auto-run on boot.
Deploy Backend-Kisum-Auth — migration 000014_permissions_wipe.up.sql auto-runs on boot, wiping every catalog + grant row.
Manual step: run docker exec auth-pod /app/migrate-permissions (or local go run ./cmd/migrate-permissions) to insert the ~105 new catalog rows and reseed membership_permissions for every active TENANT_SUPERADMIN. Flags: --dry-run, --single-membership <uuid>, --include-inactive, --skip-catalog, --skip-reseed.
Deploy Backend-Kisum + Frontend-Kisum with the renamed promoter.* permission keys.
Deploy System-Kisum-Checkout + Frontend-Kisum-Admin + Frontend-Kisum-Website (cosmetic 4-tab / 4-audience expansion).