intent · supabase_json

B2BEA.org Rebuild intent

The current B2BEA.org site has accumulated useful product thinking but also design drift, page-specific CSS, inconsistent templates, and unclear separation between public, admin, member, vendor, and company-level surfaces.

Planning Surface

Use this to decide what happens next.

Status

approved

problem

success metrics

metric	target
artifact coverage	Current site inventory, surface model, content model, design system, page specs, and implementation plan exist as catalog artifacts before coding.
template reduction	Most public pages map to fewer than 10 reusable template families.
style ownership	No page-specific CSS for shared controls, cards, pills, forms, nav, tables, or page headers.
workflow readiness	Each authenticated surface has roles, permissions, states, and core workflows specified before build.

Agent Handoff

Start Here

Completion Evidence

metric	target
artifact coverage	Current site inventory, surface model, content model, design system, page specs, and implementation plan exist as catalog artifacts before coding.
template reduction	Most public pages map to fewer than 10 reusable template families.
style ownership	No page-specific CSS for shared controls, cards, pills, forms, nav, tables, or page headers.
workflow readiness	Each authenticated surface has roles, permissions, states, and core workflows specified before build.

Problem

Goal

Create a spec-first rebuild project that reverse-engineers the current site into reviewable artifacts, defines a hardened design system, and produces implementation-ready specs before coding the replacement site.

Success Metrics

item: metric: string, target: string
item: metric: string, target: string
item: metric: string, target: string
item: metric: string, target: string

Structured Payload

Machine-readable source fields

goal

users

type	success	description
public visitor	They can quickly understand B2BEA, find useful content, discover vendors/people, and convert into the correct path.	Practitioners, vendors, partners, and buyers browsing public content, directories, resources, courses, events, and search.
B2BEA admin	They can operate the ecosystem through dense, reliable admin workflows.	Internal operator managing content, users, vendors, jobs, academy, approvals, reporting, and platform operations.
individual member	They can manage identity and benefits without admin help.	A logged-in person managing profile, learning, membership, saved content, career activity, and public/private profile presence.
vendor company admin	They can manage commercial participation and marketplace presence.	Vendor-side user managing company profile, people, claims, memberships, sponsorships, analytics, content, and lead/contact workflow.
practitioner company admin	They can manage seats, employee access, learning/career benefits, and company membership ownership.	Company-level admin for manufacturers, distributors, agencies, and consultants granting employee access to academy/careers and managing company benefits.

problem

version

project id

a820dd0c-6cef-4133-bfbd-d802fd806e44

updated at

2026-05-06T19:04:19.428Z

brand voice

tone

direct
credible
practitioner-led

off brand

Overly decorative SaaS marketing language.
Vague community claims.
Unreviewed AI-generated filler.

language rules

Use plain B2B commerce language.
Prioritize clarity over slogans.
Describe benefits through concrete user outcomes.

project name

B2BEA.org Rebuild

ux philosophy

feel

Quiet, consistent, work-focused, credible, and fast. Public pages should feel editorial and polished; authenticated surfaces should feel like dependable operating software.

explicitly avoid

One-off page CSS becoming the design system.
Marketing-page composition leaking into admin or portal workflows.
Design decisions made directly in templates without a reusable component contract.

non negotiable patterns

One shared foundation for typography, color, spacing, radius, elevation, fields, buttons, pills, cards, tables, nav, and responsive behavior.
Every page maps to a named template and component set before implementation.
Authenticated surfaces use app-grade patterns for tables, forms, status, permissions, audit trails, and empty/error states.

scope boundary

in v1

Reverse-engineer current site
Define surface model
Define design system contracts
Define page/template specs
Define content/data model contracts
Produce phased implementation plan

out v1

Writing production rebuild code
Changing current live-site behavior
Final stack decision before artifacts clarify requirements

non negotiables

No rebuild coding begins until core artifacts are drafted and reviewed.
The design system is specified before page implementation.
Public, admin, member, vendor, and practitioner company surfaces are treated as distinct surfaces with shared foundations.
Current site content/data logic is reused only after audit; legacy CSS/template structure is not preserved by default.
Acceptance criteria must be mechanically checkable wherever possible.

success metrics

metric	target
artifact coverage	Current site inventory, surface model, content model, design system, page specs, and implementation plan exist as catalog artifacts before coding.
template reduction	Most public pages map to fewer than 10 reusable template families.
style ownership	No page-specific CSS for shared controls, cards, pills, forms, nav, tables, or page headers.
workflow readiness	Each authenticated surface has roles, permissions, states, and core workflows specified before build.

what wrong looks like

A new site that still has page-specific style drift.
A beautiful public site with weak admin/member/vendor workflows.
A rebuild that copies the current IA without questioning it.
A design system that is only colors and fonts, not component contracts and states.