Metadata-Version: 2.4
Name: automas-script-maafw-pack-m9a
Version: 0.1.6
Summary: M9A project pack declarations for the AUTO-MAS MaaFW plugin
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Requires-Dist: automas-maafw-interface>=0.2.0
Requires-Dist: automas-script-maafw>=0.1.13
Requires-Dist: pydantic>=2

# automas-script-maafw-pack-m9a

M9A project pack declarations for the AUTO-MAS MaaFW plugin.

The package provides `maafw.pack.m9a.v1`. Project sources, controllers,
resources, presets, task names and templates are loaded through the generic
MaaFW project/interface flow.

Version 0.1.6 requires `automas-script-maafw>=0.1.13`, so M9A projects are
routed through the shared multi-ABI MaaFW runtime contract instead of being
resolved against an older host-only Python selector.

The plugin registers `M9A` as a standalone creatable specialized type. It uses
the shared `plugin:automas_script_maafw` editor, declares its own creation-card
description/search keywords, and serves `assets/m9a.png` through `icon_path`.

The service also exposes M9A compatibility fallback metadata for the current
`Psychube`, `Limbo` and `Lucidscape` entries. Runtime task selection continues
to use names resolved from the live `interface.json`.

On the current `dev_v2` host, `ScriptAdapterDefinition` compiles these
declarations into plugin-owned `M9APluginConfig` and
`M9APluginUserConfig` classes. The host persists them through
`PluginScriptConfig.PluginData.Config`; `Notify.CustomWebhooks` remains an
object JSON field and round-trips through the host codec. The plugin does not
register legacy host class aliases or an in-process non-plugin-to-plugin
migrator; any such conversion belongs to a separate external tool.

## Resource management contract

`maafw.pack.m9a.v1` exposes two JSON-only methods for the MaaFW resource
manager:

- `describe_resource(path)` reads the merged ProjectInterface and returns a
  `maafw.resource-profile`. `resourceVersion` always comes from
  `ProjectInterface.version`; the release directory name is deliberately not
  used because an in-place M9A update can leave that name stale.
- `plan_resource_upgrade(old_interface, new_interface, config)` returns a
  `maafw.resource-upgrade-plan` without mutating the source config. Tasks are
  mapped by exact task name first and stable `entry` second. Values not
  representable by the new interface remain in `orphans`, including the full
  original task snapshot.

The resource manager must persist the exact plan and its `orphans` before
replacing the active resource binding. The same planner is invoked separately
for the script record and every user record; the manager owns confirmation,
compare-and-swap checks, rollback and final activation. A plan with
`readyToApply: false` requires the listed `manualActions` (for example choosing
a replacement server resource).
The pack definition advertises `resource_service_key: maafw.pack.m9a.v1` and
`resource_upgrade_mode: plan-only`, so a generic manager can route to this
optional service without importing the M9A package. The planner accepts either
the decoded plugin config or a complete `PluginScriptConfig`; in the latter
case it changes only `PluginData.Config` and preserves host/other-plugin fields
verbatim.
This resource-to-resource upgrade contract does not perform legacy
non-plugin-to-plugin conversion.
