ms-markets 2.2.0.dev6__tar.gz → 2.2.1.dev8__tar.gz

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/.agents/skills/ms_markets/indices/index_workflow/SKILL.md

@@ -233,7 +233,10 @@ tests, OpenAPI, docs, examples, tutorial, changelog, and this skill aligned.
 2. Run FastAPI/OpenAPI and Adapter from API contract tests.
 3. Run Ruff on every changed Python file.
 4. Build MkDocs in strict mode.
-5. Apply the migration through the selected provider and verify current head.
+5. Apply the migration to the local runtime with
+   `metatables --local migrations upgrade --provider <provider> head` and verify
+   current head. Hosted environments receive it only from the deployment
+   workflow's migration Job.
 6. Verify mixed Asset/Index example output and custom Portfolio publication.
 
 ## Canonical References

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/.agents/skills/ms_markets/platform/bootstrap_registration/SKILL.md

@@ -85,8 +85,11 @@ For pricing bootstrap changes, also inspect:
 
 ## User-Facing Startup Pattern
 
-Operators should run the MetaTables migration provider before application startup.
-Examples and application code should then attach once, then use row APIs:
+MetaTables migrations are applied before application startup, never by it.
+Hosted environments are migrated only by a deployment workflow's migration Job;
+during development, apply a provider to the local runtime with
+`metatables --local migrations upgrade --provider <provider> head`. Examples and
+application code should then attach once, then use row APIs:
 
 ```python
 import msm

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/.agents/skills/ms_markets/platform/metatable_migrations/SKILL.md

@@ -96,8 +96,8 @@ ProjectAlembicVersion = build_alembic_version_metatable(
 migration = build_metatable_migration_provider(
     package="my_project",
     migration_namespace="my-project",
-    script_location="my_project:migrations",
-    version_location_prefix="my_project:migrations/versions",
+    script_location="my_project.migrations:",
+    version_location_prefix="my_project.migrations:versions",
     target_metadata=Base.metadata,
     alembic_registry=ProjectAlembicVersion,
     metatable_models=[
@@ -107,10 +107,12 @@ migration = build_metatable_migration_provider(
 )
 ```
 
-Always pass `version_location_prefix` with the provider's own package. The
-client default is `migrations:versions`, which resolves to whichever top-level
-`migrations` package is first on `sys.path`, including one installed by another
-distribution.
+Always pass both `script_location` and `version_location_prefix`, pointing at
+the provider's own module the way
+`metatables migrations scaffold --module my_project.migrations` derives them.
+The client default is `migrations:versions`, which resolves to whichever
+top-level `migrations` package is first on `sys.path`, including one installed
+by another distribution.
 
 `refresh_project_market_specs` should refresh only specs for project tables
 registered by that provider.

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/CHANGELOG.md

@@ -7,6 +7,35 @@ and this project follows versioned releases.
 
 ## [Unreleased]
 
+### Changed
+
+- The VS Code launch configurations and tasks that check, apply and downgrade
+  migrations pass `--local`, so they act on the local runtime instead of
+  whichever MetaTables API the SDK environment resolves, and their names say
+  so.
+
+### Documentation
+
+- The FastAPI deployment docs describe workflow API 2.3.0 and its
+  `image` → `migrate` → `deploy_api` graph, and say that publishing is a plain
+  `git push`. Since Main Sequence SDK 9.0.5, `mainsequence code-repository sync`
+  only refreshes `uv.lock`, the environment and `requirements.txt`; it no longer
+  bumps, tags, commits or pushes.
+- Every developer migration command targets the local runtime
+  (`metatables --local`), including the ADR 0045 reset path. Hosted
+  environments are migrated only by the deployment workflow's Job.
+- Downstream projects declare their own migration provider and version table.
+  The MetaTable migration, portfolio accounting and asset-indexed storage
+  guides, the pricing tutorial and the bootstrap, index and
+  `metatable_migrations` skills no longer suggest extending the ms-markets
+  revision graph or applying `msm_migrations:migration` outside the ms-markets
+  deployment.
+- MetaTable registration no longer describes the removed catalog projection
+  hook, and the `metatable_migrations` skill's project provider example uses
+  the locations `metatables migrations scaffold --module` derives.
+- Refreshed the MetaTables agent skills to 0.1.14 and the managed `AGENTS.md`
+  section from SDK 9.0.5; the SDK skill bundle is unchanged.
+
 ## [2.2.0] - 2026-10-03
 
 ### Removed

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: ms-markets
-Version: 2.2.0.dev6
+Version: 2.2.1.dev8
 Summary: Financial markets ORM, engines, and application management extensions for Main Sequence.
 Project-URL: Changelog, https://github.com/mainsequence-projects/MainSequenceMarkets/blob/main/CHANGELOG.md
 Project-URL: Source, https://github.com/mainsequence-projects/MainSequenceMarkets

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/docs/ADR/0045-squashed-initial-schema-and-namespaced-packages.md

