# Legacy Fleet Class Aliases

Fleet class compatibility is intentionally narrow. The shared resolver accepts exactly three legacy
class names and converts them to canonical classes before persona lookup:

| Legacy value           | Canonical value | Migration action                                                                                                       |
| ---------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `implementer`          | `code`          | Replace class and tool-policy references with `code`.                                                                  |
| `reviewer`             | `review`        | Replace class and tool-policy references with `review`.                                                                |
| `operator-interaction` | `interaction`   | Replace class and roster-v2 tool-policy references with `interaction`. The legacy service artifact remains compatible. |

Alias support preserves existing inputs while provisioning and typed semantic output use canonical
identities. Requested and canonical class values remain separately observable during semantic
validation.

## Lookup and override behavior

Canonicalization precedes baseline and `roles.local` lookup. A legacy-named override such as
`roles.local/implementer.md` is not a separate authority and is not selected for an `implementer`
request. Customize the canonical role instead, for example `roles.local/code.md`.

The compatibility file `operator-interaction.md` remains shipped, but `interaction` is the canonical
role class. Tess is an example display name only.

## Unresolved and custom classes

No names are inferred from historical usage, instance names, or similar wording. `worker`, `analyst`,
`canary`, Tess, and Ultron are not aliases. An otherwise unknown class is accepted only if the shared
resolver can read an actual baseline or `roles.local` contract for that exact class. A `LIBRARY.md`
row without a readable contract fails semantic validation.

Custom classes receive no protected authority implicitly. Protected class/tool-policy mismatches
fail closed.

## Retirement guidance

New configuration should emit canonical values. Existing inputs may use the three aliases during the
compatibility period, but operators should migrate class and tool-policy fields together. Do not
create new legacy-named role overrides; move their intended content to the canonical filename and
validate the roster/profile before removing the old artifact.