mainsequence 6.0.26__tar.gz → 6.0.28__tar.gz

{mainsequence-6.0.26/mainsequence.egg-info → mainsequence-6.0.28}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence
-Version: 6.0.26
+Version: 6.0.28
 Summary: Main Sequence SDK 
 Author-email: Main Sequence GmbH <dev@main-sequence.io>
 License-Expression: LicenseRef-MainSequence-Proprietary

{mainsequence-6.0.26 → mainsequence-6.0.28}/agent_scaffold/AGENTS.md

@@ -107,11 +107,17 @@ Working rules for this role:
 User-resolution rule for agents:
 
 - use `User.get_logged_user()` only when code is running with request-bound identity context:
-  - FastAPI middleware
+  - FastAPI with `LoggedUserContextMiddleware` installed by the application
   - Streamlit
   - code that explicitly binds `_CURRENT_AUTH_HEADERS`
+- treat its result as `RequestUserIdentity`: the human caller's canonical `uid` and optional
+  `username`, never a numeric id or a full account profile
+- in FastAPI handlers, prefer `request.state.user` or `request.state.user_uid`; never use
+  `request.state.user_id`
 - use `User.get_authenticated_user_details()` in standalone authenticated CLI or script code that
   is not request-bound
+- keep authentication context separate from route-level authorization, deployment ownership,
+  runtime workload credentials, and runtime target identity
 - do not describe this as a CLI versus non-CLI distinction; the boundary is request-bound identity
   context versus a plain authenticated SDK session
 

{mainsequence-6.0.26 → mainsequence-6.0.28}/agent_scaffold/skills/application_surfaces/api_surfaces/SKILL.md

@@ -94,7 +94,23 @@ Record:
 
 Use `LoggedUserContextMiddleware` when the platform-authenticated request user
 must be available through `request.state`. This middleware binds request headers
-to the SDK request context; it is not an authorization policy by itself.
+to the SDK request context; it is not an authorization policy by itself. The
+application must install it explicitly with
+`app.add_middleware(LoggedUserContextMiddleware)`.
+
+The middleware exposes only the human caller's UID-based request identity:
+
+- `request.state.user` is `RequestUserIdentity`
+- `request.state.user_uid` is the canonical public user UUID
+- `request.state.user_id` does not exist
+
+In deployed runtimes, identity comes from the trusted gateway's `X-User-UID`.
+For direct local API development, a bearer-authenticated request is validated
+through `/api/v1/users/me/`; this supports testing a local service through a
+Cloudflare tunnel before deploying it. Never inject `X-User-UID` from frontend code, and
+never confuse the requesting human with the release owner, workload principal,
+or runtime target. Use the UID for application authorization after identity has
+been resolved.
 
 ### 2. Implement the provider
 

{mainsequence-6.0.26 → mainsequence-6.0.28}/agent_scaffold/skills/platform_operations/access_control_and_sharing/SKILL.md

@@ -179,7 +179,19 @@ Current CLI note:
   - `mainsequence constants list --filter name=MODEL__DEFAULT_WINDOW`
   - `mainsequence secrets list --filter name=POLYGON_API_KEY`
 
-### 7. Access assumptions must be verified
+### 7. Public principal identity is UID-only
+
+All SDK and CLI sharing mutations identify users 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`
+
+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.
+
+### 8. 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.