mainsequence-access-control-and-sharing

Use this skill when the task is about RBAC, resource sharing, or access verification in a Main Sequence project. This skill owns organization and team access concepts, view and edit semantics, choosing the correct shareable resource boundary, and access checks across projects, DataNodeStorage, constants, secrets, buckets, artifacts, and releases. It does not own job scheduling, DataNode producer logic, or API route design.

What problem does it solve?

Determine who can view or edit a resource, ensure the correct sharing boundary, and verify access across a project to prevent misconfigurations.

Core Features & Use Cases

• 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
• identify the correct shareable object boundary: Project, DataNodeStorage, Constant, Secret, Bucket, Artifact, ResourceRelease
• explain that sharing a DataNode usually means sharing its DataNodeStorage
• choose whether configuration belongs in a Constant or Secret
• review CLI sharing flows for existing resources
• verify access assumptions before claiming a workflow is shareable

Read First

We expect you to start with foundational docs: docs/tutorial/role_based_access_control.md, docs/knowledge/infrastructure/users_and_access.md, and docs/knowledge/infrastructure/constants_and_secrets.md.

Inputs This Skill Needs

Before changing access or advising on sharing, collect or infer:

• the exact resource type being shared
• whether the actor is:
  • a user
  • a team
• whether the access should be:
  • view
  • edit
• whether the goal is:
  • consumption
  • maintenance
  • administration
• whether the resource contains sensitive configuration
• whether the task is about the resource itself or about the workflow that uses it

If the resource boundary or intended access level is unclear, stop before changing permissions.

Required Decisions

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?
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?

Build Rules

1. Share the real resource boundary

Do not speak loosely about sharing "the code" when the operational boundary is a platform object.

2. view is for consumers, edit is for maintainers

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.

3. Team sharing is for repeated access patterns

Prefer team sharing when the same access needs to be reused across several people or resources.

Prefer direct sharing when:

• the access is one-off
• the access is personal
• creating or reusing a team would add unnecessary complexity

4. Team membership is not team administration

Do not claim that a user can manage a team just because they inherit access through that team.

Keep these separate:

• inherited access to shared resources
• administration of the team itself

5. Constant vs Secret is a security boundary

Use Constant for non-sensitive runtime values. Use Secret for:

• API keys
• passwords
• bearer tokens
• credentials
• anything that would create an incident if exposed

Do not downgrade a secret into a constant for convenience.

6. Access assumptions must be verified

If the task claims a resource is shareable, readable, or maintainable by another actor, verify that path explicitly with the relevant CLI or client workflow.

Do not claim access based only on naming, role titles, or intuition.

Review Rules

When reviewing an access-control task, look for:

• sharing the wrong resource boundary
• granting edit when view is sufficient
• 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
• storing sensitive data in a Constant
• weak or unverified claims about who can access a resource
• confusion between access policy and deployment workflow

Validation Checklist

Do not claim success until you have checked:

• the resource boundary is correct
• the grant target is intentional:
  • user
  • team
• the access level is intentional:
  • view
  • edit
• the task is using Constant vs Secret correctly
• the access claim was verified against the actual resource path
• the task did not confuse sharing policy with orchestration or producer logic

This Skill Must Stop And Escalate When

• the real shareable resource is unclear
• the actor should probably be a team, but team structure is unknown
• the task mixes access policy with job scheduling or release mechanics
• the task asks for sensitive data to be stored in a Constant
• the task assumes cross-organization sharing without explicit documentation
• the request requires a policy decision the user has not made

End of description.