Skip to main content

Admin

packages/admin is the steward cockpit at admin.greengoods.app: where stewards review submitted work, manage gardens and actions, and run their community's operations. It's an operator surface by design, so it favors utility copy, one dominant workspace per route, and restrained color over marketing polish.

The Hub workspace: the app bar with the garden chip, the Work tab listing approved submissions as cards, and the navigation dock
The Hub’s Work tab within the dashboard shell.

The cockpit opens for an address that is a steward, owner, or evaluator of at least one garden; a protocol deployer also gets the protocol garden. Anyone else who signs in sees a no-access screen, where they can request steward access. A gardener or funder role alone does not open the cockpit, though it names both throughout.

The shell​

The canonical shell is CanvasLayout: an admin-owned top AppBar (garden chip, search, account actions), the .workspace-canvas, a MainSheet, and a bottom NavigationBar whose canonical items are Hub, Garden, Community, and Actions; a slot can be hidden, so a garden may show three. Every workspace overlay is a centered AdminDialog; profile, settings, and notifications render in a right-docked AdminSideSheet (bottom sheet on mobile). The /hub route is the reference surface for new page composition.

The Actions workspace: domain filter tabs, a search field, and two action cards, Water quality check and Canopy baseline, each with its status
The Actions workspace shows the garden’s action registry.

Inside src​

A route resolves in router.tsx, passes the role guards in routes/, and renders inside CanvasLayout. Each workspace under views/ composes the Admin* wrappers in components/ over shared hooks; the Material 3 tokens in styles/ are the only place color and type scale live.

DirectoryWhat lives there
src/router.tsx and src/routes/Route definitions, the canvas shell, and role guards like RequireRole.tsx
src/views/One folder per workspace: Hub, Garden, Community, Actions, Cookies, and Profile
src/components/Admin-owned building blocks such as AdminCard, AdminDialog, and the field family, each with a story, plus Shell/ for the AppBar, NavigationBar, MainSheet, and FAB; actions are the shared Button and IconButton
src/styles/The admin's Material 3 tokens, component styles, and type scale
src/__tests__/Vitest suites for views and components

Run and test​

bun run --cwd packages/admin test
bun run --cwd packages/admin build

bun run --cwd packages/admin test --coverage is the fuller pass. Visible UI changes also want rendered proof; the package guide describes the authenticated browser QA path.

How it connects​

The admin reads through the same indexer read models and shared EAS data layer as the client, and writes approvals through the contracts. Its building blocks come from shared; the admin package owns the forked cockpit shell and the Admin* wrapper components.

The steward promise guides cover pool setup, seeding, participation, work counting, confirmation and season close. Settlement and transfer procedures remain outside these release guides.

Commitment pooling spans three scopes. The pool console owns the selected garden's pool and cycle context, the Hub's Confirm tab uses the selected confirming garden, and Community's Coordination tab holds protocol confirmations. Keep those scopes distinct when you change the data projections they share.

Conventions that will bite you​

  • Use the admin wrapper inventory (components/Admin*.tsx) and the surface classes (.surface-section, .surface-card, .workspace-canvas) before composing raw border-and-shadow layouts.
  • NavigationBar is pure navigation. No leading or trailing slots, no extra items.
  • The client PWA's AppBar pattern doesn't belong here; admin has its own.
  • DashboardLayout, Sidebar, and Header are legacy migration code, not templates for new work.
  • Cards mark discrete records or action targets, not decoration; avoid nested bordered-panel mosaics, hero sections, and promo banners.

Go deeper​