mainsequence 9.0.4__tar.gz → 9.0.5.dev35__tar.gz

{mainsequence-9.0.4/mainsequence.egg-info → mainsequence-9.0.5.dev35}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence
-Version: 9.0.4
+Version: 9.0.5.dev35
 Summary: Main Sequence SDK
 Author-email: Main Sequence GmbH <dev@main-sequence.io>
 License-Expression: MIT

{mainsequence-9.0.4 → mainsequence-9.0.5.dev35}/agent_scaffold/AGENTS.md

@@ -65,8 +65,8 @@ bundle. Platform skills are installed separately under
 - CodeRepository context, local SDK execution, repository structure, and
   implementation routing:
   `.agents/skills/mainsequence/sdk_code_repository_execution/SKILL.md`
-- Local environment repair, authentication, explicitly requested updates, and
-  canonical CodeRepository sync:
+- Local environment repair, authentication, explicitly requested updates,
+  dependency sync after a dependency change, and publishing with Git:
   `.agents/skills/mainsequence/maintenance/code_repository_maintenance/SKILL.md`
 - Blocker analysis, failure classification, and SDK/platform contract mismatches:
   `.agents/skills/mainsequence/maintenance/bug_auditor/SKILL.md`

{mainsequence-9.0.4 → mainsequence-9.0.5.dev35}/agent_scaffold/skills/application_surfaces/api_surfaces/SKILL.md

@@ -241,17 +241,24 @@ mainsequence code-repository current --debug --json
 ```
 
 Declare the FastAPI resource in `.mainsequence/workflows/`, validate the
-workflow against the backend template, then move the tested commit through the
-canonical lifecycle:
+workflow against the backend template, then commit and push the tested commit
+with Git and inspect the result:
 
 ```bash
-mainsequence code-repository sync -m "Release Command Center API"
+git commit -m "Release Command Center API"
+git push
 mainsequence code-repository resources list --filter resource_type=fastapi
 ```
 
+When the dependencies changed, run `mainsequence code-repository sync --path .`
+before the commit and include the refreshed `uv.lock` and `requirements.txt`.
+The command runs no Git command and makes no platform request.
+
 Verify that:
 
-- code-repository sync used the intended Git branch
+- the push went to the intended Git branch
+- when the workflow sets a `tag_regex`, the repository's CI tagged the pushed
+  commit with a matching tag; without a `tag_regex` every push deploys
 - the workflow declaration identifies the tested FastAPI source path
 - resource discovery found that path at the exact deployed commit
 - Django resolved and built the exact image for the workflow event
@@ -261,7 +268,8 @@ Verify that:
 
 Enable automatic deployment in the repository workflow when the route paths,
 resource path, and frontend contracts are stable enough for future repository
-events to promote exact images.
+events to promote exact images. Automatic deployment and its `tag_regex` are
+set in the workflow file only; a release update does not accept them.
 
 ### 6. Verify the deployed API
 

{mainsequence-9.0.4 → mainsequence-9.0.5.dev35}/agent_scaffold/skills/maintenance/bug_auditor/SKILL.md

@@ -61,7 +61,8 @@ This skill audits. It does not implement by default.
 - RBAC and access issues:
   `.agents/skills/mainsequence/platform_operations/access_control_and_sharing/SKILL.md`
 - environment repair, authentication refresh, SDK updates, managed skill
-  refresh, and CodeRepository sync after the failure is classified:
+  refresh, dependency sync, and publishing with Git after the failure is
+  classified:
   `.agents/skills/mainsequence/maintenance/code_repository_maintenance/SKILL.md`
 
 ## Read First

{mainsequence-9.0.4 → mainsequence-9.0.5.dev35}/agent_scaffold/skills/maintenance/code_repository_maintenance/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mainsequence-code-repository-maintenance
-description: Maintain an existing Main Sequence CodeRepository checkout using the SDK-version-matched CLI. Use for inspecting repository state, building or repairing .venv, refreshing local authentication, performing explicitly requested SDK, skill, or AGENTS.md updates, publishing changes with CodeRepository sync, or diagnosing a partially completed maintenance workflow.
+description: Maintain an existing Main Sequence CodeRepository checkout using the SDK-version-matched CLI. Use for inspecting repository state, building or repairing .venv, refreshing local authentication, performing explicitly requested SDK, skill, or AGENTS.md updates, refreshing dependency files with CodeRepository sync, publishing changes with Git, or diagnosing a partially completed maintenance workflow.
 ---
 
 # Main Sequence CodeRepository Maintenance
@@ -16,7 +16,8 @@ workflows.
 Own:
 
 - local CodeRepository inspection and maintenance sequencing;
-- `.venv`, SDK, managed skill, `AGENTS.md`, and Git-release workflows;
+- `.venv`, SDK, managed skill, `AGENTS.md`, dependency sync, and Git publishing
+  workflows;
 - precondition checks, explicit approval gates, and partial-failure diagnosis.
 
 Do not own:
@@ -208,60 +209,96 @@ preserve the previous valid managed tree. Because this operation can update
 this skill, reload the refreshed `code_repository_maintenance/SKILL.md` before starting
 another maintenance routine.
 
-## Publish With Canonical CodeRepository Sync
+## Sync Dependencies After A Dependency Change
 
-Use CodeRepository sync only when the user intends to commit, tag, and push all
-reviewed repository changes.
-
-Before execution:
+Run CodeRepository sync only after the dependencies changed, for example after
+editing `[project.dependencies]` in `pyproject.toml`:
 
 ```bash
