mainsequence-metatable 0.1.30.dev56__tar.gz → 0.1.31__tar.gz

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/.agents/skills/client/metatables-migrations/SKILL.md

@@ -190,12 +190,43 @@ API Writer checks govern connection admission and provider catalog operations.
 The client reserves catalog entries, runs Alembic, closes its physical connection,
 and finalizes contracts through the API. Treat connection material as private.
 
-Python code can call `metatables.upgrade_application("ledger.migrations:migration")`;
-`src/metatables/examples/scripts/setup_metatables.py` shows the pattern, and the
-deployment migration Job uses the same call. Remove the retired
+Applications and consuming libraries use the same public Python entry point in
+an explicit setup function or deployment migration Job:
+
+```python
+from metatables import upgrade_application
+
+result = upgrade_application("ledger.migrations:migration")
+```
+
+`src/metatables/examples/scripts/setup_metatables.py` shows the pattern. Keep
+migration execution out of a library's import-time side effects. Remove the retired
 `application_migration_providers` setting and use Python references instead of aliases.
 Application migration histories remain separate from API system migrations.
 
+## Repeated runs and migration performance
+
+Use the shared `upgrade_application` path for every provider. Table-inventory and
+physical-inspection batching are automatic in the client/API implementation; no
+separate batching import, private backend helper or opt-in flag is needed.
+An unchanged Alembic revision still reconciles physical contracts and refreshes
+table descriptions, labels and column metadata. Do not skip finalization based
+only on `migrated=False` or equal revision heads: missing/unreadable tables must
+still fail, and only explicit removals may delete a catalog binding.
+
+For a slow migration, read the "Migration timings" section in
+`docs/client/deploy-application-migrations.md`. Enable INFO logging for
+`metatables.migrations.runner` to see preparation, database setup, table checks,
+Alembic, finalization and total duration. The API logs inspection and total time
+per finalization batch. Measure these separately from platform job scheduling
+and workflow coordination before attributing the delay to schema validation.
+
+Check the installed client and deployed API versions. Client optimizations need
+a package update and application image rebuild; API batching needs a shared API
+deployment. After installing a release containing the changes, refresh copied
+skills with `metatables copy-metatables-skills --path /path/to/application`.
+This command copies guidance; Python imports alone do not refresh it.
+
 ## Lifecycle invariants
 
 - Provider tables and the Alembic registry are `platform_managed` +

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.30.dev56
+Version: 0.1.31
 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.30.dev56 → mainsequence_metatable-0.1.31}/docs/adr/api/0007-database-enforced-table-access.md

@@ -51,6 +51,15 @@
 > are when grants changed outside MetaTables are repaired, not on every catalog
 > change. MySQL and SQL Server keep the full sweep on every change.
 
