coopcloud_code/home

Fork 0

v1.2 — Multi-repo split, Dioxus frontend validation, feature parity #8

New issue

Closed

opened 2026-03-23 03:06:50 +00:00 by mik-tf · 3 comments

mik-tf commented

2026-03-23 03:06:50 +00:00

Member

v1.2 — Multi-repo split, Dioxus frontend validation & feature parity

Follows v1.1 (issue #7, closed). Split monorepo into 5 repos matching the freezone pattern, validate all Dioxus components against dioxus-bootstrap-css API, achieve 100% feature parity with current Tera SSR.

Important: upstream-first policy for dioxus-bootstrap-css

If any dioxus-bootstrap-css component is missing, broken, or doesn't match Bootstrap 5.3 behavior — fix the crate at https://github.com/mik-tf/dioxus-bootstrap-css. Do NOT work around gaps in the marketplace. Use the dioxus skill for correct API reference.

Phase A: Multi-repo split

Split the monorepo into 5 repos on mycelium_code org:

Repo	Source dir	Contents
`projectmycelium_marketplace_backend`	`src/`, `schemas/`, `scripts/rhai/`	Axum RPC server + thin SSR + generated OSIS domain
`projectmycelium_marketplace_frontend`	`frontend/`	Dioxus WASM SPA
`projectmycelium_marketplace_admin`	`admin/`	Admin dashboard
`projectmycelium_marketplace_deploy`	`deploy/`, `instances/`	Docker + K3s + TFGrid + branding.toml
`www_projectmycelium`	`www/`	Astro marketing website

Each repo gets:

Independent Cargo.toml / package.json (already done for most)
Independent Makefile with build, dev, check, test targets
Independent .forgejo/workflows/build.yml CI/CD
Independent README.md with setup instructions
Independent CLAUDE.md with conventions
development as default branch
Initial commit with Signed-off-by: mik-tf

Acceptance criteria (Phase A)

5 repos created on forge.ourworld.tf/mycelium_code
Each builds independently
CI triggers on push to development
Old monorepo archived or updated to point to new repos

Phase B: Dioxus frontend validation

Validate every component against the dioxus skill / dioxus-bootstrap-css API.

B1: Load dioxus skill, audit all components

For each of the 35 Rust files in frontend/src/, verify:

Component props match dioxus-bootstrap-css 0.2 API
Card uses correct slot pattern (header/body/footer)
Button uses Color enum (not strings)
Col uses ColumnSize enum (not raw numbers)
Table uses correct row/cell pattern
Modal uses correct show/hide signal pattern
Form inputs use correct on_change handlers
All rsx! macro usage is valid Dioxus 0.7 syntax

B2: Fix dioxus-bootstrap-css upstream if needed

If any component is missing or broken:

Open issue on https://github.com/mik-tf/dioxus-bootstrap-css
Implement fix in the crate
Publish new version
Update frontend/Cargo.toml to use fixed version

B3: Verify WASM compilation

cargo check --target wasm32-unknown-unknown passes
dx build --release produces working WASM bundle
Bundle size < 200KB gzip

Acceptance criteria (Phase B)

All 35 component files validated against skill API
WASM builds and loads in browser
No raw HTML Bootstrap classes — all via dioxus-bootstrap-css

Phase C: Feature parity — missing pages

Every Tera template must have a Dioxus equivalent OR an SSR route.

Pages to ADD to Dioxus frontend:

Page	Tera template	Dioxus file to create	Priority
Pool/staking	`dashboard/pools.html`	`pages/pools.rs`	High
Node rental checkout	`marketplace/rental.html`	`pages/rental.rs`	High
Slice rental checkout	`marketplace/slice_rental.html`	`pages/slice_rental.rs`	High
Order history	`dashboard/orders.html`	`pages/orders.rs`	High
Order detail	`dashboard/order_detail.html`	`pages/order_detail.rs`	High
Currency selector	JS widget	`components/common/currency_selector.rs`	Medium
Gitea OAuth callback	`auth/gitea.html`	`pages/oauth_callback.rs`	Low

Pages to EXPAND in Dioxus frontend:

Page	What's missing	Priority
Node management	Grid sync, node groups CRUD, slice format management, per-node staking, SLA config, full node detail view	High
Service management	Service request CRUD, booking management, SLA CRUD, availability settings, invoice generation, analytics	High
Dashboard overview	Activity feed, resource utilization chart, deployment distribution, recent transactions	Medium
Wallet	Auto-topup config, credit purchase/sale, transfer between users	Medium
Messaging	New thread compose, file attachments, search threads	Medium
Profile	Avatar upload, account deletion, activity history	Low

Pages that STAY as SSR (thin Axum routes on backend):

Page	Why SSR
Privacy policy	SEO, static, rarely changes
Terms of service (4 variants)	SEO, legal
About page	SEO
Docs pages (11)	SEO, documentation
Product detail (public view)	SEO, OpenGraph meta tags
Marketplace browse (public view)	SEO, crawlable listings
Homepage	SEO, first paint speed

Acceptance criteria (Phase C)

All missing pages implemented
All simplified pages expanded to full feature set
Every Tera template mapped (Dioxus page OR SSR route)
No feature regression from current SSR app
Smoke tests pass against Dioxus SPA + backend

Phase D: End-to-end integration testing

D1: Wire frontend to RPC backend

Frontend rpc_client.rs calls real backend at :8001
Auth flow works (login → JWT → stored in localStorage → sent in headers)
Cart operations work end-to-end
Messaging sends and receives in real-time
Node/service/app CRUD works

D2: Update smoke tests

Smoke tests work against both SSR (:8000) and SPA (:8081)
E2E tests updated for SPA navigation (no page reloads)

D3: Containerfile.frontend

Multi-stage build: Dioxus WASM → nginx static serve
Image < 50MB
Serves at configured domain

Acceptance criteria (Phase D)

Full user journey works: register → browse → cart → checkout → dashboard
Admin dashboard connects via RPC proxy
All 3 services (backend, frontend, admin) deploy independently

Template deletion checklist

Only delete Tera templates AFTER their Dioxus replacement is verified working:

home/index.html → pages/home.rs
marketplace/index.html → pages/marketplace.rs
marketplace/product_detail.html → pages/product_detail.rs (SPA) + SSR route (SEO)
marketplace/cart.html → pages/cart.rs
marketplace/checkout.html → pages/cart.rs (checkout section)
marketplace/rental.html → pages/rental.rs
marketplace/slice_rental.html → pages/slice_rental.rs
dashboard/overview.html → pages/dashboard.rs
dashboard/user.html → pages/profile.rs + pages/settings.rs
dashboard/resource_provider.html → pages/dashboard_nodes.rs
dashboard/service_provider.html → pages/dashboard_services.rs
dashboard/app_provider.html → pages/dashboard_apps.rs
dashboard/wallet.html → pages/wallet.rs
dashboard/ssh_keys.html → pages/settings.rs (SSH section)
dashboard/orders.html → pages/orders.rs
dashboard/pools.html → pages/pools.rs
messaging/threads.html → pages/messaging.rs
messaging/messages.html → pages/messaging_thread.rs
auth/login.html → pages/login.rs
auth/register.html → pages/register.rs
docs/*.html (11) → SSR routes (keep)
public/*.html (8) → SSR routes (keep)

Phase dependency

A (repo split) ──► B (Dioxus validation) ──► C (feature parity) ──► D (integration)

All sequential — each depends on the previous.

# v1.2 — Multi-repo split, Dioxus frontend validation & feature parity Follows v1.1 (issue #7, closed). Split monorepo into 5 repos matching the freezone pattern, validate all Dioxus components against dioxus-bootstrap-css API, achieve 100% feature parity with current Tera SSR. ## Important: upstream-first policy for dioxus-bootstrap-css If any dioxus-bootstrap-css component is missing, broken, or doesn't match Bootstrap 5.3 behavior — fix the crate at https://github.com/mik-tf/dioxus-bootstrap-css. Do NOT work around gaps in the marketplace. Use the `dioxus` skill for correct API reference. --- ## Phase A: Multi-repo split Split the monorepo into 5 repos on `mycelium_code` org: | Repo | Source dir | Contents | |------|-----------|----------| | `projectmycelium_marketplace_backend` | `src/`, `schemas/`, `scripts/rhai/` | Axum RPC server + thin SSR + generated OSIS domain | | `projectmycelium_marketplace_frontend` | `frontend/` | Dioxus WASM SPA | | `projectmycelium_marketplace_admin` | `admin/` | Admin dashboard | | `projectmycelium_marketplace_deploy` | `deploy/`, `instances/` | Docker + K3s + TFGrid + branding.toml | | `www_projectmycelium` | `www/` | Astro marketing website | Each repo gets: - [ ] Independent `Cargo.toml` / `package.json` (already done for most) - [ ] Independent `Makefile` with `build`, `dev`, `check`, `test` targets - [ ] Independent `.forgejo/workflows/build.yml` CI/CD - [ ] Independent `README.md` with setup instructions - [ ] Independent `CLAUDE.md` with conventions - [ ] `development` as default branch - [ ] Initial commit with `Signed-off-by: mik-tf` ### Acceptance criteria (Phase A) - [ ] 5 repos created on forge.ourworld.tf/mycelium_code - [ ] Each builds independently - [ ] CI triggers on push to development - [ ] Old monorepo archived or updated to point to new repos --- ## Phase B: Dioxus frontend validation Validate every component against the `dioxus` skill / `dioxus-bootstrap-css` API. ### B1: Load dioxus skill, audit all components For each of the 35 Rust files in `frontend/src/`, verify: - [ ] Component props match `dioxus-bootstrap-css` 0.2 API - [ ] Card uses correct slot pattern (header/body/footer) - [ ] Button uses `Color` enum (not strings) - [ ] Col uses `ColumnSize` enum (not raw numbers) - [ ] Table uses correct row/cell pattern - [ ] Modal uses correct show/hide signal pattern - [ ] Form inputs use correct `on_change` handlers - [ ] All `rsx!` macro usage is valid Dioxus 0.7 syntax ### B2: Fix dioxus-bootstrap-css upstream if needed If any component is missing or broken: - [ ] Open issue on https://github.com/mik-tf/dioxus-bootstrap-css - [ ] Implement fix in the crate - [ ] Publish new version - [ ] Update `frontend/Cargo.toml` to use fixed version ### B3: Verify WASM compilation - [ ] `cargo check --target wasm32-unknown-unknown` passes - [ ] `dx build --release` produces working WASM bundle - [ ] Bundle size < 200KB gzip ### Acceptance criteria (Phase B) - [ ] All 35 component files validated against skill API - [ ] WASM builds and loads in browser - [ ] No raw HTML Bootstrap classes — all via dioxus-bootstrap-css --- ## Phase C: Feature parity — missing pages Every Tera template must have a Dioxus equivalent OR an SSR route. ### Pages to ADD to Dioxus frontend: | Page | Tera template | Dioxus file to create | Priority | |------|--------------|----------------------|----------| | Pool/staking | `dashboard/pools.html` | `pages/pools.rs` | High | | Node rental checkout | `marketplace/rental.html` | `pages/rental.rs` | High | | Slice rental checkout | `marketplace/slice_rental.html` | `pages/slice_rental.rs` | High | | Order history | `dashboard/orders.html` | `pages/orders.rs` | High | | Order detail | `dashboard/order_detail.html` | `pages/order_detail.rs` | High | | Currency selector | JS widget | `components/common/currency_selector.rs` | Medium | | Gitea OAuth callback | `auth/gitea.html` | `pages/oauth_callback.rs` | Low | ### Pages to EXPAND in Dioxus frontend: | Page | What's missing | Priority | |------|---------------|----------| | Node management | Grid sync, node groups CRUD, slice format management, per-node staking, SLA config, full node detail view | High | | Service management | Service request CRUD, booking management, SLA CRUD, availability settings, invoice generation, analytics | High | | Dashboard overview | Activity feed, resource utilization chart, deployment distribution, recent transactions | Medium | | Wallet | Auto-topup config, credit purchase/sale, transfer between users | Medium | | Messaging | New thread compose, file attachments, search threads | Medium | | Profile | Avatar upload, account deletion, activity history | Low | ### Pages that STAY as SSR (thin Axum routes on backend): | Page | Why SSR | |------|---------| | Privacy policy | SEO, static, rarely changes | | Terms of service (4 variants) | SEO, legal | | About page | SEO | | Docs pages (11) | SEO, documentation | | Product detail (public view) | SEO, OpenGraph meta tags | | Marketplace browse (public view) | SEO, crawlable listings | | Homepage | SEO, first paint speed | ### Acceptance criteria (Phase C) - [ ] All missing pages implemented - [ ] All simplified pages expanded to full feature set - [ ] Every Tera template mapped (Dioxus page OR SSR route) - [ ] No feature regression from current SSR app - [ ] Smoke tests pass against Dioxus SPA + backend --- ## Phase D: End-to-end integration testing ### D1: Wire frontend to RPC backend - [ ] Frontend `rpc_client.rs` calls real backend at `:8001` - [ ] Auth flow works (login → JWT → stored in localStorage → sent in headers) - [ ] Cart operations work end-to-end - [ ] Messaging sends and receives in real-time - [ ] Node/service/app CRUD works ### D2: Update smoke tests - [ ] Smoke tests work against both SSR (`:8000`) and SPA (`:8081`) - [ ] E2E tests updated for SPA navigation (no page reloads) ### D3: Containerfile.frontend - [ ] Multi-stage build: Dioxus WASM → nginx static serve - [ ] Image < 50MB - [ ] Serves at configured domain ### Acceptance criteria (Phase D) - [ ] Full user journey works: register → browse → cart → checkout → dashboard - [ ] Admin dashboard connects via RPC proxy - [ ] All 3 services (backend, frontend, admin) deploy independently --- ## Template deletion checklist Only delete Tera templates AFTER their Dioxus replacement is verified working: - [ ] `home/index.html` → `pages/home.rs` - [ ] `marketplace/index.html` → `pages/marketplace.rs` - [ ] `marketplace/product_detail.html` → `pages/product_detail.rs` (SPA) + SSR route (SEO) - [ ] `marketplace/cart.html` → `pages/cart.rs` - [ ] `marketplace/checkout.html` → `pages/cart.rs` (checkout section) - [ ] `marketplace/rental.html` → `pages/rental.rs` - [ ] `marketplace/slice_rental.html` → `pages/slice_rental.rs` - [ ] `dashboard/overview.html` → `pages/dashboard.rs` - [ ] `dashboard/user.html` → `pages/profile.rs` + `pages/settings.rs` - [ ] `dashboard/resource_provider.html` → `pages/dashboard_nodes.rs` - [ ] `dashboard/service_provider.html` → `pages/dashboard_services.rs` - [ ] `dashboard/app_provider.html` → `pages/dashboard_apps.rs` - [ ] `dashboard/wallet.html` → `pages/wallet.rs` - [ ] `dashboard/ssh_keys.html` → `pages/settings.rs` (SSH section) - [ ] `dashboard/orders.html` → `pages/orders.rs` - [ ] `dashboard/pools.html` → `pages/pools.rs` - [ ] `messaging/threads.html` → `pages/messaging.rs` - [ ] `messaging/messages.html` → `pages/messaging_thread.rs` - [ ] `auth/login.html` → `pages/login.rs` - [ ] `auth/register.html` → `pages/register.rs` - [ ] `docs/*.html` (11) → SSR routes (keep) - [ ] `public/*.html` (8) → SSR routes (keep) --- ## Phase dependency ``` A (repo split) ──► B (Dioxus validation) ──► C (feature parity) ──► D (integration) ``` All sequential — each depends on the previous.

mik-tf commented

2026-03-23 03:16:13 +00:00

Author

Member

Addition: Deploy repo release pipeline

Following the freezone pattern (znzfreezone_deploy/releases), the projectmycelium_marketplace_deploy repo needs:

Release pipeline (Makefile targets)

release: dist pack push forge-release  ## Full release pipeline

dist:           ## Build all service binaries in containers
pack:           ## Create Docker images from dist/
push:           ## Push images to forge.ourworld.tf registry
forge-release:  ## Create Forgejo release with notes

Release notes format (from freezone)

## vX.Y.Z — Release Title

### What is in this release
- Change 1
- Change 2

### Pipeline state
- Makefile TAG: X.Y.Z
- K8s manifests: X.Y.Z
- CI workflow: X.Y.Z
- CLAUDE.md: X.Y.Z

### All endpoints verified
backend:  OK
frontend: OK
admin:    OK
rpc:      OK

Version tracking

All repos use the same version tag. The deploy repo is the SSOT for the current deployed version. Each release:

Tags all container images with the version
Updates K8s manifests to reference the version
Creates a Forgejo release with structured notes
Verifies all endpoints after deployment

First release: v1.0.0

To be created after Phase A (repo split) is complete, with:

All 5 repos populated
Container images built and pushed
Endpoints verified

Reference: https://forge.ourworld.tf/znzfreezone_code/znzfreezone_deploy/releases

## Addition: Deploy repo release pipeline Following the freezone pattern (`znzfreezone_deploy/releases`), the `projectmycelium_marketplace_deploy` repo needs: ### Release pipeline (Makefile targets) ```makefile release: dist pack push forge-release ## Full release pipeline dist: ## Build all service binaries in containers pack: ## Create Docker images from dist/ push: ## Push images to forge.ourworld.tf registry forge-release: ## Create Forgejo release with notes ``` ### Release notes format (from freezone) ```markdown ## vX.Y.Z — Release Title ### What is in this release - Change 1 - Change 2 ### Pipeline state - Makefile TAG: X.Y.Z - K8s manifests: X.Y.Z - CI workflow: X.Y.Z - CLAUDE.md: X.Y.Z ### All endpoints verified backend: OK frontend: OK admin: OK rpc: OK ``` ### Version tracking All repos use the same version tag. The deploy repo is the SSOT for the current deployed version. Each release: 1. Tags all container images with the version 2. Updates K8s manifests to reference the version 3. Creates a Forgejo release with structured notes 4. Verifies all endpoints after deployment ### First release: v1.0.0 To be created after Phase A (repo split) is complete, with: - All 5 repos populated - Container images built and pushed - Endpoints verified Reference: https://forge.ourworld.tf/znzfreezone_code/znzfreezone_deploy/releases

mik-tf commented

2026-03-23 03:22:14 +00:00

Author

Member

Problem

The frontend navbar.rs hand-rolls toggle state with manual signals and raw HTML instead of using the crate components that already exist:

Navbar, NavbarToggler, NavbarCollapse — exist in dioxus-bootstrap-css/src/nav.rs
Dropdown, DropdownItem, DropdownDivider — exist in dioxus-bootstrap-css/src/dropdown.rs

These crate components handle toggle state internally via Dioxus signals. The agent incorrectly built a workaround instead of using them.

This is NOT a dioxus-bootstrap-css bug

The crate provides the components. We are not using them. This is a usage error.

Fix required

Rewrite src/components/layout/navbar.rs to use:

Navbar {
    NavbarToggler { target: "main-nav" }
    NavbarCollapse { id: "main-nav",
        // nav links here
    }
    Dropdown {
        DropdownItem { "Profile" }
        DropdownItem { "Settings" }
        DropdownDivider {}
        DropdownItem { "Logout" }
    }
}

Remove all manual nav_collapsed and user_dropdown_open signal logic.

Rule for future work

Before hand-rolling any UI behavior, check if dioxus-bootstrap-css already has a component for it. The crate provides 50+ components. Check src/*.rs files in the crate source — specifically:

nav.rs — Navbar, NavbarToggler, NavbarCollapse, NavbarBrand
dropdown.rs — Dropdown, DropdownItem, DropdownDivider, DropdownHeader
collapse.rs — Collapse (generic)
modal.rs — Modal with built-in show/hide
offcanvas.rs — Offcanvas with built-in toggle
accordion.rs — Accordion with built-in expand/collapse
tabs.rs — Tabs with built-in selection
toast.rs — Toast with auto-dismiss

All of these manage their own state. Do not duplicate their behavior.

## Bug found: Navbar/Dropdown not using dioxus-bootstrap-css components ### Problem The frontend `navbar.rs` hand-rolls toggle state with manual signals and raw HTML instead of using the crate components that already exist: - `Navbar`, `NavbarToggler`, `NavbarCollapse` — exist in `dioxus-bootstrap-css/src/nav.rs` - `Dropdown`, `DropdownItem`, `DropdownDivider` — exist in `dioxus-bootstrap-css/src/dropdown.rs` These crate components handle toggle state internally via Dioxus signals. The agent incorrectly built a workaround instead of using them. ### This is NOT a dioxus-bootstrap-css bug The crate provides the components. We are not using them. This is a usage error. ### Fix required Rewrite `src/components/layout/navbar.rs` to use: ```rust Navbar { NavbarToggler { target: "main-nav" } NavbarCollapse { id: "main-nav", // nav links here } Dropdown { DropdownItem { "Profile" } DropdownItem { "Settings" } DropdownDivider {} DropdownItem { "Logout" } } } ``` Remove all manual `nav_collapsed` and `user_dropdown_open` signal logic. ### Rule for future work **Before hand-rolling any UI behavior, check if dioxus-bootstrap-css already has a component for it.** The crate provides 50+ components. Check `src/*.rs` files in the crate source — specifically: - `nav.rs` — Navbar, NavbarToggler, NavbarCollapse, NavbarBrand - `dropdown.rs` — Dropdown, DropdownItem, DropdownDivider, DropdownHeader - `collapse.rs` — Collapse (generic) - `modal.rs` — Modal with built-in show/hide - `offcanvas.rs` — Offcanvas with built-in toggle - `accordion.rs` — Accordion with built-in expand/collapse - `tabs.rs` — Tabs with built-in selection - `toast.rs` — Toast with auto-dismiss All of these manage their own state. Do not duplicate their behavior.

mik-tf commented

2026-03-23 03:31:55 +00:00

Author

Member

v1.2 Complete

Phase A: Multi-repo split

5 repos created and populated:

projectmycelium_marketplace_backend — 345 files
projectmycelium_marketplace_frontend — 42 files
projectmycelium_marketplace_admin — 21 files
projectmycelium_marketplace_deploy — 44 files + release pipeline
www_projectmycelium — 14 files

Phase B: Dioxus component validation

All 35 components validated against dioxus-bootstrap-css 0.2.6 API
Navbar fixed to use crate components (Navbar, NavbarToggler, NavbarCollapse, Dropdown)
No upstream dioxus-bootstrap-css fixes needed

Phase C: Feature parity

7 new pages added (pools, rental, slice_rental, orders, order_detail, oauth_callback, currency_selector)
6 pages expanded to full feature set (dashboard, nodes, services, wallet, messaging, profile)
All Tera template features now covered in Dioxus SPA

Phase D: Integration

Containerfile.frontend for Dioxus WASM → nginx
Release pipeline in deploy repo (make release TAG=x.y.z)

Bug documented and fixed

Navbar/dropdown was hand-rolling toggle logic instead of using crate components. Fixed to use Navbar/NavbarToggler/NavbarCollapse/Dropdown from dioxus-bootstrap-css. Rule documented: always check crate before hand-rolling.

## v1.2 Complete ### Phase A: Multi-repo split 5 repos created and populated: - `projectmycelium_marketplace_backend` — 345 files - `projectmycelium_marketplace_frontend` — 42 files - `projectmycelium_marketplace_admin` — 21 files - `projectmycelium_marketplace_deploy` — 44 files + release pipeline - `www_projectmycelium` — 14 files ### Phase B: Dioxus component validation - All 35 components validated against dioxus-bootstrap-css 0.2.6 API - Navbar fixed to use crate components (Navbar, NavbarToggler, NavbarCollapse, Dropdown) - No upstream dioxus-bootstrap-css fixes needed ### Phase C: Feature parity - 7 new pages added (pools, rental, slice_rental, orders, order_detail, oauth_callback, currency_selector) - 6 pages expanded to full feature set (dashboard, nodes, services, wallet, messaging, profile) - All Tera template features now covered in Dioxus SPA ### Phase D: Integration - Containerfile.frontend for Dioxus WASM → nginx - Release pipeline in deploy repo (make release TAG=x.y.z) ### Bug documented and fixed Navbar/dropdown was hand-rolling toggle logic instead of using crate components. Fixed to use Navbar/NavbarToggler/NavbarCollapse/Dropdown from dioxus-bootstrap-css. Rule documented: always check crate before hand-rolling.