-git status --short
-git diff --stat
-mainsequence code-repository sync --path . -m "<specific commit message>" --dry-run
+mainsequence code-repository sync --path .
 ```
 
-Review every pending file because the command stages with `git add -A`. Do not
-continue when unrelated or unexplained changes would be included.
+In the project root it runs `uv lock`, `uv sync`, and the locked runtime export
+`uv export --locked --no-dev --no-hashes` into `requirements.txt`. It accepts
+only `--path`. It sends no request to the platform, creates no SSH or deploy
+key, changes no version, and runs no `git add`, `commit`, `tag`, or `push`.
+Review the changed `uv.lock` and `requirements.txt` and publish them with the
+dependency change.
 
-The command performs the same branch preflight even for `--dry-run`: it rejects
-a detached checkout and rejects a Git branch that is not registered under the
-logical CodeRepository. Do not bypass that validation or supply a CodeRepositoryBranch UID
-manually. Register or select the correct Git branch first.
+## Publish With Git
 
-After that branch preflight, `--dry-run` resolves the existing `uv` executable,
-previews its patch version without mutation, requests the backend-owned tag for
-that future version, rejects an invalid or existing local tag, prints the
-complete plan, and returns without generating an SSH key, querying private
-remote refs, changing dependencies or repository files, or mutating Git state.
-
-After review:
+Publish only when the user intends to commit and push the reviewed changes.
+Commit and push with Git as usual:
 
 ```bash
