coulomb-social/docs/capability/stage-1-cutover.md

Stage 1 cutover — productive transfer set

Field	Value
Decision	../decisions/2026-08-12-feature-cut-stage-1.md
Model	model-v0.yaml
Date	2026-08-12
Stance	Partial rebuild is enough for transfer; extend with later use cases after Bubble is reference-only

Goal of stage 1

Move members to app.coulomb.social as the productive home and retire Bubble on apex as a productive system. After transfer:

• Bubble may remain online only as an implementation reference (read-only / archival / comparison), not as the place where new work happens.
• Additional capabilities (marketplace, social graph, monetization, …) ship later on the rebuild without blocking transfer.

Must capabilities (stage 1)

1. User onboarding — cap.member-onboarding

Members can obtain and use an account on the rebuild without depending on Bubble for day-to-day login.

Feature	Status	Notes
OIDC sign-in (existing LLDAP/KeyCape users)	shipped	Case A proven
JIT Member + user-engine link	shipped
Session / account diagnostics	shipped	/account/session/
Public Create account + verified mail	partial / blocked	App entry ready; NK mailbox (CSOC-IN-0001)
Guided first landing on app home	shipped	post-login → Spaces
Bulk / assisted member transfer from Bubble	todo	Process + optional import; no password migration

Stage-1 acceptance: known operators and community members can sign in; new members can register once NK path is live or operator-provisioned LLDAP accounts cover the transfer cohort. No Bubble password import.

2. Spaces with markdown content — cap.space-content

Members work in spaces whose durable content is markdown (ADR-0002).

Feature	Status	Notes
Space list (tenant-scoped)	shipped
Space detail + render page from Forgejo	shipped
Edit in Forgejo + refresh / webhook	shipped	git SoR
Space CRUD (create/read/update/delete or archive)	partial	Admin/seed today; member UI CRUD todo
Title on space	partial	Model field exists; member edit UI todo
Abstract on space	partial	Use description as abstract until renamed
Visual on space (cover/image)	todo	Not in model yet
Page list within space	partial	path-based pages; richer list todo
Page CRUD (create/update/delete markdown pages)	partial	Via Forgejo only; in-app or first-class API todo
Title on page	partial	From H1 / filename; structured frontmatter todo
Abstract on page	todo	Frontmatter or metadata
Visual on page	todo	Frontmatter image / assets
Fail-closed missing binding	shipped

Stage-1 acceptance: members can create and maintain spaces and pages with Title, Abstract, Visual as first-class fields (not only raw git for metadata), content body in markdown, readable on app host. Exact UX (in-app editor vs structured form + Forgejo body) can vary; utility must not require Bubble.

3. Move page between spaces — cap.page-transfer

Feature	Status	Notes
Transfer page to another space	todo	Move markdown (+ assets) + rewrite links; metadata follows
Authz (source + destination membership)	todo

Stage-1 acceptance: a page can leave space A and appear in space B without Bubble, with clear ownership after the move.

4. Duplicate page — cap.page-copy

Feature	Status	Notes
Generate copy of page (same or other space)	todo	New slug/title; independent thereafter
Copy assets referenced by page	todo	Or document “copy body only” if scoped

Stage-1 acceptance: member can produce an independent copy without manual git surgery as the only path (operator git escape hatch may exist but is not the product path).

Explicitly later (not stage-1 blockers)

Examples — full list in model-v0.yaml:

• Favorites / social graph
• Marketplace (challenges, methods, solutions)
• Monetization / payments
• Full Bubble workflow automation parity
• Pixel-perfect Research chrome parity
• In-app collaborative real-time editing

Platform dependencies (not product features)

Dependency	Stage-1 role
NetKingdom OIDC + (eventually) registration mail	Onboarding
apps-pg	Space/member metadata
Forgejo	Markdown SoR
Railiance deploy	Host app.coulomb.social

Implementation backlog (derived)

Priority order suggested for build work after this decision:

1. Space member CRUD + Title / Abstract edit
2. Visual field (space, then page) + asset storage convention
3. Page metadata (title/abstract/visual) + create/update/delete path
4. Page copy
5. Page transfer
6. Onboarding: transfer cohort process + unstick public registration residual

Bubble export/mapping (CSOC-WP-0001-T02) feeds content migration into these capabilities but does not redefine the must set.

Open product questions

1. Visual — cover image only, or gallery? Max size? assets next to markdown vs object store?
2. Abstract — rename Space.description → abstract in UI only, or schema rename?
3. Page body editing — stage 1: product forms for Title/Abstract/Visual + markdown body path; exact editor TBD.
4. Delete — hard delete vs archive (is_active)?
5. Transfer cohort — require public self-registration, or LLDAP bulk invite for stage 1?
6. Content substrate — see docs/architecture/2026-08-12-content-substrate-exploration.md (markitect-tool + markdown SoR; evaluate shard-wiki thin slice vs folder/git store).
7. Authoring — top-down and bottom-up both first-class; lazy title/abstractor/visual with regenerate + lock — docs/architecture/authoring-modes-and-lazy-projections.md.