coopcloud_code/home

Fork 0

v1.1 — Production Hardening, White-Label & Dioxus Frontend #7

New issue

Closed

opened 2026-03-23 02:02:35 +00:00 by mik-tf · 2 comments

mik-tf commented

2026-03-23 02:02:35 +00:00

Member

Marketplace v1.1 — Production Hardening, White-Label & Dioxus Frontend

Follows v1.0 (issue #1, complete). This issue covers multi-repo split, branding config, provider abstraction, Dioxus WASM frontend, deploy pipeline, production infrastructure, and marketing site.

Reference implementation: znzfreezone_code/ (5 repos: backend, frontend, admin, deploy, home).

Phase A: Multi-Repo Split & Branding Config

A1: Split admin into separate repo

Move admin/ to mycelium_code/projectmycelium_marketplace_admin.

Independent Cargo.toml, Makefile, CI/CD
Containerfile for Docker image
README with setup instructions
Reference: znzfreezone_code/znzfreezone_admin

A2: Split deploy into separate repo

Move deploy/ to mycelium_code/projectmycelium_marketplace_deploy.

Docker Compose (local dev, demo, prod)
Containerfiles for all services (backend, frontend, admin)
TFGrid single-VM deployment (tfgrid/Makefile)
K3s 3-node cluster deployment (k3s/Makefile)
instances/ directory for per-deployment configs
branding.toml template system
make release TAG=x.y.z pipeline (dist → pack → push)
Reference: znzfreezone_code/znzfreezone_deploy

A3: Create branding.toml config system

Single source of truth for white-label customization:

[branding]
name = "Project Mycelium Marketplace"
short_name = "Mycelium"
domain = "projectmycelium.org"
jurisdiction = "Global"
legal_entity = "ThreeFold DMCC"
support_email = "support@projectmycelium.org"

[branding.colors]
primary = "#2563eb"
secondary = "#1e40af"
accent = "#3b82f6"

[pricing]
base_currency = "TFP"
tfp_to_usd = 0.1

[features]
kyc_enabled = false
oauth_enabled = false
near_enabled = true

Backend reads BRANDING_CONFIG env var
Injects branding into all templates/components
instances/_template/branding.toml for new deployments
instances/mycelium/branding.toml for production

Acceptance criteria (Phase A)

Admin repo builds independently (cargo check)
Deploy repo has make release TAG=x.y.z pipeline
branding.toml loaded by backend, injected into responses
New marketplace instance deployable by copying branding.toml

Phase B: Provider Abstraction & Deploy Pipeline

B1: Payment provider trait

pub trait PaymentProvider: Send + Sync {
    fn name(&self) -> &str;
    fn is_demo(&self) -> bool;
    async fn create_payment(&self, amount: f64, currency: &str) -> Result<PaymentIntent>;
    async fn verify_payment(&self, payment_id: &str) -> Result<PaymentStatus>;
}

DemoPaymentProvider — always succeeds (dev/testing)
Future: Stripe, ClickPesa, crypto providers
Selection via PAYMENT_PROVIDER env var
Reference: znzfreezone_backend/src/providers/payment.rs

B2: Email provider trait

pub trait EmailProvider: Send + Sync {
    fn name(&self) -> &str;
    fn is_configured(&self) -> bool;
    async fn send(&self, to: &str, subject: &str, html: &str) -> Result<()>;
}

DemoEmailProvider — logs to console
ResendProvider — real email via Resend API
Reference: znzfreezone_backend/src/providers/email.rs

B3: Containerfiles for all services

Containerfile.backend — multi-stage Rust build → Alpine
Containerfile.frontend — Dioxus WASM build → nginx
Containerfile.admin — Rust build → Alpine
Registry: forge.ourworld.tf/mycelium_code/

B4: CI/CD pipeline update

.forgejo/workflows/build.yml
Triggers on push to development
Pipeline: check → test → dist → pack → push → smoke
Branch-aware tagging (:development, :latest, :vX.Y.Z)

Acceptance criteria (Phase B)

PAYMENT_PROVIDER=demo works (no external deps)
EMAIL_PROVIDER=resend sends real emails
All 3 Containerfiles build successfully
CI pipeline runs on push to development

Phase C: Dioxus WASM Frontend

New repo: mycelium_code/projectmycelium_marketplace_frontend

Why Dioxus over Tera SSR

Type safety — schema-generated types compile-check UI components
Component reuse — one ProductCard used everywhere, not duplicated across 65 templates
Reactivity — cart updates, filters, messaging without page reloads
Hero ecosystem alignment — hero_os_ui_wasm already uses Dioxus + dioxus-bootstrap-css
Generated SDK ready — types_wasm_generated.rs (1,651 lines) and osis_client_generated.rs (2,869 lines) exist

Stack

Framework: Dioxus 0.7
UI library: dioxus-bootstrap-css (50+ Bootstrap 5.3 components, zero JS)
Router: dioxus-router (client-side SPA routing)
HTTP client: gloo-net (fetch API for JSON-RPC calls)
Types: Auto-generated from marketplace.oschema via types_wasm_generated.rs

Architecture: Hybrid SSR + SPA

Public pages (SEO) → SSR (thin Axum, 10-15 routes)
  /, /marketplace/*, /products/{id}, /docs/*
  Renders HTML with meta tags, OpenGraph, structured data

Authenticated pages → Dioxus SPA (WASM)
  /app/dashboard, /app/cart, /app/wallet,
  /app/messaging, /app/nodes, /app/services
  Client-side routing, data via JSON-RPC to :8001

SSR for crawlers + social previews. SPA for everything interactive.

Component structure (~250 components)

src/
  main.rs                    # Dioxus app entry
  router.rs                  # SPA routes
  rpc_client.rs              # JSON-RPC client (wraps generated SDK)
  state.rs                   # Global signals (user, cart, theme)
  components/
    layout/                  # Navbar, Sidebar, Footer, ThemeToggle
    common/                  # ProductCard, NodeStatus, Badge, Spinner
    marketplace/             # Browse, Filter, Search, CategoryNav
    product/                 # Detail, Reviews, Pricing, SliceConfig
    cart/                    # CartView, CartItem, Checkout
    dashboard/               # Overview, Stats, ActivityFeed
    wallet/                  # Balance, Transactions, TopUp
    messaging/               # ThreadList, MessageView, Compose
    nodes/                   # NodeList, NodeDetail, GroupManager
    services/                # ServiceList, Booking, SLA
    apps/                    # AppList, Deployment, Health
    auth/                    # Login, Register, Profile
    admin/                   # (if admin also moves to Dioxus)
  pages/                     # Route-level page components

What gets removed from backend

Once Dioxus SPA is complete:

65 Tera templates (25,716 lines) → deleted
15 Axum SSR controllers (7,540 lines) → reduced to ~15 thin SEO routes
ContextBuilder pattern → replaced by Dioxus signals
ResponseBuilder → replaced by JSON-RPC responses
Net: ~30,000 lines removed, ~15,000 lines of typed components added

Acceptance criteria (Phase C)

Dioxus SPA serves all authenticated pages
SSR serves public/SEO pages with proper meta tags
WASM bundle < 200KB gzip
All existing smoke tests pass against SPA + backend
E2E tests updated for SPA navigation
Tera templates removed from backend

Phase D: Production Infrastructure

D1: Encrypted admin auth

AES-256-GCM encrypted user store (admin-users.toml.enc)
CLI commands: serve, add-user, list-users, remove-user
Reference: znzfreezone_admin/src/admin_users.rs

D2: MCP endpoint

Auto-generated from marketplace.oschema
Exposes all 23 types as AI tools
POST /mcp endpoint on RPC server
Reference: znzfreezone_backend/src/mcp.rs

D3: Prometheus metrics

GET /metrics endpoint
Counters: rpc_requests_total, rpc_errors_total
Histograms: rpc_request_duration_seconds
Gauges: active_connections, osis_object_count

D4: Structured logging

RUST_LOG_FORMAT=json for production
Structured fields: method, status, duration, user_email
Compatible with Loki/ELK stack

D5: Backup system

restic + S3-compatible storage (MinIO or external)
Retention: 7 daily / 4 weekly / 3 monthly
Automated via K8s CronJob or cron
Restore procedure documented

D6: Health monitoring

K8s CronJob (5-min interval)
Checks: backend health, RPC responsiveness, OSIS connectivity, frontend serving
Alert on failure (webhook to Slack/email)

Acceptance criteria (Phase D)

Admin auth uses encrypted store
MCP endpoint responds to tool discovery
/metrics returns Prometheus format
JSON logs parseable by log aggregator
Backup runs daily, restore tested
Health monitor alerts on service down

Phase E: HA Deployment & Marketing

E1: K3s production deployment

Full HA deployment scripts in deploy repo:

setup-server.sh — K3s server + Kadalu
setup-agent.sh — K3s agent nodes
setup-storage.sh — GlusterFS Replica3
setup-dns.sh — Cloudflare DNS automation
3 compute nodes + 3 gateway nodes
Reference: znzfreezone_deploy/k3s/

E2: TFGrid single-VM deployment

OpenTofu IaC for TFGrid VM provisioning
Docker Compose for single-VM deployment
make all ENV=dev for full deploy
Reference: znzfreezone_deploy/tfgrid/

E3: Marketing website

New repo: projectmycelium/www_projectmycelium (or under mycelium_code)

Astro + Tailwind CSS
Pages: Home, About, Products, Pricing, Docs, Contact
Reads from branding.toml for customization
Reference: znzfreezone/www_znzfreezone

Acceptance criteria (Phase E)

K3s cluster deploys with make all ENV=prod
Single-VM deploys with make all ENV=dev
Marketing site live at configured domain
All services accessible via HTTPS
Health checks pass on cluster

Final Repo Structure

mycelium_code/
  home/                                  # Issues
  projectmycelium_marketplace/           # Backend (Axum RPC + thin SSR)
  projectmycelium_marketplace_frontend/  # Dioxus WASM SPA
  projectmycelium_marketplace_admin/     # Admin dashboard
  projectmycelium_marketplace_deploy/    # Docker + K3s + TFGrid

projectmycelium/ (or mycelium_code)
  www_projectmycelium/                   # Marketing website (Astro)

Mirrors the freezone:

znzfreezone_code/
  home/
  znzfreezone_backend/
  znzfreezone_frontend/
  znzfreezone_admin/
  znzfreezone_deploy/
znzfreezone/
  www_znzfreezone/

Phase Dependencies

A (split + branding) ──► B (providers + deploy) ──► D (infra)
                    └──► C (Dioxus frontend)    ──► E (HA + marketing)

A is prerequisite for everything. B and C can run in parallel. D and E follow.

Key Design Principles

Schema is SSOT — marketplace.oschema drives types, CRUD, RPC, Rhai, WASM SDK, OpenRPC
Branding is config — branding.toml drives all customization, no code changes
Providers are pluggable — payment, email, KYC swap via env var
Frontend is typed — Dioxus components compile-check against schema types
Deploy is repeatable — make release TAG=x.y.z for any instance
Multi-repo, single convention — same Makefile patterns, same commit format, same branching

# Marketplace v1.1 — Production Hardening, White-Label & Dioxus Frontend Follows v1.0 (issue #1, complete). This issue covers multi-repo split, branding config, provider abstraction, Dioxus WASM frontend, deploy pipeline, production infrastructure, and marketing site. Reference implementation: `znzfreezone_code/` (5 repos: backend, frontend, admin, deploy, home). --- ## Phase A: Multi-Repo Split & Branding Config ### A1: Split admin into separate repo Move `admin/` to `mycelium_code/projectmycelium_marketplace_admin`. - Independent Cargo.toml, Makefile, CI/CD - Containerfile for Docker image - README with setup instructions - Reference: `znzfreezone_code/znzfreezone_admin` ### A2: Split deploy into separate repo Move `deploy/` to `mycelium_code/projectmycelium_marketplace_deploy`. - Docker Compose (local dev, demo, prod) - Containerfiles for all services (backend, frontend, admin) - TFGrid single-VM deployment (`tfgrid/Makefile`) - K3s 3-node cluster deployment (`k3s/Makefile`) - `instances/` directory for per-deployment configs - `branding.toml` template system - `make release TAG=x.y.z` pipeline (dist → pack → push) - Reference: `znzfreezone_code/znzfreezone_deploy` ### A3: Create branding.toml config system Single source of truth for white-label customization: ```toml [branding] name = "Project Mycelium Marketplace" short_name = "Mycelium" domain = "projectmycelium.org" jurisdiction = "Global" legal_entity = "ThreeFold DMCC" support_email = "support@projectmycelium.org" [branding.colors] primary = "#2563eb" secondary = "#1e40af" accent = "#3b82f6" [pricing] base_currency = "TFP" tfp_to_usd = 0.1 [features] kyc_enabled = false oauth_enabled = false near_enabled = true ``` - Backend reads `BRANDING_CONFIG` env var - Injects branding into all templates/components - `instances/_template/branding.toml` for new deployments - `instances/mycelium/branding.toml` for production ### Acceptance criteria (Phase A) - [ ] Admin repo builds independently (`cargo check`) - [ ] Deploy repo has `make release TAG=x.y.z` pipeline - [ ] `branding.toml` loaded by backend, injected into responses - [ ] New marketplace instance deployable by copying `branding.toml` --- ## Phase B: Provider Abstraction & Deploy Pipeline ### B1: Payment provider trait ```rust pub trait PaymentProvider: Send + Sync { fn name(&self) -> &str; fn is_demo(&self) -> bool; async fn create_payment(&self, amount: f64, currency: &str) -> Result<PaymentIntent>; async fn verify_payment(&self, payment_id: &str) -> Result<PaymentStatus>; } ``` - `DemoPaymentProvider` — always succeeds (dev/testing) - Future: Stripe, ClickPesa, crypto providers - Selection via `PAYMENT_PROVIDER` env var - Reference: `znzfreezone_backend/src/providers/payment.rs` ### B2: Email provider trait ```rust pub trait EmailProvider: Send + Sync { fn name(&self) -> &str; fn is_configured(&self) -> bool; async fn send(&self, to: &str, subject: &str, html: &str) -> Result<()>; } ``` - `DemoEmailProvider` — logs to console - `ResendProvider` — real email via Resend API - Reference: `znzfreezone_backend/src/providers/email.rs` ### B3: Containerfiles for all services - `Containerfile.backend` — multi-stage Rust build → Alpine - `Containerfile.frontend` — Dioxus WASM build → nginx - `Containerfile.admin` — Rust build → Alpine - Registry: `forge.ourworld.tf/mycelium_code/` ### B4: CI/CD pipeline update - `.forgejo/workflows/build.yml` - Triggers on push to `development` - Pipeline: check → test → dist → pack → push → smoke - Branch-aware tagging (`:development`, `:latest`, `:vX.Y.Z`) ### Acceptance criteria (Phase B) - [ ] `PAYMENT_PROVIDER=demo` works (no external deps) - [ ] `EMAIL_PROVIDER=resend` sends real emails - [ ] All 3 Containerfiles build successfully - [ ] CI pipeline runs on push to development --- ## Phase C: Dioxus WASM Frontend New repo: `mycelium_code/projectmycelium_marketplace_frontend` ### Why Dioxus over Tera SSR 1. **Type safety** — schema-generated types compile-check UI components 2. **Component reuse** — one `ProductCard` used everywhere, not duplicated across 65 templates 3. **Reactivity** — cart updates, filters, messaging without page reloads 4. **Hero ecosystem alignment** — `hero_os_ui_wasm` already uses Dioxus + `dioxus-bootstrap-css` 5. **Generated SDK ready** — `types_wasm_generated.rs` (1,651 lines) and `osis_client_generated.rs` (2,869 lines) exist ### Stack - **Framework**: Dioxus 0.7 - **UI library**: `dioxus-bootstrap-css` (50+ Bootstrap 5.3 components, zero JS) - **Router**: `dioxus-router` (client-side SPA routing) - **HTTP client**: `gloo-net` (fetch API for JSON-RPC calls) - **Types**: Auto-generated from `marketplace.oschema` via `types_wasm_generated.rs` ### Architecture: Hybrid SSR + SPA ``` Public pages (SEO) → SSR (thin Axum, 10-15 routes) /, /marketplace/*, /products/{id}, /docs/* Renders HTML with meta tags, OpenGraph, structured data Authenticated pages → Dioxus SPA (WASM) /app/dashboard, /app/cart, /app/wallet, /app/messaging, /app/nodes, /app/services Client-side routing, data via JSON-RPC to :8001 ``` SSR for crawlers + social previews. SPA for everything interactive. ### Component structure (~250 components) ``` src/ main.rs # Dioxus app entry router.rs # SPA routes rpc_client.rs # JSON-RPC client (wraps generated SDK) state.rs # Global signals (user, cart, theme) components/ layout/ # Navbar, Sidebar, Footer, ThemeToggle common/ # ProductCard, NodeStatus, Badge, Spinner marketplace/ # Browse, Filter, Search, CategoryNav product/ # Detail, Reviews, Pricing, SliceConfig cart/ # CartView, CartItem, Checkout dashboard/ # Overview, Stats, ActivityFeed wallet/ # Balance, Transactions, TopUp messaging/ # ThreadList, MessageView, Compose nodes/ # NodeList, NodeDetail, GroupManager services/ # ServiceList, Booking, SLA apps/ # AppList, Deployment, Health auth/ # Login, Register, Profile admin/ # (if admin also moves to Dioxus) pages/ # Route-level page components ``` ### What gets removed from backend Once Dioxus SPA is complete: - 65 Tera templates (25,716 lines) → deleted - 15 Axum SSR controllers (7,540 lines) → reduced to ~15 thin SEO routes - `ContextBuilder` pattern → replaced by Dioxus signals - `ResponseBuilder` → replaced by JSON-RPC responses - **Net: ~30,000 lines removed, ~15,000 lines of typed components added** ### Acceptance criteria (Phase C) - [ ] Dioxus SPA serves all authenticated pages - [ ] SSR serves public/SEO pages with proper meta tags - [ ] WASM bundle < 200KB gzip - [ ] All existing smoke tests pass against SPA + backend - [ ] E2E tests updated for SPA navigation - [ ] Tera templates removed from backend --- ## Phase D: Production Infrastructure ### D1: Encrypted admin auth - AES-256-GCM encrypted user store (`admin-users.toml.enc`) - CLI commands: `serve`, `add-user`, `list-users`, `remove-user` - Reference: `znzfreezone_admin/src/admin_users.rs` ### D2: MCP endpoint - Auto-generated from `marketplace.oschema` - Exposes all 23 types as AI tools - `POST /mcp` endpoint on RPC server - Reference: `znzfreezone_backend/src/mcp.rs` ### D3: Prometheus metrics - `GET /metrics` endpoint - Counters: rpc_requests_total, rpc_errors_total - Histograms: rpc_request_duration_seconds - Gauges: active_connections, osis_object_count ### D4: Structured logging - `RUST_LOG_FORMAT=json` for production - Structured fields: method, status, duration, user_email - Compatible with Loki/ELK stack ### D5: Backup system - restic + S3-compatible storage (MinIO or external) - Retention: 7 daily / 4 weekly / 3 monthly - Automated via K8s CronJob or cron - Restore procedure documented ### D6: Health monitoring - K8s CronJob (5-min interval) - Checks: backend health, RPC responsiveness, OSIS connectivity, frontend serving - Alert on failure (webhook to Slack/email) ### Acceptance criteria (Phase D) - [ ] Admin auth uses encrypted store - [ ] MCP endpoint responds to tool discovery - [ ] `/metrics` returns Prometheus format - [ ] JSON logs parseable by log aggregator - [ ] Backup runs daily, restore tested - [ ] Health monitor alerts on service down --- ## Phase E: HA Deployment & Marketing ### E1: K3s production deployment Full HA deployment scripts in deploy repo: - `setup-server.sh` — K3s server + Kadalu - `setup-agent.sh` — K3s agent nodes - `setup-storage.sh` — GlusterFS Replica3 - `setup-dns.sh` — Cloudflare DNS automation - 3 compute nodes + 3 gateway nodes - Reference: `znzfreezone_deploy/k3s/` ### E2: TFGrid single-VM deployment - OpenTofu IaC for TFGrid VM provisioning - Docker Compose for single-VM deployment - `make all ENV=dev` for full deploy - Reference: `znzfreezone_deploy/tfgrid/` ### E3: Marketing website New repo: `projectmycelium/www_projectmycelium` (or under `mycelium_code`) - Astro + Tailwind CSS - Pages: Home, About, Products, Pricing, Docs, Contact - Reads from `branding.toml` for customization - Reference: `znzfreezone/www_znzfreezone` ### Acceptance criteria (Phase E) - [ ] K3s cluster deploys with `make all ENV=prod` - [ ] Single-VM deploys with `make all ENV=dev` - [ ] Marketing site live at configured domain - [ ] All services accessible via HTTPS - [ ] Health checks pass on cluster --- ## Final Repo Structure ``` mycelium_code/ home/ # Issues projectmycelium_marketplace/ # Backend (Axum RPC + thin SSR) projectmycelium_marketplace_frontend/ # Dioxus WASM SPA projectmycelium_marketplace_admin/ # Admin dashboard projectmycelium_marketplace_deploy/ # Docker + K3s + TFGrid projectmycelium/ (or mycelium_code) www_projectmycelium/ # Marketing website (Astro) ``` Mirrors the freezone: ``` znzfreezone_code/ home/ znzfreezone_backend/ znzfreezone_frontend/ znzfreezone_admin/ znzfreezone_deploy/ znzfreezone/ www_znzfreezone/ ``` --- ## Phase Dependencies ``` A (split + branding) ──► B (providers + deploy) ──► D (infra) └──► C (Dioxus frontend) ──► E (HA + marketing) ``` A is prerequisite for everything. B and C can run in parallel. D and E follow. --- ## Key Design Principles 1. **Schema is SSOT** — `marketplace.oschema` drives types, CRUD, RPC, Rhai, WASM SDK, OpenRPC 2. **Branding is config** — `branding.toml` drives all customization, no code changes 3. **Providers are pluggable** — payment, email, KYC swap via env var 4. **Frontend is typed** — Dioxus components compile-check against schema types 5. **Deploy is repeatable** — `make release TAG=x.y.z` for any instance 6. **Multi-repo, single convention** — same Makefile patterns, same commit format, same branching

mik-tf commented

2026-03-23 02:06:07 +00:00

Author

Member

Important: dioxus-bootstrap-css upstream-first policy

During Phase C (Dioxus frontend migration), if we encounter any issue with dioxus-bootstrap-css — missing component, broken behavior, incomplete Bootstrap 5.3 coverage, accessibility gap, or API ergonomics problem — we fix the crate itself at https://github.com/mik-tf/dioxus-bootstrap-css.

Do NOT:

Work around a missing component with raw HTML in Dioxus
Copy-paste Bootstrap CSS classes manually
Create marketplace-specific component wrappers for things the crate should handle
Suppress warnings or ignore rendering differences

DO:

Open an issue on dioxus-bootstrap-css
Implement the fix/addition in the crate
Publish a new version
Use the fixed version in marketplace

The marketplace migration is the stress test for dioxus-bootstrap-css. Every gap we find and fix makes the crate better for the entire ecosystem. This is the same principle as fixing hero_rpc_generator when the schema parser had issues with optional field syntax — we fixed the tool, not the schema.

## Important: dioxus-bootstrap-css upstream-first policy During Phase C (Dioxus frontend migration), if we encounter any issue with `dioxus-bootstrap-css` — missing component, broken behavior, incomplete Bootstrap 5.3 coverage, accessibility gap, or API ergonomics problem — we **fix the crate itself** at https://github.com/mik-tf/dioxus-bootstrap-css. **Do NOT:** - Work around a missing component with raw HTML in Dioxus - Copy-paste Bootstrap CSS classes manually - Create marketplace-specific component wrappers for things the crate should handle - Suppress warnings or ignore rendering differences **DO:** - Open an issue on dioxus-bootstrap-css - Implement the fix/addition in the crate - Publish a new version - Use the fixed version in marketplace The marketplace migration is the stress test for dioxus-bootstrap-css. Every gap we find and fix makes the crate better for the entire ecosystem. This is the same principle as fixing hero_rpc_generator when the schema parser had issues with optional field syntax — we fixed the tool, not the schema.

mik-tf commented

2026-03-23 02:41:25 +00:00

Author

Member

v1.1 Complete

Commit: 0e802cb

Phase	What	Lines
A	Branding config (branding.toml, instances/, white-label SSOT)	600
B	Provider abstraction (Payment/Email traits, CI/CD pipeline)	401
C	Dioxus WASM frontend (38 files, dioxus-bootstrap-css, 15 pages)	6,499
D	Production infra (MCP 92 tools, Prometheus, logging, backup, health)	1,500+
E	K3s HA deployment + Astro marketing website	1,000+

Repo structure now matches freezone pattern

projectmycelium_marketplace/
  src/              — Backend (Axum RPC + thin SSR)
  frontend/         — Dioxus WASM SPA (dioxus-bootstrap-css)
  admin/            — Admin dashboard (Axum + Bootstrap)
  deploy/           — Docker + K3s + TFGrid
  www/              — Marketing website (Astro + Tailwind)
  schemas/          — marketplace.oschema (SSOT)
  instances/        — Per-deployment branding configs
  scripts/rhai/     — Rhai operational scripts

Next: repo split (admin, deploy, frontend, www as separate repos)

## v1.1 Complete Commit: `0e802cb` | Phase | What | Lines | |-------|------|-------| | A | Branding config (branding.toml, instances/, white-label SSOT) | 600 | | B | Provider abstraction (Payment/Email traits, CI/CD pipeline) | 401 | | C | Dioxus WASM frontend (38 files, dioxus-bootstrap-css, 15 pages) | 6,499 | | D | Production infra (MCP 92 tools, Prometheus, logging, backup, health) | 1,500+ | | E | K3s HA deployment + Astro marketing website | 1,000+ | ### Repo structure now matches freezone pattern ``` projectmycelium_marketplace/ src/ — Backend (Axum RPC + thin SSR) frontend/ — Dioxus WASM SPA (dioxus-bootstrap-css) admin/ — Admin dashboard (Axum + Bootstrap) deploy/ — Docker + K3s + TFGrid www/ — Marketing website (Astro + Tailwind) schemas/ — marketplace.oschema (SSOT) instances/ — Per-deployment branding configs scripts/rhai/ — Rhai operational scripts ``` ### Next: repo split (admin, deploy, frontend, www as separate repos)