coopcloud_code/home
0
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

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
Copy link

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:

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
Copy link

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:

  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

## 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
Copy link

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:

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
Copy link

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.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
meeting-notes

Meeting notes and follow-ups

  
meeting-sensitive

Sensitive meeting; no shared archive or AI processing

  
meeting-transcript

Raw meeting transcript; AI drafts the report

No labels
meeting-notes
meeting-sensitive
meeting-transcript
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#8
No description provided.