# Legacy vs new Figma: functionality and coexistence

This compares the user-facing legacy UI inventory with the two project-linked Figma files, treating the repositories as one application rather than separate products to count. It accounts for **273 legacy capability records**, **90 design-outcome records**, **32 named Figma pages**, and **702 action/access records**: 535 legacy and 167 designed actions. These are research-record counts, not unique-feature counts or a migration-completion percentage.

**Attendance is an explicit legacy handoff in the designs.** The portal’s Resources and Study pages are explicitly **not M1**. Other legacy-only workflows need a keep/rebuild/retire decision; a gap does not automatically require a permanent link.

## Venn view

**[Open the large, interactive Venn explorer](venn-explorer.html)** · [Download the large SVG](venn-large.svg)

The explorer opens directly in a browser, without a server. Click an area to inspect capability records, CRUD/named actions, qualified roles, source evidence and handoffs. Use **Browse all records** for the complete inventory, search and source/status filters; inactive legacy UI is an explicit opt-in. Diagram areas are navigational groups, not proportional feature counts. The separate decision band preserves policy/ownership uncertainty, and **M1 exclusions** shows phase constraints.

![Legacy-only, shared and new-only user outcomes](venn.svg)

The diagram summarizes outcome families and designed deltas, not entire screens or record counts. A bundled record can overlap legacy and contain a new interaction: unified search adds cross-object results, not the first ability to find people, groups or locations. Profile attachment upload does not replace existing legal/compliance form processing. LMDS documents and historical report parity remain unresolved, outside the exclusive sets.