+> Amendment (2026-10-10): [ADR 0014](0014-main-sequence-release-jobs-and-production-migrations.md#conditional-system-bootstrap-2026-10-10-amendment)
+> replaces the unconditional deployment sweep on PostgreSQL/TimescaleDB with
+> fresh native-security and login validation under the security-state lock.
+> Every deployment still checks table policies. Unchanged security evidence uses
+> incremental grant application and one conditional write of the complete
+> manifest; drift, credential rotation, pending state or missing evidence retains
+> full repair. An explicit admin repair remains a full sweep. A routine catalog
+> update must not establish a new native baseline for unverified outside drift.
+
 > Amendment (2026-10-09): [ADR 0022](0022-concurrent-requests-and-connection-reuse.md)
 > reuses login-role connections within a pod, only by the login role that opened them
 > and never through `SET ROLE`; no session state carries over from one use to the next.

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/docs/adr/api/0013-application-owned-migrations.md

@@ -95,6 +95,80 @@ requires inspection and application-owned recovery. No server executor journal i
 claimed for client DDL. Downgrade to base clears the recorded revision and reconciles
 dropped tables. Revision files already applied remain immutable.
 
+### Batched inspection (2026-10-09 amendment)
+
+This is an implementation refinement of the lifecycle above, not a change to
+execution ownership, authorization or the migration API.
+
+- The client reads one table inventory per schema before Alembic and a fresh one
+  afterwards. Missing inventory entries still use `has_table` so views and temporary
+  tables retain their previous behavior. The first pass also rejects unversioned
+  application storage; it is not repeated for that check.
+- The API authorizes every requested binding before physical inspection. It resolves
+  the admitted DataSource once per finalization request and shares a read connection
+  across its tables. PostgreSQL/TimescaleDB use four metadata queries per schema
+  (plus a diagnostic query for missing tables). SQLite/MySQL/SQL Server use SQLAlchemy
+  bulk reflection with dialect fallbacks and preserve their existing projections.
+- Reflection caches last only for that inspection. No snapshot is reused across DDL
+  or requests. An unchanged Alembic revision still finalizes physical contracts and
+  refreshes semantic metadata; it is not evidence that the database has no drift.
+- Missing, inaccessible and foreign-owned tables keep their existing failure
+  semantics. A bulk database error falls back to independent table inspections after
+  closing the failed transaction, so an unrelated table can still finalize. Only
+  explicitly removed, physically absent application tables lose their binding.
+- Client phase timings and API inspection/total timings report where time is spent.
+  They do not include platform job scheduling or workflow coordination.
+
+The client still sends bounded finalization requests (ten tables per batch); the
+HTTP request/response contract is unchanged. Client inventory improvements require
+a package update and application rebuild. API batching benefits existing clients
+after the shared API is deployed, with larger gains for clients sending batches.
+
+### Conditional catalog reconciliation (2026-10-10 amendment)
+
+Reconciliation means making the catalog describe the freshly observed physical
+table while preserving declared semantic metadata. It is additional MetaTables
+behavior around Alembic, not an instruction to reapply migration scripts or rebuild
+identical catalog rows. An unchanged Alembic revision does not prove absence of
+physical drift or completion of an earlier catalog finalization.
+
+```mermaid
+flowchart TD
+    A[Run pending Alembic revisions] --> B[Fresh admission and physical inspection]
+    B --> C[Reconcile physical facts with existing semantic metadata]
+    C --> D{Do stored projections match?}
+    D -->|Yes| E[Keep existing projection rows and UUIDs]
+    D -->|No| F[Replace damaged or changed projections]
+    E --> G[Update only changed contract and lifecycle fields]
+    F --> G
+    G --> H[Fresh security-policy checks and commit]
+```
+
+- Finalization retains the catalog lock, per-table Writer/provider/source checks,
+  fresh physical inspection, owner reachability, foreign-key target validation,
+  missing-table/removal handling, and Timescale hypertable checks. No physical
+  snapshot or authorization result is cached across requests.
+- The API reads existing column, index and foreign-key projections in three batch
+  queries. Comparison includes their scalar fields, full contract fragments and
+  resolved FK target UIDs, and detects missing, extra or damaged rows. Projection
+  row UUIDs and reflection ordering of independent objects are not differences;
+  column ordinals and the order of columns inside keys/indexes remain meaningful.
+- Matching projections are kept, even if only the recorded Alembic revision or
+  lifecycle metadata changes. Changed projections are replaced inside the existing
+  per-table savepoint. Equal-valued contract, snapshot and lifecycle fields are not
+  assigned, avoiding unnecessary ORM dirtiness and metadata/search writes.
+- Hosted/local runtime security-policy checks are explicitly retained at commit
+  even when table metadata is unchanged. Existing policy reconciliation repairs
+  policy differences; equal policies and their JSON permission manifest do not
+  require metadata writes. A failed physical check or conversion still fails
+  rather than being hidden by equality.
+- A healthy unchanged finalization issues no table/projection metadata DML. A
+  matching contract with damaged projections still repairs them. A previously
+  committed migration with failed finalization can retry at the same revision;
+  physical drift is freshly observed and catalog reconciliation completes without
+  replaying already-applied DDL. The response contract and client calls stay the
+  same; no consuming-application opt-in is required.
+
 ## MetaTables system migrations
 
 Hosted system upgrades also run as a deployment prerequisite Job
@@ -132,3 +206,20 @@ connection dialect/TLS options, catalog authorization and runtime hold release.
 SQLite integration tests use disposable files. Hosted driver configuration is
 checked without starting databases. Container/database-matrix tests are on demand;
 backend/runtime tests are not added to required CI checks.
+
+The batching amendment adds non-container checks for query/connection counts,
+fresh reflection after DDL, unchanged-revision reconciliation, authorization before
+inspection, independent failures and dialect fallbacks. PostgreSQL query grouping is
+checked with a recording driver; SQLite executes real local DDL. Hosted performance
+and live MySQL/SQL Server/PostgreSQL verification remain pending.
+
+The conditional-reconciliation amendment adds SQL-recording checks for zero
+metadata writes and stable projection UUIDs on unchanged finalization, damaged
+scalar/fragment and missing/extra projection repair, revision-only updates,
+semantic changes at the same revision, drift plus failed-finalization retry, and
+fresh permission/missing/inaccessible/owner checks, including self-referencing key
+projection repair. A real local-runtime check verifies zero catalog DML on an
+unchanged upgrade while still refreshing physical security policies, and detects
+a newly added trigger that changes write safety without changing the contract.
+Existing local SQLite application-provider tests verify actual physical drift and recovery without
+reapplying DDL. These are focused non-container checks, not new required CI jobs.

mainsequence_metatable-0.1.31/docs/adr/api/0014-main-sequence-release-jobs-and-production-migrations.md

@@ -0,0 +1,183 @@
+# ADR 0014: System migrations in the deployment workflow
+
+Date: 2026-10-02
+
+Status: Accepted. Implemented on `development`; hosted verification pending.
+Amended 2026-10-03 ([MetaTables #13](https://github.com/mainsequence-projects/MetaTables/issues/13)): the Job reads the declared runtime database itself
+and initializes it on the first deployment.
+
+Owners: MetaTables API. Main Sequence owns Job execution, images, deployment and
+platform authentication.
+
+Related: [ADR 0001: Runtime storage and bootstrap](0001-unified-api-storage-and-local-sqlite.md),
+[ADR 0008: Database workflows and recovery](0008-mysql-mssql-table-workflows.md) and
+[ADR 0013: Application-owned migrations](0013-application-owned-migrations.md).
+
+## Context
+
+Main Sequence deploys the hosted API from `.mainsequence/workflows/metatables-api.yaml`.
+Settings runs system migrations inside the running API, and that API can only
+apply the revisions it ships. A release's new revisions must be applied before
+its API serves.
+
+## Decision
+
+### The Job prepares the declared database (amended 2026-10-03)
+
+The Job no longer reads the running API. `metatables runtime upgrade` loads
+`runtime_database` from the candidate image's `configuration.yaml` and the
+Environment Secret it names ([ADR 0001](0001-unified-api-storage-and-local-sqlite.md)).
+Every run executes the same steps:
+
+1. Check that the login can secure the database (ADR 0007 prerequisites).
+2. Apply the system migrations.
+3. Register the runtime DataSource, or update its connection to the declaration.
+4. Freshly validate access setup and repair changes. Per-User role passwords
+   derive from the login password, so a rotated password reaches them on the
+   next deployment. The conditional reconciliation amendment below replaces
+   unconditional rebuilding on every deployment.
+
+The first deployment therefore initializes the database. A missing declaration
+or Secret, an unreachable database or unmet prerequisites fail the Job and block
+the rollout. The deployment workflow is the authority, so no admin caller is
+required. A new runtime DataSource records the Job's SDK user as its creator.
+The Job prints `initialized`, `upgraded` or `up_to_date` with the revisions.
+
+Settings' **Run MetaTables migrations** and `metatables runtime initialize` remain
+for Local mode only. The original decision follows. The amendment supersedes
+steps 1–2, the skip rules and the Settings initialization paragraph.
+
+### Conditional system bootstrap (2026-10-10 amendment)
+
+An unchanged deployment remains a validation gate, but does not restart completed
+work or rewrite an identical catalog/security projection. This concerns the
+MetaTables **system** Job, separate from application-provider finalization in
+[ADR 0013](0013-application-owned-migrations.md).
+
+```text
+resolve declaration and Secret
+  -> bootstrap lock
+  -> fresh history, recovery and runtime-binding checks
+  -> current heads + completed journal?
+       yes: fresh physical system-schema validation; preserve journal
+       no: existing Alembic execution and durable recovery; validate schema
+  -> reconcile runtime registration if changed
+  -> security-state lock; fresh native security and login validation
+  -> unchanged evidence? fresh table-policy checks; apply only grant differences
+       otherwise: full security repair, including credential rotation
+  -> commit; fresh registration/reference verification; release bootstrap lock
+```
+
+Hosted configuration defers database inspection to the authoritative preflight
+inside the bootstrap lock. The local path retains its pre-lock check, so an old
+store cannot be replaced or a new file created before compatibility is checked.
+Registration/reference validation is read again after commit under the lock;
+it does not repeat schema reflection or the already verified migration history.
+Startup and explicit activation continue their existing fresh checks.
+
+Matching Alembic heads alone are insufficient. Only a **completed** progress
+journal allows skipping Alembic and journal writes, after fresh schema validation.
+A missing journal is established through the existing path. An incomplete
+journal retains plan/binding checks, acknowledged-step recovery and rejection
+of unknown outcomes. A completed journal records its original execution; a
+source-code change without new revisions does not reset that history. Schema
+drift still blocks deployment and is not silently repaired by replaying Alembic.
+
+On PostgreSQL/TimescaleDB, the existing private `SQLSecurityState.manifest` stores
+versioned native-security evidence and a domain-separated credential checksum,
+alongside roles, memberships, privileges and routine evidence. No schema revision
+is needed. Initialization compares fresh database evidence: role attributes and
+memberships; schema, relation, column, routine, database and default ACLs; owners,
+routine definitions and row-security policies. Table data and statistics are
+excluded. Declared schemas and grant-target tables are included even when the
+login has grant authority without owning them. Fresh per-login authentication
+uses the configured TLS material and a new connection, never a pooled session
+that could conceal a password change.
+The security-state row stays locked until commit to serialize with catalog
+changes and caller admission.
+
+All registered table policies are freshly checked even on the unchanged path.
+Unchanged table owners and `PUBLIC` grants cause no ownership/revoke writes.
+Policies and grant differences still apply when a trigger or catalog change
+affects access. Native drift, credential rotation, pending/unready state or
+missing evidence invokes full repair. Login authentication failures likewise
+require repair. Exhausted login connection capacity conservatively falls back
+to the existing repair. libpq can omit SQLSTATE on a connection/authentication
+failure; these ambiguous driver connection errors also require repair rather
+than allowing a skip. Other probe failures fail deployment. An old installation
+therefore performs one full repair to establish evidence, then converges.
+Explicit admin repair remains a full sweep; MySQL/SQL Server keep their existing
+security initialization behavior.
+
+The complete manifest is compared and persisted once, including backend fields;
+reconciliation must not remove and then restore the routine fingerprint. Ordinary
+incremental changes cannot checkpoint unverified native drift as success. Failed
+security work rolls back its catalog checkpoint and remains repairable on retry.
+
+Named timings cover declaration/Secret resolution, bootstrap/security lock waits,
+preflight, catalog/Alembic execution, system-schema validation, registration,
+native security and login authentication validation, routine repair, table
+policies, roles/grants, credential-store setup, commit and final registration
+verification. Each timing
+reports completion/failure without connection strings, passwords, checksums or
+driver exception text. Successful security setup logs the selected path and its
+reason, including first-run evidence establishment.
+
+Focused verification uses disposable SQLite catalog transactions and recording
+PostgreSQL adapters: unchanged deployments invoke no Alembic or catalog/journal
+DML; unchanged native security emits no role/grant DDL or manifest UPDATE;
+schema drift, interrupted/ambiguous recovery, credential rotation, permission
+drift and failed repair remain checked. Live PostgreSQL/TimescaleDB validation is
+separate from these non-container checks.
+
+### Original decision (2026-10-02)
+
+The deployment workflow upgrades the runtime from the candidate image before the
+rollout:
+
+```text
+candidate image -> migrate-system Job -> API deployment
+```
+
+A failed upgrade blocks the rollout.
+
+The Job, `jobs/migrate_system.py`, runs `metatables runtime upgrade`:
+
+1. Find the Environment's MetaTables API the same way the client does.
+2. Read `GET /runtime-context/` as an organization admin. For admins,
+   `bootstrap.candidate` is the Settings DataSource's public configuration with
+   its Secret references; the Secrets are resolved through the SDK.
+3. Apply this package's system migrations through the shared bootstrap operation:
+   backend lock, progress recovery, runtime registration, access setup and
+   verification. A runtime already at the current revision is left untouched.
+
+The command acts only on an active runtime. With no API deployment or no active
+runtime yet, it succeeds without DDL. The Environment's DataSource is set
+through the deployed API, so if it is set the command migrates when necessary;
+if it is not, it skips migrations and the API deploys. An API release that the
+workflow created but has never deployed counts as no API deployment, so the
+first run deploys the API. A non-admin identity or an unreadable
+context fails before DDL. When it registers the runtime DataSource, it records
+the Job identity's user UID as the creator.
+
+Settings' **Run MetaTables migrations** and `metatables runtime initialize` keep
+initializing a newly selected DataSource: the API serving them is the deployed
+revision and runs its own migrations, so there is no version skew. API startup
+stays inspection-only.
+
+Both targets declare `automatic_redeployment` with `tag_regex: null`, so every
+eligible commit runs the graph. Package publication stays in GitHub Actions.
+
+The upgrade owns only `metatables.api.backend.migrations` and
+`metatables_catalog_version`. Application providers keep their own histories
+under ADR 0013.
+
+## Consequences
+
+- The previous API keeps serving during the upgrade, so each schema change must
+  stay compatible with the previous release. Coordination with its writes is not
+  defined yet.
+- An upgrade followed by a failed deployment leaves the database upgraded. There
+  is no automatic downgrade.
+- The workflow runs only when the platform receives the branch's commit.
+  Verification in a hosted Environment is pending.

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/docs/client/define-and-migrate-tables.md

@@ -89,7 +89,21 @@ metatables --local migrations upgrade --provider ledger.migrations:migration
 The local API must already be running; `--local` selects its connection, so inspect
 runtime status to verify the database actually selected in Settings.
 
-Python setup code can call `metatables.upgrade_application("ledger.migrations:migration")`.
+Applications and libraries use the same public import in their migration Job or
+explicit setup function:
+
+```python
+from metatables import upgrade_application
+
+result = upgrade_application("ledger.migrations:migration")
+```
+
+The shared runner automatically uses the installed client's table inventories and
+the API's batched finalization. No separate batching import or option is needed.
+Keep this call in the explicit migration lifecycle, rather than executing it when
+a library is imported. See [migration timings](deploy-application-migrations.md#migration-timings)
+for diagnostics and the client/API updates needed to receive these optimizations.
+
 For current and downgrade, use `metatables.migrations.runner.run_migration` with
 `operation="current"` or `operation="downgrade", revision="0001"`.
 

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/docs/client/deploy-application-migrations.md

@@ -26,6 +26,28 @@ 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.
 
+## Migration timings
+
+At INFO level, `metatables.migrations.runner` logs preparation, database setup,
+table-presence checks before and after Alembic, Alembic execution, catalog
+finalization and total duration. The API logs physical inspection and total time
+for each finalization batch. Use these to distinguish database work from platform
+scheduling and workflow coordination.
+
+An already-current database still reconciles the provider's catalog contracts.
+Checks use fresh table inventories and batched physical reflection; an unchanged
+revision does not skip missing-table checks, permissions or metadata refresh.
+PostgreSQL batches metadata queries by schema; other dialects use SQLAlchemy's
+bulk reflection and its supported fallbacks. Caches do not survive the request.
+Client improvements require updating the application's installed MetaTables package
+and rebuilding its image; API improvements require deploying the shared API.
+Applications and libraries continue to use `from metatables import upgrade_application`;
+batching is automatic in this shared path, with no new import or opt-in flag.
+After updating the installed package, refresh its agent guidance with
+`metatables copy-metatables-skills --path /path/to/application`. This copies the
+matching migration skill and its guide snapshots; importing Python code does not
+update a project's copied skills.
+
 ## Declare the migration Job
 
 Add one Job script that applies every provider the application owns, in
@@ -117,6 +139,10 @@ its branch to discover the API; declare it on the Job:
           level: view
 ```
 
+`upgrade_application()` waits up to five minutes for the API to wake or finish
+replacing its pods before it fails with `ApiResolutionError`; other client calls
+wait 30 seconds.
+
 Team membership takes effect on the workload's next request, in the catalog and in
 the database. When a workload User changes, add the new one to the Team; nothing
 in MetaTables changes. A table registered in a namespace the caller already

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/docs/client/installation-and-connection.md

@@ -74,7 +74,7 @@ application migrations, persistence and credentials.
 
 ## Copy client skills into an application
 
-After installing MetaTables, explicitly copy its five client usage skills into a
+After installing MetaTables, explicitly copy its client usage skills into a
 consuming project:
 
 ```bash
@@ -88,12 +88,17 @@ metatables --json copy-metatables-skills --path /path/to/application
 `metatables` does not copy skills.
 
 The destination is `<application>/.agents/skills/metatables/`. It contains the
-local development, table, application migration, time-index updater and legacy
+local development, table, application migration, table discovery, time-index updater and legacy
 application upgrade skills, with matching
 guide/example snapshots in each skill's `references/` folder. The installed client
 version is recorded in `PINNED_FROM.txt`. Skills for API implementation or
 MetaTables project development are outside this bundle.
 
+After upgrading the installed package, run the copy command again to refresh the
+matching guidance. The migration skill includes the public `upgrade_application`
+import, repeated-run behavior and migration timing diagnostics. Python imports
+use the installed library independently of these copied agent instructions.
+
 Running the command again replaces the whole `metatables` namespace: folders the
 installed client does not ship, including any added there, are removed. Keep the
 application's own skills in another `.agents/skills/` namespace; the copy never

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/docs/contributing/documentation.md

@@ -56,7 +56,7 @@ belong to their component documentation and project instructions.
 | --- | --- |
 | `.agents/skills/client/metatables-local-development/SKILL.md` | Local-first application development, runtime/DataSource checks, isolated verification and explicit return to the environment. |
 | `.agents/skills/client/metatables-meta-tables/SKILL.md` | SQLAlchemy contracts, external registration, governed queries and client access operations. |
-| `.agents/skills/client/metatables-migrations/SKILL.md` | Alembic providers, offline revisions, approved API-side execution and migration recovery for managed application tables. |
+| `.agents/skills/client/metatables-migrations/SKILL.md` | Application-owned Alembic providers, offline revisions, shared migration execution, timing diagnostics and recovery for managed application tables. |
 | `.agents/skills/client/metatables-table-discovery/SKILL.md` | Table search, and the authoritative rules for table descriptions, labels and column metadata (ADR 0018). |
 | `.agents/skills/client/metatables-time-index-table-updates/SKILL.md` | Producers, dependencies, incremental frames and existing-table readers. |
 

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/docs/operations/catalog-migrations.md

@@ -10,6 +10,13 @@ new image, and a failure blocks the rollout. Settings is read-only in Hosted mod
 See [the deployment gate](hosted-runtime.md#deployment-gate) and
 [ADR 0014](../adr/api/0014-main-sequence-release-jobs-and-production-migrations.md).
 
+The deployment gate checks revisions and registration during preflight, then
+validates the full system schema once inside the migration runner, including when
+the database is already current. Registration and permission setup finish under
+the same bootstrap lock. Schema reflection is batched across the required tables;
+the job logs the number of tables validated and elapsed time. Startup and explicit
+activation still perform their own fresh schema validation.
+
 Local mode initializes its SQLite file explicitly in Settings:
 
 1. Open **Settings**. Local mode prefills the single local SQLite runtime file,

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/pyproject.toml

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

{mainsequence_metatable-0.1.30.dev56 → mainsequence_metatable-0.1.31}/src/mainsequence_metatable.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.30.dev56
+Version: 0.1.31
 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.30.dev56 → mainsequence_metatable-0.1.31}/src/mainsequence_metatable.egg-info/SOURCES.txt

@@ -249,6 +249,7 @@ src/metatables/api/app/routes/update_statistics.py
 src/metatables/api/backend/__init__.py
 src/metatables/api/backend/backends/__init__.py
 src/metatables/api/backend/backends/access.py
+src/metatables/api/backend/backends/batch_inspection.py
 src/metatables/api/backend/backends/catalog.py
 src/metatables/api/backend/backends/catalog_ddl.py
 src/metatables/api/backend/backends/catalog_types.py
@@ -331,6 +332,7 @@ src/metatables/api/backend/migrations/versions/0012_table_creator.py
 src/metatables/api/backend/migrations/versions/__init__.py
 src/metatables/api/backend/operations/__init__.py
 src/metatables/api/backend/operations/bootstrap_migrations.py
+src/metatables/api/backend/operations/bootstrap_timing.py
 src/metatables/api/backend/operations/catalog_schema.py
 src/metatables/api/backend/operations/create_table.py
 src/metatables/api/backend/operations/finalize_managed.py
@@ -468,6 +470,7 @@ tests/catalog/test_contract_projection.py
 tests/catalog/test_database_config.py
 tests/catalog/test_index_statistics.py
 tests/catalog/test_migration.py
+tests/catalog/test_schema_validation.py
 tests/contracts/capabilities.json
 tests/contracts/client_signatures.json
 tests/contracts/database_operations.json
@@ -515,6 +518,7 @@ tests/e2e/test_local_actor_client_api.py
 tests/e2e/test_local_cli_workflow.py
 tests/e2e/test_local_client_selection.py
 tests/e2e/test_managed_finalize_client_api.py
+tests/e2e/test_managed_finalize_unchanged.py
 tests/e2e/test_namespaces_admin_http.py
 tests/e2e/test_public_imports.py
 tests/e2e/test_remaining_client_routes.py
@@ -545,6 +549,7 @@ tests/examples/test_documented_examples.py
 tests/examples/test_postgresql_examples.py
 tests/examples/test_setup_launch.py
 tests/examples/test_tutorial.py
+tests/integrations/test_batch_introspection.py
 tests/integrations/test_connection_reuse.py
 tests/integrations/test_credential_store.py
 tests/integrations/test_data_source_rules.py
@@ -571,6 +576,7 @@ tests/packaging/test_distribution_sources.py
 tests/packaging/test_editable_build.py
 tests/packaging/test_installed_distribution.py
 tests/permissions/test_access_map.py
+tests/permissions/test_deployment_security.py
 tests/permissions/test_governed_sql_scope.py
 tests/permissions/test_incremental_security.py
 tests/permissions/test_local_actor_membership.py