mainsequence 9.0.27.dev71__py3-none-any.whl → 9.0.29.dev72__py3-none-any.whl

agent_scaffold/skills/mainsequence-inference/SKILL.md

@@ -50,15 +50,18 @@ credential storage and must not appear in messages or `provider_options`.
 
 Pass optional `custom_id="openai-work"` to `client.complete()` to select that named
 credential within the caller's Environment. Omit it to retain the first available
-owned credential, then the first shared credential. A missing or ambiguous explicit
-name fails; do not retry using a different credential. Recorded requests retain the
-exact credential UID for replay. Custom endpoints use their existing provider
-identifier and do not accept `custom_id`.
-
-Sharing a configured provider authorizes recipients, including workload users,
-to use its credentials and receive them in local Tau. They may copy those credentials;
-revoking a share cannot remove copies already delivered. Explain this before
-guiding someone through sharing. This inference client executes on the server;
+owned credential, then the first credential of another person that the caller may
+use through its policies. A missing or ambiguous explicit name fails; do not retry
+using a different credential. Recorded requests retain the exact credential UID for
+replay. Custom endpoints use their existing provider identifier and do not accept
+`custom_id`.
+
+A credential's `user` policy authorizes its holders, including workload users,
+to use it and receive it in local Tau; a custom model provider's `user` policy lets
+them send requests through it and receive its stored authentication in local Tau.
+Holders may copy a delivered credential or authentication; detaching the policy
+cannot remove copies already delivered. Explain this before guiding someone
+through giving the `user` policy. This inference client executes on the server;
 provider management remains with the existing provider clients.
 
 ## Construct a completion envelope

agent_scaffold/skills/maintenance/bug_auditor/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: doc-bug-auditor
-description: Reviews a Main Sequence CodeRepository for status, blockers, failures, and completion.
+description: Diagnose failures and assess requested work in the current repository using code, logs, tests, and the installed Main Sequence SDK. Use for failure classification, SDK contract mismatches, and evidence-based completion checks.
 ---
 
 # Main Sequence Bug Auditor
@@ -17,6 +17,11 @@ Use this skill to inspect a checked-out Main Sequence CodeRepository and determi
 
 This skill is for diagnosis and assessment. Default behavior is read-only unless the task explicitly asks for edits.
 
+Limit the assessment to the requested work in the current repository. Use this
+skill directly; no prior routing skill or platform catalog is required. Local
+diagnosis needs no signed-in session. Authenticate only when the requested
+investigation requires live platform verification.
+
 ## This Skill Can Do
 
 - inspect CodeRepository state and summarize completion status
@@ -45,13 +50,12 @@ This skill must not claim ownership of:
 
 This skill audits. It does not implement by default.
 
-## Route Adjacent Work
+## Related Skills When Needed
+
+Consult these only when the failing operation needs their contract or the user
+requests follow-up work. They are not prerequisites for starting or completing
+an audit:
 
-- Product architecture, platform ontology, and CodeRepository Blueprint work:
-  use the matching platform-owned design skill declared by the installed
-  platform catalog; do not assume its filesystem path
-- bootstrap, routing, and repository structure:
-  `.agents/skills/mainsequence/sdk_code_repository_execution/SKILL.md`
 - MetaTable and table-update implementation issues: use the installed
   `metatables` package skill that owns the affected contract
 - Command Center FastAPI contract or release issues:

agent_scaffold/skills/maintenance/code_repository_maintenance/SKILL.md

@@ -11,6 +11,9 @@ authentication, scaffold, and Git behavior. Select and sequence commands here;
 do not reproduce their Python implementation or replace them with ad hoc shell
 workflows.
 
+Use this skill directly for the current checkout and the requested maintenance
+task. No prior routing skill or platform catalog is required.
+
 ## Preserve The Boundary
 
 Own:
@@ -22,16 +25,13 @@ Own:
 
 Do not own:
 
-- platform ontology or CodeRepository Blueprint design;
 - domain implementation for data packages, APIs, jobs, or releases;
 - backend repository reconciliation;
 - MCP authorization policy, OAuth token storage, or access-token extraction;
 - repository-owned skills outside `.agents/skills/mainsequence/`.
 
