Files
stack/docs/fleet/migration/legacy-class-aliases.md
Jarvis 01202767df feat(fleet): add shared role semantics
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 16:46:38 -05:00

2.5 KiB

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.