Mas Plan Schedule

MAS Plan Schedule

Objective

Keep AUTO-MAS plan schedules easy to extend without turning them into a generic field engine. Each schedule type owns its data model, config class, table UI, and user consumption path. Shared code should only cover type registration, API dispatch, list selection, and CRUD orchestration.

Current Architecture

Backend has one shared multi-config collection and one lightweight registration table.

1. app/models/schema.py Defines API-facing schedule schemas and shared aliases: WeeklyPlanConfig, PlanConfigType, PlanCreateType, PlanConfigData, PlanComboxConsumer.
2. app/models/config.py Defines concrete ConfigBase schedule classes such as MaaPlanConfig and MaaEndPlanConfig. Registers them in PLAN_BOOK.
3. app/core/config.py Uses PLAN_BOOK to create plans, delete referenced plans, filter combobox options by consumer, and wire GlobalConfig.PlanConfig.
4. app/api/plan.py Uses schema models plus PLAN_BOOK for plan CRUD serialization.
5. app/api/info.py Exposes consumer-specific plan combobox routes through PlanComboxIn.consumer.

Frontend has one runtime descriptor registry and separate table implementations.

1. frontend/src/utils/planTypeRegistry.ts Owns runtime plan descriptors: config type, create type, label, default name, selector tag, reload behavior, and table component.
2. frontend/src/views/plan/index.vue Orchestrates plan list state, current plan selection, CRUD calls, name editing, and table dispatch.
3. frontend/src/views/plan/tables/*.vue Owns concrete table UI and per-type field behavior.
4. frontend/src/composables/usePlanApi.ts Wraps plan API calls. Do not duplicate generated OpenAPI models here.
5. frontend/src/utils/planNameUtils.ts Reads the registry for labels/default names.

Where Things Belong

Use types/ for type-only shapes that are not already exported by OpenAPI. Use utils/ or a feature folder for runtime registries, constants, validators, and label maps.

planTypeRegistry.ts is runtime code because it imports Vue defineAsyncComponent and generated API enum values. Do not move it into types/ unless it is split into a type-only file and a runtime registry file.

Do not put plan schedule types in frontend/src/types/script.ts. Script types and schedule types are separate domains.

Adding A New Schedule Type

Follow this order.

1. Add backend config class Create a concrete ConfigBase plan class in app/models/config.py. Add ConfigItem fields before super().__init__(). Reuse WeeklyPlanConfig only if the new type has the same Info + ALL + weekdays shape.
2. Add backend schema Create the matching Pydantic schema item/info classes in app/models/schema.py. Extend all four aliases: PlanConfigType, PlanCreateType, PlanConfigData, and PlanComboxConsumer. Keep model_config = ConfigDict(extra="forbid") on schedule config models.
3. Add the consumer constant Append the new consumer string to PLAN_CONSUMER_VALUES in app/utils/constants.py. PLAN_BOOK does not hold consumer literals directly; it indexes this tuple (PLAN_CONSUMER_VALUES[0], [1], ...), so a new type has nothing to reference until the tuple grows. This tuple and the PlanComboxConsumer literal in app/models/schema.py are two independent hardcoded lists of the same values with no generated link. Update both, and keep them in the same order — existing PLAN_BOOK entries reference the tuple positionally, so inserting rather than appending silently repoints existing plan types at the wrong consumer.
4. Register in PLAN_BOOK Add create_type, config_class, schema_class, consumer, script_class, and field_name. This is the backend source of truth for plan CRUD, deletion reference cleanup, and combobox filtering.
5. Wire the user consumer Add or extend the user config field that stores the selected plan ID. Use type-specific validation or runtime type checks before dereferencing the plan as a concrete class. When deleting a plan, field_name should be reset only for the bound consumer type.
6. Add frontend descriptor Register the type in frontend/src/utils/planTypeRegistry.ts. Use generated OpenAPI enum values from @/api. Point tableComponent to the type-specific table component.
7. Add frontend table Create a dedicated table component under frontend/src/views/plan/tables/. Keep per-type field logic in the table or a type-specific utility/composable. Do not build a generic field renderer unless multiple real schedule types share the same behavior.
8. Regenerate OpenAPI client Never edit generated files under frontend/src/api/ by hand. Ask the developer to run the project API generation command after backend schema changes. Frontend plan types derive from generated OpenAPI (PlanIndexItem.type, PlanCreateIn.type), so the registry cannot see a new type until regeneration runs.