The record-level decisions and checked legacy counterparts are in [comparison.json](comparison.json). New-only delta evidence: [ND-001 / NW-004](FIGMA-APP-MAP.md#nw-004), [ND-002 / NP-005](FIGMA-APP-MAP.md#np-005) and [NP-012](FIGMA-APP-MAP.md#np-012), [ND-004 / NW-008](FIGMA-APP-MAP.md#nw-008).

## Where users cross systems

[HANDOFFS.md](HANDOFFS.md) maps **25 workflow boundaries**, with entry locations, source-backed legacy route patterns, exact legacy action-rule IDs, audience/context requirements and return-flow risks. [handoffs.csv](handoffs.csv) is the filterable version. These are recommendations and design requirements, **not implemented links**.

| New entry / situation | Existing destination or decision | Evidence / boundary |
| --- | --- | --- |
| Calendar meeting details or Classroom Attendance | Legacy attendance; resolve the canonical product, group and editable meeting/date | [H01](HANDOFFS.md#h01), [NW-009](FIGMA-APP-MAP.md#nw-009), [NG-006](FIGMA-APP-MAP.md#ng-006) |
| Resources and portal Study during M1 | Choose legacy continuity or a separately confirmed delivered replacement; the companion Web Study file does not establish its release phase | [H04](HANDOFFS.md#h04), [H05](HANDOFFS.md#h05) |
| Finance, Reports, publishing, registration, applications and specialist tools | Retain a legacy bridge if the workflow remains supported and no delivered replacement owns it | [Boundary registry](HANDOFFS.md#boundaries) |
| Supported personnel or church/location changes from relevant settings | Decide whether authorized direct editing replaces the old request process; do not assume a submitted request is an applied change | [H23](HANDOFFS.md#h23) |
| Location Documents | Design names LMDS as the document destination; establish its existing capability, access and ownership before calling this new-only | [H20](HANDOFFS.md#h20), [NG-012](FIGMA-APP-MAP.md#ng-012) |
| Legacy users need an evidenced new-only delta | Conditional reverse links to new search, person attachments or group fellowships, only after actual delivery and independent authorization | [H18](HANDOFFS.md#h18), [H19](HANDOFFS.md#h19), [H21](HANDOFFS.md#h21) |

**Link contract:** no production origin, greenfield runtime route or generic `returnUrl` was established. “Online” meeting format is not BSF Online product identity. Map canonical person/child/class/group/study/meeting/location identities; a meeting’s `classLocationId` is not the shared `locationId`. Re-authorize at the destination. Prefer a separate tab until a supported return contract exists, then revalidate context and refresh state; tabs do not guarantee session isolation. New-only fellowships/group-date overrides may have no legacy attendance meeting.

## Files

| Artifact | Use |
| --- | --- |
| [venn-explorer.html](venn-explorer.html) | Large, zoomable Venn with clickable areas and searchable capability/action/role/evidence/handoff drill-downs; self-contained offline snapshot |
| [venn-large.svg](venn-large.svg) | Matching 1800 × 1600 vector overview for sharing or printing |
| [FIGMA-APP-MAP.md](FIGMA-APP-MAP.md) | Unified new-design inventory by application area, with actions, audiences, scope, phase and Figma evidence |
| [legacy-crosswalk.csv](legacy-crosswalk.csv) | Every legacy record, its classification, new counterparts, action IDs and handoff references |
| [new-crosswalk.csv](new-crosswalk.csv) | Every new-design record, its legacy counterparts, phase and classification |
| [actions-and-access.csv](actions-and-access.csv) | Both sides’ CRUD and named actions, qualified actor evidence, scope, conditions and source URLs |
| [design-coverage.csv](design-coverage.csv) | All named pages, recorded visual/census coverage and remaining limits |
| [HANDOFFS.md](HANDOFFS.md) / [handoffs.csv](handoffs.csv) | Workflow boundaries and executable-link prerequisites |
| [figma-catalog.json](figma-catalog.json) | Canonical design observations, evidence, page coverage and source metadata |
| [comparison.json](comparison.json) | Canonical curated classifications, accepted/rejected matches, deltas, policy gaps and handoffs |
| [venn.svg](venn.svg) | Theme-aware vector diagram; browser-rendered and geometry checked |
| [validation.json](validation.json) | Executed integrity/smoke checks and explicitly unverified surfaces |

CSV and Markdown are exports. The JSON observations and curated comparison are the canonical research data. The unchanged [legacy catalog](../legacy-ui/catalog.json) and [legacy app map](../legacy-ui/APP-MAP.md) remain the detailed legacy baseline.

<a id="scope-and-access-semantics"></a>
## Scope and access semantics

- **Shared:** comparable user outcome on both sides, not automatic field, action, role, data or release parity. Classification is asymmetric: legacy lecture playback/download can be shared while the bundled new lesson menu is partial because print/share is not resolved.
- **Partial:** related functionality exists, but meaningful actions, states, audience or scope are not established as equivalent. Do not remove a legacy bridge solely because a partial row exists.
- **Legacy-only:** no equivalent functional design evidenced in the reviewed scope. This is not proof of absence in unreviewed external systems and is not a decision to retain the workflow.
- **New-only:** a designed outcome/delta with no available equivalent evidenced in the reviewed legacy front end. The claim is scoped to that outcome, not a whole page or all external/backend functionality.
- **Unresolved:** insufficient evidence, not absence or denial. This includes named external owners, ambiguous identity/scope and unread variants.
- **Inactive legacy:** disabled/stub or explicitly no-longer-in-use records. These do not generate working continuity requirements. The unavailable location-delete handler is also excluded at action level.

The legacy-side record classifications are:

| Classification | Records |
| --- | ---: |
| Shared | 10 |
| Partial | 74 |
| Legacy-only | 153 |
| Unresolved | 18 |
| Inactive legacy | 18 |

Legacy wizard stages and presentation variants are separate records; the new designs often bundle them. Do not compare these numbers with Figma frame counts or interpret them as feature coverage percentages.

**Access:** legacy actor selectors must be read with action scope, state, add-ons and conditions. They are not an automatic OR grant; authenticated-surface evidence does not mean every signed-in user can mutate. New annotations/frame variants describe design intent only. A target person’s Role column or an example footer is not the viewer’s permission. Formal new-policy and backend-grant parity were not established.

In the action CSV, `included_as_active_legacy_source` means the action is not recorded as disabled/stub/no-longer-used in the reviewed source. It does not prove production reachability; conditional host/data/identity limitations still apply. Named actions such as assign, move, submit, approve, verify, upload and request-deletion are preserved rather than forced into misleading CRUD letters.

## Policy and parity decisions before cutover

| Topic | Unresolved contract |
| --- | --- |
| Risk flags | Legacy is explicitly HQRM (position 94), non-self. New Add says HQ; Edit/Remove audiences are unspecified. Do not translate HQ into a grant. |
| Primary/service/jurisdiction roles | Preserve eligible-role catalogs, pending-role/date restrictions and class/area/region scope; new role labels/scheduling are not a permission matrix. |
| Accounts and deletion | Local MemberSupport IdentityUser, staff business-person recovery/PII operations and new deletion requests are different scopes. Login/recovery provider and deletion target remain unresolved. |
| Role versus group context | Static role artboards and Web Study group selection do not establish effective-role switching, impersonation or the relationship to portal-managed groups. |
| Calendar and attendance | Decide canonical product/group/meeting/location mapping and date ownership before routing new group-calendar events into old attendance. |
| External documents and historical data | Inspect LMDS and runtime legacy report/embedded-dashboard contents before declaring novelty or retiring routes. |

Exact source IDs and decisions are in `comparison.json` under `policy_gaps`; the full action conditions are in the access CSV.

## Design sources and limits

The project’s [PR discussion](https://github.com/BSFTech/mybsf/pull/10#issuecomment-5939592418) links these files and also raises the unresolved relationship between their group experiences:

- [myBSF Handoff](https://www.figma.com/design/h11tulxABPfJVtrbMJX1oC/myBSF-Handoff?node-id=9-3): portal, people, classes/groups, locations, hierarchy, calendar, profile and future resources/study.
- [BSF Web Study Handoff](https://www.figma.com/design/IssfNohi5PuSlYFIjPS03J/BSF-Web-Study-Handoff?node-id=2-30): participant lesson-study, archive, navigation, login and profile.

“All pages” here means the 32 named pages in those two project-linked files, including two nonfunctional covers and a duplicate-prototype page. This is not a claim to have enumerated a private Figma organization. Links identify observed live nodes, not immutable Figma versions; capture/source metadata is retained in the catalog. Session-local screenshot paths, where present, are diagnostics rather than portable attachments.

Role variants, class-creation steps and class-area move confirmation were reviewed. **Full visual review is not claimed:** All Classes and Class Detail retain partial flags for some empty/no-result, small-label/HQ-note and move-result details. Account-deletion modal copy/scope and some destination interiors remain unresolved. Page/frame limits are preserved in the coverage CSV; unverified details were not converted into exclusive-set gaps.

No greenfield implementation, deployed link, authenticated production legacy session, SSO return flow or backend authorization was tested. This is a design-versus-legacy UI comparison, not a shipped-functionality audit. See `validation.json` for the integrity and browser-render checks actually executed.