Release v0.1.7

docs/MODULE_ARCHITECTURE.md

@@ -458,6 +458,17 @@ routers and live module activation fail fast if two routers register the same
 HTTP method and path. That keeps OpenAPI output and FastAPI route order from
 silently masking a module collision.
 
+Tenant deletion and cleanup use the registry-owned delete-veto contract. A
+module that owns tenant-bound data may declare `delete_veto_providers` on its
+manifest for resource types such as `tenant` or `group`. Providers receive
+`(session, tenant_id, resource_id)` and should return `DeleteVetoIssue`, an
+iterable of `DeleteVetoIssue`, or `None`; older exception-based providers are
+still treated as blocking vetoes. Core attributes each issue to the provider
+module and adds resource context before the tenancy module exposes the issues
+through the deletion plan. `blocker` issues prevent destructive or retire
+operations, `warning` issues explain retained data, and `info` issues document
+non-blocking lifecycle facts.
+
 ## Database And Migrations
 
 Core owns the database/session lifecycle. Modules access the database through core session dependencies and register their models/migrations through their manifest.
@@ -492,13 +503,34 @@ against the configured offline license before adding the entry to the install
 plan. Catalog entries may also declare `migration_safety` as `automatic`,
 `requires_review`, `forward_only`, or `destructive`; forward-only and
 destructive entries require explicit operator acknowledgement in the install
-plan before installer preflight allows activation.
+plan before installer preflight allows activation. Forward-only and destructive
+catalog entries must also declare a tested recovery path. Catalog update entries
+can define direct-update windows with `current_version_min` and
+`current_version_max_exclusive`, mark intermediate `bridge_release` targets, and
+explicitly opt into reviewed downgrade or same-version package-refresh plans.
+Module migration order can be declared with `migration_after` and
+`migration_before` in manifests or release catalogs; installer preflight turns
+that metadata, module dependencies, and named interface relationships into an
+ordered migration plan.
+
+Modules that need live-data work outside Alembic schema revisions may declare
+`migration_tasks` on `MigrationSpec`. This is deliberately narrower than a
+general lifecycle hook system. Each task has a stable `task_id`, one of four
+phases (`pre_migration_check`, `pre_migration_prepare`,
+`post_migration_backfill`, `post_migration_verify`), a short operator-facing
+summary, a task version, safety metadata, and an idempotent executor. Installer
+preflight blocks non-idempotent tasks, forward-only/destructive tasks without
+operator acknowledgement, and installed manifest tasks that have no executor.
+Catalog task metadata is surfaced before activation as pending because the
+executor can only be verified after the package is installed.
 
 Modules should provide:
 
 - pinned backend and WebUI package refs for official catalog entries
 - module dependency metadata for catalog target-state planning
 - migration-safety metadata for catalog update planning
+- migration task metadata when live-data checks, preparation, backfills, or
+  verification must run around Alembic
 - compatibility metadata in the module manifest
 - named interface contracts in the manifest and catalog entry when the module
   provides or consumes cross-module APIs
@@ -984,13 +1016,19 @@ The package install-plan API records operator intent only:
 - `POST /api/v1/admin/system/modules/install-plan/catalog/{module_id}` saves
   a planned install or update row from a validated catalog entry. Installed
   modules are planned as updates. Catalog signature and approved-channel policy
-  are enforced before the row is saved. The saved plan row can also carry a
+  are enforced before the row is saved. When the selected catalog row requires
+  companion dependency or interface-provider updates, the endpoint adds those
+  rows to the plan automatically. The saved plan row can also carry a
   data-safety acknowledgement used by preflight for forward-only or destructive
   catalog entries.
 - Install-plan preflight returns a structured `target_plan` summary so the
   admin UI can show current version, target version, package refs,
-  migration-safety level, and acknowledgement state without requiring JSON
-  editing.
+  migration-safety level, update-window and bridge metadata, recovery metadata,
+  and acknowledgement state without requiring JSON editing.
+- Install-plan preflight also returns a structured `migration_plan` summary with
+  target enabled modules and ordered module migration steps. When the installer
+  runs with migration enabled, the database migration command receives that
+  target module set and ordered module list.
 - `POST /api/v1/admin/system/modules/{module_id}/uninstall-plan` saves a
   planned non-destructive uninstall row for an installed module after it has
   been disabled. The Python distribution name is resolved from the installed