Service progression module — JetSetGo MCP reference

The serviceprogression module defines reusable lifecycle-step templates — called profiles — that describe how a scheduled service moves through its operational stages (for example checked-in → boarding → boarded → departed). Each profile owns an ordered set of named steps plus a set of assigned departure fields: custom fields whose data is captured at the profile's single departure step. Profiles are attached to resources, and check-in/operations tooling then drives each day's services through the attached profile's steps.

What the operator uses it for

Operators model the operational stage flow that suits a class of operating asset: they create profiles, add and rename steps, order them, mark exactly one step as the departure step, and assign custom data-capture fields to that step. A typical profile reads checked-in → boarded → departed, with passenger counts or similar values captured on the departure step.

The module deliberately does not attach profiles to resources. That link lives on the resource record and is written by the resources module; this module only reports how many resources use a profile ("used by N resources") and uses that as its delete guard.

Where it sits

Upstream, the customfields module supplies the pool of eligible departure fields (custom fields associated with service departures); a profile assigns a subset of them. Downstream, resources carry the profile reference written elsewhere, and day-of-service operations consume the resolved step sequence at runtime.

Key concepts

Profile — a named lifecycle-step template; the unit operators create, rename, and delete.
Step — one stage in a profile: name, sort_key ordering (spaced by 10), optional icon slug, and the is_departure_step flag.
Departure step — the single step per profile flagged as the point where departure-time data is captured.
Departure field — a custom field assigned to a profile and captured on its departure step; assigning creates a link row, never a new field.
Delete guard — a profile still referenced by any resource cannot be deleted.
Probe-gated enrichment — cross-module names (resource names, custom-field names) appear in reads only where the tenant tracks those relationships; otherwise ids only.

Tools

Tool	Class	Purpose
`serviceprogression_profiles_list`	Read	List profiles with ordered steps, step count, and resource usage where tracked.
`serviceprogression_profile_get`	Read	Fetch one profile: ordered steps, assigned departure fields, using resources.
`serviceprogression_departure_fields_list`	Read	List eligible departure fields (active, service-departure association).
`serviceprogression_profile_create`	Guarded write	Create a profile by name.
`serviceprogression_profile_update`	Guarded write	Rename a profile.
`serviceprogression_profile_delete`	Guarded write (destructive)	Hard-delete a profile; blocked while any resource uses it.
`serviceprogression_step_create`	Guarded write	Add a step; appends at max sort key + 10 unless positioned.
`serviceprogression_step_update`	Guarded write	Update name / departure flag / icon on any subset.
`serviceprogression_step_delete`	Guarded write (destructive)	Hard-delete a step; warns when deleting a departure step with assigned fields.
`serviceprogression_steps_reorder`	Guarded write	Recompute sort keys to (index+1)×10 from a full ordered id list.
`serviceprogression_departure_field_assign`	Guarded write	Link an eligible custom field to a profile.
`serviceprogression_departure_field_remove`	Guarded write (destructive)	Delete a profile↔field link row (the field itself is untouched).

Rules worth knowing

One departure step per profile, enforced in the module rather than the database. Setting the flag on a new or existing step first unsets the incumbent, then sets the new step; the preview honestly names both ("X becomes the departure step, replacing Y").
Resource-usage delete guard. Deleting a profile referenced by any resource fails at preview with the resource names listed, so reassignment happens before deletion.
Reorder requires an exact permutation. serviceprogression_steps_reorder rejects partial, extra, or duplicated id lists and recomputes every sort key as (index+1)×10.
Sort-key spacing. New steps append at (highest existing sort key)+10; gaps are intentional so future inserts rarely require renumbering.
Icons are lowercase slugs. Inputs are trimmed and lowercased; null clears the icon; omitting it on update leaves it untouched.
Step-set drift detection. Every step write fingerprints the profile's whole step set, so a concurrent departure-flag or ordering change forces a re-preview instead of silently overwriting.
Assignment integrity. Assigning a field already linked to the profile fails at preview and re-checks at confirm; removing an assignment deletes only the link row, never the underlying custom field.
Deleting the departure step is allowed but warned. If the profile has assigned departure fields, the preview states that those fields lose their capture step.

Resources — writes the profile-to-resource attachment this module treats as read-only.
Schedule — the services whose day-of-service flow these profiles describe.