-Route architecture changes to `code_repository_design`, implementation routing to
-`sdk_code_repository_execution`, and failure classification to
-`maintenance/bug_auditor` when diagnosis extends beyond the maintenance
-workflow itself.
+For an unexplained failure, consult `maintenance/bug_auditor` when deeper
+diagnosis is needed. This is an optional handoff, not a maintenance prerequisite.
 
 The local identity contract is Git-native. The containing repository remote,
 attached branch, and exact HEAD commit select the platform CodeRepository and
@@ -45,19 +45,21 @@ fall back to credential claims or injected CodeRepositoryBranch values.
 
 ## Inspect Before Changing State
 
-1. Follow repository instructions, including `AGENTS.md` when present, and read
-   the relevant skills. The SDK never scaffolds or edits repository `AGENTS.md`.
+1. Follow repository instructions, including `AGENTS.md` when present. Consult
+   domain-specific instructions only when relevant to the requested operation.
+   The SDK never scaffolds or edits repository `AGENTS.md`.
 2. Confirm the repository root and the user's requested maintenance outcome.
-3. Inspect code repository and Git state:
+3. Inspect SDK and Git state:
 
    ```bash
-   mainsequence code-repository current --debug --json
    mainsequence code-repository sdk-status --path . --json
    git status --short
    ```
 
-   Before branch-owned platform operations, require the current Git branch,
-   `code_repository_branch_uid`, and `code_repository_branch_status=resolved`.
+   Before branch-owned platform operations, also inspect
+   `mainsequence code-repository current --debug --json` and require the current
+   Git branch, `code_repository_branch_uid`, and
+   `code_repository_branch_status=resolved`.
    Local environment and skill updates do not require a registered platform
    branch or a signed-in session.
 
@@ -316,7 +318,7 @@ second:
 
 ```yaml
 # .mainsequence/workflows/api-production.yaml
-api_version: "2.3.0"
+api_version: "3.0.0"
 name: api-production
 scope:
   environments: [production]
@@ -333,7 +335,7 @@ resources:
 
 ```yaml
 # .mainsequence/workflows/api-development.yaml
-api_version: "2.3.0"
+api_version: "3.0.0"
 name: api-development
 scope:
   environments: [development]  # the development Environment's exact name

agent_scaffold/skills/platform_operations/access_control_and_sharing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mainsequence-access-control-and-sharing
-description: Use this skill when the task is about RBAC, resource sharing, or access verification in a Main Sequence CodeRepository. This skill owns organization and team access concepts, view and edit semantics, choosing the correct shareable resource boundary, access checks across CodeRepositories, constants, secrets, buckets, artifacts, and releases, and whether an application uses its own grants or acts for its requester (`acts_for_requester`). It does not own job scheduling, domain-package data behavior, or API route design.
+description: Use this skill when the task is about RBAC, resource sharing, or access verification in a Main Sequence CodeRepository. This skill owns organization and team access concepts, the policies of each shareable resource, choosing the correct shareable resource boundary, access checks across CodeRepositories, constants, secrets, buckets, artifacts, Agents, releases and Jobs, and whether an application uses its own grants or acts for its requester (`acts_for_requester`). It does not own job scheduling, domain-package data behavior, or API route design.
 ---
 
 # Main Sequence Access Control And Sharing
@@ -14,7 +14,7 @@ This skill is for:
 - RBAC reasoning
 - organization, user, role, and team access concepts
 - direct sharing vs team sharing
-- `view` vs `edit`
+- choosing the policy a person, a workload or a team needs
 - deciding which resource is the real sharing boundary
 - choosing between `Constant` and `Secret`
 - access verification for shared resources
@@ -23,16 +23,22 @@ This skill is for:
 
 - explain the Main Sequence access model in operational terms
 - decide whether a resource should be shared directly to a user or to a team
-- decide whether a user needs `view` or `edit`
+- decide which policy a user, a workload or a team needs
 - identify the correct shareable object boundary:
   - `CodeRepository`
+  - `CodeRepositoryBranch`
+  - `OrganizationProject`
   - `Constant`
   - `Secret`
   - `Bucket`
   - `Artifact`
+  - `Agent`
   - `ResourceRelease`
