Files
stack/docs/fleet/migration/example-profile-disposition.md
Jarvis dcb3f5a2ca
All checks were successful
ci/woodpecker/pr/ci Pipeline was successful
test(fleet): validate shipped artifact dispositions
2026-07-14 20:24:50 -05:00

4.8 KiB

Executable Fleet Example, Profile, and Service-Preset Dispositions

Issue: #758 · Card: FCM-M1-003 · Status: M1 executable disposition evidence

This document records the executable disposition for every currently shipped fleet YAML artifact. The authoritative baseline classification remains the legacy inventory. The executable guard is packages/mosaic/src/fleet/example-profile-dispositions.ts; its test fails if a shipped YAML artifact is added, removed, or left without one of the dispositions below.

Disposition rules

  • Explicit v1 fixture: the artifact is loaded through the existing v1 roster parser and must declare version: 1. It remains a compatibility fixture; it is not silently treated as a v2 roster or given inferred aliases.
  • Canonical profile: the artifact is loaded through loadProfiles, which uses the shared baseline-plus-roles.local persona resolver and rejects unreadable or unresolved classes.
  • Canonical service policy: the artifact is loaded through the operator-interaction service policy reader and provisioned with a generic supplied identity. It validates its runtime, model, reasoning, and legacy tool-policy compatibility without hardcoding a product identity.

No artifact is retired in this card. A later retirement requires both a replacement link and a visible deprecation note; the executable guard must then record the new disposition before the artifact can be removed.

Shipped artifacts

Artifact Disposition Executable path Compatibility notes
examples/coding.yaml Explicit v1 fixture v1 roster parser Retains approved implementer and reviewer compatibility inputs.
examples/general.yaml Explicit v1 fixture v1 roster parser Retains unresolved worker without an inferred canonical role.
examples/hybrid.yaml Explicit v1 fixture v1 roster parser Retains implementer, reviewer, and resolver-dependent researcher.
examples/local-canary.yaml Explicit v1 fixture v1 roster parser Retains the local-tmux canary topology.
examples/minimal.yaml Explicit v1 fixture v1 roster parser Retains canary without an inferred canonical role.
examples/operator-interaction.yaml Explicit v1 fixture v1 roster parser Keeps Tess only as an example instance name; operator-interaction remains compatibility input.
examples/research.yaml Explicit v1 fixture v1 roster parser Retains resolver-dependent researcher and analyst.
profiles/business.yaml Canonical profile shared profile/persona resolver Every referenced business class must resolve to a readable contract.
profiles/marketing.yaml Canonical profile shared profile/persona resolver Every referenced marketing class must resolve to a readable contract.
profiles/personal-assistant.yaml Canonical profile shared profile/persona resolver No interaction equivalence is inferred.
profiles/research.yaml Canonical profile shared profile/persona resolver Every research class must resolve to a readable contract.
profiles/software-delivery.yaml Canonical profile shared profile/persona resolver Retains the governance profile; authority validation remains FCM-M1-002 evidence.
services/operator-interaction.yaml Canonical service policy service-policy reader/provisioner Generic provisioning supplies the instance name; the policy itself never names Tess.

Running the guard

pnpm --filter @mosaicstack/mosaic test -- example-profile-dispositions.spec.ts

The guard is intentionally limited to shipped assets and validation. It does not generate environment files, mutate a roster, reconcile a fleet, migrate an installed roster, or launch an agent.