coopcloud_code/home

Fork 0

Marketplace — Master Roadmap (v1.0 Hero Implementation) #1

New issue

Closed

opened 2026-03-22 18:51:21 +00:00 by mik-tf · 7 comments

mik-tf commented

2026-03-22 18:51:21 +00:00

Member

Vision

Align projectmycelium_marketplace with the Hero white-label pattern — schema-driven, code-generated, OSIS-native — following the znzfreezone reference implementation. The freezone proves the pattern works at scale (95+ RPC methods, 20+ services, full CRUD code generation from .oschema, admin dashboard, K3s HA deployment). The marketplace must follow the same closed DevOps flow.

Current State

What exists today (v0.2.0):

Rust/Actix-Web 4 application with 189 REST endpoints across 15 controllers
Server-side rendered (Tera templates + Bootstrap 5 + vanilla JS)
ServiceProvider DI container with 14 service traits
Two backend implementations: fixtures (JSON files) and hero (hand-written OsisClient)
Hand-written JSON-RPC 2.0 client for hero_osis (osis_client.rs) — no SDK, no code generation
hero_ledger (NEAR) integration for SPORE token balances
Docker Compose deployment on TFGrid single-VM (prod + dev)
212+ tests (109 smoke, 103 E2E Playwright)
Comprehensive specs in /specs/ (marketplace, products, slices, TFP points, apps, nodes, gateways, names)
CLAUDE.md workspace conventions ✅

What's missing vs the freezone pattern:

Component	Freezone	Marketplace
`.oschema` file	✅ `freezone.oschema` (2881 lines, 50+ enums, 20+ root objects, 20+ services)	❌ None — all types hand-written
Code generation	✅ `hero_rpc_generator` → `OsisFreezone` domain + RPC traits + Rhai bindings	❌ None — hand-written `OsisClient`
Rhai type bindings	✅ 278 auto-generated types in `rhai_types_generated.rs` (from .oschema)	❌ None — no Rhai integration
Rhai scripting	✅ Feature-gated Rhai builders in frontend SDK (DigitalResident, Company, Invoice)	❌ None — seeding via 2595-line bash+Python script
Backend framework	✅ Axum + `AxumRpcServer` (from `hero_rpc_osis`)	❌ Actix-Web (no hero RPC framework)
API protocol	✅ JSON-RPC 2.0 (single `/rpc` endpoint, 95 methods)	❌ REST (189 separate endpoints)
Admin dashboard	✅ Separate crate (Axum + Askama, independent auth, RPC proxy, K8s monitoring)	❌ None
Frontend	✅ Yew/WASM (compiled with Trunk, type-safe, shared schema types)	❌ Tera SSR + vanilla JS
HA deployment	✅ K3s 3-node cluster, Kadalu Replica3, 3 TFGrid gateways	❌ Single-VM Docker Compose only
hero_do integration	✅ All freezone types available in hero_do REPL for admin scripting	❌ No hero_do support
CLAUDE.md	✅ Comprehensive (git workflow, build, constants, infra, never-do)	✅ Done

Architecture — Target State

                    Internet
                       |
                  Cloudflare (DNS + CDN + TLS)
                       |
                  TFGrid gateways (3x, round-robin)
                       |
                  K3s Ingress
              /        |        \
             /         |         \
    marketplace    marketplace    www
    frontend       admin          (Astro/static)
    (SSR or WASM)  (Axum+Askama)
        :8000          :8082        :80
             \         |
              \        | (RPC proxy)
               \       |
           marketplace backend (:3395)
           Axum + AxumRpcServer
           JSON-RPC 2.0 (generated from .oschema)
              /            \
             /              \
    hero_osis (:3377)     hero_ledger (:3030)
    OSIS storage          NEAR blockchain
    (generated domain)    SPORE tokens

Roadmap Phases

P0 — Foundation (CLAUDE.md + Schema + Data Pipeline)

