Files
stack/docs/tasks/758-legacy-example-profile-disposition.md
Jarvis 1c3f28ae5a
All checks were successful
ci/woodpecker/pr/ci Pipeline was successful
docs(fleet): define declarative config requirements
Refs #758
2026-07-14 14:21:20 -05:00

8.2 KiB

#758 Legacy shipped example and profile disposition inventory

Baseline: origin/main at M0 planning time. This inventory is normative input to M1; M0 changes no examples or profiles.

Allowed dispositions

  1. Migrate: rewrite as v2 and validate with the executable schema plus the existing baseline/roles.local resolver.
  2. Compatibility fixture: retain as explicitly versioned v1 input for migration tests; it must not be advertised as current authoring guidance.
  3. Retire: remove only in its own implementation PR with a replacement and deprecation note.

No item may remain decision-required when M1 exits.

Fleet examples

Shipped path M0 observed concern Planned disposition Target card Required evidence
packages/mosaic/framework/fleet/examples/minimal.yaml Uses unresolved legacy canary; v1 field form also requires migration decision-required: map through existing resolver, retain as compatibility fixture, or retire with replacement FCM-M1-04 Explicit M1 disposition plus v2 schema/shared-resolver CI
packages/mosaic/framework/fleet/examples/coding.yaml Legacy implementer/reviewer aliases may be present migrate; preserve alias cases separately in migration fixtures FCM-M1-04 Alias conversion and current v2 validation
packages/mosaic/framework/fleet/examples/general.yaml Legacy/general classes require authority review migrate or retire unsupported roles with replacement FCM-M1-04 No unresolved class
packages/mosaic/framework/fleet/examples/hybrid.yaml Mixed runtime/provider capability combinations migrate FCM-M1-04 Runtime-capability and resolver validation
packages/mosaic/framework/fleet/examples/local-canary.yaml Local lifecycle and socket semantics migrate FCM-M1-04 Default/named socket and stopped-state fixtures
packages/mosaic/framework/fleet/examples/operator-interaction.yaml operator-interaction becomes interaction; Tess remains instance data migrate FCM-M1-04 Alias test and interaction role resolution
packages/mosaic/framework/fleet/examples/research.yaml Legacy analyst may lack canonical contract decision-required: map through existing resolver or retire FCM-M1-04 Explicit M1 disposition; no silent alias

System-type profiles

Shipped path M0 observed concern Planned disposition Target card Required evidence
packages/mosaic/framework/fleet/profiles/software-delivery.yaml Must represent required governance seats or explicit waivers migrate FCM-M1-04 Full-profile topology validation
packages/mosaic/framework/fleet/profiles/business.yaml Classes must resolve through shared resolver migrate or document waived-class policy FCM-M1-04 Profile validation parity
packages/mosaic/framework/fleet/profiles/marketing.yaml Classes must resolve through shared resolver migrate or document waived-class policy FCM-M1-04 Profile validation parity
packages/mosaic/framework/fleet/profiles/personal-assistant.yaml Interaction/orchestration authority must remain bounded migrate FCM-M1-04 Authority and topology tests
packages/mosaic/framework/fleet/profiles/research.yaml Potential legacy analyst/worker class ambiguity decision-required: resolved local role or retirement FCM-M1-04 Explicit M1 disposition; no unresolved class

Shipped fleet service presets

Shipped path M0 observed concern Planned disposition Target card Required evidence
packages/mosaic/framework/fleet/services/operator-interaction.yaml Uses legacy operator-interaction class/tool policy and launch hints; it participates in the interaction/Tess launch contract even though it is not an example/profile migrate to canonical interaction through the shared resolver, preserving Tess as instance data; retain legacy alias coverage in a dedicated compatibility fixture FCM-M1-04 v2 schema, shared resolver, runtime-capability, tool-policy, and alias tests

No other shipped file currently exists under packages/mosaic/framework/fleet/services/. Future service presets added before FCM-M1-04 must be inventoried under the same migrate/compatibility/retire rule.

Required compatibility fixtures

M1/M4 may add dedicated test fixtures rather than retaining public examples in an obsolete form:

  • v1 snake_case and camelCase equivalents;
  • deterministic implementer → code, reviewer → review, and operator-interaction → interaction aliases;
  • ambiguous worker, analyst, canary, and unknown classes that fail pending explicit resolution;
  • schema-only host, ssh, socket, and top-level connector fields reported as unsupported for local v2 apply;
  • the observed 9-roster/12-projection mismatch represented synthetically, with three unmanaged/orphan candidates;
  • running, stopped/dead, and unknown observed-state migration cases;
  • legacy generated, allowlisted local, forbidden command/channel/credential, and unknown env keys using names and synthetic hashes only—never values.

Exit rule

FCM-M1-04 cannot close until every inventoried example, profile, and service preset is migrated, retained as a versioned compatibility fixture, or retired with documented replacement evidence. CI must validate all shipped YAML/JSON examples, profiles, and service presets through the same executable schema and shared profile/persona resolver used by roster load, migration, and apply.