stack/docs/fleet/LEGACY-EXAMPLE-PROFILE-DISPOSITION-INVENTORY.md

Fleet Configuration Management — Legacy Example and Profile Disposition Inventory

Issue: #758 · Baseline: origin/main 49e8a541 · Status: M0 inventory; no source examples or profiles are changed by this document.

The v2 compiler may not silently accept an unresolved class. Before M1 exits, every shipped file below must be either migrated and executable, retained as an explicitly versioned v1 fixture, or retired with a replacement/deprecation note. Class resolution must use the existing profile/persona/provision baseline-plus-roles.local resolver; this inventory does not create a parallel resolver.

Examples

Shipped file	Current class evidence	M0 disposition decision	Required M1/M4 evidence
framework/fleet/examples/coding.yaml	orchestrator, enhancer, implementer, reviewer	Migrate: implementer → code, reviewer → review; retain orchestration/enhancer intent	v2 fixture validates; role aliases and authority matrix tested
framework/fleet/examples/general.yaml	orchestrator, enhancer, worker	Migrate only after operator chooses a concrete canonical role for worker; no implicit conversion	Explicit replacement class, or versioned v1 fixture/retirement note
framework/fleet/examples/hybrid.yaml	orchestrator, enhancer, implementer, researcher, reviewer	Migrate aliases; resolve researcher through existing role resolver or retain/version	Shared resolver validation; no ad-hoc class scanner
framework/fleet/examples/local-canary.yaml	orchestrator, implementer, reviewer	Migrate aliases; preserve its local-tmux canary purpose	v2 fixture validates and preserves safe stopped/running behavior
framework/fleet/examples/minimal.yaml	canary	Retire or version as v1 unless an existing canonical role contract is selected deliberately	Replacement link/deprecation note or CI-valid v1 fixture
framework/fleet/examples/operator-interaction.yaml	operator-interaction	Migrate alias to interaction; preserve instance/display name as configuration, not schema identity	v2 interaction fixture validates; no Tess literal is required
framework/fleet/examples/research.yaml	orchestrator, enhancer, researcher, analyst	Resolve researcher/analyst through baseline + roles.local, or version/retire	Resolver evidence and explicit disposition for each unresolved class

Profiles

Shipped file	Current class evidence	M0 disposition decision	Required M1/M4 evidence
framework/fleet/profiles/business.yaml	ceo, coo, cfo, product-manager, marketing-lead, sales-lead, operations-manager, customer-success-manager, code, review	Retain only if every class resolves through the existing role library/roles.local; otherwise version/retire rather than weakening validation	Shared resolver CI result for every class; documented role source or replacement
framework/fleet/profiles/marketing.yaml	marketing-lead, content-strategist, copywriter, seo-specialist, social-media-manager, brand-strategist, growth-marketer, ux-designer	Same resolver-or-version/retire rule	Per-class resolver CI result and replacement/deprecation record if unresolved
framework/fleet/profiles/personal-assistant.yaml	personal-assistant, executive-assistant, scheduler, inbox-manager, researcher	Same resolver-or-version/retire rule	Per-class resolver CI result; do not infer interaction equivalence
framework/fleet/profiles/research.yaml	lead-researcher, researcher, data-analyst, data-scientist, market-analyst, documentation, review	Same resolver-or-version/retire rule	Per-class resolver CI result and explicit compatibility posture
framework/fleet/profiles/software-delivery.yaml	orchestrator, board, planner, decomposition, code, review, security-review, site-tester, documentation, merge-gate, rebase, operator, session-review, enhancer	Retain as the governance reference; add validator, team-leader, and interaction only through approved role/profile work, not silent substitution	CI validates all current classes; separate fixture proves required M1 authority seats

Required disposition controls

1. No silent aliasing: only implementer → code, reviewer → review, and operator-interaction → interaction are approved deterministic aliases in this M0 baseline. worker, analyst, canary, and domain-specific classes require resolver evidence or an explicit version/retirement decision.
2. No identity hardcoding: Tess and Ultron are optional instance/display names. An example/profile may demonstrate the capability but must not make a product name a required class or machine ID.
3. No lifecycle inference from an example: examples describe desired configuration only; migration of an installed v1 roster separately preserves observed stopped/running state.
4. No secret or command migration: examples/profiles must not introduce credential values or MOSAIC_AGENT_COMMAND; those legacy keys are M2 quarantine inputs, never v2 authoring fields.
5. Evidence is executable: M1/M4 CI must enumerate these exact files, validate retained/migrated inputs through the shared resolver, and fail if a file lacks its documented disposition.