Implementation comparison — September 23, 2026

Compared the 30 existing requirement rows with freshly fetched GitHub main 4afd9bfd93a9eded44a522a190f397eb71c929e2. Netlify independently identifies that exact commit as the current production deploy; no authenticated acceptance tests or production database writes were performed. This is a source comparison, not a blanket completion/sign-off audit. Priorities, owners and statuses remain unchanged.

• Homepage, registration, email/password auth, profile: corresponding pages and server actions exist under src/app/ and src/lib/auth/actions.ts. A Not started/In progress marker elsewhere must not be read as proof these surfaces are absent.
• Directory: dashboard/directory, lib/directory and lib/connections/actions.ts implement directory search, map/list UI and connection request/acceptance actions. Privacy/permission acceptance still needs runtime review.
• Events, one-click registration, add-to-calendar: dashboard/events, lib/events/actions.ts and lib/events/calendar.ts contain event surfaces, RSVP actions and per-event Google/Outlook/ICS helpers. External-registration paths also exist. Calendar subscription (all events) remains a separate Hold requirement; individual calendar buttons do not satisfy it.
• Resources, library search, partner/sponsor and affiliate links: dashboard/resources/ResourcesHub.tsx contains benefits, blog search, newsletters and partner surfaces. This supports implementation presence, not acceptance of every search/category requirement or current content completeness.
• Recordings: event/resources code and docs/psychedelx-recordings-import.md provide recording support evidence; every historical recording's availability was not checked.
• Conference Carousel: conference routes/components and RSVP actions exist; historical Not started status needs acceptance review rather than assuming conference functionality is absent.
• Admin Portal: dashboard/admin and lib/admin/actions.ts contain role checks, team content permissions and legacy per-user permission fallback. The old proposed toggle model should be compared with these actual controls.
• Member-ID spine / Mailchimp: signup calls audience sync, passes FNAME/LNAME fields and applies a portal registration tag. The separate Universal member ID requirement is not established across every external system by that code alone.
• Post-registration onboarding: authenticated welcome/WhatsApp flows, profile completion and tour state have source evidence. This is separate from ‣, which remains active/not started.
• In-portal community chat: current code supports WhatsApp handoff/onboarding and community redirects to directory connections. Read the old title alongside its explicit outsource-chat decision; do not turn it into a requirement to build a native chat engine. Join intent/self-attestation is not independently verified WhatsApp membership.
• Mobile-responsive UI: responsive classes/layouts exist; this pass did not perform viewport or accessibility acceptance QA.
• Career placeholder/full content, Job Board and Grants: this pass did not establish dedicated implemented workflows. Keep Hold/v1.1 decisions until their individual acceptance criteria and current brief are reviewed.
• Google SSO, native app-store presence, push notifications, paid membership infrastructure, PWA/offline: preserve existing Out priorities. No proposal to reactivate them follows from this reconciliation.

Exact source paths, source-copy checks and a row-by-row evidence matrix are recorded in /Users/jcornetta/Workspace Migration/2026-09-23/IPN-TECH-RESTRICTED-RECONCILIATION.md. Old workshop dates, effort estimates and the proposed build sequence remain historical planning, not a current delivery schedule.

<aside> 📦

Workshop tool. Every feature/requirement for the IPN Member Portal — now a live database, one page per requirement, each with room for a detailed build spec. Source: the requirements doc (projects/IPN Member Portal/requirements.md) and the Member Experience Workshop output. The Priority property reflects the last Community Task Force session — open any requirement page to flesh out its spec.

</aside>

<aside> 🧭

Build Queue & Self-Assignment. Use the Proposed build sequence (v1.0) list below the database as the dependency-ordered backlog. When either Justin or Luke has spare capacity, claim the next unclaimed item: set Owner (Person) to your name, set Status to In progress, and fill in Start Date — so the other person sees it's taken and we don't double-dip. Mark Status Closed (or Done - Revisit if more iteration is expected) + Completed Date when finished. Use Sub-items to break a requirement into trackable subtasks — expand a parent row in the table to see its children. #13 Mobile-responsive UI is cross-cutting (a quality bar on every UI feature), so it doesn't get its own slot in the sequence.

</aside>

How to use this database

1. Pre-workshop (now): Justin reviews each requirement — sanity-check the proposed Value / Effort.