Superseded on 2026-10-20 by apps/mvp/docs/rulings.md (ARCH-1, FLOW-2). Kept as prior art.

Account flows

Design for #3871. Proposed execution and storage contract; this document is not implementation or production evidence.

Scope and creation

flow.new offers Scope: Repository or Global. Repository is the default and retains the current repository. Global belongs to the authenticated account, never to an inferred repository, team or browser profile. Selecting Global removes the repository destination; a repository remains an explicit execution target when the flow needs one. Creation still opens the shared form and requires the person's submission.

Durable storage

The product backend owns an account flow library, keyed by authenticated account ID and flow name. Each update appends an immutable revision containing the executable bundle, typed payload and success schemas, declared capabilities and effects, model-invocable policy, dependency content identities and source digest. The current revision is a pointer updated with an expected-revision fence. Source and revisions survive browser reloads, workspace replacement and host restart. Workspace scratch directories and browser collections are projections, never the library's authority.

Authoring uses the existing create-flow pipeline in an account-owned workspace. Its output enters the library only after the ordinary validation and human confirmation. No personal workspace is silently provisioned against an arbitrary repository. Global editing and deletion use the same library door and ownership checks; an existing run retains its pinned revision after either operation.

Discovery and precedence

The shared catalog resolves this order once for slash, button, CLI, API and agent doors. A repository flow with the same canonical name shadows a Global flow. System names cannot be replaced from either source. An explicit scope selector on the existing flow card or run form can select the shadowed Global revision; it does not create a second slash namespace. Catalog rows retain source scope, owner and immutable revision. Account changes invalidate the catalog before any new account data is shown.

Authorization and execution

Account identity comes from the authenticated server session, never a payload owner ID. Only the owner reads, authors, updates or deletes a private Global flow. Repository membership does not grant access to another member's library. Catalog results containing private flows are private to that account and are never broadcast on a repository-wide topic.

A Global flow runs as the invoking person in the explicitly selected repository, using the existing runner, trust admission and approval mechanisms. The library is a source of executable definitions, not a grant. Repository access, declared capabilities, effect authorization, model-invocable restrictions and human confirmation are rechecked at launch. No source account credentials or secrets travel with a bundle. Repository secrets remain repository-scoped, and their values never enter catalog rows, forms, logs or traces. Global flows cannot approve, merge or move main.

Resolve and pin the Global revision and dependency identities before persisting launch. Recovery uses that pin and the original account/repository binding, even if the catalog changes. Missing revisions, missing dependencies and unavailable account execution hosts fail visibly; they never fall back to another flow or repository. Repeated submissions use the existing durable launch idempotency key.

Acceptance evidence

Before enabling the scope, test persistence across restart; account isolation; repository shadowing; system protection; explicit scope resolution; denied repository access and capabilities; human confirmation; cancellation; deduplicated launch; revision-pinned recovery; deletion with a running revision; and stale catalog responses after account switching. Exercise each through the shared catalog and runner, with real storage dependencies.

The deployed real-tier agent eval must open the Global creation form, submit through the human door, create one flow, discover and run that same pinned definition in two authorized repositories, demonstrate repository-name precedence, and refuse access from a second account. Record the deployed revision and run IDs. Local code or fixture results cannot satisfy that receipt.

Landing boundary

The current flow.new implementation requires a repository workspace. This design must be accepted before adding the new account-owned storage and execution boundary. Until the complete path exists, do not expose a Global option that would write to a repository or claim to create a Global flow. The form, backend ownership checks, shared catalog resolver and runner must land together before production evaluation.