PyPI - mainsequence-metatable - Versions diffs - 0.1.48.dev77__tar.gz → 0.1.49.dev78__tar.gz - Mend

Files changed (603) hide show

{mainsequence_metatable-0.1.48.dev77 → mainsequence_metatable-0.1.49.dev78}/.agents/skills/client/metatables-migrations/SKILL.md RENAMED Viewed

@@ -46,22 +46,34 @@ 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.** 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
+3. **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, 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. Pushing the file creates the Job's and the other
+   resources' workload Users before any step runs. The first migration in an
+   Environment 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.
+   Nothing is created by hand and no Organization admin is needed: do not tell the
+   user to create the namespace before the push.
+4. **Grant the other workloads, and an owner.** Follow "Give the Job access" in
+   `docs/client/deploy-application-migrations.md`, in each Environment. A person who
+   manages the Job in the platform manages the namespace's access: they grant
+   `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`. Until then those resources' requests are refused; they succeed
+   on the next request after the grant, with no redeployment, so do not redeploy or
+   change code for that. They also grant `owner` to themselves or to a Team they belong
+   to, so the namespace keeps an owner when the Job is recreated: their authority
+   follows the workload User that created the namespace, and a recreated Job runs as a
+   new one. Managing the Job gives no access to the namespace's tables until they grant
+   themselves a role. A Team holding the roles with the workloads as members is
+   optional; it saves granting again when a Job or release is recreated.
+   Step 4 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
@@ -70,14 +82,6 @@ migrations. Read `docs/client/deploy-application-migrations.md`.
    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, 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.
 Rules:
@@ -311,5 +315,6 @@ Read `docs/operations/recovery-and-observability.md`.
 Verify provider scope and placement, revision content, the selected environment
 connection, repeat execution, and final active bindings. Check that the deployment
 workflow runs the migration Job before every resource that uses the tables, and
-that each Environment's namespaces grant the Job's workload User `editor`. Report
+that in each Environment the Job's workload User holds `editor` on its namespaces, the
+other resources hold the roles they need, and a person or Team holds `owner`. Report
 separately what was checked offline and what was exercised against a configured API.

@@ -131,7 +131,9 @@ To find tables, use `MetaTable.search` as described in the
 sharing/label actions are not supported API workflows.
 Use `get_access`, `grant_role`, `revoke_role`, `allowed_actions` and `explain` on a
 table or `Namespace` for roles (`metadata_viewer`, `data_viewer`, `data_writer`,
-`editor`, `owner`); `Namespace.create(name)` makes the caller its owner. Labels can be
+`editor`, `owner`); `Namespace.create(name)` makes the caller its owner. Registering a
+table into a missing namespace also creates it: a person gets `owner`, a workload `editor`
+(see the [migrations skill](../metatables-migrations/SKILL.md)). Labels can be
 changed through the documented table PATCH path. Authorization is owned by the API
 catalog; see `docs/security/ownership-and-sharing.md`.

@@ -54,7 +54,7 @@ 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. 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
+an owner, grants these on the namespaces, directly or through a Team (step 4 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.

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

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

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

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

mainsequence-metatable 0.1.48.dev77__tar.gz → 0.1.49.dev78__tar.gz

mainsequence-metatable 0.1.48.dev77tar.gz → 0.1.49.dev78tar.gz