+  - `Job`
 - choose whether configuration belongs in a `Constant` or a `Secret`
 - review CLI sharing flows for existing resources
+- manage a team's members and decide who controls the team, through the
+  team's policies
 - verify access assumptions before claiming a workflow is shareable
 - decide whether an application uses its own grants or acts for its
   requester, and explain what acting for the requester allows
@@ -61,6 +67,16 @@ This skill only reasons about access to deployed resources such as `ResourceRele
 1. Repository instructions, including `AGENTS.md` when present.
 2. <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/users_and_access/>
 3. <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/constants_and_secrets/>
+4. <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/object_access/>
+   for every shareable object, whose access is decided by policies
+5. <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/code_repositories/>
+   for code repositories, their branches and Projects
+6. <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/agents/>
+   for Agents and the releases that back them
+7. <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/resource_releases/>,
+   <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/scheduling_jobs/>
+   and <https://mainsequence-sdk.github.io/mainsequence-sdk/knowledge/infrastructure/artifacts/>
+   for releases, Jobs, buckets and Artifacts
 
 The pages above are the authoritative reference for access control and sharing.
 If the task is specifically about a resource type, also read that resource's own
@@ -74,9 +90,25 @@ Before changing access or advising on sharing, collect or infer:
 - whether the actor is:
   - a user
   - a team
-- whether the access should be:
-  - `view`
-  - `edit`
+- which policy the access needs:
+  - for a `Constant`, which is decided by policies: `reader`, `editor` or `owner`
+  - for a `Secret`, which is decided by policies: `reader`, `value_reader`,
+    `editor` or `owner`
+  - for a `Bucket`, which is decided by policies: `reader`, `contributor`,
+    `editor` or `owner`
+  - for a `CodeRepository`, a `CodeRepositoryBranch` or an
+    `OrganizationProject`, which are decided by policies: `reader`, `editor`
+    or `owner`
+  - for an `Artifact`, which is decided by policies: `viewer`, `editor` or
+    `owner`
+  - for an `Agent`, which is decided by policies: `viewer`, `user`,
+    `operator`, `editor` or `owner`
+  - for a `ResourceRelease`, which is decided by policies: `viewer`, `user`,
+    `editor` or `owner`
+  - for a `Job`, which is decided by policies: `viewer`, `runner`, `editor` or
+    `owner`
+  - for a model-provider credential or a custom model provider, which are
+    decided by policies: `user`, `editor` or `owner`
 - whether the goal is:
   - consumption
   - maintenance
@@ -92,7 +124,14 @@ For every non-trivial access task, decide:
 
 1. What is the real shareable object?
 2. Is this direct user access or team-based access?
-3. Does the user need `view` or `edit`?
+3. Which policy does the principal need: on a `Constant`, `reader`, `editor` or `owner`; on a
+   `Secret`, `reader`, `value_reader`, `editor` or `owner`; on a `Bucket`, `reader`,
+   `contributor`, `editor` or `owner`; on an `Artifact`, `viewer`, `editor` or `owner`; on a
+   `CodeRepository`, a `CodeRepositoryBranch` or an `OrganizationProject`, `reader`, `editor` or
+   `owner`; on an `Agent`, `viewer`, `user`, `operator`, `editor` or `owner`; on a
+   `ResourceRelease`, `viewer`, `user`, `editor` or `owner`; on a `Job`, `viewer`, `runner`,
+   `editor` or `owner`; on a model-provider credential or a custom model provider, `user`,
+   `editor` or `owner`?
 4. Is this configuration non-sensitive or sensitive?
 5. Is the task really an access problem, or is it actually an orchestration or implementation problem?
 6. Is the task creating a `Constant` or `Secret` by name, and does that name already exist?
@@ -105,17 +144,187 @@ Do not speak loosely about sharing "the code" when the operational boundary is a
 
 Examples:
 
-- sharing a deployed experience usually means sharing the `ResourceRelease`
+- sharing a deployed experience usually means a policy on the
+  `ResourceRelease`, or on the `Agent` when the release backs one
 - sharing runtime configuration means sharing the `Constant` or `Secret`
 
-### 2. `view` is for consumers, `edit` is for maintainers
+### 2. Consumers get the narrowest policy, maintainers get `editor`
 
 Use the simplest rule unless the task requires something more specific:
 
-- `view` for people who need to read, inspect, or consume
-- `edit` for people who need to maintain, update, or administer
-
-Do not grant `edit` when `view` is enough.
+- the narrowest reading or using policy, such as `reader`, `viewer` or
+  `user`, for people who need to read, inspect, or consume
+- `editor` for people who need to maintain or update
+- `owner` only for the people who decide who has access
+
+Do not grant `editor` when a reading or using policy is enough. No resource
+uses view and edit sharing any more.
+
+A `Constant` is decided by its policies:
+
+- `reader` sees the constant and its value;
+- `editor` also changes its name and value, deletes it and sees who has access;
+- `owner` also decides who has access.
+
+The person or workload that creates a constant holds `owner`. Give `reader` to
+consumers and `editor` to maintainers, with the access methods on `Constant`
+(`get_access()`, `attach_policy()`, `detach_policy()`, `explain_access()`) or
+`mainsequence constants access list|grant|revoke|explain`. A constant has no
+`add_to_view()` or `add_to_edit()`, and its access methods need no Environment.
+
+A `Secret` is decided by its policies too:
+
+- `reader` sees the secret and its name, never its value;
+- `value_reader` also reads its current value;
+- `editor` also reads earlier values, sets a new value, deletes it and sees who
+  has access;
+- `owner` also decides who has access.
+
+The person or workload that creates a secret holds `owner`. Give
+`value_reader` to the workloads and the few people that need the value, and
+`editor` to maintainers; `reader` is for people who configure workloads that
+use the secret but must never know it. A workload holding only `reader` cannot
+read the value: `Secret.get()` raises `PermissionDeniedError` with
+`required_action` `secrets.read_value`. Use the access methods on `Secret` or
+`mainsequence secrets access list|grant|revoke|explain`; a secret has no
+`add_to_view()` or `add_to_edit()`. A repository workflow file's `access` entry
+for a secret names the policy it gives (`policy: reader`, `value_reader`,
+`editor` or `owner`). A secret the platform manages, such as a hosted database
+password, cannot get a new value or be deleted.
+
+A `Bucket` is decided by its policies too:
+
+- `reader` browses its folders and the Artifacts in it shared with the person;
+- `contributor` also uploads Artifacts and creates folders;
+- `editor` also renames the bucket, renames and deletes folders, deletes the
+  bucket with every Artifact in it and sees who has access;
+- `owner` also decides who has access.
+
+The person or workload that creates a bucket holds `owner`, also when an
+Artifact upload creates it by name. Give `contributor` to the people and the
+workloads that upload into a bucket, and `editor` to maintainers. Uploading
+into an existing bucket without `contributor` raises `PermissionDeniedError`
+with `required_action` `buckets.add_artifact`. Use the access methods on
+`Bucket`; a bucket has no `add_to_view()` or `add_to_edit()`, and the CLI has
+no bucket commands. A repository workflow file's `access` entry for a bucket
+names the policy it gives (`policy: reader`, `contributor`, `editor` or
+`owner`).
+
+A `CodeRepository`, its `CodeRepositoryBranch` objects and an
+`OrganizationProject` are decided by their policies too, each with `reader`,
+`editor` and `owner`:
+
+- on a repository, `reader` sees it, its GitHub link and issues, and every
+  branch in it; `editor` also renames or archives it, adds deploy keys,
+  creates branches, edits every branch and sees who has access; `owner` also
+  decides who has access. Only Organization admins delete a repository;
+- on a branch, `reader` sees the branch, its files, Jobs, runs, logs and
+  releases, and calls its releases; `editor` also changes and deletes it,
+  edits its Jobs and releases and manages what its workloads can reach;
+  `owner` also decides who has access;
+- on a Project, a named group of branches in one Environment, `reader` sees
+  it and its branches; `editor` also renames it, adds and removes branches and
+  deletes it; `owner` also decides who has access.
+
+A repository's creator and a Project's creator hold `owner`; a branch's
+creator holds nothing for being its creator. Repository and Project policies
+pass down to the branches: `reader` gives branch `reader`, and `editor` and
+`owner` give branch `editor`, so share the repository or the Project when
+every branch should follow. Using a repository or a branch needs the
+platform's `user` product role: without it every route, the access methods
+included, raises `PermissionDeniedError` with `code` `missing_product_role`,
+also through a Team, and no policy gives it. Use the access methods on
+`CodeRepository`, `CodeRepositoryBranch` and `OrganizationProject(uid=...)`,
+or `mainsequence code-repository access list|grant|revoke|explain` for a
+repository; the CLI has no branch or Project access commands. A repository
+workflow file's `access.branch` and `access.branches` entries name the
+workload's policy (`branch: reader`, or `policy: reader` on a `branches`
+entry).
+
+Model-provider credentials and custom model providers are decided by policies
+too, as two types:
+
+- a model-provider credential, one person's sign-in to a built-in model
+  provider: `user` selects it and receives it in sessions and workloads,
+  including local Tau, where it can be copied; `editor` also refreshes it,
+  signs in again, revokes it and sees who has access; `owner`, which the
+  credential's person holds, also decides who has access;
+- a custom model provider, an inference endpoint with its own authentication
+  and models: `user` sends requests through it and its models and receives its
+  stored authentication in sessions and workloads, including local Tau, where
+  it can be copied; `editor` also changes its endpoint, authentication and
+  models, deletes it and sees who has access; `owner`, which its creator holds,
+  also decides who has access.
+
+Give `user` to the people and workloads that send requests through a
+credential or a custom provider, and only to those you trust with a credential
+they can copy; give `editor` to maintainers. The SDK has no model or command
+for these records. A repository workflow file's `access` entry for model
+providers names the policy it gives (`policy: user`, `editor` or `owner`).
+
+An `Artifact` is decided by its policies too:
+
+- `viewer` sees it and downloads its file;
+- `editor` also replaces its file, deletes it and sees who has access;
+- `owner` also decides who has access.
+
+Every policy that sees an Artifact also downloads it, and a downloaded copy
+stays with the person. Uploading under the name of an Artifact you can see
+replaces its file, which needs `editor` or `owner`: with `viewer` alone
+`Artifact.upload_file()` raises `PermissionDeniedError` with
+`required_action` `artifacts.overwrite`. The Jobs whose runs published an
+Artifact give `viewer` on it to everyone who holds a policy on the Job. Use the
+access methods on `Artifact`; the CLI has no Artifact commands. A repository
+workflow file's `access` entry for an Artifact names the policy it gives, such
+as `policy: viewer`.
+
+An `Agent` is decided by its policies:
+
+- `viewer` talks to it, gives it Tasks, sees all its Tasks and reads the
+  person's own log lines;
+- `user` talks to it and gives it Tasks, seeing only the Tasks the person
+  asked for;
+- `operator` also stops any Task or session run;
+- `editor` also configures it, moves it to a new runtime build, deletes it,
+  manages what its workload can reach and sees who has access;
+- `owner` also decides who has access.
+
+Give `user` to most people, and `viewer` only to those who should see other
+people's Tasks. The Agent works with its own access unless it acts for the
+person asking. Its policies also decide its runtime release and that release's
+backing Job: give access on the Agent, never on its release, which refuses a
+policy of its own with `BadRequestError` `code` `sharing_managed_by_owner`.
+Use the access methods on `Agent`, or `mainsequence agent access
+list|grant|revoke|explain`. A repository workflow file's `access` entry for an
+Agent names the policy it gives, such as `policy: user`.
+
+A `ResourceRelease` and a `Job` are decided by their policies:
+
+- on a release, `viewer` sees its configuration, revisions and logs and calls
+  it; `user` calls it without its logs; `editor` also changes its
+  configuration, activates static deployments, deletes it and manages what its
+  workload can reach; `owner` also decides who has access;
+- on a Job, `viewer` sees it, its runs, logs and outputs; `runner` also runs
+  it and stops its runs; `editor` also changes and deletes it and manages what
+  its workload can reach; `owner` also decides who has access.
+
+A release that backs no Agent and a standalone Job also take the policies of
+their branch: branch `reader` gives `viewer`, and `editor` and `owner` give
+`editor`. A release's backing Job follows the release and is changed, run and
+deleted with it. Give
+`user` on a release to the people who only call it, and `runner` on a Job to
+the people who run it without changing it. Use the access methods on
+`ResourceRelease` and `Job`, or `mainsequence code-repository resources access
+list|grant|revoke|explain` and `mainsequence code-repository jobs access
+list|grant|revoke|explain`. A repository workflow file's `access` entry for a
+release or a Job names the policy it gives, such as `policy: user` on a release
+or `policy: runner` on a Job.
+
+The creator of an Agent, a release, a Job or an Artifact holds `owner`, except
+the Organization's automation identity, which creates the objects of
+repository workflows and holds no policy on them. The access methods of all
+four take no Environment; with a workload's runtime credentials they reach
+only the objects of that workload's Environment.
 
 ### 3. Team sharing is for repeated access patterns
 
@@ -136,6 +345,29 @@ Keep these separate:
 - inherited access to shared resources
 - administration of the team itself
 
+Membership is who is in the team. Control is the policies on the team, not view
+and edit sharing:
+
+- `viewer` sees the team and its members;
+- `membership_manager` adds and removes members;
+- `editor` renames, describes, activates or deactivates it and sees its policies;
+- `owner` does everything, including deleting it and deciding who manages it;
+- every member holds `member`: they can see the team and its members, and leave it.
+
+Any person can create a team and becomes its owner and first member. Use
+`Team.add_member()`, `remove_member()`, `leave()` and the access methods
+(`get_access()`, `attach_policy()`, `detach_policy()`, `explain_access()`), or
+`mainsequence organization teams members ...`, `leave` and `access ...`. A
+team has no `add_to_view()` or `add_to_edit()`. Before saying who can change a
+team, read it with `team.get_access()` or `explain_access()`.
+
+Working in an Organization Environment is a policy too: `member` works in it
+and creates Projects, Buckets, Constants, Secrets, model providers and
+repositories there; `observer` works in it without creating anything. Only
+Organization admins attach them, to people and Teams, with the access methods
+on `OrganizationEnvironment`. Admission never shows objects that are not shared
+with the person.
+
 An application that checks whether its caller or requester belongs to a team
 uses `in_teams()`; the identity carries no team list. See
 `.agents/skills/mainsequence/application_surfaces/api_surfaces/SKILL.md`.
@@ -182,15 +414,16 @@ Current CLI note:
 
 ### 7. Public principal identity is UID-only
 
-All SDK and CLI sharing mutations identify users and teams by public UUID:
+All SDK and CLI access changes identify people, workload identities and teams
+by public UUID:
 
-- `add_to_view(user_uid)` and `add_to_edit(user_uid)`
-- `remove_from_view(user_uid)` and `remove_from_edit(user_uid)`
-- the corresponding team methods use `team_uid`
+- `attach_policy(policy, principal_type="user", principal_uid=user_uid)` and
+  `attach_policy(policy, principal_type="team", principal_uid=team_uid)`
+- `detach_policy(binding_uid)`, with a binding UID that `get_access()` lists
 
-Never pass or request a numeric user or team database ID. CLI sharing commands
-take `<USER_UID>` or `<TEAM_UID>`, and access-state output is interpreted through
-public UID fields.
+Never pass or request a numeric user or team database ID. CLI access commands
+take `--user <USER_UID>` or `--team <TEAM_UID>` and `<BINDING_UID>`, and access
+output is interpreted through public UID fields.
 
 ### 8. Access assumptions must be verified
 
@@ -207,9 +440,14 @@ release or an Agent, reaches platform data.
 
 An application runs as its own workload User (`workload_user_uid` on the
 `ResourceRelease`, `Job` or `Agent`). Its own access comes from grants to that
-User: share what it needs with that User as with any person, with `view`
-unless it must maintain the object. These grants cover every call the
-application makes for itself.
+User: give it the policies it needs as you would a person, a reading or using
+policy unless it must maintain the object. A `Constant` it reads needs
+`reader`, a `Secret` whose value it reads needs `value_reader`, a `Bucket` it
+uploads Artifacts into needs `contributor`, an `Artifact` it reads needs
+`viewer`, a release it calls needs `user`, a `Job` it runs needs `runner`, an
+`Agent` it gives Tasks to needs `user`, and a model-provider credential or a
+custom model provider it sends requests through needs `user`. These grants
+cover every call the application makes for itself.
 
 ### Acting for its requester: `acts_for_requester`
 
@@ -304,7 +542,8 @@ authority; the application's per-operation permission checks remain necessary.
 When reviewing an access-control task, look for:
 
 - sharing the wrong resource boundary
-- granting `edit` when `view` is sufficient
+- granting `editor` or `owner` when a reading or using policy is sufficient
+- a policy on a release that backs an Agent instead of on the Agent
 - using direct user grants where a team should be used
 - using a team when the access is clearly one-off
 - treating team membership as team administration
@@ -331,9 +570,18 @@ Do not claim success until you have checked:
 - the grant target is intentional:
   - user
   - team
-- the access level is intentional:
-  - `view`
-  - `edit`
+- the policy is intentional:
+  - `reader`, `editor` or `owner` on a `Constant`
+  - `reader`, `value_reader`, `editor` or `owner` on a `Secret`
+  - `reader`, `contributor`, `editor` or `owner` on a `Bucket`
+  - `reader`, `editor` or `owner` on a `CodeRepository`, a
+    `CodeRepositoryBranch` or an `OrganizationProject`
+  - `viewer`, `editor` or `owner` on an `Artifact`
+  - `viewer`, `user`, `operator`, `editor` or `owner` on an `Agent`
+  - `viewer`, `user`, `editor` or `owner` on a `ResourceRelease`
+  - `viewer`, `runner`, `editor` or `owner` on a `Job`
+  - `user`, `editor` or `owner` on a model-provider credential or a custom
+    model provider
 - the task is using `Constant` vs `Secret` correctly
 - any `Constant` or `Secret` creation path first resolved existence by name when idempotency matters
 - the access claim was verified against the actual resource path

agent_scaffold/skills/platform_operations/orchestration_and_releases/SKILL.md

@@ -205,6 +205,17 @@ Artifact and Bucket operations derive their Organization Environment from the
 process-frozen current Git branch and registered `CodeRepositoryBranch`. Do not ask the
 user to select an Environment UID or branch UID.
 
+Uploading an Artifact into an existing Bucket needs the Bucket's `contributor`
+policy or more; give it to the workload that uploads, for example a Job's
+workload User. A refused upload raises `PermissionDeniedError` with
+`required_action` `buckets.add_artifact`. An upload that names a new Bucket
+creates it, and the uploader holds `owner`. An upload under the name of an
+Artifact you can see in the Bucket replaces that Artifact's file, which needs
+its `editor` or `owner` policy; with `viewer` alone it raises
+`PermissionDeniedError` with `required_action` `artifacts.overwrite`. A name
+taken by an Artifact you cannot see raises `ConflictError`. See
+`.agents/skills/mainsequence/platform_operations/access_control_and_sharing/SKILL.md`.
+
 Examples:
 
 - vendor drops

agent_scaffold/skills/sdk_code_repository_execution/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mainsequence-sdk-code-repository-execution
-description: Use the installed Main Sequence SDK and CLI for Git-derived CodeRepository context, version-matched contract authority, and selecting the relevant SDK or domain-package skill. Use for repository integration and SDK execution questions; use a platform-owned design skill when architecture or ontology is unresolved.
+description: Use the installed Main Sequence SDK and CLI for Git-derived CodeRepository context, version-matched contract authority, and selecting the relevant SDK or domain-package skill. Use for repository integration and SDK execution questions.
 ---
 
 # Main Sequence SDK CodeRepository Execution
@@ -28,11 +28,8 @@ create, copy, update, or remove it.
 
 Use skill descriptions to select the domain involved in the request. This skill
 is not a mandatory first step for maintenance, audits, or already-scoped domain
-work. A platform design skill is useful when product architecture, ontology, or
-the CodeRepository Blueprint is unresolved; select it from the installed
-platform catalog rather than assuming its filesystem path.
-Use that catalog to select platform-owned CodeRepository-to-Agent setup and
-other platform capabilities as well.
+work. Use the installed platform catalog to select platform-owned
+CodeRepository-to-Agent setup and other platform capabilities.
 
 - Environment repair, authentication, explicitly requested updates, dependency
   sync, and Git publishing: