mainsequence-metatable 0.1.47.dev75__tar.gz → 0.1.48.dev77__tar.gz

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/.agents/skills/client/metatables-migrations/SKILL.md

@@ -46,35 +46,35 @@ migrations. Read `docs/client/deploy-application-migrations.md`.
 1. **Develop locally.** Author the revision and apply it to verified local SQLite
    with the [local development skill](../metatables-local-development/SKILL.md).
 2. **Commit the revision with the code that needs it.**
-3. **Give the Job access.** Any person admitted to the Environment sets it up; no
-   Organization admin is needed. Follow "Give the Job access" in
-   `docs/client/deploy-application-migrations.md`, in this order, in each
-   Environment:
-   1. Before the first push, create each namespace the provider creates tables in:
-      **Create namespace** in that Environment's Admin, or `Namespace.create(name)`
-      from the person's own session connected to it. The creator becomes `owner`.
-   2. Push the workflow file. It creates the Job's and the other resources' workload
-      Users before any step runs, so the first migration may stop with
-      `namespace_access_required`.
-   3. As owner, grant the migration Job's workload User `editor`, and `data_writer` to
-      resources that only read and write rows, in the namespace's Access panel (find
-      a workload by its Job or release name) or with `grant_role` and its
-      `workload_user_uid`. A Team the owner belongs to, holding the roles with the
-      workloads as members, is optional; it saves granting again when a Job is
-      recreated.
-   4. Re-run the migration Job.
-
-   These are the person's actions, made in MetaTables, not in the repository. Tell
-   the user the steps; with their explicit go-ahead you may run `Namespace.create`
-   and `grant_role` from their session against the target Environment. Never put them
-   in the migration Job: workloads are refused. A namespace created before ADR 0024
-   has no owner until an Organization admin grants one. Recommend one namespace per
+3. **Give the Job access.** Nothing is created by hand and no Organization admin is
+   needed. Follow "Give the Job access" in `docs/client/deploy-application-migrations.md`,
+   in each Environment:
+   1. Push the workflow file. It creates the Job's and the other resources' workload
+      Users before any step runs.
+   2. The first migration registers the provider's tables. A namespace they name that
+      does not exist yet is created by that registration, and the Job gets `editor` on
+      it. Do not tell the user to create the namespace before the push.
+   3. A person who manages the Job in the platform then manages the namespace's
+      access: grant `data_writer` to resources that only read and write rows, and
+      `owner` to themselves or to a Team they belong to, in the namespace's Access
+      panel (find a workload by its Job or release name) or with `grant_role` and its
+      `workload_user_uid`. A Team holding the roles with the workloads as members is
+      optional; it saves granting again when a Job or release is recreated.
+
+   Step 3 is the person's action, made in MetaTables, not in the repository. Tell the
+   user the step; with their explicit go-ahead you may run `grant_role` from their
+   session against the target Environment. Never put grants in the migration Job:
+   workloads are refused. If the namespace name is already taken, the first run stops
+   with `namespace_access_required`; an owner grants the Job `editor`, or the
+   application uses another namespace. A namespace created before ADR 0024 has no
+   owner until an Organization admin grants one. Recommend one namespace per
    application; it is not required (see "Namespaces and applications" in
    `docs/security/ownership-and-sharing.md`).
 4. **Deploy.** The application's `.mainsequence/workflows/` file declares a
    migration Job that calls `upgrade_application` for each provider, in
    dependency order, from the candidate image. The Job and every resource that
-   uses MetaTables declare `access.branches: [{repository: MetaTables, level: view}]`.
+   uses MetaTables declare `access.branches: [{repository: MetaTables, policy: reader}]`
+   (workflow API `3.0.0`; the platform refuses `2.3.0` files and `level:` entries).
    Every deployed resource that reads or writes the tables (FastAPI,
    `harness_agent` and others) has a deploy step with `needs: [migrate]`. A failed
    migration blocks the rollout.