-mainsequence code-repository sync --path . -m "<specific commit message>"
+git status --short
+git diff --stat
+git add <reviewed paths>
+git commit -m "<specific commit message>"
+git push
+```
+
+Review every pending file and stage only the files that belong to the change.
+Do not continue when unrelated or unexplained changes would be included. Push
+to the attached branch that `mainsequence code-repository current` resolved; a
+detached checkout or an unregistered branch is a preflight failure.
+
+The platform deploys from the push according to the repository's
+`.mainsequence/workflows/*.yaml`. A declaration's `tag_regex` decides which
+pushes deploy:
+
+- omitted or `null`: every push to the branch deploys;
+- a regular expression: a push deploys only when a matching tag points at the
+  branch's latest commit.
+
+Automatic deployment and `tag_regex` are set in the workflow file only; a
+`ResourceRelease` or `Job` update does not accept them. The Main Sequence
+platform does not create tag names and the CLI does not tag. Versions and
+release tags belong to the repository: the version is raised in
+`pyproject.toml` (for example `uv version --bump patch`) in the commit to
+release, and the repository's own CI creates the tag. Do not create or push a
+release tag by hand unless the user asks for it. When the user wants tag-based
+releases and the repository has no such CI yet, propose a workflow like this
+example and wait for approval before adding it:
+
+```yaml
+# Example: .github/workflows/release.yml in the CodeRepository
+name: release
+on:
+  push:
+    branches: [main]
+concurrency:
+  group: release-main
+  cancel-in-progress: false
+permissions:
+  contents: write
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: astral-sh/setup-uv@v6
+      - run: uv sync --locked
+      - run: uv run pytest
+      - name: Tag the version declared in pyproject.toml
+        run: |
+          TAG="v$(uv version --short)"
+          if git rev-parse -q --verify "refs/tags/$TAG" >/dev/null; then
+            echo "$TAG already exists; nothing to release"
+            exit 0
+          fi
+          git tag "$TAG" "$GITHUB_SHA"
+          git push origin "refs/tags/$TAG"
 ```
 
-The canonical command always:
-
-1. selects `mainsequence-<repository-slug>-<first-16-sha256>` from the normalized
-   `host[:non-default-port]/repository/path`, never from the repository basename alone and never
-   from a legacy basename-only key;
-2. previews the `uv` patch version, requests the backend-owned CodeRepositoryBranch tag, and rejects an
-   invalid or existing local tag;
-3. registers a new or inaccessible key through the owning CodeRepository and verifies a dry-run push with
-   that forced identity;
-4. queries the exact tag ref on `origin` and stops if it exists or cannot be checked;
-5. applies the patch version bump and verifies it matches the preview;
-6. runs `uv lock` and `uv sync`;
-7. exports locked production requirements;
-8. stages and commits the changes;
-9. creates the returned annotated tag unchanged; and
-10. atomically pushes the explicit branch and tag refs with `--follow-tags`.
-
-Do not offer alternate bump modes, a no-push mode, or a hand-written sequence
-of equivalent commands. Do not call `sync-after-commit` or any backend repair
-endpoint. The GitHub branch-push webhook owns backend repository
-reconciliation.
+With that example, a `tag_regex` such as `^v[0-9]+\.[0-9]+\.[0-9]+$` deploys
+only the commits CI tagged. Details:
+<https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/scheduling_jobs/>
+
+Do not call `sync-after-commit` or any backend repair endpoint. The GitHub
+branch-push webhook owns backend repository reconciliation.
 
 ## Diagnose Partial Completion Before Retrying
 
@@ -273,12 +310,10 @@ Never rerun an entire mutating workflow blindly.
   environment, and the failed command before retrying.
 - After a skill refresh failure, keep the previous managed tree and identify
   whether the SDK or platform lane failed.
-- After a sync failure, inspect `git status`, `git log -1`, the current package
-  version, tags pointing at `HEAD`, the upstream branch, and remote tags before
-  deciding which step remains.
-
-A blind sync retry may create another patch bump or collide with an existing
-commit or tag.
+- After a dependency sync failure, inspect `pyproject.toml`, `uv.lock`, and the
+  exact failing `uv` output; the command stops at the first failing step.
+- After a push failure, inspect `git status`, `git log -1`, and the upstream
+  branch before retrying.
 
 ## Validate And Report
 
@@ -289,7 +324,7 @@ documentation, and the changed files. Report:
 - the code repository path and installed SDK version;
 - files or generated state changed;
 - validation run and its result;
-- whether changes remain local or were committed, tagged, and pushed;
+- whether changes remain local or were committed and pushed;
 - any remaining authentication, environment, Git, or webhook verification
   gap.
 

{mainsequence-9.0.4 → mainsequence-9.0.5.dev35}/agent_scaffold/skills/platform_operations/orchestration_and_releases/SKILL.md

@@ -217,24 +217,33 @@ For deployed APIs, agents, or other supported resources:
 
 ### 6.1 Automatic ResourceRelease deployment
 
-`automatic_deployment` is the automated deployment opt-in flag on a `ResourceRelease`. It means repository synchronization can rotate an existing release to the latest synced CodeRepository commit for the same resource path.
+`automatic_deployment` is the automated deployment opt-in flag on a `ResourceRelease`. It means a Git push can rotate an existing release to the pushed CodeRepository commit for the same resource path.
 
-When `automatic_deployment=True`, repository-sync events may create a unified `DeploymentRun` with `target_type="resource_release"` and source `repository_event`. That run:
+Automatic deployment and its `tag_regex` are set in the repository's `.mainsequence/workflows/*.yaml` only. A `ResourceRelease` or `Job` update does not accept `automatic_deployment` or `automatic_redeployment_policy`; the SDK models expose both as read-only fields. Change the workflow file, commit it, and push it.
 
-- reads the CodeRepository's current synced commit
+The declaration's `tag_regex` decides which pushes deploy:
+
+- omitted or `null`: every push to the branch deploys
+- a regular expression: a push deploys only when a matching tag points at the branch's latest commit
+
+The platform does not create or name tags. Release tags come from the repository's own CI, for example a GitHub Actions workflow that tags the version declared in `pyproject.toml` after the tests pass. The maintenance skill `.agents/skills/mainsequence/maintenance/code_repository_maintenance/SKILL.md` has an example. `mainsequence code-repository sync` only refreshes `uv.lock`, the local environment, and `requirements.txt`; it does not commit, tag, or push.
+
+When `automatic_deployment=True`, a qualifying push may create a unified `DeploymentRun` with `target_type="resource_release"` and source `repository_event`. That run:
+
+- reads the pushed commit
 - resolves the current code repository resource at the release's existing resource path
 - resolves supporting resources required by the release kind
 - creates or resolves the code repository image for that commit
 - redeploys the existing release to the current resource, README, and code repository image
 - records state, phase, outcome, revision context, artifact context, steps, logs, result, and errors on the deployment run
 
-This is not a local development shortcut. It does not deploy unpushed local files. The repository must be pushed, the code repository must be synced, and code repository resource discovery must find the resource at the same path for the current commit.
+This is not a local development shortcut. It does not deploy unpushed local files. The commit must be pushed, carry a matching tag when the workflow sets a `tag_regex`, and code repository resource discovery must find the resource at the same path for that commit.
 
 Enable `automatic_deployment` only when:
 
-- the release should track the CodeRepository's synced version
+- the release should track the branch's pushed commits, or its tagged releases when a `tag_regex` is set
 - the resource path is stable across commits
-- the current synced branch/version is an acceptable deployment source for that release
+- the pushed branch, and its tags when a `tag_regex` is set, are an acceptable deployment source for that release
 - required supporting resources are available for the current commit
 - the team accepts CI/CD-style rotation for this release
 
@@ -244,7 +253,7 @@ Keep `automatic_deployment` disabled when:
 - each release rotation needs human approval
 - the resource path or entrypoint is still moving
 - API or widget contracts are not stable enough for automatic rotation
-- the current branch/CodeRepository sync target is not the intended deployment source
+- the pushed branch is not the intended deployment source
 
 Declare opted-in releases in the repository workflow and validate the file
 against the backend template. Repository events create deployment runs.
@@ -276,7 +285,8 @@ When reviewing an orchestration task, look for:
 - no run/log verification after creation
 - unsafe use of `--strict`
 - workflows depending on laptop-specific file paths instead of Artifacts
-- `automatic_deployment` enabled without an explicit decision about repository-sync CI/CD rotation
+- `automatic_deployment` enabled without an explicit decision about push-driven CI/CD rotation and `tag_regex`
+- client code that tries to set `automatic_deployment` or `automatic_redeployment_policy` through a release or Job update instead of the workflow file
 - assumptions that automatic deployment will deploy local unpushed changes
 - automatic release rotation where the resource path or required supporting resources are not stable
 - tasks that are really resource/release problems rather than simple job problems
@@ -297,7 +307,8 @@ Do not claim success until you have checked:
 - runs and logs were inspected when execution success matters
 - resources and releases were verified when deployment success matters
 - `automatic_deployment` is intentionally enabled or disabled on each release
-- automatic deployment runs were inspected when repository-sync rotation matters
+- the workflow's `tag_regex` is intentional, and the repository's CI creates matching tags when one is set
+- automatic deployment runs were inspected when push-driven rotation matters
 - automatic deployment results match the intended commit, resource, README, image, and terminal status
 
 If the workflow uses `.mainsequence/workflows/`, also check:
@@ -320,7 +331,7 @@ If the workflow uses Artifacts, also check:
 - a Job workflow cannot resolve an exact source image
 - an automatically deployed Job has no persisted synchronized CodeRepositoryBranch commit
 - the workflow depends on local file paths that should be platform Artifacts
-- automatic deployment is requested but the deployment source branch/current synced CodeRepository version is unclear
+- automatic deployment is requested but the deployment source branch or its `tag_regex` is unclear
 - automatic deployment is requested but the resource path or required README is not stable
 - the task is actually about RBAC policy rather than orchestration
 - the task is actually about producer semantics rather than platform execution

{mainsequence-9.0.4 → mainsequence-9.0.5.dev35}/agent_scaffold/skills/sdk_code_repository_execution/SKILL.md

@@ -54,7 +54,7 @@ Do not let this skill become a domain manual.
 - CodeRepository audits, blocker analysis, and upstream SDK assessment:
   `.agents/skills/mainsequence/maintenance/bug_auditor/SKILL.md`
 - local environment repair, CodeRepository authentication refresh, SDK updates,
-  managed skill refresh, and canonical CodeRepository sync:
+  managed skill refresh, dependency sync, and publishing with Git:
   `.agents/skills/mainsequence/maintenance/code_repository_maintenance/SKILL.md`
 - jobs, schedules, artifacts, images, resources, and releases:
   `.agents/skills/mainsequence/platform_operations/orchestration_and_releases/SKILL.md`

{mainsequence-9.0.4 → mainsequence-9.0.5.dev35}/mainsequence/cli/api.py

@@ -949,36 +949,6 @@ def get_code_repository_repository(
         raise ApiError(f"GitHubRepositoryBinding fetch failed: {e}") from e
 
 
-def render_code_repository_branch_default_redeployment_tag(
-    code_repository_branch_uid: str,
-    *,
-    version: str,
-) -> str:
-    normalized_uid = str(code_repository_branch_uid).strip()
-    normalized_version = str(version).strip()
-    if not normalized_uid:
-        raise ApiError("CodeRepositoryBranch UID is required.")
-    if not normalized_version:
-        raise ApiError("CodeRepository version is required.")
-
-    r = authed(
-        "POST",
-        f"/api/v1/code-repository-branches/{normalized_uid}/default-redeployment-tag/",
-        {"version": normalized_version},
-    )
-    if not r.ok:
-        raise ApiError(f"Default redeployment tag rendering failed ({r.status_code}).")
-    payload = r.json()
-    if not isinstance(payload, dict):
-        raise ApiError("Default redeployment tag rendering returned an unexpected payload.")
-    if str(payload.get("version") or "").strip() != normalized_version:
-        raise ApiError("Default redeployment tag rendering returned another version.")
-    tag_name = str(payload.get("tag_name") or "").strip()
-    if not tag_name:
-        raise ApiError("Default redeployment tag rendering returned no tag name.")
-    return tag_name
-
-
 def resolve_code_repository_branch_uid(code_repository_branch_ref: str) -> str:
     payload = get_code_repository_branch(code_repository_branch_ref)
     normalized_uid = str(payload.get("uid") or "").strip()