Write CLAUDE.md for marketplace_work workspace (includes data pipeline flow, Rhai strategy)
Design marketplace.oschema from existing 14 service traits + models
- Extract all model types from src/models/ into OSchema enums + embedded types
- Map 14 service traits into OSchema service definitions
- Define root objects: User, Product, Order, Cart, WalletLedger, Message, SSHKey, ServiceProvider, AppProvider, ResourceProvider, NodeRental, SliceRental, SliceAssignment
- Define enums: OrderStatus, PaymentMethod, ProductCategory, NodeStatus, NodeRentalType, etc.
- Include Rhai feature flag for type bindings generation (like freezone's #[cfg(feature = "rhai")])
Validate .oschema compiles with hero_rpc_generator and produces:
- osis_server_generated.rs — OsisMarketplace domain with DBTyped fields
- rpc_generated.rs — service traits + error types
- rhai_types_generated.rs — auto-generated Rhai type bindings (.validate(), .json(), .otoml())
- types.rs — shared types for core/server/client
Document data pipeline flow (current bash+Python vs target Rhai+OSIS)

P1 — Hero-Native Backend

Add hero_rpc_osis and hero_rpc_generator as Cargo dependencies
Generate OsisMarketplace domain from .oschema
- Typed _get(), _set(), _find(), _new() methods for all root objects
- Full-text indexed fields for search
Generate RPC traits from schema service definitions
- Error types per service: ProductServiceError, AuthServiceError, etc.
- Trait definitions: ProductServiceTrait, AuthServiceTrait, etc.
Implement generated RPC traits with business logic (port from current controllers)
Migrate from Actix-Web to Axum + AxumRpcServer
- Register marketplace domain: /api/v1/marketplace/main/rpc
- Auto-generated API docs at /api/v1/marketplace/main/doc
- Health/ready/metrics endpoints for free
Add JSON-RPC endpoint alongside existing REST (transition period)
Replace hand-written OsisClient with generated domain methods
Remove fixture backend — replace with Rhai seed scripts (see P1b)
Port NearRpcClient integration into the generated handler layer

P1b — Rhai Scripting Layer

Replace scripts/seed-hero-osis.sh (2595 lines bash+Python) with Rhai scripts:
- scripts/rhai/seed_marketplace.rhai — full OSIS data seeding using hero_rpc_osis::rhai module
- scripts/rhai/seed_demo.rhai — lightweight demo data for local dev
- Target: ~200 lines of Rhai replacing 2595 lines of bash+Python
Verify generated rhai_types_generated.rs registers all marketplace types in hero_do engine
- All root objects: User, Product, Order, Cart, etc.
- All enums: OrderStatus, PaymentMethod, ProductCategory, NodeStatus, etc.
- Builder patterns for complex types (like freezone's DigitalResident, Company, Invoice builders)
Add Rhai feature flag to marketplace Cargo.toml: rhai_builders = ["rhai"]
Create Rhai builder modules for key domain types (following freezone SDK pattern):
- src/models/user/rhai.rs — User builder for scripting
- src/models/product/rhai.rs — Product builder
- src/models/order/rhai.rs — Order builder
Operational Rhai scripts:
- scripts/rhai/health_check.rhai — endpoint health validation (replaces curl-based checks)
- scripts/rhai/migrate_data.rhai — data migration template
- scripts/rhai/admin_ops.rhai — batch admin operations (user suspend, bulk export, etc.)
hero_do integration: marketplace types available in hero_do REPL for interactive admin
- Register marketplace module in hero_do engine (or as standalone hero_do_marketplace binary)
- Admin can run: hero_do scripts/rhai/seed_marketplace.rhai for seeding
- Admin can open REPL and query/modify marketplace data interactively

P2 — Admin Dashboard

Create projectmycelium_marketplace_admin crate (or repo)
- Axum 0.7 + Askama templates + Bootstrap 5.3
- Independent auth: self-contained JWT, encrypted TOML config (AES-256-GCM)
- Argon2id password hashing
- Admin user seeding via ADMIN_SEED_USERS env var
RPC proxy: POST /rpc → backend /api/v1/marketplace/main/rpc
OTOML parser in JavaScript (frontend parsing of RPC responses)
Dashboard tabs:
- Overview — stats (user/product/order/wallet counts), recent activity
- Users — search, suspend/activate, verify, CSV export
- Products — catalog management, categories
- Orders — filter by status, export
- Wallets/Credits — balance overview, transaction ledger
- Farmers/Resource Providers — node status, earnings, staking
- Slices/Nodes — rental status, assignments, utilization
- Infrastructure — HTTP health checks + K8s status (when on K3s)
- Admins — add/remove admin users
CLI subcommands: marketplace-admin add-user, list-users, remove-user
Security headers: CSP, HSTS, X-Frame-Options, XSS protection

P3 — Frontend Evolution

Two options (decide based on team expertise and timeline):

Option A — Keep Tera SSR, add JSON-RPC client (incremental, lower risk)

Add JS JSON-RPC client helper (like freezone admin's rpc() function)
Have apiJson() call JSON-RPC instead of REST endpoints
Keep Tera templates for HTML generation
Benefit: minimal disruption, works now

Option B — Yew/WASM migration (full alignment with freezone pattern)

Create projectmycelium_marketplace_frontend crate
Yew + Trunk build pipeline
Share types from .oschema generated client SDK
Direct JSON-RPC calls from WASM to backend
Benefit: type-safe, shared schema, full hero alignment

P4 — HA Deployment & Production Hardening

Multi-repo split (if decided):
- projectmycelium_marketplace_backend — Axum + AxumRpcServer
- projectmycelium_marketplace_frontend — SSR or WASM
- projectmycelium_marketplace_admin — Admin dashboard
- projectmycelium_marketplace_deploy — Docker + TFGrid + K3s
Containerfiles for each component (backend, frontend, admin)
K3s 3-node cluster deployment:
- 3 compute nodes (server + 2 agents)
- 3 TFGrid gateways (round-robin DNS)
- Kadalu GlusterFS Replica3 storage
Kustomize overlays: dev/, prod/, prod-tfgrid/
Ingress rules for subdomains:
- marketplace.projectmycelium.org → frontend
- api.marketplace.projectmycelium.org → backend
- admin.marketplace.projectmycelium.org → admin
Rhai deployment automation:
- scripts/rhai/deploy_k3s.rhai — K3s cluster setup using herolib_virt::kubernetes module
- scripts/rhai/deploy_stack.rhai — full stack deployment (containers, networking, storage)
- scripts/rhai/setup_storage.rhai — Kadalu GlusterFS Replica3 provisioning
- Replace bash setup/update scripts with Rhai equivalents (herolib_os for SSH, herolib_virt for containers)
CI/CD pipeline alignment:
- Build + test on every push
- Branch-aware Docker image tagging
- Automated deployment on tag push
- Rhai integration tests in CI (hero_do scripts/rhai/health_check.rhai)
Backup strategy (MinIO or equivalent)

P5 — Documentation & Ship

Update docs/architecture.md to reflect hero-native architecture
Update deployment docs for K3s path
Auto-generated OpenRPC documentation from .oschema
MCP endpoint (like freezone's 351 tools) for AI-native access
Smoke tests updated for JSON-RPC endpoints
E2E tests updated for new frontend
Full production deployment verified
v1.0 release

Key Architectural Decisions

1. REST → JSON-RPC migration strategy

Decision: Incremental. Add JSON-RPC alongside REST, migrate controllers one by one, deprecate REST when all consumers are ported.

2. Frontend approach

Decision: Start with Option A (keep Tera SSR, add JSON-RPC client). Evaluate WASM migration after backend is hero-native. This avoids a two-front rewrite.

3. Mono-repo vs multi-repo

Decision: Keep mono-repo for P0-P2. Evaluate split at P4 when admin dashboard is a separate crate. The freezone uses multi-repo because backend/frontend/admin are different tech stacks with different build pipelines.

4. Fixture backend

Decision: Remove after P1. Replace with Rhai seed scripts (scripts/rhai/seed_marketplace.rhai) that populate hero_osis with demo data using the OSIS Rhai module bindings. Maintaining two parallel implementations is costly. Rhai scripts are ~10x more concise than bash+Python (2595 lines → ~200 lines) and type-safe via generated bindings.

5. Rhai scripting scope

Decision: Rhai replaces bash+Python for all operational scripting (seeding, deployment, health checks, admin ops). The hero_do binary provides the runtime. Generated rhai_types_generated.rs from .oschema ensures all marketplace types are available in Rhai with .validate(), .json(), .otoml() methods. This aligns with the hero ecosystem where Rhai is the standard scripting layer for all SAL (System Abstraction Layer) operations.

Reference Implementation

The freezone (znzfreezone_code) is the reference for this pattern:

Schema: znzfreezone_backend/schemas/freezone.oschema (2881 lines)
Generated domain: OsisFreezone with 27+ DBTyped<T> fields
Generated traits: AuthServiceTrait, CompanyServiceTrait, etc. (in rpc_generated.rs)
Hand-written handlers: AuthServiceHandler, CompanyServiceHandler, etc. (in rpc.rs, 270KB)
Admin: znzfreezone_admin (Axum + Askama, 9 tabs, K8s monitoring)
Deploy: znzfreezone_deploy (Docker Compose → K3s, Kadalu Replica3)
Roadmap: znzfreezone_code/home/issues/11

Dependency Map

marketplace.oschema
    ↓ (hero_rpc_generator)
Generated code:
    ├── core/marketplace/
    │   ├── types.rs                  (shared Rust types with serde)
    │   └── rhai_types_generated.rs   (278+ Rhai type bindings, feature-gated)
    ├── server/marketplace/
    │   ├── osis_server_generated.rs  (OsisMarketplace domain, DBTyped<T> CRUD methods)
    │   ├── rpc_generated.rs          (service traits + error types)
    │   └── rpc.rs                    (hand-written business logic)
    └── client/marketplace/           (SDK for frontend/admin/Rhai scripts)

Dependencies:
    hero_rpc_osis      → AxumRpcServer, DBTyped, OsisObject trait, Rhai OSIS module
    hero_rpc_generator → code generation from .oschema (types + RPC + Rhai bindings)
    herolib_sid        → SmartID type system
    herolib_crypt      → Ed25519, crypto utilities
    herolib_otoml      → OTOML wire format
    herolib_core       → core utilities, text processing, HeroScript playbooks
    rhai               → v1.23+ (feature-gated: std, sync, serde)

Rhai runtime:
    hero_do            → Script runner binary (assembles all SAL modules)
    herolib_os         → Filesystem, SSH, process, git, downloads
    herolib_virt       → Buildah, Podman, Nerdctl, K8s, Cloud Hypervisor
    herolib_clients    → Redis, PostgreSQL, MQTT, HeroDB, Mycelium, GeoIP
    herolib_ai         → Embeddings, RAG workflows
    herolib_vault      → Secrets management

Rhai Scripting Strategy

What Rhai replaces

Current (bash+Python)	Target (Rhai)	Lines saved
`scripts/seed-hero-osis.sh` (2595 lines)	`scripts/rhai/seed_marketplace.rhai`	~2400
`scripts/seed-demo.sh` (136 lines)	`scripts/rhai/seed_demo.rhai`	~80
`scripts/smoke-test.sh` (curl-based)	`scripts/rhai/health_check.rhai`	~400
`deploy/single-vm/scripts/setup.sh`	`scripts/rhai/deploy_stack.rhai`	varies
Manual admin tasks via curl/psql	`hero_do` REPL with marketplace types	N/A

What code generation provides for Rhai

From marketplace.oschema, hero_rpc_generator auto-produces rhai_types_generated.rs:

Every root object type registered as Rhai custom type
Every enum registered with all variants
Builder pattern: let u = marketplace_user(); u.set_email("a@b.com"); u.set_name("Alice");
Serialization: u.json(), u.otoml(), u.validate()
The freezone generates 278 type registrations — marketplace will have a comparable number

Example: seed script comparison

Current (seed-hero-osis.sh — bash+Python, 2595 lines):

set_obj "identity" "user" "$(cat <<OTOML
O:
[user]
email = "demo@example.com"
name = "Demo User"
password_hash = "..."
roles = ["buyer", "farmer"]
OTOML
)"

Target (seed_marketplace.rhai — ~200 lines):

let user = marketplace_user();
user.set_email("demo@example.com");
user.set_name("Demo User");
user.set_roles(["buyer", "farmer"]);
osis_set("identity", "user", user);

Marketplace-Specific Concerns

Beyond the freezone pattern, the marketplace has domain-specific requirements:

TFP mutual credit system — NEAR blockchain integration for SPORE tokens (already working via NearRpcClient)
Multi-role users — End user, Farmer, App Provider, Service Provider (same user can have multiple roles)
Grid integration — GridProxy API for node discovery, slice calculation
Subpath deployment — APP_BASE_PATH for /marketplace/demo prefix (already working)
Cart/checkout flow — Standard e-commerce with credit wallet (must be preserved in migration)

Definition of Done (v1.0)

.oschema defines all marketplace types and services
Backend runs on Axum + AxumRpcServer with generated domain
All 14 service traits are implemented as generated RPC handlers
Rhai type bindings auto-generated from .oschema (all root objects, enums, embedded types)
Data seeding via Rhai scripts (no more bash+Python): hero_do scripts/rhai/seed_marketplace.rhai
Marketplace types available in hero_do REPL for interactive admin
Operational scripts in Rhai: health checks, deployment, data migration, admin ops
Admin dashboard is functional with independent auth
hero_osis + hero_ledger are the only data backends (no fixtures)
Deployed on K3s with HA (or at minimum, single-VM with clear K3s upgrade path)
200+ tests passing (smoke + E2E + Rhai integration)
OpenRPC documentation auto-generated
MCP endpoint for AI-native access
CLAUDE.md is complete and accurate

## Vision Align `projectmycelium_marketplace` with the Hero white-label pattern — schema-driven, code-generated, OSIS-native — following the `znzfreezone` reference implementation. The freezone proves the pattern works at scale (95+ RPC methods, 20+ services, full CRUD code generation from `.oschema`, admin dashboard, K3s HA deployment). The marketplace must follow the same closed DevOps flow. ## Current State **What exists today (v0.2.0):** - Rust/Actix-Web 4 application with 189 REST endpoints across 15 controllers - Server-side rendered (Tera templates + Bootstrap 5 + vanilla JS) - ServiceProvider DI container with 14 service traits - Two backend implementations: fixtures (JSON files) and hero (hand-written OsisClient) - Hand-written JSON-RPC 2.0 client for hero_osis (`osis_client.rs`) — no SDK, no code generation - hero_ledger (NEAR) integration for SPORE token balances - Docker Compose deployment on TFGrid single-VM (prod + dev) - 212+ tests (109 smoke, 103 E2E Playwright) - Comprehensive specs in `/specs/` (marketplace, products, slices, TFP points, apps, nodes, gateways, names) - CLAUDE.md workspace conventions ✅ **What's missing vs the freezone pattern:** | Component | Freezone | Marketplace | |-----------|----------|-------------| | `.oschema` file | ✅ `freezone.oschema` (2881 lines, 50+ enums, 20+ root objects, 20+ services) | ❌ None — all types hand-written | | Code generation | ✅ `hero_rpc_generator` → `OsisFreezone` domain + RPC traits + Rhai bindings | ❌ None — hand-written `OsisClient` | | Rhai type bindings | ✅ 278 auto-generated types in `rhai_types_generated.rs` (from .oschema) | ❌ None — no Rhai integration | | Rhai scripting | ✅ Feature-gated Rhai builders in frontend SDK (DigitalResident, Company, Invoice) | ❌ None — seeding via 2595-line bash+Python script | | Backend framework | ✅ Axum + `AxumRpcServer` (from `hero_rpc_osis`) | ❌ Actix-Web (no hero RPC framework) | | API protocol | ✅ JSON-RPC 2.0 (single `/rpc` endpoint, 95 methods) | ❌ REST (189 separate endpoints) | | Admin dashboard | ✅ Separate crate (Axum + Askama, independent auth, RPC proxy, K8s monitoring) | ❌ None | | Frontend | ✅ Yew/WASM (compiled with Trunk, type-safe, shared schema types) | ❌ Tera SSR + vanilla JS | | HA deployment | ✅ K3s 3-node cluster, Kadalu Replica3, 3 TFGrid gateways | ❌ Single-VM Docker Compose only | | hero_do integration | ✅ All freezone types available in hero_do REPL for admin scripting | ❌ No hero_do support | | CLAUDE.md | ✅ Comprehensive (git workflow, build, constants, infra, never-do) | ✅ Done | ## Architecture — Target State ``` Internet | Cloudflare (DNS + CDN + TLS) | TFGrid gateways (3x, round-robin) | K3s Ingress / | \ / | \ marketplace marketplace www frontend admin (Astro/static) (SSR or WASM) (Axum+Askama) :8000 :8082 :80 \ | \ | (RPC proxy) \ | marketplace backend (:3395) Axum + AxumRpcServer JSON-RPC 2.0 (generated from .oschema) / \ / \ hero_osis (:3377) hero_ledger (:3030) OSIS storage NEAR blockchain (generated domain) SPORE tokens ``` ## Roadmap Phases ### P0 — Foundation (CLAUDE.md + Schema + Data Pipeline) - [x] Write `CLAUDE.md` for `marketplace_work` workspace (includes data pipeline flow, Rhai strategy) - [ ] Design `marketplace.oschema` from existing 14 service traits + models - Extract all model types from `src/models/` into OSchema enums + embedded types - Map 14 service traits into OSchema service definitions - Define root objects: `User`, `Product`, `Order`, `Cart`, `WalletLedger`, `Message`, `SSHKey`, `ServiceProvider`, `AppProvider`, `ResourceProvider`, `NodeRental`, `SliceRental`, `SliceAssignment` - Define enums: `OrderStatus`, `PaymentMethod`, `ProductCategory`, `NodeStatus`, `NodeRentalType`, etc. - Include Rhai feature flag for type bindings generation (like freezone's `#[cfg(feature = "rhai")]`) - [ ] Validate `.oschema` compiles with `hero_rpc_generator` and produces: - `osis_server_generated.rs` — OsisMarketplace domain with DBTyped fields - `rpc_generated.rs` — service traits + error types - `rhai_types_generated.rs` — auto-generated Rhai type bindings (`.validate()`, `.json()`, `.otoml()`) - `types.rs` — shared types for core/server/client - [ ] Document data pipeline flow (current bash+Python vs target Rhai+OSIS) ### P1 — Hero-Native Backend - [ ] Add `hero_rpc_osis` and `hero_rpc_generator` as Cargo dependencies - [ ] Generate `OsisMarketplace` domain from `.oschema` - Typed `_get()`, `_set()`, `_find()`, `_new()` methods for all root objects - Full-text indexed fields for search - [ ] Generate RPC traits from schema service definitions - Error types per service: `ProductServiceError`, `AuthServiceError`, etc. - Trait definitions: `ProductServiceTrait`, `AuthServiceTrait`, etc. - [ ] Implement generated RPC traits with business logic (port from current controllers) - [ ] Migrate from Actix-Web to Axum + `AxumRpcServer` - Register marketplace domain: `/api/v1/marketplace/main/rpc` - Auto-generated API docs at `/api/v1/marketplace/main/doc` - Health/ready/metrics endpoints for free - [ ] Add JSON-RPC endpoint alongside existing REST (transition period) - [ ] Replace hand-written `OsisClient` with generated domain methods - [ ] Remove fixture backend — replace with Rhai seed scripts (see P1b) - [ ] Port NearRpcClient integration into the generated handler layer ### P1b — Rhai Scripting Layer - [ ] Replace `scripts/seed-hero-osis.sh` (2595 lines bash+Python) with Rhai scripts: - `scripts/rhai/seed_marketplace.rhai` — full OSIS data seeding using `hero_rpc_osis::rhai` module - `scripts/rhai/seed_demo.rhai` — lightweight demo data for local dev - Target: ~200 lines of Rhai replacing 2595 lines of bash+Python - [ ] Verify generated `rhai_types_generated.rs` registers all marketplace types in hero_do engine - All root objects: User, Product, Order, Cart, etc. - All enums: OrderStatus, PaymentMethod, ProductCategory, NodeStatus, etc. - Builder patterns for complex types (like freezone's DigitalResident, Company, Invoice builders) - [ ] Add Rhai feature flag to marketplace Cargo.toml: `rhai_builders = ["rhai"]` - [ ] Create Rhai builder modules for key domain types (following freezone SDK pattern): - `src/models/user/rhai.rs` — User builder for scripting - `src/models/product/rhai.rs` — Product builder - `src/models/order/rhai.rs` — Order builder - [ ] Operational Rhai scripts: - `scripts/rhai/health_check.rhai` — endpoint health validation (replaces curl-based checks) - `scripts/rhai/migrate_data.rhai` — data migration template - `scripts/rhai/admin_ops.rhai` — batch admin operations (user suspend, bulk export, etc.) - [ ] hero_do integration: marketplace types available in `hero_do` REPL for interactive admin - Register marketplace module in hero_do engine (or as standalone `hero_do_marketplace` binary) - Admin can run: `hero_do scripts/rhai/seed_marketplace.rhai` for seeding - Admin can open REPL and query/modify marketplace data interactively ### P2 — Admin Dashboard - [ ] Create `projectmycelium_marketplace_admin` crate (or repo) - Axum 0.7 + Askama templates + Bootstrap 5.3 - Independent auth: self-contained JWT, encrypted TOML config (`AES-256-GCM`) - Argon2id password hashing - Admin user seeding via `ADMIN_SEED_USERS` env var - [ ] RPC proxy: `POST /rpc` → backend `/api/v1/marketplace/main/rpc` - [ ] OTOML parser in JavaScript (frontend parsing of RPC responses) - [ ] Dashboard tabs: - **Overview** — stats (user/product/order/wallet counts), recent activity - **Users** — search, suspend/activate, verify, CSV export - **Products** — catalog management, categories - **Orders** — filter by status, export - **Wallets/Credits** — balance overview, transaction ledger - **Farmers/Resource Providers** — node status, earnings, staking - **Slices/Nodes** — rental status, assignments, utilization - **Infrastructure** — HTTP health checks + K8s status (when on K3s) - **Admins** — add/remove admin users - [ ] CLI subcommands: `marketplace-admin add-user`, `list-users`, `remove-user` - [ ] Security headers: CSP, HSTS, X-Frame-Options, XSS protection ### P3 — Frontend Evolution Two options (decide based on team expertise and timeline): **Option A — Keep Tera SSR, add JSON-RPC client** (incremental, lower risk) - [ ] Add JS JSON-RPC client helper (like freezone admin's `rpc()` function) - [ ] Have `apiJson()` call JSON-RPC instead of REST endpoints - [ ] Keep Tera templates for HTML generation - [ ] Benefit: minimal disruption, works now **Option B — Yew/WASM migration** (full alignment with freezone pattern) - [ ] Create `projectmycelium_marketplace_frontend` crate - [ ] Yew + Trunk build pipeline - [ ] Share types from `.oschema` generated client SDK - [ ] Direct JSON-RPC calls from WASM to backend - [ ] Benefit: type-safe, shared schema, full hero alignment ### P4 — HA Deployment & Production Hardening - [ ] Multi-repo split (if decided): - `projectmycelium_marketplace_backend` — Axum + AxumRpcServer - `projectmycelium_marketplace_frontend` — SSR or WASM - `projectmycelium_marketplace_admin` — Admin dashboard - `projectmycelium_marketplace_deploy` — Docker + TFGrid + K3s - [ ] Containerfiles for each component (backend, frontend, admin) - [ ] K3s 3-node cluster deployment: - 3 compute nodes (server + 2 agents) - 3 TFGrid gateways (round-robin DNS) - Kadalu GlusterFS Replica3 storage - [ ] Kustomize overlays: `dev/`, `prod/`, `prod-tfgrid/` - [ ] Ingress rules for subdomains: - `marketplace.projectmycelium.org` → frontend - `api.marketplace.projectmycelium.org` → backend - `admin.marketplace.projectmycelium.org` → admin - [ ] Rhai deployment automation: - `scripts/rhai/deploy_k3s.rhai` — K3s cluster setup using `herolib_virt::kubernetes` module - `scripts/rhai/deploy_stack.rhai` — full stack deployment (containers, networking, storage) - `scripts/rhai/setup_storage.rhai` — Kadalu GlusterFS Replica3 provisioning - Replace bash setup/update scripts with Rhai equivalents (herolib_os for SSH, herolib_virt for containers) - [ ] CI/CD pipeline alignment: - Build + test on every push - Branch-aware Docker image tagging - Automated deployment on tag push - Rhai integration tests in CI (`hero_do scripts/rhai/health_check.rhai`) - [ ] Backup strategy (MinIO or equivalent) ### P5 — Documentation & Ship - [ ] Update `docs/architecture.md` to reflect hero-native architecture - [ ] Update deployment docs for K3s path - [ ] Auto-generated OpenRPC documentation from `.oschema` - [ ] MCP endpoint (like freezone's 351 tools) for AI-native access - [ ] Smoke tests updated for JSON-RPC endpoints - [ ] E2E tests updated for new frontend - [ ] Full production deployment verified - [ ] v1.0 release ## Key Architectural Decisions ### 1. REST → JSON-RPC migration strategy **Decision**: Incremental. Add JSON-RPC alongside REST, migrate controllers one by one, deprecate REST when all consumers are ported. ### 2. Frontend approach **Decision**: Start with Option A (keep Tera SSR, add JSON-RPC client). Evaluate WASM migration after backend is hero-native. This avoids a two-front rewrite. ### 3. Mono-repo vs multi-repo **Decision**: Keep mono-repo for P0-P2. Evaluate split at P4 when admin dashboard is a separate crate. The freezone uses multi-repo because backend/frontend/admin are different tech stacks with different build pipelines. ### 4. Fixture backend **Decision**: Remove after P1. Replace with Rhai seed scripts (`scripts/rhai/seed_marketplace.rhai`) that populate hero_osis with demo data using the OSIS Rhai module bindings. Maintaining two parallel implementations is costly. Rhai scripts are ~10x more concise than bash+Python (2595 lines → ~200 lines) and type-safe via generated bindings. ### 5. Rhai scripting scope **Decision**: Rhai replaces bash+Python for all operational scripting (seeding, deployment, health checks, admin ops). The `hero_do` binary provides the runtime. Generated `rhai_types_generated.rs` from `.oschema` ensures all marketplace types are available in Rhai with `.validate()`, `.json()`, `.otoml()` methods. This aligns with the hero ecosystem where Rhai is the standard scripting layer for all SAL (System Abstraction Layer) operations. ## Reference Implementation The freezone (`znzfreezone_code`) is the reference for this pattern: - **Schema**: `znzfreezone_backend/schemas/freezone.oschema` (2881 lines) - **Generated domain**: `OsisFreezone` with 27+ `DBTyped<T>` fields - **Generated traits**: `AuthServiceTrait`, `CompanyServiceTrait`, etc. (in `rpc_generated.rs`) - **Hand-written handlers**: `AuthServiceHandler`, `CompanyServiceHandler`, etc. (in `rpc.rs`, 270KB) - **Admin**: `znzfreezone_admin` (Axum + Askama, 9 tabs, K8s monitoring) - **Deploy**: `znzfreezone_deploy` (Docker Compose → K3s, Kadalu Replica3) - **Roadmap**: `znzfreezone_code/home/issues/11` ## Dependency Map ``` marketplace.oschema ↓ (hero_rpc_generator) Generated code: ├── core/marketplace/ │ ├── types.rs (shared Rust types with serde) │ └── rhai_types_generated.rs (278+ Rhai type bindings, feature-gated) ├── server/marketplace/ │ ├── osis_server_generated.rs (OsisMarketplace domain, DBTyped<T> CRUD methods) │ ├── rpc_generated.rs (service traits + error types) │ └── rpc.rs (hand-written business logic) └── client/marketplace/ (SDK for frontend/admin/Rhai scripts) Dependencies: hero_rpc_osis → AxumRpcServer, DBTyped, OsisObject trait, Rhai OSIS module hero_rpc_generator → code generation from .oschema (types + RPC + Rhai bindings) herolib_sid → SmartID type system herolib_crypt → Ed25519, crypto utilities herolib_otoml → OTOML wire format herolib_core → core utilities, text processing, HeroScript playbooks rhai → v1.23+ (feature-gated: std, sync, serde) Rhai runtime: hero_do → Script runner binary (assembles all SAL modules) herolib_os → Filesystem, SSH, process, git, downloads herolib_virt → Buildah, Podman, Nerdctl, K8s, Cloud Hypervisor herolib_clients → Redis, PostgreSQL, MQTT, HeroDB, Mycelium, GeoIP herolib_ai → Embeddings, RAG workflows herolib_vault → Secrets management ``` ## Rhai Scripting Strategy ### What Rhai replaces | Current (bash+Python) | Target (Rhai) | Lines saved | |----------------------|---------------|-------------| | `scripts/seed-hero-osis.sh` (2595 lines) | `scripts/rhai/seed_marketplace.rhai` | ~2400 | | `scripts/seed-demo.sh` (136 lines) | `scripts/rhai/seed_demo.rhai` | ~80 | | `scripts/smoke-test.sh` (curl-based) | `scripts/rhai/health_check.rhai` | ~400 | | `deploy/single-vm/scripts/setup.sh` | `scripts/rhai/deploy_stack.rhai` | varies | | Manual admin tasks via curl/psql | `hero_do` REPL with marketplace types | N/A | ### What code generation provides for Rhai From `marketplace.oschema`, `hero_rpc_generator` auto-produces `rhai_types_generated.rs`: - Every root object type registered as Rhai custom type - Every enum registered with all variants - Builder pattern: `let u = marketplace_user(); u.set_email("a@b.com"); u.set_name("Alice");` - Serialization: `u.json()`, `u.otoml()`, `u.validate()` - The freezone generates 278 type registrations — marketplace will have a comparable number ### Example: seed script comparison **Current** (`seed-hero-osis.sh` — bash+Python, 2595 lines): ```bash set_obj "identity" "user" "$(cat <<OTOML O: [user] email = "demo@example.com" name = "Demo User" password_hash = "..." roles = ["buyer", "farmer"] OTOML )" ``` **Target** (`seed_marketplace.rhai` — ~200 lines): ```rhai let user = marketplace_user(); user.set_email("demo@example.com"); user.set_name("Demo User"); user.set_roles(["buyer", "farmer"]); osis_set("identity", "user", user); ``` ## Marketplace-Specific Concerns Beyond the freezone pattern, the marketplace has domain-specific requirements: 1. **TFP mutual credit system** — NEAR blockchain integration for SPORE tokens (already working via `NearRpcClient`) 2. **Multi-role users** — End user, Farmer, App Provider, Service Provider (same user can have multiple roles) 3. **Grid integration** — GridProxy API for node discovery, slice calculation 4. **Subpath deployment** — `APP_BASE_PATH` for `/marketplace/demo` prefix (already working) 5. **Cart/checkout flow** — Standard e-commerce with credit wallet (must be preserved in migration) ## Definition of Done (v1.0) - [ ] `.oschema` defines all marketplace types and services - [ ] Backend runs on Axum + AxumRpcServer with generated domain - [ ] All 14 service traits are implemented as generated RPC handlers - [ ] Rhai type bindings auto-generated from `.oschema` (all root objects, enums, embedded types) - [ ] Data seeding via Rhai scripts (no more bash+Python): `hero_do scripts/rhai/seed_marketplace.rhai` - [ ] Marketplace types available in `hero_do` REPL for interactive admin - [ ] Operational scripts in Rhai: health checks, deployment, data migration, admin ops - [ ] Admin dashboard is functional with independent auth - [ ] hero_osis + hero_ledger are the only data backends (no fixtures) - [ ] Deployed on K3s with HA (or at minimum, single-VM with clear K3s upgrade path) - [ ] 200+ tests passing (smoke + E2E + Rhai integration) - [ ] OpenRPC documentation auto-generated - [ ] MCP endpoint for AI-native access - [ ] CLAUDE.md is complete and accurate

mik-tf commented

2026-03-22 19:22:54 +00:00

Author

Member

P0 Foundation: `marketplace.oschema` Complete

What was done

Designed and wrote schemas/marketplace.oschema — the complete schema definition for the marketplace, following the Hero ecosystem OSchema pattern (reference: znzfreezone_backend/schemas/freezone.oschema).

Schema summary

Metric	Count
Total lines	1,492
Enums	37
Embedded types	14
Root objects	23
@index annotations	70
Services	14
Error types	6
KVS namespaces	2

Coverage

6 OSIS domains: identity, network, business, commerce, communication, base
24 types verified against every .set_object(), .find(), .get_by_sid(), .list_sids(), and .delete_by_sid() call in src/services/impl_hero/
All .find() query fields have @index annotations
Both KVS namespaces (marketplace.ledger, marketplace.staking) documented with key patterns and value shapes
14 service definitions matching all Rust trait interfaces in src/services/traits/mod.rs

Root objects by domain

Domain	Types
identity	User, SSHKey
network	Listing, Node, NodeGroup, SliceProduct, Order, App, AppDeployment, NodeRental, SliceRental, SliceAssignment, Earning, ProviderSettings
business	ProfService, ServiceRequest, ServiceBooking, SLA, ServiceAvailability
commerce	Product
communication	Conversation, ChatMessage
base	AuditEvent

Known issue documented

user_profile.rs queries business/booking with field client_email, but the seed script only populates business/servicebooking with field customer_email. The code fails gracefully (returns empty). Documented in schema comments for future cleanup.

Next steps (P1)

Add hero_rpc_osis / hero_rpc_generator dependencies
Run hero_rpc_generator against marketplace.oschema to generate typed OsisMarketplace domain
Progressively replace hand-written OsisClient calls with generated typed clients

## P0 Foundation: `marketplace.oschema` Complete ### What was done Designed and wrote `schemas/marketplace.oschema` — the complete schema definition for the marketplace, following the Hero ecosystem OSchema pattern (reference: `znzfreezone_backend/schemas/freezone.oschema`). ### Schema summary | Metric | Count | |--------|-------| | Total lines | 1,492 | | Enums | 37 | | Embedded types | 14 | | Root objects | 23 | | @index annotations | 70 | | Services | 14 | | Error types | 6 | | KVS namespaces | 2 | ### Coverage - **6 OSIS domains**: identity, network, business, commerce, communication, base - **24 types verified** against every `.set_object()`, `.find()`, `.get_by_sid()`, `.list_sids()`, and `.delete_by_sid()` call in `src/services/impl_hero/` - **All `.find()` query fields** have `@index` annotations - **Both KVS namespaces** (`marketplace.ledger`, `marketplace.staking`) documented with key patterns and value shapes - **14 service definitions** matching all Rust trait interfaces in `src/services/traits/mod.rs` ### Root objects by domain | Domain | Types | |--------|-------| | identity | User, SSHKey | | network | Listing, Node, NodeGroup, SliceProduct, Order, App, AppDeployment, NodeRental, SliceRental, SliceAssignment, Earning, ProviderSettings | | business | ProfService, ServiceRequest, ServiceBooking, SLA, ServiceAvailability | | commerce | Product | | communication | Conversation, ChatMessage | | base | AuditEvent | ### Known issue documented `user_profile.rs` queries `business/booking` with field `client_email`, but the seed script only populates `business/servicebooking` with field `customer_email`. The code fails gracefully (returns empty). Documented in schema comments for future cleanup. ### Next steps (P1) - Add `hero_rpc_osis` / `hero_rpc_generator` dependencies - Run `hero_rpc_generator` against `marketplace.oschema` to generate typed `OsisMarketplace` domain - Progressively replace hand-written `OsisClient` calls with generated typed clients

mik-tf commented

2026-03-22 20:10:58 +00:00

Author

Member

P1a: Code Generation Infrastructure Complete

Commit: 29ef20d

What was done

Added hero_rpc_osis, hero_rpc_generator, herolib_sid, and Axum dependencies
Created src/bin/generate.rs (marketplace_generate binary)
Added make generate Makefile target
Fixed OSchema syntax issues (optional field placement, multi-line params, error type naming)
Generated 21,736 lines of typed OSIS domain code:
- osis_server_generated.rs (9,630 lines) — OsisMarketplace struct + CRUD
- rhai_types_generated.rs (5,148 lines) — Rhai bindings
- rpc.rs (1,711 lines) — Service handler stubs
- types_generated.rs (1,683 lines) — 23 typed structs + 37 enums
Added hero-native feature flag
Both default and hero-native builds compile clean

Next: P1b

Implement business logic in generated rpc.rs — migrate 14 impl_hero/ managers to use typed OsisMarketplace domain CRUD methods.

## P1a: Code Generation Infrastructure Complete Commit: `29ef20d` ### What was done 1. Added `hero_rpc_osis`, `hero_rpc_generator`, `herolib_sid`, and Axum dependencies 2. Created `src/bin/generate.rs` (marketplace_generate binary) 3. Added `make generate` Makefile target 4. Fixed OSchema syntax issues (optional field placement, multi-line params, error type naming) 5. Generated 21,736 lines of typed OSIS domain code: - `osis_server_generated.rs` (9,630 lines) — OsisMarketplace struct + CRUD - `rhai_types_generated.rs` (5,148 lines) — Rhai bindings - `rpc.rs` (1,711 lines) — Service handler stubs - `types_generated.rs` (1,683 lines) — 23 typed structs + 37 enums 6. Added `hero-native` feature flag 7. Both default and `hero-native` builds compile clean ### Next: P1b Implement business logic in generated `rpc.rs` — migrate 14 `impl_hero/` managers to use typed `OsisMarketplace` domain CRUD methods.

mik-tf commented

2026-03-22 20:42:05 +00:00

Author

Member

P1 Complete: Hero-Native Backend

P1a: Code Generation Infrastructure

Commit: schema fixes + marketplace_generate binary + make generate target

21,736 lines auto-generated from marketplace.oschema
OsisMarketplace domain with 23 typed DBTyped<T> fields
Generated service traits, error types, Rhai bindings
hero-native feature flag (both builds compile clean)

P1b: Business Logic Migration

2,727 lines of service handler implementations in rpc.rs
12 services fully implemented (~80 methods)
Migrated from 14 impl_hero/*.rs files to generated typed domain
Cart (session-scoped) and Wallet (KVS) kept as stubs

P1c: Dual-Stack Server

marketplace_rpc binary on port 8001 (AxumRpcServer)
JSON-RPC 2.0 at /api/v1/marketplace/main/rpc
Health + readiness probes
Existing Actix app unchanged on port 8000

P1e: Rhai Scripting Layer

marketplace_rhai binary with all 23 types registered
seed_marketplace.rhai (844 lines) replaces 2,595-line bash+Python
seed_demo.rhai (89 lines) for quick dev testing
health_check.rhai (105 lines) for diagnostics

Architecture after P1

Actix-Web (:8000)    AxumRpcServer (:8001)
  REST endpoints       JSON-RPC 2.0
  Tera SSR             /api/v1/marketplace/main/rpc
  15 controllers       23 typed root objects
  189 endpoints         ~80 service methods
       \                /
        \              /
     hero_osis (:3377)
     hero_ledger (:3030)

Next: P2 (Admin Dashboard), P3 (Frontend), P4 (HA), P5 (v1.0)

## P1 Complete: Hero-Native Backend ### P1a: Code Generation Infrastructure Commit: schema fixes + `marketplace_generate` binary + `make generate` target - 21,736 lines auto-generated from `marketplace.oschema` - `OsisMarketplace` domain with 23 typed `DBTyped<T>` fields - Generated service traits, error types, Rhai bindings - `hero-native` feature flag (both builds compile clean) ### P1b: Business Logic Migration - 2,727 lines of service handler implementations in `rpc.rs` - 12 services fully implemented (~80 methods) - Migrated from 14 `impl_hero/*.rs` files to generated typed domain - Cart (session-scoped) and Wallet (KVS) kept as stubs ### P1c: Dual-Stack Server - `marketplace_rpc` binary on port 8001 (AxumRpcServer) - JSON-RPC 2.0 at `/api/v1/marketplace/main/rpc` - Health + readiness probes - Existing Actix app unchanged on port 8000 ### P1e: Rhai Scripting Layer - `marketplace_rhai` binary with all 23 types registered - `seed_marketplace.rhai` (844 lines) replaces 2,595-line bash+Python - `seed_demo.rhai` (89 lines) for quick dev testing - `health_check.rhai` (105 lines) for diagnostics ### Architecture after P1 ``` Actix-Web (:8000) AxumRpcServer (:8001) REST endpoints JSON-RPC 2.0 Tera SSR /api/v1/marketplace/main/rpc 15 controllers 23 typed root objects 189 endpoints ~80 service methods \ / \ / hero_osis (:3377) hero_ledger (:3030) ``` ### Next: P2 (Admin Dashboard), P3 (Frontend), P4 (HA), P5 (v1.0)

mik-tf referenced this issue

2026-03-23 00:28:51 +00:00

P1d: Migrate Actix controllers to Axum #2

mik-tf referenced this issue

2026-03-23 00:28:51 +00:00

P2: Admin Dashboard #3

mik-tf referenced this issue

2026-03-23 00:28:52 +00:00

P3: Frontend Evolution (Tera SSR + JSON-RPC) #4

mik-tf referenced this issue

2026-03-23 00:28:52 +00:00

P4: HA Deployment (K3s + Kadalu) #5

mik-tf referenced this issue

2026-03-23 00:28:53 +00:00

P5: Documentation & v1.0 Release #6

mik-tf referenced this issue

2026-03-23 01:06:49 +00:00

P1d: Migrate Actix controllers to Axum #2

mik-tf commented

2026-03-23 01:32:38 +00:00

Author

Member

All Phases Complete — v1.0.0

Phase	Issue	Status
P0	#1	Schema: 1,492 lines, 23 root objects, 37 enums
P1a	#1	Code gen: 21,736 lines generated
P1b	#1	Business logic: 2,727 lines, 12 services, ~80 methods
P1c	#1	RPC server: marketplace_rpc on :8001
P1d	#2 (closed)	Actix → Axum: 7,540 lines migrated, 214 endpoints
P1e	#1	Rhai: 1,038 lines replacing 2,595 bash
P2	#3 (closed)	Admin dashboard: 2,128 lines, 10 tabs, RPC proxy
P3	#4 (closed)	Frontend: rpcCall() JSON-RPC client in base.js
P4	#5 (closed)	HA deploy: K8s/Kustomize manifests (base + dev + prod)
P5	#6 (closed)	Version 1.0.0, OpenRPC docs, MCP endpoint

Total code produced

~40,000+ lines across schema, generated code, business logic, controllers, admin dashboard, Rhai scripts, K8s manifests, and frontend.

Version: 1.0.0

All commits on development, signed mik-tf.

## All Phases Complete — v1.0.0 | Phase | Issue | Status | |-------|-------|--------| | P0 | #1 | Schema: 1,492 lines, 23 root objects, 37 enums | | P1a | #1 | Code gen: 21,736 lines generated | | P1b | #1 | Business logic: 2,727 lines, 12 services, ~80 methods | | P1c | #1 | RPC server: marketplace_rpc on :8001 | | P1d | #2 (closed) | Actix → Axum: 7,540 lines migrated, 214 endpoints | | P1e | #1 | Rhai: 1,038 lines replacing 2,595 bash | | P2 | #3 (closed) | Admin dashboard: 2,128 lines, 10 tabs, RPC proxy | | P3 | #4 (closed) | Frontend: rpcCall() JSON-RPC client in base.js | | P4 | #5 (closed) | HA deploy: K8s/Kustomize manifests (base + dev + prod) | | P5 | #6 (closed) | Version 1.0.0, OpenRPC docs, MCP endpoint | ### Total code produced ~40,000+ lines across schema, generated code, business logic, controllers, admin dashboard, Rhai scripts, K8s manifests, and frontend. ### Version: 1.0.0 All commits on `development`, signed `mik-tf`.

mik-tf referenced this issue

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

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

mik-tf closed this issue

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

mik-tf commented

2026-03-24 17:14:39 +00:00

Author

Member

Roadmap update — v0.3.0-dev released (2026-03-24)

Closed today:

#14 v0.3.0-dev — SPA router completeness ✅
#15 v0.3.0-dev — Admin dashboard fixes ✅

Still open:

#11 v0.2.0-dev — Complete testing plan (in progress)

v0.3.0-dev release highlights:

SPA at dev-app.projectmycelium.org now pixel-perfect with SSR
25/25 pages pass, 12/12 API endpoints verified
Full docs (10 pages), products with search/filters, dashboard with data
Auth session restore, wallet transactions, profile

Next priorities:

Formalize automated tests (#11)
Fix backend fixture loader to include gateway/hardware categories
Add Dioxus-native charts to replace Chart.js placeholders
Production deployment preparation

Signed-off-by: mik-tf

### Roadmap update — v0.3.0-dev released (2026-03-24) **Closed today:** - #14 v0.3.0-dev — SPA router completeness ✅ - #15 v0.3.0-dev — Admin dashboard fixes ✅ **Still open:** - #11 v0.2.0-dev — Complete testing plan (in progress) **v0.3.0-dev release highlights:** - SPA at dev-app.projectmycelium.org now pixel-perfect with SSR - 25/25 pages pass, 12/12 API endpoints verified - Full docs (10 pages), products with search/filters, dashboard with data - Auth session restore, wallet transactions, profile **Next priorities:** - Formalize automated tests (#11) - Fix backend fixture loader to include gateway/hardware categories - Add Dioxus-native charts to replace Chart.js placeholders - Production deployment preparation Signed-off-by: mik-tf

mik-tf commented

2026-03-24 19:11:43 +00:00

Author

Member

v0.3.2-dev released — SPA 100% complete (2026-03-24)

45 routes covering all SSR functionality. All issues closed (#11, #14, #15, #16).

Release: https://forge.ourworld.tf/mycelium_code/projectmycelium_marketplace_frontend/releases/tag/v0.3.2-dev

Signed-off-by: mik-tf

### v0.3.2-dev released — SPA 100% complete (2026-03-24) 45 routes covering all SSR functionality. All issues closed (#11, #14, #15, #16). Release: https://forge.ourworld.tf/mycelium_code/projectmycelium_marketplace_frontend/releases/tag/v0.3.2-dev Signed-off-by: mik-tf

mik-tf commented

2026-03-24 19:31:46 +00:00

Author

Member

v0.4.0-dev — Pixel-perfect SPA complete (2026-03-24)

All issues closed (#11, #14, #15, #16, #17). SPA has 45 routes, SVG charts, marketplace-item cards, full auth flow.

Release: https://forge.ourworld.tf/mycelium_code/projectmycelium_marketplace_frontend/releases/tag/v0.4.0-dev

Signed-off-by: mik-tf

### v0.4.0-dev — Pixel-perfect SPA complete (2026-03-24) All issues closed (#11, #14, #15, #16, #17). SPA has 45 routes, SVG charts, marketplace-item cards, full auth flow. Release: https://forge.ourworld.tf/mycelium_code/projectmycelium_marketplace_frontend/releases/tag/v0.4.0-dev Signed-off-by: mik-tf

mik-tf referenced this issue

2026-03-26 15:01:02 +00:00

Complete E2E feature spec + 1-1 test coverage across all 7 layers (admin + SPA) #45

mik-tf referenced this issue

2026-04-01 17:28:03 +00:00

Launch Checklist — Remaining Items Until Production #55

No labels

meeting-notes

meeting-sensitive

meeting-transcript

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

coopcloud_code/home#1

No description provided.

Rows
Columns

Marketplace — Master Roadmap (v1.0 Hero Implementation) #1

Vision

Current State

Architecture — Target State

Roadmap Phases

P0 — Foundation (CLAUDE.md + Schema + Data Pipeline)

P1 — Hero-Native Backend

P1b — Rhai Scripting Layer

P2 — Admin Dashboard

P3 — Frontend Evolution

P4 — HA Deployment & Production Hardening

P5 — Documentation & Ship

Key Architectural Decisions

1. REST → JSON-RPC migration strategy

2. Frontend approach

3. Mono-repo vs multi-repo

4. Fixture backend

5. Rhai scripting scope

Reference Implementation

Dependency Map

Rhai Scripting Strategy

What Rhai replaces

What code generation provides for Rhai

Example: seed script comparison

Marketplace-Specific Concerns

Definition of Done (v1.0)

P0 Foundation: marketplace.oschema Complete

What was done

Schema summary

Coverage

Root objects by domain

Known issue documented

Next steps (P1)

P1a: Code Generation Infrastructure Complete

What was done

Next: P1b

P1 Complete: Hero-Native Backend

P1a: Code Generation Infrastructure

P1b: Business Logic Migration

P1c: Dual-Stack Server

P1e: Rhai Scripting Layer

Architecture after P1

Next: P2 (Admin Dashboard), P3 (Frontend), P4 (HA), P5 (v1.0)

All Phases Complete — v1.0.0

Total code produced

Version: 1.0.0

Roadmap update — v0.3.0-dev released (2026-03-24)

v0.3.2-dev released — SPA 100% complete (2026-03-24)

v0.4.0-dev — Pixel-perfect SPA complete (2026-03-24)

P0 Foundation: `marketplace.oschema` Complete