Workflow-first MVPDocs Center liveHelp routes reservedProjects & Billing in codeSupply & Marketplace in code

Team

Team now carries the shared execution pre-check order on top of its dedicated module entrance. Member directory, owner/operator/member boundary lanes, permission posture, and billable execution rules are all derived from one shared model, while empty and error demos remain available for testing.

Help Center Docs Center

Team Workbench

Team now reads, activates, and refreshes scope through one shared foundation

Module 5 Day 10 now keeps the member directory on D1-backed org data, invite writes, activation enforcement, and selected-member scope refresh on one path, so later RBAC work does not need to rebuild the team surface from a read-only scaffold.

Service boundary: workbench-control-plane-service · demo:error

State demoLive Empty Error

Module 5 Day 10 membership mutation live

Owners

Active members

Invites pending

Member directory

A single directory of account members with their effective project scope, role posture, and last activity.

Boundary lanes

User-facing owner, operator, and member lanes explain who owns the account root and who only acts inside narrower scopes.

Permission ladder

The Team module keeps the identity-to-credit permission sequence visible before later enforcement becomes active.

Execution rules

Billable execution stays attached to the same shared org model, so testing never bypasses permission or credit gates.

Team state

Membership data is currently unavailable

This error-state demo models the future org or RBAC boundary failing before the member table loads.

Module 1 needs the shell now so Module 5 can later add real permission errors without changing the front-end structure.

Reset demo Testing playbook

Team details

Recover the Team entry structure

Use the org and data-foundation docs to confirm how shared Team boundaries should fail gracefully.

The detail pane is now resilient before live org data is attached.

Org and RBAC Data foundation

Recent foundation activity

Team now shares the same root mutation evidence as Projects, so invites, activations, and account-level switches can be reviewed without leaving the operator surface.

No recent foundation mutations have been captured yet.

Boundary lanes

Owner boundary

Owns the account root, billing posture, project portfolio, and final escalation path.

0 members

ProjectsBillingUsageTeamDevelopersMarketplaceSettlement

Can cross account and project boundaries, and acts as the final approver for commercial or structural changes.

No members in this lane yet

Operator boundary

Operates review, moderation, payout, and exception flows without owning the entire account root.

0 members

RunsUsageBillingMarketplaceSettlement

Acts on review, support, billing, and payout surfaces, but does not redefine the product or account root by default.

No members in this lane yet

Member boundary

Builds and edits inside allowed projects without inheriting account-wide billing or payout authority.

0 members

WorkflowsProfilesTargetsProject-scoped registries

Works inside a project-scoped surface and should fail closed on account-wide or commercial mutations.

No members in this lane yet

Execution pre-check order

1. Identity

Confirm who is acting before any execution path or project data is exposed.

Anonymous, stale, or mismatched actors fail before the system resolves account or project scope.

2. Billing account

An execution request must resolve to a real account before memberships, credits, or projects are considered.

Missing account context blocks execution before org reads or usage mutations begin.

3. Account state

Restricted or incomplete account posture can still block mutation even when the actor belongs to the account.

Account posture fails closed before the system checks plan, project, or object scope.

4. Plan capability

Commercial capabilities stay behind plan checks instead of leaking into ad-hoc UI-only rules.

Execution paths that need paid or restricted capabilities stop here before project or object mutation begins.

5. Project scope

Execution must resolve to an allowed project before workflow, registry, or run-scoped objects are touched.

Cross-project execution attempts fail even if the actor still belongs to the wider account.

6. Object ownership

Workflow, profile, target install, run, and later executor receipts must all belong to the same allowed project.

Mixed-project object selection fails before action grants or credit reservation can start.

7. Action scope

Read, write, execute, review, publish, and payout each need an explicit grant after the object boundary is already known.

The actor may still view context but cannot mutate or execute without the action-specific permission.

8. Credit availability

Credits reserve last so billing never acts as a hidden substitute for identity, scope, or ownership checks.

Execution fails visibly when credits are insufficient, but only after the earlier permission ladder has passed.

Testing is not a billing bypass

Any accepted execution follows the same credit gate whether the operator calls it a test or production run.

Editing can stay open when credits are exhausted

Configuration stays visible, but execution actions must block clearly once credits are not available.

Reserve after permission, before execution

Credits should only reserve after identity, project, object, and action checks have already passed.

Org and RBAC Data foundation Module roadmap

Module 5 accepted

The developer, marketplace, and settlement entry surfaces are now explicit so team scope, supply onboarding, and commercial enforcement keep the same foundation. Project creation, team invite writes, membership activation, active-project switching, and project detail mutation plus broader membership scope refresh now stay live on Day 10, so the next default slice can move into Auth / RBAC enforcement.