B2BEA.org Rebuild implementation-roadmap

Full legacy body rendered for humans

B2BEA.org V1 Implementation Roadmap

Source of record: RedKey Supabase Studio artifact.

• Project: B2BEA.org Rebuild
• Project ID: a820dd0c-6cef-4133-bfbd-d802fd806e44
• Artifact: implementation-roadmap
• Version: 2
• Status: draft
• Updated: 2026-05-08

Purpose

Convert the existing B2BEA.org Studio artifacts into an ordered build sequence. This roadmap does not authorize code by itself. It defines the slices that implementation plans must target.

Build Rule

Do not write one implementation plan for the whole rebuild. Each slice gets its own implementation plan, test gate, and acceptance review.

Architecture Direction

Use a hybrid-first architecture: Eleventy remains the public static publishing layer; a dedicated app/runtime layer handles authenticated, permissioned, write-heavy, preview, export, and operational surfaces.

Slice Order

| slice | name | goal | depends_on | done_when |

| --- | --- | --- | --- | --- |

| 0 | Hybrid Platform Skeleton | Establish repo/workspace layout, route ownership split, shared design-system package, app guard pattern, data adapter interfaces, metadata validation, and QA harness across Eleventy plus app layer. | target-architecture-spec v2, design-system-spec, route-family-inventory, qa-baseline-spec | Public Eleventy shell and private app shell routes both render with shared tokens, route registry, tested guards, and screenshot smoke coverage. |

| 1 | Public Static Core | Build/migrate public reusable Eleventy page families and priority public routes. | Slice 0, page-template-spec, route-customization-review, seo-geo-social-spec, sanity-schema-spec | Public custom exceptions are isolated; standard public route families render through reusable Eleventy templates with metadata and QA coverage. |

| 2 | Content And Publishing | Build Sanity standard page workflow and custom HTML import workflow in the app layer under /admin. | Slice 0, sanity-schema-spec, custom-html-import-spec, publishing-model-spec, security-privacy-spec | Core admins can preview/publish/archive/rollback standard and custom content without bypassing metadata and QA rules. |

| 3 | Auth And Entitlements | Implement login/account routing, entitlement evaluator, protected resource/course gates, and access-state pages. | Slice 0, entitlement-model-spec, permission-lifecycle-matrix, security-privacy-spec | Server-side guards enforce protected reads/actions; Eleventy public pages can call protected app endpoints only through validated flows. |

| 4 | Admin Operations | Build compact /admin operational modules for users, vendors, companies, jobs, categories, academy, and review queues. | Slice 0, security-privacy-spec, data-model-spec | Admin workflows use table/detail/review patterns with audit events for material changes. |

| 5 | Member Workspace | Build member dashboard, profile, career profile, account, resources, and academy progress views in the app layer. | Slice 3, data-model-spec | Members can manage only their own profile/account/progress and see clear entitlement states. |

| 6 | Vendor Workspace | Build /vendor private workspace and reviewed public projection workflow in the app layer, with public profile output available to Eleventy. | Slice 3, vendor-portal-workflow-spec, security-privacy-spec | Vendor edits remain private until B2BEA review; vendor users cannot access other vendor accounts; approved public projection can feed static public pages. |

| 7 | Company Workspace | Build /company private practitioner company workspace in the app layer. | Slice 3, company-workspace-data-spec, company-workspace-template-spec | Company admins manage roster/seats/assignments/jobs privately; no public company directory/profile is created. |

| 8 | Surveys, Forms, Academy Certification | Build reusable survey/form engine and certification extensions only after core shells are stable. | Slice 3, survey-system-spec, academy-certification-spec | Assignment, submission, reporting, export, and privacy rules pass role-based tests. |

| 9 | Production Cutover | Complete redirects, migration, analytics, monitoring, sitemap/search index, visual QA, and release runbook across static and app layers. | All launch slices, qa-baseline-spec | Release gate passes automated tests, screenshots, route checks, migration rehearsal, and manual checklist. |

Spec Gating

| missing_or_follow_on_spec | blocks |

| --- | --- |

| target-architecture-spec v2 | Slice 0 |

| route-customization-review | Slice 1 |

| sanity-schema-spec | Slices 1, 2 |

| seo-geo-social-spec | Slices 1, 2, 9 |

| custom-html-import-spec | Slice 2 |

| security-privacy-spec | Slices 0, 2, 3, 4, 5, 6, 7, 8 |

| qa-baseline-spec | Slice 0 and every launch slice |

| vendor-portal-workflow-spec | Slice 6 |

| company-workspace-template-spec | Slice 7 |

| notification-spec | Slices 4, 6, 7, 8 if notification workflows are included in launch |

| academy-certification-spec | Slice 8 |

Implementation Plan Rule

Each implementation plan must name the slice and exact page families/capabilities in scope, list files/modules to create or modify across Eleventy, app, and shared packages, include tests before implementation tasks, include browser/mobile QA routes when UI is involved, include migration or redirect tasks when existing routes change, and end with a release-readiness checkpoint.

Launch Boundary

Launch V1 should include slices 0 through 7 only if resources allow proper QA. If schedule pressure appears, defer slice 8 before weakening auth, publishing, vendor review, company privacy, or QA gates.

Acceptance Criteria

• Every build slice has dependencies, output, and done criteria.
• Eleventy public speed is preserved instead of discarded.
• Private app workflows are not forced into static/client-only behavior.
• Slice 0 is narrow enough to implement first without migrating content.
• Missing specs are explicit and mapped to blocked slices.