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`](../decisions/2026-08-12-feature-cut-stage-1.md) |
| Model | [`model-v0.yaml`](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`.