# Shared Component Ownership

## Objective

Say who maintains each shared component and how changes to it get reviewed.

A recorded owner for every shared component, with review rules that scale to how widely the component is used.

## 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. Split the components into the ones that belong to the design system and the ones that belong to a single product area, and record the split explicitly. Most codebases have a middle tier that everyone edits and nobody maintains, and that tier is where the inconsistencies come from.
2. Attach an owner to each shared component and make the ownership record live next to the code, so it is updated in the same change as the component rather than in a document that goes stale within a quarter.
3. Require review by the owner for any change that alters a component's public shape, its accessibility behaviour, or its default appearance. Internal refactors that leave all three untouched do not need it.
4. Define where an accessibility problem escalates and how quickly. An unlabelled control or a keyboard trap in a shared component is not a normal queue item, and the route to getting it fixed must be written down before it is needed.
5. Do not make ownership a gate with no bypass. Provide a documented path for an urgent production fix that notifies the owner and requires follow-up review, because a rule that blocks incident response gets abandoned entirely the first time it bites.

## 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

- Design-system components and product-area components need different rules, and the boundary between them must be recorded. Treating every shared file identically either slows product work or leaves the system unguarded.
- Changes to a component's public shape, accessibility behaviour, or default appearance need the owner's review, because those are the changes that reach screens the author has never opened.
- Accessibility defects need a named escalation route and a stated response time. Without one they queue behind feature work and stay in a component rendered on every page.
- An urgent production fix must be able to ship without waiting for the owner, provided the owner is notified and the change is reviewed afterwards. Ownership that cannot be bypassed under pressure is ownership that gets deleted.
- An owner who leaves or changes teams must trigger reassignment; an unowned shared component drifts back into the state this feature exists to fix.
- Ownership must be recorded per component or per directory, not per repository, or every change to anything summons the same small group.
- The rules apply to the component's tests and documentation as well as its implementation, or the behaviour stays guarded while its description quietly rots.

## 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

- [ ] Every shared component is classified as design system or product area, and the classification is stored with the code.
- [ ] Each shared component has a recorded owner, and reassignment happens when an owner departs.
- [ ] Changes to public shape, accessibility behaviour, or default appearance require owner review.
- [ ] There is a written escalation route and response expectation for accessibility defects.
- [ ] An urgent fix can ship without the owner present, with notification and follow-up review required.
- [ ] Ownership records cover a component's tests and documentation as well as its implementation.
- [ ] 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.