@@ -40,9 +40,10 @@ MetaTables local SQLite runtime (#15). The wheel also still installed top-level
 ## Consequences
 
 - A database at any of `0001`–`0017` fails with Alembic's unknown-revision error.
-  With 2.0.x still installed, run
-  `metatables migrations downgrade base --provider msm_migrations:migration`,
-  then install 2.1.0 and upgrade from empty.
+  For a local runtime, with 2.0.x still installed, run
+  `metatables --local migrations downgrade base --provider msm_migrations:migration`,
+  then install 2.1.0 and upgrade from empty. Hosted environments are migrated
+  only by the deployment workflow's migration Job.
 - Imports of `cli` and `command_center` change to `msm_cli` and
   `msm_command_center`.
 - Later schema changes are new revisions after `0018`. MetaTables generates them

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/docs/fast_api/v1/index.md

@@ -133,9 +133,9 @@ It contains no route, schema, service, or runtime logic.
 
 The release is managed by
 `.mainsequence/workflows/ms-markets-api.yaml`. The declaration uses workflow API
-`2.1.0`, retains three release revisions for rollback, and its
-automatic-redeployment policy follows every synchronized
-`main` commit (`tag_regex: null`). The backend resolves the verified image for
+`2.3.0`, retains three release revisions for rollback, and its
+automatic-redeployment policy deploys every pushed commit of the tracked branch
+(`tag_regex: null`). The backend resolves the verified image for
 the exact eligible commit, so the workflow must not contain a
 `related_image_uid`. It requests the standard API capacity of `0.25` vCPU and
 `0.5` GiB on non-spot infrastructure. The release admits the supported
@@ -145,10 +145,22 @@ The frontend identifies this release by its stable ResourceRelease UID; the SDK
 resolves the current opaque RPC endpoint at request time after every automatic
 API redeployment.
 
-Use `mainsequence code-repository sync --path . -m "<message>"` to publish
-repository changes. A successful sync triggers the backend-owned image build
-and release rotation; use the deployment-run interfaces to verify the terminal
-state and logs instead of treating the Git push alone as deployment success.
+The same file declares the `migrate-markets` Job, which follows the same
+every-push policy, and the order of each deployment: the `image` step prepares
+the `markets-api` image, `migrate` runs `jobs/migrate_markets.py` from that
+image, and `deploy_api` deploys the API with `needs: [migrate]`. A failed
+migration blocks the rollout and the previous release keeps serving; see
+[Hosted Deployments](../../knowledge/msm/migrations/index.md#hosted-deployments).
+
+Publish repository changes with a plain `git push` of the tracked branch; the
+workflow files decide what deploys. The tracked `main` branch changes only through
+release pull requests from `development`; see [Releasing](../../releasing.md). Since Main Sequence SDK 9.0.5,
+`mainsequence code-repository sync` only refreshes local dependencies
+(`uv lock`, `uv sync`, `uv export --locked --no-dev --no-hashes`); it does not
+bump the version, tag, commit, or push. The push starts the backend-owned image
+build, the migration Job, and the release rotation; use the deployment-run
+interfaces to verify the terminal state and logs instead of treating the Git
+push alone as deployment success.
 
 Runtime dependencies must be resolvable from the backend build environment.
 The published `ms-markets` 2.x package therefore declares

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/docs/knowledge/msm/assets/asset_indexed_data_nodes.md

@@ -245,9 +245,11 @@ class ExampleAssetMetric(AssetTimestampedDataNode):
         return self.set_frame(self.build_frame(rows))
 ```
 
-Add the storage class to the markets migration model registry so the MetaTables
-migration provider registers it after the `Asset` MetaTable dependency. Runtime
-startup can then attach it with `msm.start_engine(models=[...])`. Do not call
+Add the storage class to the model registry of the migration provider that owns
+it, so that provider registers it after the `Asset` MetaTable dependency: the
+markets registry for a built-in ms-markets table, or the project's own provider
+for a project table. Runtime startup can then attach it with
+`msm.start_engine(models=[...])`. Do not call
 `PlatformTimeIndexMetaTable.register(...)`, manually bind storage by UID, or
 reconstruct a generic `MetaTable` in application code.
 

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/docs/knowledge/msm/platform/meta_table_registration.md

@@ -135,14 +135,12 @@ backend rows are treated as missing migration finalization, not as permission to
 register application tables.
 
 The catalog is finalized by the MetaTables migration upgrade flow. That command
-applies Alembic-rendered SQL with the environment connection selected by the
-MetaTables API, synchronizes the
-provider MetaTable catalog, and runs the `msm` provider hook that writes the
-catalog projection with the current platform UID, namespace, table name,
-description, model name, and SDK version. The catalog is an inventory
-projection, not the schema authority and not the runtime binding source. The
-catalog is intentionally MetaTable-specific; TimeIndexTableUpdater registration state belongs
-in a separate catalog if it is needed later.
+reserves the provider's MetaTables through the MetaTables API, applies the
+Alembic revisions with the environment connection selected by that API, and
+finalizes the provider's `MetaTable` and `TimeIndexMetaTable` bindings from
+`reserved` to `active`. The `msm` provider registers no
+`after_register_metatables` hook and keeps no secondary catalog table; the
+finalized backend resources are the inventory.
 
 When startup attaches platform-managed MetaTables, it partitions requested
 models into normal `MetaTable` models and `PlatformTimeIndexMetaTable` storage

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/docs/knowledge/msm/platform/metatable_migrations.md

@@ -27,9 +27,11 @@ The provider is constructed with the `metatables.migrations` helpers:
 
 `MarketsAlembicVersion` stores Alembic state in
 `public.ms_markets__alembic_version`. This package-specific version table avoids
-collisions in databases that host multiple independent providers. Downstream
-projects that inherit from ms-markets should use this same provider and version
-table when they are extending the ms-markets revision graph.
+collisions in databases that host multiple independent providers. The provider
+and its revision graph belong to ms-markets alone. A downstream project that
+adds its own tables declares its own provider, module, and version table; it
+neither adds revisions to the ms-markets graph nor applies
+`msm_migrations:migration`, which only the ms-markets deployment migrates.
 
 Although the physical table is in PostgreSQL `public`, the provider metadata
 authors default-schema tables as `schema=None`. `public` is the database
@@ -111,7 +113,8 @@ history is the Alembic revision graph plus the provider's version table.
 The implementation requires `mainsequence-metatable>=0.1.14,<0.2` with
 `mainsequence>=9.0.5,<10`. The client exposes `AlembicMetaTableMigration`,
 `AlembicVersionMetaTable`, application-owned Alembic execution, and the command
-shape where `metatables migrations upgrade --provider msm_migrations:migration head`
+shape where
+`metatables --local migrations upgrade --provider msm_migrations:migration head`
 applies without `--apply`, `--to`, or `--register-metatables`. Namespace-scoped
 revision directories use the Alembic `version_locations` configured by the
 provider. Upgrading the client keeps the provider package, namespace, model

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/docs/knowledge/msm_portfolios/portfolios/accounting.md

@@ -487,9 +487,13 @@ stale valuation, inverse FX guess, or weight-only fallback.
 ## Migration And Validation
 
 The ms-markets migration provider creates the canonical ledger and rebuildable
-state/cash-flow schemas. Apply it through the repository's existing MetaTables migration
-deployment workflow before runtime attachment. This is an ordinary deployment
-step, not a client development dependency.
+state/cash-flow schemas. Hosted environments receive them only from the
+ms-markets deployment's `migrate-markets` Job, which runs before the Markets API
+rolls out; applications that use portfolio accounting do not apply the
+ms-markets provider themselves. During ms-markets development, apply it to the
+local runtime with
+`metatables --local migrations upgrade --provider msm_migrations:migration head`
+before runtime attachment.
 
 For changes to this accounting surface, run at least:
 

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/docs/tutorial/05-pricing.md

@@ -661,8 +661,10 @@ migrated and registered with the same path as built-in tables:
    base identifier with the mixin namespace to produce the globally unique
    MetaTable identifier.
 4. Declare relationships with normal SQLAlchemy `ForeignKey(...)` targets.
-5. Add or sync the package/project migration that creates or refreshes the
-   table and finalizes the schema.
+5. Add a revision to the project's own migration provider that creates or
+   changes the table, and apply it to the local runtime with
+   `metatables --local migrations upgrade --provider <provider> head`. Hosted
+   environments receive it from the project's deployment migration Job.
 6. Attach at runtime with `msm.start_engine(models=[MyModelTable])`.
 7. Put row operations in an optional `MarketsMetaTableRow` wrapper.
 

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "ms-markets"
-version = "2.2.0.dev6"
+version = "2.2.1.dev8"
 description = "Financial markets ORM, engines, and application management extensions for Main Sequence."
 readme = "README.md"
 requires-python = ">=3.13,<3.14"

{ms_markets-2.2.0.dev6 → ms_markets-2.2.1.dev8}/tests/msm/maintenance/test_migrations.py

@@ -65,7 +65,9 @@ def test_migration_upgrade_command_uses_metatables_cli_flags() -> None:
     from metatables.cli.app import app
     from typer.testing import CliRunner
 
-    upgrade_command = "metatables migrations upgrade --provider msm_migrations:migration head"
+    upgrade_command = (
+        "metatables --local migrations upgrade --provider msm_migrations:migration head"
+    )
     help_result = CliRunner().invoke(
         app,
         ["migrations", "upgrade", "--help"],