# Scheduling Interface Pattern Migration

Scheduling implements the platform interface pattern language on its owned
surfaces without importing optional module internals.

## Surface Map

| Surface | Pattern | Consequential actions | Help context |
| --- | --- | --- | --- |
| `/scheduling` request list and detail | Persistent list-detail workspace with a lifecycle rail | Open, close, remind, decide, create holds, create final event | `scheduling.list`, `scheduling.request` |
| `/scheduling` create/edit | Bounded editor with unsaved-change guard and typed Core controls | Save or discard a request definition | `scheduling.editor` |
| `/scheduling/public/:requestId/:token` | Privacy-bounded public participation form | Submit or replace the invited participant's response | `scheduling.public-participation` |
| `scheduling.widget.open-requests` | Compact dashboard contribution | Navigate to the selected request | `scheduling.request` |

## Interaction Contract

- Closing a poll, creating reminder jobs or Calendar objects, and deciding a
  final slot require a shared confirmation dialog. Invitation-link revocation
  uses the same component with danger emphasis.
- Disabled actions expose the active busy, permission, immutable-response, or
  optional-capability reason through Core's action-tooltip and blocker
  components.
- Calendar selection uses the optional `calendar.picker` UI capability and
  bounded Calendar scopes. Scheduling never imports Calendar WebUI code.
- Participant selection uses Core's provider-backed `PeoplePicker`; public
  participation receives only the privacy-bounded request projection.
- Stable documentation topics are available from the list, editor, detail,
  public participation page, and dashboard widget. Core resolves them through
  Docs when enabled and through hosted documentation otherwise.

## Verification

Run:

```bash
cd webui
npm run test:view-model
npm run test:ui-structure
```

The structural check guards shared components, optional-module boundaries,
confirmation gates, contextual documentation, public credential controls, and
request-specific widget navigation. Backend tests validate manifest metadata,
permission boundaries, lifecycle transitions, public participation, and
Calendar capability behavior.