# Digital Business Card

## Objective

Give every member a shareable card page with their photo, links, and save-to-contacts.

A per-member public card page with photo, role, links, and a download that imports into a phone's contacts.

## Before You Begin

This feature is being added to an application that already exists and already
works. Do not scaffold a new project, and do not assume a blank slate.

Inspect the codebase first and establish:

- The existing application structure and where code of this kind already lives.
- The framework and version in use.
- The existing design system — colours, spacing, typography, and component conventions.
- Existing UI components you can reuse instead of writing new ones.
- The existing database structure, if this feature needs to persist anything.
- The existing authentication and authorization system, if this feature is user-scoped.
- Dependencies already installed, so you don't add a library that duplicates one.
- The existing test setup and conventions.

Only start writing code once you understand the above. If the application
already implements part of this feature, extend it rather than replacing it.

## Implementation Instructions

1. Build this as a presentation of the app's existing Public Profile Pages, not a second profile. One record, two layouts. A member who updates their title should not have to update it twice.
2. Take the photo from Avatar Upload rather than adding a new image field, and reuse the crop and compression the app already applies so a card photo is not a full-resolution original served to every visitor.
3. Give each card a save-to-contacts download containing the fields the member has chosen to publish, and nothing else. Everything on the card and nothing beyond it.
4. Let the member decide field by field what appears publicly, and default to showing very little. A card is a public page indexed by search engines, and people will put a personal phone number on it without thinking about that.
5. Do not build a card designer. Ship one well-made layout that adapts to how much detail a member has filled in, and reuse the app's Social Sharing for the preview image rather than adding a separate one.

## UI and UX Requirements

Match the application's existing design system exactly. Reuse its components,
spacing, and typography. This feature should look like it was always there.

## Responsive Requirements

Works on mobile, tablet, and desktop. Touch targets are large enough to hit on a
phone, and nothing overflows horizontally at 320px.

## Accessibility Requirements

- Fully keyboard navigable.
- Correct semantic elements and ARIA roles.
- Visible focus states.
- Meets WCAG AA contrast.
- Dynamic changes are announced to screen readers.
- Respects prefers-reduced-motion.

## Edge Cases

- The contact file must import cleanly on both major mobile platforms, which disagree about how names, photos, and multiple links are encoded. Test an actual import on each rather than assuming a well-formed file is enough.
- Many members have no photo, no title, or only one link. The layout must stay balanced when most fields are empty, using initials in place of a photo instead of a broken image or a large blank area.
- Unpublishing a card cannot recall the copies already saved to people's phones. Serve a plain page saying the card is no longer available rather than a 404, and keep the URL stable so an old link explains itself.
- The share preview image is usually seen as a thumbnail in a message. Keep the name legible at that size and do not rely on fine detail, small logos, or low-contrast text that disappears when scaled down.
- Decide what happens when a member leaves the organisation. Silently deleting the card breaks every link they handed out; the safer default is to unpublish and show a neutral message, with the member's personal details removed.
- A public card page is scraped. Do not expose an email address as plain machine-readable text unless the member opted in knowing that, and apply the app's existing Rate Limiting to the contact download.
- A card is opened almost entirely on phones, often on poor connections. It must render usefully before the photo loads and must not depend on a heavy script to show a name and a phone number.
- Links a member adds are user-generated and public. Run them through the same URL validation the app applies elsewhere so a card cannot be used to launder a hostile destination under your domain.

## Testing

Exercise the feature end to end in the running application. Cover every edge case
above, then run the existing test suite and confirm nothing regressed.

## Acceptance Criteria

- [ ] Each member's card renders from the existing profile record with no duplicated fields.
- [ ] The save-to-contacts download imports correctly on both major mobile platforms.
- [ ] Cards with missing photos, titles, or links stay visually balanced.
- [ ] Members control field by field what is published, defaulting to minimal disclosure.
- [ ] An unpublished card serves a stable explanatory page rather than an error.
- [ ] The share preview stays legible at thumbnail size.
- [ ] Departed members' cards follow a defined, documented behaviour.
- [ ] The feature matches the existing design system.
- [ ] No existing functionality is broken.

## Adaptation Rules

- Match the existing design system. Do not introduce a new colour palette,
  spacing scale, or component library.
- Reuse existing components and utilities wherever they fit.
- Follow the naming, file layout, and code style already present.
- Do not upgrade, replace, or remove existing dependencies to make this
  feature fit. Adapt the feature to the app, not the app to the feature.
- Do not break existing functionality. If a change is genuinely required in
  existing code, make the smallest one that works and say so.
- If something in these instructions conflicts with how the application is
  built, follow the application and explain the deviation.

## Final Verification

Before you report the work as done:

1. Re-read the acceptance criteria above and check each one against what you
   actually built.
2. Run the application and exercise the feature end to end.
3. Run the existing test suite and confirm you have broken nothing.
4. Check the feature on mobile, tablet, and desktop widths.
5. Check keyboard navigation and focus handling.
6. Summarize what changed: files added, files modified, and anything you
   deliberately did differently because of how this application is built.

If any acceptance criterion is unmet, fix it before reporting completion.