mainsequence-metatable 0.1.46.dev73__tar.gz → 0.1.47.dev75__tar.gz

{mainsequence_metatable-0.1.46.dev73 → mainsequence_metatable-0.1.47.dev75}/.agents/skills/client/metatables-meta-tables/SKILL.md

@@ -58,7 +58,7 @@ contract. Preserve the user's existing authorization and scope.
 
 A UID is catalog identity. An optional identifier is unique in the connected catalog.
 A physical binding is DataSource + schema + table name. A catalog
-namespace groups resources and grants; it is not a SQL schema. Contract hashes
+namespace groups tables for access: a role on it applies to every table in it. It is not a SQL schema. Contract hashes
 are fingerprints, not table identity. See `docs/concepts/identity-and-scope.md`.
 
 ## SQLAlchemy contract rules

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

@@ -46,15 +46,31 @@ 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.** Before the first hosted migration in each
-   Environment, a person (no admin needed) creates each namespace the provider
-   creates tables in, with `Namespace.create(name)` or the Admin, and becomes its
-   `owner`. As owner they grant `editor` to the migration Job's workload User and
-   `data_writer` to resources that only read and write rows, directly or through a
-   Team they belong to that contains those workloads. Recommend one namespace per
+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
    application; it is not required (see "Namespaces and applications" in
-   `docs/security/ownership-and-sharing.md`). Tell the user these steps; they are
-   made in MetaTables (and, for a Team, the platform), not in the repository.
+   `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
@@ -252,11 +268,12 @@ Read `docs/operations/recovery-and-observability.md`.
   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. With `namespace_access_required`, an owner
-  the error lists grants the `caller_user_uid` `editor` on the namespace, or adds it
-  to a Team that holds it. 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.
+  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
+  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.
 - If reservation fails otherwise, compare provider scope and physical identities
   before changing code. Do not create a second catalog row for the same table.
 - If Alembic succeeds but finalization fails, physical DDL may already be

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

@@ -51,6 +51,14 @@ The optional `hash_namespace` separates producer identities, **not output tables
 A test namespace alone does not protect shared physical rows. Use a disposable
 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
+[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.
+
 ## Configuration and dependencies
 
 Use `TimeIndexTableUpdateConfig` with described `Field` values and realistic

{mainsequence_metatable-0.1.46.dev73/src/mainsequence_metatable.egg-info → mainsequence_metatable-0.1.47.dev75}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.46.dev73
+Version: 0.1.47.dev75
 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.46.dev73 → mainsequence_metatable-0.1.47.dev75}/docs/adr/api/0024-namespace-and-table-access-roles.md

@@ -2,10 +2,12 @@
 
 Status: Accepted.
 
-Implementation status: implemented on development. Non-container tests pass; the
-container database suites and the MetaTables Admin's Access panels are pending. The
-user guides are [Ownership, roles, and inheritance](../../security/ownership-and-sharing.md)
-and the [actions and roles](../../security/permissions.md).
+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;
+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
+[actions and roles](../../security/permissions.md).
 
 Owner: MetaTables API, with client and Admin consumers.
 

{mainsequence_metatable-0.1.46.dev73 → mainsequence_metatable-0.1.47.dev75}/docs/adr/index.md

@@ -41,7 +41,7 @@ decisions belong in the SDK repository and are linked as dependencies.
 | [0018: Table search by meaning and columns](api/0018-table-search.md) | Accepted; implemented; container engine verification pending | One route ranks visible tables by BM25 keywords and a local English embedding model over a per-table document that includes columns, merges the rankings and returns `matched_columns`; the index refreshes on every metadata write. |
 | [0022: Concurrent requests per pod and reused database connections](api/0022-concurrent-requests-and-connection-reuse.md) | Accepted; implemented on development; deployment and load verification pending | One number per pod sizes its threads, data-request admission, catalog pool and login-role connections; connections are reused only by the role that opened them, and maximum pods × 3T stays within the database's connection limit. |
 | [0023: A daily security check instead of a sweep in every deployment](api/0023-daily-security-check.md) | Accepted; implemented on development; deployment and first scheduled run pending | A deployment sets up only what the new release needs; a daily Job, which administrators can also start, repairs whatever differs from the plan without pausing caller SQL and records its outcome. |
-| [0024: Access roles for namespaces and tables](api/0024-namespace-and-table-access-roles.md) | Accepted; implemented on development; container suites and Admin pending | Actions and roles (`metadata_viewer`, `data_viewer`, `data_writer`, `editor`, `owner`) replace Reader/Writer; `namespaces.create` and `tables.create` are checked on the parent, the creator of a namespace owns it, admins hold every action, workloads use access but never manage it, and an ordinary user deploys a new application without an admin. |
+| [0024: Access roles for namespaces and tables](api/0024-namespace-and-table-access-roles.md) | Accepted; implemented on development (API and Admin); hosted deployment pending | Actions and roles (`metadata_viewer`, `data_viewer`, `data_writer`, `editor`, `owner`) replace Reader/Writer; `namespaces.create` and `tables.create` are checked on the parent, the creator of a namespace owns it, admins hold every action, workloads use access but never manage it, and an ordinary user deploys a new application without an admin. |
 
 ## Agents
 

{mainsequence_metatable-0.1.46.dev73 → mainsequence_metatable-0.1.47.dev75}/docs/client/deploy-application-migrations.md

@@ -15,9 +15,9 @@ 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 hosted migration in each Environment,
-   create the application's namespace and grant the Job `editor` on it
-   ([below](#give-the-job-access)). No Organization admin is needed.
+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.
 
@@ -111,34 +111,54 @@ against the branch's workflow template before committing it.
 
 ## Give the Job access
 
-The Job runs as its own workload User. Workload Users never create namespaces or own
-tables, so a person sets up the application's namespace once per Environment
-([ADR 0024](../adr/api/0024-namespace-and-table-access-roles.md)):
-
-1. **Create the namespace.** Any person can, in that Environment's MetaTables (the
-   Admin's namespace page, or `Namespace.create("ledger")` from Python). The creator
-   becomes its `owner`.
-2. **Grant the workloads their roles.** As owner, grant `editor` to the migration
-   Job's workload User and `data_writer` to resources that only read and write rows,
-   such as the FastAPI release. Each resource's `workload_user_uid` names it, and its
-   workload User exists as soon as the workflow file is applied.
-3. **Optionally use a Team.** Instead of the workload Users, grant the roles to a
-   Team you belong to and add the workload Users to it. A recreated Job then needs
-   only Team membership, not a new grant. Teams are Organization-wide and a workload
-   reaches only its own Environment's MetaTables, so one Team can hold the roles in
-   every Environment.
+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.
 
 ```python
 from metatables import Namespace
 
