ms-markets 2.2.10.dev35__tar.gz → 2.2.11.dev36__tar.gz

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/.agents/skills/ms_markets/platform/metatable_migrations/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mainsequence-markets-metatable-migrations
-description: Use this skill when an ms-markets project extension needs MetaTables-managed migration wiring. MetaTable migrations are handled by the metatables client (mainsequence-metatable); this skill only covers project table/spec refresh through after_register_metatables.
+description: Use this skill when an ms-markets project extension needs MetaTables-managed migration wiring, or when a workload needs MetaTables roles on the `mainsequence.markets` namespace. MetaTable migrations are handled by the metatables client (mainsequence-metatable); this skill covers project table/spec refresh through after_register_metatables and the roles that the ms-markets deployment and consuming projects need.
 ---
 
 # Main Sequence Markets MetaTable Migration Extensions
@@ -20,8 +20,8 @@ MetaTable registration:
 - `metatables.migrations.metadata_for_models`
 - `metatables.migrations.run_mainsequence_alembic_env`
 - the `metatables migrations ... --provider <package>.migrations:migration` CLI
-- the `metatables-migrations` and `metatables-upgrade-legacy-app` skills that
-  `metatables copy-metatables-skills` installs under `.agents/skills/metatables/`
+- the `metatables-migrations` skill that `metatables copy-metatables-skills`
+  installs under `.agents/skills/metatables/`
 - the project-local migration provider, when the project defines one
 
 This skill does not own schema migration commands, migration engines, registry
@@ -51,7 +51,7 @@ Before changing project extension migration wiring, inspect:
 
 1. `.agents/skills/metatables/metatables-migrations/SKILL.md` and its
    `references/docs/client/define-and-migrate-tables.md`
-2. `.agents/skills/metatables/metatables-upgrade-legacy-app/SKILL.md` when the
+2. `.agents/skills/mainsequence/maintenance/metatables_transition/SKILL.md` when the
    project still imports `mainsequence.meta_tables` or calls
    `mainsequence migrations`
 3. `metatables migrations --help` for the installed client's command shape
@@ -70,23 +70,77 @@ ms-markets schema is migrated only by the ms-markets deployment's
 tables does not apply `msm_migrations:migration`; its own migration Job applies
 only its own providers. Do not migrate at application startup.
 