@@ -267,10 +267,10 @@ Read `docs/operations/recovery-and-observability.md`.
   another install overwrote it. Move the provider under an application-owned
   module (see [Provider placement](#provider-placement)), preserving its provider
   identity and applied revision history. Do not edit files in `site-packages`.
-- If reservation fails with `namespace_not_found` (403), create the namespace and
-  grant the Job `editor`, as in step 3. `namespace_access_required` is expected on a
-  new application's first run: an owner the error lists grants the `caller_user_uid`
-  `editor` on the namespace, or adds it to a Team that holds it, then the Job is
+- If reservation fails with `namespace_access_required` (403), the namespace already
+  exists: it is taken, or the Job was recreated with a new workload User. An owner the
+  error lists, or a manager of the workload that created the namespace, grants the
+  `caller_user_uid` `editor`, or adds it to a Team that holds it, then the Job is
   re-run. With `namespace_required`, set the table's namespace. With
   `table_not_editable`, an owner of the table or its namespace grants `editor`. Do
   not change code or physical names to get around it.

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/.agents/skills/client/metatables-time-index-table-updates/SKILL.md

@@ -53,8 +53,8 @@ output binding or explicitly authorized row scope for mutation tests.
 
 A deployed producer runs as its Job's workload User. It needs `editor` on its output
 tables, which lets it operate updaters and write rows, and `data_viewer` on its
-inputs. Grant these on the namespaces, directly or through a Team, the same way and
-in the same order as the migration Job's `editor` (step 3 of the
+inputs. A person who manages the migration Job that created the output namespace, or
+an owner, grants these on the namespaces, directly or through a Team (step 3 of the
 [migrations skill](../metatables-migrations/SKILL.md)); no Organization admin is
 needed. Output tables belong to the migration provider and its namespace: a workload
 never creates a table outside a namespace.

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/.mainsequence/workflows/metatables-api.yaml

@@ -1,4 +1,4 @@
-api_version: "2.3.0"
+api_version: "3.0.0"
 name: metatables-api
 resources:
   - key: metatables
@@ -27,14 +27,14 @@ resources:
     access:
       secrets:
         - name: METATABLES_RUNTIME_DATABASE
-          level: view
+          policy: value_reader
       # /runtime-context/ tells applications this branch's Analyst (ADR 0019).
       resources:
         - key: metatables-analyst-agent
-          level: view
+          policy: viewer
         # The Admin's "Run security check now" starts the daily check (ADR 0023).
         - key: check-security
-          level: edit
+          policy: editor
 
   - key: metatables-analyst-agent
     kind: harness_agent
@@ -61,7 +61,7 @@ resources:
     # The Analyst reads only as the person it serves (ADR 0020); it holds no grants.
     acts_for_requester: true
     access:
-      branch: view
+      branch: reader
 
   - key: migrate-system
     kind: job
@@ -77,7 +77,7 @@ resources:
     access:
       secrets:
         - name: METATABLES_RUNTIME_DATABASE
-          level: view
+          policy: value_reader
 
   # The full database security check, outside the deployment (ADR 0023). Not a
   # workflow step: every push activates its image, and it skips while the
@@ -101,7 +101,7 @@ resources:
     access:
       secrets:
         - name: METATABLES_RUNTIME_DATABASE
-          level: view
+          policy: value_reader
 
 execution:
   steps:

{mainsequence_metatable-0.1.47.dev75/src/mainsequence_metatable.egg-info → mainsequence_metatable-0.1.48.dev77}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.47.dev75
+Version: 0.1.48.dev77
 Summary: Main Sequence MetaTables Python client and standalone API
 Author-email: Main Sequence GmbH <dev@main-sequence.io>
 License-Expression: MIT

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/docs/adr/api/0024-namespace-and-table-access-roles.md

@@ -3,7 +3,8 @@
 Status: Accepted.
 
 Implementation status: implemented on development, in the API and in the MetaTables
-Admin's Access panels. Non-container tests pass. The container matrix passes on SQLite;
+Admin's Access panels. Namespaces created by a workload's registration (sections 3 and 5)
+are implemented in the API; the Admin does not yet label the `manager` source. Non-container tests pass. The container matrix passes on SQLite;
 on PostgreSQL, TimescaleDB, SQL Server and MySQL one runtime-bootstrap test fails, as it
 did before this change. Hosted deployment is pending. The user guides are
 [Ownership, roles, and inheritance](../../security/ownership-and-sharing.md) and the
@@ -52,8 +53,8 @@ instance contains namespaces, and a namespace contains tables.
 - A principal holds at most one binding per object; granting another role replaces
   it. Because roles are nested, its access is the strongest role among its own, its
   Teams' and its namespace's bindings. There is no explicit deny.
-- Organization admins, Team membership and namespace inheritance are **computed**, never
-  stored.
+- Organization admins, Team membership, namespace inheritance and the managers of a
+  namespace's creating workload are **computed**, never stored.
 - The API checks actions, never role names. One evaluator answers both single checks
   and list filters, so a list never shows what a check would refuse.
 - Each action has a level: `read` (see metadata), `use` (read data), `write` (change
@@ -206,6 +207,10 @@ workload Users, Teams.
 - A person who creates a namespace is granted `owner` on it (source `creator`). A taken
   name is refused and never adopted; the refusal names its owners when the caller may
   see them.
+- Registering a table into a namespace that does not exist creates it. A person who
+  does so is granted `owner`. A workload User is granted `editor`, and the namespace
+  records it as its **creating workload**: the people who manage that workload manage
+  the namespace's access. An existing namespace needs `tables.create`, whoever created it.
 - A person who creates a table outside any namespace is granted `owner` on it.
 - A table created in a namespace gets no binding: the namespace's roles cover it.
 
@@ -216,12 +221,17 @@ workload Users, Teams.
 | Every action on every object | Organization admin, from the platform on each request | `admin` |
 | The roles granted to a Team | the caller's current Team membership, from the platform | `team`, with the Team |
 | The table role of the same name | a role on the table's current namespace | `namespace`, with the namespace |
+| `namespaces.get`, `namespaces.get_access`, `namespaces.set_access` on a namespace | managing its creating workload, from the platform on each request | `manager`, with the workload |
+
+Managing the creating workload is access management only. It gives no role: no access
+to the namespace's tables, no `namespaces.update` and no table-level bindings.
 
 **Constraints** that no role overrides:
 
-- A workload User is never granted `owner`, never grants or revokes a role, never
-  creates a namespace and never creates a table outside a namespace. A Team holding
-  `owner` gives its workload members no access management.
+- A workload User is never granted `owner`, never grants or revokes a role and never
+  creates a table outside a namespace. It creates a namespace only by registering a
+  table into a free name, and then holds `editor`. A Team holding `owner` gives its
+  workload members no access management.
 - A non-admin grants roles only to Teams they belong to, checked with the platform at
   that moment, and to people and workload Users they can find in their own platform
   directory.
@@ -233,7 +243,9 @@ workload Users, Teams.
 
 1. hold `set_access` on the object and every action of the role on it (owners and
    admins always do); or
-2. manage the target workload User and hold every action of the role on the object.
+2. manage the target workload User and hold every action of the role on the object; or
+3. manage the namespace's creating workload: any role, `owner` included, on that
+   namespace.
 
 Revoking your own binding, and lowering or revoking a binding of a workload you manage,
 are always allowed. Revoking the last owner leaves the admins. Every grant and revoke is
@@ -264,45 +276,44 @@ tables and whose FastAPI `crm-api` reads and writes them. Nothing exists yet.
 ```text
  Ana (no admin role)                          MetaTables of the Environment
  ───────────────────                          ─────────────────────────────
- 1. create namespace crm  ──────────────────► namespace crm      Ana: owner (creator)
-    (namespaces.create, through member)
+ 1. push the workflow file ──► the platform creates migrate-crm and crm-api
+                               and their workload Users; Ana manages them
 
- 2. push the workflow file ──► the platform creates migrate-crm and crm-api
-                               and their workload Users
+ 2. deploy: migrate-crm  ───────────────────► namespace crm      migrate-crm: editor
+            registers its tables in crm                          (creating workload)
+                                              its tables (no binding of their own)
 
- 3. grant on crm  ──────────────────────────► migrate-crm: editor
-    (owner of crm)                            crm-api:     data_writer
-                                              directly, or to a Team
-                                              Ana belongs to that contains them
+ 3. grant on crm  ──────────────────────────► crm-api:     data_writer
+    (manages migrate-crm)                     Ana or a Team she belongs to: owner
 
- 4. deploy:  migrate-crm ───────────────────► creates its tables in crm
-                                              (no binding of their own)
-             crm-api     ───────────────────► reads and writes their rows
+ 4. crm-api  ───────────────────────────────► reads and writes their rows
 ```
 
-1. **Namespace.** Ana creates `crm` with `namespaces.create`, which every person holds
-   through `member`, and becomes its `owner`.
-2. **Workloads.** Applying the workflow file creates both workload Users before any of
-   its Jobs run.
-3. **Access.** As `owner`, Ana grants `editor` to the migration Job's workload User and
-   `data_writer` to the FastAPI's, either directly or through a Team she belongs to that
-   contains them.
-4. **Deploy.** The Job creates and migrates its tables; the FastAPI uses them.
+1. **Workloads.** Applying the workflow file creates both workload Users before any of
+   its Jobs run. The platform reports that Ana manages them.
+2. **Namespace and tables.** The first deployment's migration Job registers its tables
+   in `crm`. The namespace does not exist, so the registration creates it, grants the
+   Job `editor` and records it as the creating workload.
+3. **Access.** Because she manages `migrate-crm`, Ana manages `crm`'s access. She grants
+   `data_writer` to the FastAPI's workload User, and `owner` to herself or to a Team she
+   belongs to, so the namespace keeps an owner if the Job is recreated.
+4. **Use.** The FastAPI reads and writes rows; its requests before step 3 were refused,
+   and succeed on the next request after it, with no redeployment.
 
 This completes without an administrator:
 
-- Every step needs only `member`, held by every person, or the `owner` binding Ana
-  received in step 1.
-- A Team is optional. With direct bindings, a recreated workload's new User needs the
-  owner to grant its role again. With a Team, it needs only Team membership.
-- The workload Users exist only once step 2 applies the file. If the first migration
-  runs before step 3, it stops with `namespace_access_required`, naming the Job's
-  workload User, the namespace, the missing action and the namespace's owners; re-running
-  it after step 3 succeeds. If step 1 is missing, it stops with `namespace_not_found`.
+- Every step needs only the push, the registration in step 2, or managing the Job.
+- No namespace is created by hand, and the first migration succeeds.
+- A Team is optional. With direct bindings, a recreated workload's new User needs an
+  owner, or a manager of the creating workload, to grant its role again. With a Team,
+  it needs only Team membership.
+- A taken name stops the migration with `namespace_access_required`, naming the Job's
+  workload User, the namespace, the missing action and the owners when the Job may see
+  them. An owner grants the Job `editor`, or the application uses another namespace.
 - Least privilege holds from the start: the FastAPI writes rows but cannot migrate,
-  delete or share.
-- Each Environment has its own MetaTables. Another Environment repeats steps 1 and 3
-  there, done by someone the platform admits to it.
+  delete or share, and the Job never decides access.
+- Each Environment has its own MetaTables. The first deployment there creates the
+  namespace; step 3 is repeated by someone who manages the Job in that Environment.
 
 ### 6. API and clients
 
@@ -310,13 +321,15 @@ This completes without an administrator:
   texts. The role documentation is generated from it.
 - `POST /namespaces/` creates a namespace (replaces `POST /security/namespaces/`).
 - `GET /namespaces/{uid}/access/` and `GET /meta-tables/{uid}/access/` return the
-  bindings with their source, who granted each and when.
+  bindings with their source, who granted each and when. A namespace's document also
+  names its creating workload.
 - `POST .../access/changes/` grants and revokes roles in one request, checked against
   the access revision the caller read.
 - `GET .../access/me/` returns the caller's allowed actions; the Admin shows only the
   buttons they allow.
 - `GET .../access/explain/?user_uid=...&action=...` explains why someone can or cannot
-  do something.
+  do something. The `manager` source is shown only for the caller: the platform tells
+  only the caller which workloads they manage.
 - Removed: `PUT /meta-tables/{uid}/permissions`, `PUT /namespaces/{uid}/permissions`,
   `POST /security/namespaces/` and the Reader/Writer assignment documents.
 - The Python client gets `Namespace.create()`, `get_access()`, `grant_role()`,
@@ -337,7 +350,8 @@ One new system migration converts every grant, with no compatibility layer:
 | Namespace Writer | `editor` |
 | Namespace without an owner | none; admins hold it until they grant an owner |
 
-Access history is kept.
+Access history is kept. A second migration records each namespace's creating workload;
+existing namespaces have none, and their owners and admins manage them.
 
 ## Consequences
 
@@ -348,8 +362,11 @@ Access history is kept.
   that person's access.
 - A workload can no longer create a table outside a namespace. Updater Jobs that do so
   today must set a namespace.
-- Any person may claim a free namespace name. Admins can rename a namespace or change its
-  owners.
+- Any person, or a workload by registering a table, may claim a free namespace name.
+  Admins can rename a namespace or change its owners.
+- The people who manage a namespace's creating workload manage its access for as long as
+  the platform reports that they manage it. A namespace whose creating workload nobody
+  manages any more keeps its owners, and admins.
 - The catalog stores bindings instead of Reader/Writer flags, every route checks an
   action, and database reconciliation gains the admin role.
 - This amends ADR 0002 (namespace access is no longer admin-only; Reader/Writer become
@@ -363,5 +380,7 @@ Access history is kept.
 - The conversion migration on a catalog with every kind of existing grant.
 - The deployment of section 5 end to end as a non-admin, with direct bindings and with a
   Team; a recreated workload; a namespace name already taken.
+- A workload's registration creates the namespace with `editor`; a manager of the Job
+  grants any role; anyone else is refused.
 - In the database: `data_viewer` gets `SELECT` only; `data_writer` writes rows but its
   migration admission is refused; an admin reads a table without a binding.

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/docs/client/deploy-application-migrations.md

@@ -15,13 +15,16 @@ before anything that uses the tables rolls out. See
    [Local storage](local-storage.md).
 2. **Commit the revision with the code that needs it.** Applied revisions are
    immutable; every later schema change is a new revision.
-3. **Give the Job access.** Before the first push to each Environment, create the
-   application's namespace; once the workload Users exist, grant them their roles
-   ([below](#give-the-job-access)). Any person can; no Organization admin is needed.
-4. **Deploy.** The application's workflow runs its migration Job from the
-   candidate image, then deploys the resources that read or write the tables.
-
-Hosted runtimes are migrated only by step 4. Do not run `metatables migrations
+3. **Deploy.** The application's workflow runs its migration Job from the
+   candidate image, then deploys the resources that read or write the tables. The
+   first deployment to an Environment creates the application's namespace there and
+   gives the Job `editor` on it.
+4. **Grant the other workloads.** Someone who manages the migration Job grants the
+   resources that read and write rows their roles on the namespace
+   ([below](#give-the-job-access)). Nobody creates the namespace by hand, and no
+   Organization admin is needed.
+
+Hosted runtimes are migrated only by step 3. Do not run `metatables migrations
 upgrade` or `downgrade` against a hosted API from a developer machine or agent
 session. Do not migrate at application startup either: several pods would race,
 and a failure would not stop the rollout.
@@ -73,7 +76,7 @@ for provider in ("ledger.migrations:migration",):
 Gate the deployments on it in `.mainsequence/workflows/<application>.yaml`:
 
 ```yaml
-api_version: "2.3.0"
+api_version: "3.0.0"
 name: ledger
 resources:
   - key: ledger-api
@@ -111,48 +114,54 @@ against the branch's workflow template before committing it.
 
 ## Give the Job access
 
-The Job runs as its own workload User. Workloads never create namespaces, never grant
-roles, and create tables only inside a namespace where they hold `editor`
-([ADR 0024](../adr/api/0024-namespace-and-table-access-roles.md)). So a person sets up
-the application's access, once per Environment, and no Organization admin is needed.
-Do it in this order:
-
-1. **Before the first push, create the namespace.** Any person admitted to the
-   Environment can, in that Environment's MetaTables: with **Create namespace** on the
-   deployed Admin's Namespaces page, or with `Namespace.create("ledger")` from your own
-   session connected to that Environment
-   ([installation and connection](installation-and-connection.md)). You become its
-   `owner`. A name that is already taken is refused with its owners, when you can see
-   them; ask one of them for access instead.
-2. **Push the workflow file.** Applying it creates the Job, the FastAPI release and
-   their workload Users before any step runs. The first migration can run before
-   step 3 and stop with `namespace_access_required`; that is expected.
-3. **Grant the workloads their roles.** On the namespace's **Access** panel, find each
-   workload by its Job or release name and grant the migration Job `editor` and every
-   resource that only reads and writes rows, such as the FastAPI release, `data_writer`.
-   From Python, pass each resource's `workload_user_uid`, which the Main Sequence SDK
-   returns on the Job and the ResourceRelease.
-4. **Re-run the migration Job** if step 2's run was refused, or deploy again. It creates
-   the application's tables in the namespace; the tables need no grants of their own.
-
-Repeat steps 1, 3 and 4 in every Environment, each done by someone the platform admits
-to that Environment: each Environment has its own MetaTables and its own workload Users.
+The Job runs as its own workload User. A workload never grants roles and never creates
+a table outside a namespace ([ADR 0024](../adr/api/0024-namespace-and-table-access-roles.md)).
+It creates its namespace by registering its first table there:
+
+1. **Push the workflow file.** Applying it creates the Job, the FastAPI release and
+   their workload Users before any step runs.
+2. **The first migration creates the namespace.** When a provider's tables name a
+   namespace that does not exist in this Environment, the Job's registration creates
+   it and grants the Job `editor`. The namespace records the Job as its creating
+   workload. Later runs and new tables need nothing more.
+3. **Grant the other workloads, and an owner.** The people who manage the Job in the
+   platform manage the namespace's access. In that Environment's Admin, open the
+   namespace's **Access** panel, find each workload by its Job or release name, and
+   grant `data_writer` to every resource that only reads and writes rows, such as the
+   FastAPI release. Grant `owner` to yourself or to a Team you belong to, so the
+   namespace keeps an owner if the Job is recreated. From Python, pass each resource's
+   `workload_user_uid`, which the Main Sequence SDK returns on the Job and the
+   ResourceRelease. The FastAPI's requests are refused until then, and succeed on the
+   next request after the grant, with no redeployment.
+
+Repeat step 3 in every Environment, done by someone who manages the Job there: each
+Environment has its own MetaTables and its own workload Users.
 
 ```python
 from metatables import Namespace
 
-ledger = Namespace.create("ledger")                       # step 1: you become its owner
-ledger.grant_role(migration_job_workload_user_uid, "editor")   # step 3
-ledger.grant_role(api_workload_user_uid, "data_writer")
+ledger = next(n for n in Namespace.filter(search="ledger") if n.name == "ledger")
+ledger.grant_role(api_workload_user_uid, "data_writer")       # step 3
+ledger.grant_role(your_user_uid, "owner")
 ```
 
+Managing the Job lets you manage the namespace's access only: it gives you no access
+to its tables until you grant yourself a role.
+
 **Optionally, a Team.** Grant the roles to a Team you belong to instead of to the
 workload Users, and add the workload Users to that Team: any person can create a Team
 and, as its owner, add workloads they can view. A recreated Job or release then needs
 only Team membership, not a new grant. One Team can hold the roles in every Environment:
 Teams are Organization-wide, and a workload reaches only its own Environment's
 MetaTables. People in the Team receive the same roles, so leave it once the workloads
-are in if you should not hold them yourself; you stay the namespace's owner.
+are in if you should not hold them yourself.
+
+**A name that is already taken.** If the namespace already exists, created by another
+application, by a person or before this change, the first migration stops with
+`namespace_access_required`. An owner of that namespace grants the Job `editor`, or the
+application uses another namespace. A person may still create a namespace in advance,
+with **Create namespace** in the Admin or `Namespace.create("ledger")`, and grant the
+Job `editor`; nothing requires it.
 
 **Namespaces created before roles.** A namespace from before ADR 0024 has no owner: its
 former Writers hold `editor`. An Organization admin grants someone `owner` on it once;
@@ -161,8 +170,9 @@ from then on that owner manages it.
 One namespace per application is the recommended layout, not a rule; see
 [Namespaces and applications](../security/ownership-and-sharing.md#namespaces-and-applications).
 
-The Job also needs platform `view` on the Environment's `metatables` release and
-its branch to discover the API; declare it on the Job:
+The Job also needs the platform's `reader` policy on the MetaTables branch, which
+gives it `viewer` on the branch's `metatables` release, to discover the API. Declare it
+on the Job (workflow API `3.0.0`):
 
 ```yaml
   - key: migrate-ledger
@@ -173,7 +183,7 @@ its branch to discover the API; declare it on the Job:
     access:
       branches:
         - repository: MetaTables
-          level: view
+          policy: reader
 ```
 
 `upgrade_application()` waits up to five minutes for the API to wake or finish
@@ -187,18 +197,17 @@ the database.
 
 ### When registration is refused
 
-- **`namespace_not_found`**: the namespace does not exist in this Environment. Create
-  it (step 1) and grant the roles (step 3).
-- **`namespace_access_required`**: the namespace exists, but the `caller_user_uid` the
-  error names lacks `tables.create` on it. The error lists the namespace's owners when
-  the caller can see the namespace; one of them grants it `editor` (step 3). Expected
-  on a new application's first run.
+- **`namespace_access_required`**: the namespace already exists, but the
+  `caller_user_uid` the error names lacks `tables.create` on it. The error lists the
+  namespace's owners when the caller can see the namespace. One of them, or a manager
+  of the workload that created the namespace, grants it `editor`. A recreated Job gets
+  this too: its new workload User has no role yet.
 - **`namespace_required`**: a workload tried to create a table outside any namespace.
   Set the table's namespace.
 - **`table_not_editable`**: the table already exists and the caller lacks
   `tables.update` on it. An owner of the table or its namespace grants `editor`.
 
-After the grant, re-run the Job (step 4). Do not run the Job as an Organization admin
+After the grant, re-run the Job. Do not run the Job as an Organization admin
 or change physical names to get around a refusal.
 
 ## What the Job guarantees
@@ -212,8 +221,8 @@ or change physical names to get around a refusal.
 - The Job finds the Environment's MetaTables API the same way any client does
   ([installation and connection](installation-and-connection.md)). That API must
   be deployed with its system migrations applied; otherwise the Job fails. Its
-  workload User needs `editor`, directly or through a Team, on every namespace the
-  provider creates tables in.
+  workload User needs `editor`, directly or through a Team, on every existing
+  namespace the provider creates tables in; a namespace it creates gives it `editor`.
 
 ## Keep each release compatible with the previous one
 

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/docs/concepts/permissions-namespaces-labels.md

@@ -14,8 +14,11 @@ every action, data included.
 ## Namespaces
 
 A catalog namespace groups tables for access. Any person can create a namespace whose
-name is free and becomes its owner. A namespace is visible to whoever holds a role on
-it or can see at least one of its tables; counts show visible tables only. A role on a
+name is free and becomes its owner. Registering a table into a missing namespace also
+creates it: a person owns it; a workload gets `editor`, and the people who manage that
+workload manage the namespace's access. A namespace is visible to whoever holds a role
+on it, can see at least one of its tables, or manages its creating workload; counts
+show visible tables only. A role on a
 namespace gives the table role of the same name on its current and future tables.
 Revoking it, or moving a table out, removes that contribution; independent direct or
 Team bindings remain. Moving a table needs `tables.update` on the table and

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/docs/operations/hosted-runtime.md

@@ -23,7 +23,7 @@ at least two runtime replicas; see [pods and connections](#size-pods-and-databas
 The platform applies these settings on the next successful deployment.
 
 The Python package bundles this same workflow for [client discovery](../client/installation-and-connection.md).
-Workflow API `2.3.0` derives a FastAPI release name from the directory containing
+Workflow API `3.0.0` derives a FastAPI release name from the directory containing
 `source_path`, so the declared directory is also the client's exact lookup name.
 Do not maintain a separate name constant in consuming projects. After changing
 that source path, publish/install a matching package build. Clients select the

{mainsequence_metatable-0.1.47.dev75 → mainsequence_metatable-0.1.48.dev77}/docs/security/index.md

@@ -4,8 +4,10 @@ MetaTables separates **application administration** from **access to namespaces
 and tables**. Organization admins configure the application and hold every action.
 Everyone else gets access through **roles** granted on a namespace or a table:
 `metadata_viewer`, `data_viewer`, `data_writer`, `editor` and `owner`. Any person can
-create a namespace or a table and owns what they create. Nobody needs to become an
-Organization admin to deploy an application or maintain its tables.
+create a namespace or a table and owns what they create. A deployed migration Job
+creates its application's namespace on its first run, and the people who manage the
+Job manage that namespace's access. Nobody needs to become an Organization admin to
+deploy an application or maintain its tables.
 
 The API enforces this model in both local and hosted runtimes. The Admin UI and
 Python client use the same access endpoints. [ADR 0024](../adr/api/0024-namespace-and-table-access-roles.md)
@@ -92,7 +94,8 @@ These are browser routes. Resource API URLs remain unchanged and enforce their
 own permissions: DataSource mutations and validation, runtime configuration and
 selection, system migrations, local database destruction, external imports and
 global Security operations require admin admission. Granting roles on a namespace or
-table is available to its owners.
+table is available to its owners, and on a namespace also to the managers of the
+workload that created it.
 
 Every operation is enforced by the API, including requests from the Python client.
 The UI shows the API's effective permissions. Hidden buttons are a presentation