-ledger = Namespace.create("ledger")
-ledger.grant_role(migration_job_workload_user_uid, "editor")
+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")
 ```
 
-Every table the Job creates in the namespace is covered by these roles and gets no
-binding of its own. One namespace per application is the recommended layout, not a
-rule; see
+**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.
+
+**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;
+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
@@ -167,19 +187,19 @@ the database.
 
 ### When registration is refused
 
-- **`namespace_not_found`**: the namespace does not exist in this Environment.
-  Create it (step 1) and grant the role (step 2).
-- **`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 `editor` (step 2).
+- **`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_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. Ask an owner of the table or its namespace to grant `editor`.
+  `tables.update` on it. An owner of the table or its namespace grants `editor`.
 
-The first deployment of a new application can run its migration before step 2: the
-workload Users exist only once the workflow file is applied. Re-run the Job after
-granting the role.
+After the grant, re-run the Job (step 4). Do not run the Job as an Organization admin
+or change physical names to get around a refusal.
 
 ## What the Job guarantees
 

{mainsequence_metatable-0.1.46.dev73 → mainsequence_metatable-0.1.47.dev75}/docs/security/ownership-and-sharing.md

@@ -169,12 +169,14 @@ tables without a namespace.
 
 ### Recommended: one namespace per application
 
-1. A person creates the application's namespace, for example `crm`, and becomes its
-   owner.
-2. They grant `editor` to the migration Job's workload User and `data_writer` to the
-   workload Users that only read and write rows, or grant these roles to Teams they
-   belong to that contain those workloads.
-3. The migration Job creates and migrates the application's tables in `crm`.
+1. Before the first push, a person creates the application's namespace, for example
+   `crm`, and becomes its owner.
+2. Pushing the workflow file creates the workload Users. The owner grants `editor` to
+   the migration Job's workload User and `data_writer` to the workload Users that only
+   read and write rows, or grants these roles to a Team they belong to that contains
+   those workloads.
+3. The migration Job creates and migrates the application's tables in `crm`. If its
+   first run came before step 2, re-run it.
 
 This needs no Organization admin. A Team is optional: it saves granting again when a
 workload User changes. Teams are Organization-wide and a workload reaches only its

{mainsequence_metatable-0.1.46.dev73 → mainsequence_metatable-0.1.47.dev75}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "mainsequence-metatable"
-version = "0.1.46.dev73"
+version = "0.1.47.dev75"
 description = "Main Sequence MetaTables Python client and standalone API"
 readme = "README.md"
 requires-python = ">=3.13"

{mainsequence_metatable-0.1.46.dev73 → mainsequence_metatable-0.1.47.dev75/src/mainsequence_metatable.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.46.dev73
+Version: 0.1.47.dev75
 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.46.dev73 → mainsequence_metatable-0.1.47.dev75}/uv.lock

@@ -854,7 +854,7 @@ mcp = [
 
 [[package]]
 name = "mainsequence-metatable"
-version = "0.1.46"
+version = "0.1.47"
 source = { editable = "." }
 dependencies = [
     { name = "alembic" },