-Required in every Environment: the `migrate-markets` Job and the `markets-api`
-release run as their own workload Users, which have no MetaTables grants until an
-Organization admin runs `scripts/bootstrap_metatables_access.py` from a checkout
-of the branch deployed there. The script creates the Team that owns the tables in
-that Environment (`ms-markets-<environment>`), as
-`.agents/skills/metatables/metatables-migrations/SKILL.md` prescribes. Without it the
-Job fails with `403` `table_not_editable` or `namespace_not_writable` (`422 MetaTable
-is not editable` from a MetaTables API before 0.1.27), and the API is not deployed.
-Do not work around a failed migration by changing revisions or table definitions,
-asking for direct table grants or running the Job as an admin. Check the Job run
-logs, then have an admin run the bootstrap. `docs/releasing.md` ("MetaTables access
-in each Environment") has the steps.
 The MetaTables API needs no provider code, allowlist, or
 `application_migration_providers` alias. Keep the provider package, namespace,
 model registry, version-table binding, revision IDs, and applied revision
 history when upgrading the client.
 
+## MetaTables Access
+
+Access to the ms-markets tables follows the MetaTables namespace and table roles
+(MetaTables ADR 0024, copied with the MetaTables skills under
+`.agents/skills/metatables/metatables-migrations/references/docs/adr/api/0024-namespace-and-table-access-roles.md`).
+Every ms-markets table is in the `mainsequence.markets` namespace, and a role on the
+namespace covers every table in it, including tables registered later. Workloads run
+as their own workload Users: they never grant roles, are never `owner`, and get no
+MetaTables role from a workflow entry. The workflow's
+`access.branches: [{repository: MetaTables, policy: reader}]` only lets them find the
+Environment's MetaTables API.
+
+In each Environment, the ms-markets deployment's principals hold these roles on
+`mainsequence.markets`:
+
+| Principal | Role |
+| --- | --- |
+| `migrate-markets` (migration Job) | `editor` |
+| `markets-api` (FastAPI release) | `data_writer` |
+| a person, or a Team of people only | `owner` |
+
+Where `mainsequence.markets` predates roles, an Organization admin granted its first
+owner once, and its owners grant every other role. In an Environment where it does
+not exist yet, the first `migrate-markets` run creates it and gets `editor`; the
+people who manage that Job then grant the API `data_writer` and an owner. Nobody
+creates the namespace before the push.
+
+A workload without a role can't see the tables: `msm.start_engine` then fails at
+startup because they look unregistered, so that workload's rollout fails and only
+the next push deploys it.
+
+A project that installs ms-markets and uses these tables asks an owner of
+`mainsequence.markets` for the smallest role each of its workloads needs, in each
+Environment. Ask before the project's push when the workload already exists. A
+workload the push creates gets its role right after it, and the next push deploys
+it if it attaches the tables at startup.
+
+| Consumer workload | Role on `mainsequence.markets` |
+| --- | --- |
+| Migration Job that registers its own tables in `mainsequence.markets` | `editor` on the namespace |
+| Updater producer that writes an ms-markets table | table `editor` on each output table, plus `data_viewer` on the namespace for its inputs |
+| Row writer (asset or OpenFIGI registration, categories, calendars, Index rows) | `data_writer` |
+| Reader | `data_viewer` |
+
+Prefer table `editor` for producers: namespace `editor` also allows deleting every
+table in the namespace. The project's own tables belong in its own namespace, which
+its first migration creates (see `.agents/skills/metatables/metatables-migrations/SKILL.md`).
+
+Refusals name what is missing:
+
+- `namespace_access_required` (403) when a migration Job registers into
+  `mainsequence.markets`: the Job's workload User (`caller_user_uid`) lacks
+  `tables.create` there, for example after the platform recreated the Job. An owner
+  grants it `editor`, then the Job runs again.
+- `table_not_editable`: the caller lacks `tables.update` on an existing table. An
+  owner of the table or of the namespace grants `editor`.
+- A refused row read or write in a running workload: it lacks `data_viewer` or
+  `data_writer`. Its requests succeed from the next one after the grant, with no
+  redeployment.
+
+Do not work around a refusal by changing revisions, table definitions or physical
+names, by putting grants in a Job or in application code, or by running the Job as an
+Organization admin. Check the Job run logs, then ask an owner of
+`mainsequence.markets` for the role. "MetaTables access in each Environment" in the
+ms-markets `docs/releasing.md` lists the grants for its own deployment.
+
 ## Expected Project Pattern
 
 The project migration provider owns the migrated model list:

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/CHANGELOG.md

@@ -7,6 +7,54 @@ and this project follows versioned releases.
 
 ## [Unreleased]
 
+## [2.2.11] - 2026-10-21
+
+### Changed
+
+- Requires `mainsequence>=9.0.29,<10` and `mainsequence-metatable>=0.1.51,<0.2`; the
+  lock and exported `requirements.txt` select `mainsequence` 9.0.30,
+  `mainsequence-metatable` 0.1.51 and, through them, `mcp` 2.3.0. SDK 9.0.24 and
+  earlier refuse the platform's identity-only caller assertions, so the Markets API,
+  locked at 9.0.19, answered `401` to every signed request; SDK 9.0.25 and 9.0.26 raise
+  when code reads the request identity's `team_uids`; and MetaTables clients before
+  0.1.51 fail on SDK 9.0.30. This release adds no Alembic revision.
+- The deployment workflow uses workflow API `3.0.0`, the only version the platform
+  accepts: `markets-api` and `migrate-markets` declare `policy: reader` on the
+  MetaTables branch, the conversion of their former `level: view`.
+- MetaTables access follows its namespace and table roles (MetaTables ADR 0024). On
+  `mainsequence.markets` the `migrate-markets` Job holds `editor`, the `markets-api`
+  release `data_writer`, and a person or a people-only Team `owner`; the namespace's
+  owners grant these in each Environment. The release, migration and FastAPI guides
+  and the packaged `metatable_migrations` skill describe them, with the roles consuming
+  projects need: `editor` for migration Jobs that register tables in
+  `mainsequence.markets`, table `editor` on their outputs plus `data_viewer` for
+  updater producers, `data_writer` for row writers and `data_viewer` for readers.
+- `IndexActor.team_uids` is deprecated and empty for HTTP callers, because caller
+  assertions name no Teams. The Index actor never reads the request identity's
+  `team_uids`; an SDK `User` still contributes its `organization_teams`. No Index
+  operation authorizes by Team.
+- Canonical Index dataset discovery no longer reports `can_edit=True` to the user who
+  registered the table, because registering grants no MetaTables role by itself.
+  `can_edit` is `None`; the platform checks edit access when a change runs.
+- `get_openfigi_api_key()` raises `OpenFigiConfigurationError` naming `value_reader` on
+  `OPEN_FIGI_API_KEY` when the caller may not read the Secret's value. Its
+  missing-Secret message also says that a Secret is hidden from a caller without a
+  policy on it. A deployment that calls OpenFIGI declares
+  `secrets: [{name: OPEN_FIGI_API_KEY, policy: value_reader}]`.
+- Test fixtures sign identity-only caller assertions, and a test checks that an
+  assertion listing `team_uids`, for the caller or for a requester, is refused.
+- Refreshed the copied Main Sequence SDK skills to 9.0.30 and the MetaTables skills to
+  0.1.51 (0.1.35 dropped the retired `metatables-upgrade-legacy-app` skill), and removed
+  the retired managed block from `AGENTS.md`: `mainsequence code-repository update` no
+  longer exists.
+
+### Removed
+
+- `scripts/bootstrap_metatables_access.py` and its tests. It called Team bulk-member
+  and MetaTables Reader/Writer routes that no longer exist, and roles replace its Team
+  Writer model. `mainsequence.markets` exists in the development and Production
+  Environments, and its owner grants the roles above.
+
 ## [2.2.10] - 2026-10-11
 
 ### Fixed

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: ms-markets
-Version: 2.2.10.dev35
+Version: 2.2.11.dev36
 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
@@ -227,8 +227,8 @@ Requires-Python: <3.14,>=3.13
 Requires-Dist: alembic>=1.18.4
 Requires-Dist: cachetools
 Requires-Dist: fastapi>=0.136.3
-Requires-Dist: mainsequence-metatable<0.2,>=0.1.33
-Requires-Dist: mainsequence<10,>=9.0.19
+Requires-Dist: mainsequence-metatable<0.2,>=0.1.51
+Requires-Dist: mainsequence<10,>=9.0.29
 Requires-Dist: numpy
 Requires-Dist: pandas
 Requires-Dist: pip>=26.1.1
@@ -384,8 +384,8 @@ Recommended entry points:
 
 ## Quick Start
 
-`ms-markets` 2.x requires Python 3.13, Main Sequence SDK `>=9.0.19,<10`, and
-the MetaTables client `mainsequence-metatable>=0.1.33,<0.2`, which is imported
+`ms-markets` 2.x requires Python 3.13, Main Sequence SDK `>=9.0.29,<10`, and
+the MetaTables client `mainsequence-metatable>=0.1.51,<0.2`, which is imported
 as `metatables`. SDK 8 and earlier are not supported; install a 1.x
 `ms-markets` release when maintaining an SDK 8 project. See
 [ADR 0043](https://mainsequence-projects.github.io/MainSequenceMarkets/ADR/0043-sdk-9-metatables-client-hard-cut/)
@@ -501,9 +501,9 @@ Runtime dependencies are declared in
 [pyproject.toml](https://github.com/mainsequence-projects/MainSequenceMarkets/blob/main/pyproject.toml).
 The core stack starts with:
 
-- `mainsequence>=9.0.19,<10` for identity, login, Git source context,
+- `mainsequence>=9.0.29,<10` for identity, login, Git source context,
   CodeRepository, jobs, and agents
-- `mainsequence-metatable>=0.1.33,<0.2` (import `metatables`) for MetaTables,
+- `mainsequence-metatable>=0.1.51,<0.2` (import `metatables`) for MetaTables,
   time-index table updaters, governed compiled SQL, and application-owned
   Alembic migrations
 - `SQLAlchemy` for market-domain ORM models

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/README.md

@@ -107,8 +107,8 @@ Recommended entry points:
 
 ## Quick Start
 
-`ms-markets` 2.x requires Python 3.13, Main Sequence SDK `>=9.0.19,<10`, and
-the MetaTables client `mainsequence-metatable>=0.1.33,<0.2`, which is imported
+`ms-markets` 2.x requires Python 3.13, Main Sequence SDK `>=9.0.29,<10`, and
+the MetaTables client `mainsequence-metatable>=0.1.51,<0.2`, which is imported
 as `metatables`. SDK 8 and earlier are not supported; install a 1.x
 `ms-markets` release when maintaining an SDK 8 project. See
 [ADR 0043](https://mainsequence-projects.github.io/MainSequenceMarkets/ADR/0043-sdk-9-metatables-client-hard-cut/)
@@ -224,9 +224,9 @@ Runtime dependencies are declared in
 [pyproject.toml](https://github.com/mainsequence-projects/MainSequenceMarkets/blob/main/pyproject.toml).
 The core stack starts with:
 
-- `mainsequence>=9.0.19,<10` for identity, login, Git source context,
+- `mainsequence>=9.0.29,<10` for identity, login, Git source context,
   CodeRepository, jobs, and agents
-- `mainsequence-metatable>=0.1.33,<0.2` (import `metatables`) for MetaTables,
+- `mainsequence-metatable>=0.1.51,<0.2` (import `metatables`) for MetaTables,
   time-index table updaters, governed compiled SQL, and application-owned
   Alembic migrations
 - `SQLAlchemy` for market-domain ORM models

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/docs/fast_api/v1/index.md

@@ -145,7 +145,7 @@ 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.3.0`, retains three release revisions for rollback, and its
+`3.0.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
@@ -164,10 +164,15 @@ 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).
 
-!!! warning "Required before deploying to an Environment"
-    The Job and the API run as their own workload Users. They can't migrate or
-    use the ms-markets tables until an Organization admin runs
-    `scripts/bootstrap_metatables_access.py` for that Environment; see
+Both workloads declare the `reader` policy on the MetaTables branch
+(`access.branches`), which lets them find the Environment's MetaTables API.
+
+!!! warning "Required in every Environment"
+    The Job and the API run as their own workload Users. The Job migrates the
+    ms-markets tables only with the `editor` role on the `mainsequence.markets`
+    MetaTables namespace, and the API reads and writes their rows with
+    `data_writer`. The namespace's owners grant these roles in each Environment;
+    workflow entries can't. See
     [MetaTables access in each Environment](../../releasing.md#metatables-access-in-each-environment).
 
 Publish repository changes with a plain `git push` of the tracked branch; the
@@ -182,24 +187,31 @@ push alone as deployment success.
 
 Runtime dependencies must be resolvable from the backend build environment.
 The published `ms-markets` 2.x package therefore declares
-`mainsequence>=9.0.19,<10` and `mainsequence-metatable>=0.1.33,<0.2` without
+`mainsequence>=9.0.29,<10` and `mainsequence-metatable>=0.1.51,<0.2` without
 exact patch pins. The lower bounds enforce the SDK 9 and MetaTables client
-extraction hard cut and the SDK request identity that the platform's current
-caller assertions require (SDK 9.0.18 and later), while the project lock and exported runtime requirements
-select the exact releases validated for this repository. MetaTables 0.1.33 retains
-batched migration inspections and a five-minute migration API discovery budget,
-and refreshes changed authored metadata at unchanged revisions. Metadata
-finalization requires the corresponding shared MetaTables API update. Do not replace the
-published dependencies with machine-local `[tool.uv.sources]` path overrides.
+extraction hard cut, the identity-only caller assertions the platform signs (SDK
+9.0.27 and later; 9.0.25 and 9.0.26 are excluded), and a MetaTables client that
+works with SDK 9.0.30 and knows the namespace and table roles (0.1.51), while the
+project lock and exported runtime requirements select the exact releases validated
+for this repository: `mainsequence` 9.0.30 and `mainsequence-metatable` 0.1.51.
+MetaTables 0.1.51 retains batched migration inspections and a five-minute migration
+API discovery budget, and refreshes changed authored metadata at unchanged
+revisions. Metadata finalization requires the corresponding shared MetaTables API
+update. Do not replace the published dependencies with machine-local
+`[tool.uv.sources]` path overrides.
 
 `create_app()` installs the SDK request identity with
 `install_request_identity(app)`; the platform launcher refuses to serve an
 application without it. It authenticates every request before its handler: a
 hosted request by the gateway's signed caller assertion, a local request by its
 Bearer token. Handlers read the verified caller from `request.state.user` (a
-`RequestUserIdentity` with the canonical `uid`, `team_uids` and
-`is_organization_admin`) or `User.get_logged_user()`. The Index routes derive
-their actor, including its Teams, from that identity; route code does not parse
+`RequestUserIdentity` with the canonical `uid` and `is_organization_admin`) or
+`User.get_logged_user()`. The platform's caller assertions carry only those two
+facts, for the caller and for a requester; an assertion that lists `team_uids` is
+refused with `401`. Membership is checked on demand with
+`RequestUserIdentity.in_teams()`, which no Markets route needs. The Index routes
+derive their actor from that identity's `uid`; the deprecated
+`IndexActor.team_uids` stays empty for HTTP callers. Route code does not parse
 authentication headers or bind SDK request-header context variables.
 
 ## API Discoverability

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/docs/getting-started.md

@@ -1,7 +1,7 @@
 # Getting Started
 
-`ms-markets` 2.x requires Python 3.13, Main Sequence SDK `>=9.0.19,<10`, and
-the MetaTables client `mainsequence-metatable>=0.1.33,<0.2` (imported as
+`ms-markets` 2.x requires Python 3.13, Main Sequence SDK `>=9.0.29,<10`, and
+the MetaTables client `mainsequence-metatable>=0.1.51,<0.2` (imported as
 `metatables`). It cannot run against an SDK 8 or earlier contract and does not
 provide compatibility aliases or a mixed-version mode. Install a 1.x
 `ms-markets` release when maintaining an SDK 8 project.

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/docs/knowledge/msm/migrations/index.md

@@ -80,7 +80,7 @@ previous release keeps serving.
 
 ### Migration diagnostics and repeated runs
 
-The minimum client is MetaTables 0.1.33. `upgrade_application()` automatically
+The minimum client is MetaTables 0.1.51. `upgrade_application()` automatically
 uses fresh table inventories and batched physical inspections; PostgreSQL
 reflection is batched by schema. Finalization requests remain bounded to ten
 tables each, with the version table first. No batching option or project-specific
@@ -116,7 +116,7 @@ requires no new grant or application revision. If `0020` committed but
 finalization failed, deploy the repaired shared API and rerun the hosted Job at
 head; keep all existing application data and applied revisions. An already
 current development hypertable keeps its owner and rows. This is a server
-requirement; the Markets migration client remains 0.1.33.
+requirement; the Markets migration client requirement is separate (currently 0.1.51).
 
 The runner carries changed, non-empty authored table descriptions, labels, and
 column descriptions, labels, and logical names in each finalization batch. An
@@ -131,11 +131,13 @@ unchanged-contract write avoidance, and startup optimizations require the shared
 MetaTables API to be deployed with that release too. Update matching guidance
 with `metatables copy-metatables-skills --path .` after updating the client.
 
-!!! warning "Required: MetaTables access for the deployment"
-    The migration Job runs as its own workload User, which has no MetaTables
-    grants until an Organization admin runs `scripts/bootstrap_metatables_access.py`
-    for that Environment. Until then every hosted migration fails and the API is not
-    deployed; see
+!!! warning "Required: MetaTables roles for the deployment"
+    The migration Job runs as its own workload User and needs the `editor` role on
+    the `mainsequence.markets` namespace; the API needs `data_writer`. These are
+    MetaTables roles, not workflow entries. In each Environment the namespace's
+    owners grant them, or, where the Job's first run created the namespace, the
+    people who manage the Job. Without `editor` the Job's registration fails with
+    `namespace_access_required` and the API is not deployed; see
     [MetaTables access in each Environment](../../../releasing.md#metatables-access-in-each-environment).
 
 The ms-markets schema is owned and migrated only by this repository's

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/docs/knowledge/msm/platform/metatable_migrations.md

@@ -110,8 +110,8 @@ history is the Alembic revision graph plus the provider's version table.
 
 ## Client Requirement
 
-The implementation requires `mainsequence-metatable>=0.1.33,<0.2` with
-`mainsequence>=9.0.19,<10`. The client exposes `AlembicMetaTableMigration`,
+The implementation requires `mainsequence-metatable>=0.1.51,<0.2` with
+`mainsequence>=9.0.29,<10`. The client exposes `AlembicMetaTableMigration`,
 `AlembicVersionMetaTable`, application-owned Alembic execution, and the command
 shape where
 `metatables --local migrations upgrade --provider msm_migrations:migration head`

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/docs/releasing.md

@@ -163,7 +163,7 @@ requires no new grant or application revision. If `0020` committed but
 finalization failed, deploy the repaired shared API and rerun the hosted Job at
 head; keep all existing application data and applied revisions. An already
 current development hypertable keeps its owner and rows. This is a server
-requirement; the Markets migration client remains 0.1.33.
+requirement; the Markets migration client requirement is separate (currently 0.1.51).
 
 FastAPI startup also uses `api_endpoint_scope(discovery_timeout=300)` for its
 canonical and pricing runtime attachments. Discovery during shared-API wake or
@@ -178,11 +178,15 @@ persistent temporary failures also stop startup. Normal requests do not use this
 
 ### Upgrading the migration client
 
-The project requires `mainsequence-metatable>=0.1.33,<0.2`; `uv.lock` and
-`requirements.txt` select 0.1.33. After changing the dependency, run
-`mainsequence code-repository sync --path .`, refresh the MetaTables-owned
-guidance with `metatables copy-metatables-skills --path .`, and run the checks
-above. Keep the provider identity, version table, and applied revisions unchanged.
+The project requires `mainsequence>=9.0.29,<10` and
+`mainsequence-metatable>=0.1.51,<0.2`; `uv.lock` and `requirements.txt` select
+`mainsequence` 9.0.30 and `mainsequence-metatable` 0.1.51. Move the SDK and the
+client together: MetaTables clients before 0.1.51 fail on SDK 9.0.30, and 0.1.51
+itself requires SDK 9.0.29 or later. The SDK floor also excludes 9.0.25 and 9.0.26,
+which raise on the request identity's Teams. After changing the dependency, run
+`mainsequence code-repository sync --path .`, refresh the MetaTables-owned guidance
+with `metatables copy-metatables-skills --path .`, and run the checks above. Keep the
+provider identity, version table, and applied revisions unchanged.
 
 The candidate image uses the shared `upgrade_application()` runner and batched
 inspections. The Job explicitly wraps the runner in
@@ -205,62 +209,65 @@ revision alone is not proof of deployment success. See
 
 ### MetaTables access in each Environment
 
-!!! warning "Required in every Environment"
-    An Organization admin must run `scripts/bootstrap_metatables_access.py` for an
-    Environment before ms-markets can be deployed there. Without it:
-
-    - the `migrate-markets` Job fails with `403` `table_not_editable` or
-      `namespace_not_writable` (a MetaTables API before 0.1.27 answers
-      `422 MetaTable is not editable`). The error's `caller_user_uid` is the
-      workload User missing from the Team;
-    - the API rollout is blocked and no release becomes active.
-
-    Run it before the first deployment to a new Environment, and again whenever
-    the platform recreates the Job or the release.
-
-This is the model MetaTables 0.1.27 prescribes: in each Environment, one platform
-Team owns an application's tables and its workload Users are the Team's members
-(see the vendored `metatables-migrations` skill).
-
 The `migrate-markets` Job and the `markets-api` release run as their own workload
-Users, which start with no grants. The workflow gives both `view` on the MetaTables
-repository (`access.branches`), so they can find the Environment's MetaTables API.
-A workflow cannot grant MetaTables table access, so an Organization admin runs
-`scripts/bootstrap_metatables_access.py` once per Environment. Run it from a
-checkout of the branch deployed there: `development` for the development
-Environment, `main` for Production.
-
-```bash
-uv run --frozen --all-extras python -m scripts.bootstrap_metatables_access --dry-run
-uv run --frozen --all-extras python -m scripts.bootstrap_metatables_access
-```
-
-The script names the Team after the checkout's Environment (`ms-markets-development`,
-`ms-markets-production`). It:
-
-- creates the Team if it doesn't exist;
-- adds the workload Users of the Job and release declared in the workflow;
-- creates the `mainsequence.markets` namespace if it is missing;
-- grants the Team Writer on the namespace.
-
-Tables in that namespace inherit the grant, including the ones the migration
-registers later. Once `msm.alembic_version` is registered, the script checks each
-workload User's effective access to it.
-
-Re-running the script changes only what is missing. Run it again whenever the
-platform recreates the Job or the release, because the new workload User is not
-in the Team.
-
-A workload User exists only after the workload's first deployment. In an
-Environment where the Job has not run yet:
-
-1. Run the script, then push. The Job's first run fails, because its workload User
-   is not in the Team yet.
-2. Run the script again.
-3. Run the Job with `mainsequence code-repository jobs run <JOB_UID>`.
-
-The API rolls out on the next push to the branch, because the CLI cannot retry a
-blocked deployment.
+Users. The workflow gives both the `reader` policy on the MetaTables branch
+(`access.branches`), so they can find the Environment's MetaTables API. Their access
+to the ms-markets tables is a MetaTables role on the `mainsequence.markets` namespace
+(MetaTables ADR 0024). A role on the namespace covers every table in it, including
+tables registered later. Workflow entries don't grant MetaTables roles and workloads
+never grant them: the namespace's owners do, in the namespace's **Access** panel of
+that Environment's MetaTables Admin or with `grant_role`.
+
+| Principal | Role on `mainsequence.markets` | Why |
+| --- | --- | --- |
+| `migrate-markets` workload User | `editor` | registers and migrates the ms-markets tables |
+| `markets-api` workload User | `data_writer` | reads and writes rows; never migrates, deletes or shares tables |
+| a person, or a Team of people only | `owner` | decides who has access; a workload is never an owner |
+
+Without `editor`, the Job's registration fails with `403` `namespace_access_required`
+(`table_not_editable` for an existing table), naming its workload User as
+`caller_user_uid`; the API rollout is blocked and the previous release keeps serving.
+Without a role on the namespace, the API can't attach its tables at startup, so its
+rollout fails and only the next push deploys it. A running API whose role is missing
+has its MetaTables requests refused; they succeed from the next request after the
+grant, with no redeployment.
+
+**Where the namespace exists.** `mainsequence.markets` predates roles in the
+development and Production Environments, so no migration creates it there. When
+roles arrived, an Organization admin granted it a first owner, and the old Team
+Writer binding became `editor` for every member of that Team, `markets-api`
+included. The owner keeps the Job's `editor` and lowers the API: grant the API's
+workload User `data_writer`, then take it out of the Team that holds `editor`.
+
+**In a new Environment.** Nobody creates the namespace before the push. The first
+`migrate-markets` run registers the tables, which creates `mainsequence.markets` and
+grants the Job `editor`. The people who manage the Job then manage the namespace's
+access: they grant `markets-api` `data_writer`, and `owner` to themselves or to a
+Team they belong to, so the namespace keeps an owner when the Job is recreated. The
+API's first rollout there fails at startup because it has no role yet; push again
+after the grant.
+
+**When the platform recreates the Job or the release**, its new workload User has no
+role. With direct bindings, an owner grants the role again; with a Team that holds
+the role, add the new workload User to the Team. The Job can then be run again, but a
+blocked API rollout resumes only with the next push to the branch.
+
+**Consumers.** An application that uses the ms-markets tables gets its roles in each
+Environment from an owner of `mainsequence.markets`:
+
+| Consumer workload | Role |
+| --- | --- |
+| Migration Job that registers tables in `mainsequence.markets` | `editor` on the namespace |
+| Updater producer that writes an ms-markets table | table `editor` on each output table, plus `data_viewer` on the namespace |
+| Row writer (assets, OpenFIGI details, categories, calendars, Index rows) | `data_writer` on the namespace |
+| Reader | `data_viewer` on the namespace |
+
+Prefer table `editor` for producers: namespace `editor` would also let them delete
+every table in the namespace. Grant before the consumer's push when its workload
+already exists. A workload the push creates gets its role right after it; if it
+attaches ms-markets tables at startup (`msm.start_engine`), its first rollout fails
+until then and the next push deploys it. A consumer keeps its own tables in its own
+namespace, which its first migration creates.
 
 ## Failure recovery
 

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/docs/tutorial/index.md

@@ -17,7 +17,7 @@ helpers for time-indexed facts).
 
 ### Prepare the schema before starting runtime code
 
-1. Install the locked dependencies, including MetaTables 0.1.33 or later.
+1. Install the locked dependencies, including MetaTables 0.1.51 or later.
 2. For local ms-markets schema development, verify the local MetaTables runtime
    and use `metatables --local migrations upgrade --provider msm_migrations:migration head`.
    For a hosted environment, the ms-markets deployment's migration Job applies

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/examples/msm/platform/metatable_migration_lifecycle.py

@@ -24,7 +24,7 @@ def main() -> None:
 
     print("\nHosted: candidate image -> jobs/migrate_markets.py -> API rollout")
     print(f"The Job calls metatables.upgrade_application({PROVIDER!r}) on every deployment.")
-    print("MetaTables >=0.1.33 batches inspections; the Job explicitly allows 300s to wake.")
+    print("MetaTables >=0.1.35 batches inspections; the Job explicitly allows 300s to wake.")
     print("It uses api_endpoint_scope(discovery_timeout=300); failures still stop rollout.")
     print("At head, catalog reconciliation still runs; migrated=False is not a skip signal.")
     print("Changed non-empty authored metadata refreshes without a new Alembic revision.")

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "ms-markets"
-version = "2.2.10.dev35"
+version = "2.2.11.dev36"
 description = "Financial markets ORM, engines, and application management extensions for Main Sequence."
 readme = "README.md"
 requires-python = ">=3.13,<3.14"
@@ -36,8 +36,8 @@ dependencies = [
   "alembic>=1.18.4",
   "cachetools",
   "fastapi>=0.136.3",
-  "mainsequence>=9.0.19,<10",
-  "mainsequence-metatable>=0.1.33,<0.2",
+  "mainsequence>=9.0.29,<10",
+  "mainsequence-metatable>=0.1.51,<0.2",
   "numpy",
   "pandas",
   "pip>=26.1.1",

{ms_markets-2.2.10.dev35 → ms_markets-2.2.11.dev36}/src/msm/services/assets/openfigi.py

@@ -379,14 +379,22 @@ def get_openfigi_api_key(
     *,
     secret_name: str = OPENFIGI_API_KEY_SECRET_NAME,
 ) -> str:
-    """Read the OpenFIGI API key from Main Sequence Secrets."""
+    """Read the OpenFIGI API key from Main Sequence Secrets.
+
+    Reading a Secret's value needs the `value_reader` policy on it. A caller
+    without it gets `OpenFigiConfigurationError` naming that grant.
+    """
 
     try:
         secret = _get_mainsequence_secret(secret_name)
     except Exception as exc:
-        if exc.__class__.__name__ == "DoesNotExist":
+        error_name = exc.__class__.__name__
+        if error_name == "DoesNotExist":
             message = _missing_openfigi_secret_message(secret_name)
             raise OpenFigiConfigurationError(message) from exc
+        if error_name == "PermissionDeniedError":
+            message = _unreadable_openfigi_secret_message(secret_name)
+            raise OpenFigiConfigurationError(message) from exc
         raise
 
     raw_value = getattr(secret, "value", None)
@@ -412,7 +420,19 @@ def _get_mainsequence_secret(secret_name: str) -> Any:
 
 
 def _missing_openfigi_secret_message(secret_name: str) -> str:
-    return f"{secret_name} needs to be set in {OPENFIGI_SECRET_SETUP_URL} before using OpenFIGI."
+    return (
+        f"{secret_name} needs to be set in {OPENFIGI_SECRET_SETUP_URL} before using OpenFIGI. "
+        f"A Secret that exists is hidden from a caller without a policy on it; the caller "
+        f"needs `value_reader` on {secret_name}."
+    )
+
+
+def _unreadable_openfigi_secret_message(secret_name: str) -> str:
+    return (
+        f"The caller may not read the value of the {secret_name} Secret. Reading it needs "
+        f"`value_reader` on {secret_name}: its owner grants it, or the caller's deployment "
+        f"workflow declares `secrets: [{{name: {secret_name}, policy: value_reader}}]`."
+    )
 
 
 def _ensure_normalized_openfigi_result(item: Mapping[str, Any]) -> dict[str, Any]: