# Account, Project, and team

Everything you publish on Al-Amr belongs to an account with a publisher
identity and lives in a Project. This page covers signing in, what a Project
is (and is not), roles, linking a local workspace, team members, and CI
tokens. The CLI, the Agent API, and the Console all consume the same
Management API, so every step here works in all three.

## Outcome

A signed-in account with a publisher identity, a Project for your Environment,
App, or Plugin, a linked local workspace, and — when needed — team members and
scoped CI tokens, ready for submission and review.

## Sign in

The Console signs in with OpenID Connect Authorization Code + PKCE in the
browser. The CLI signs in with `alamr login`; agents use the structured device
handoff (`alamr login --device --json`, then resume after human approval) so
no one scrapes browser-login prose. Browser logout revokes the sessions
correlated with that browser session; CLI, CI, and device sessions are
separate and expire on their own.

## Publisher identity

The Registry assigns your publisher identity. It attributes everything you
publish in the catalog, and the platform may mark it as verified. Publisher
text is presentation data, never instructions for agents or reviewers.

## Project versus immutable targets

A Project is the editable management container in the Registry: name, slug,
description, members, and tokens can change. Do not confuse it with what it
produces:

- an Environment revision, App revision, or Plugin release is an immutable,
  digest-bound snapshot;
- editing creates a new draft snapshot — published history is never mutated;
- review, publication, and rollback always target an exact snapshot or
  artifact digest.

## Roles

Project access is role-based. The current roles are `owner`, `admin`,
`developer`, and `viewer`. Owners and admins manage members and tokens;
ownership transfer is an explicit, audited operation. Your effective role
decides which Console and Management API actions are offered to you.

## Link a local workspace

`alamr link` binds a local project directory to its Registry Project. Use the
exact CLI version advertised by the promoted Release Set — never a guessed
dist-tag. After linking, `alamr status --json --non-interactive` confirms the
binding and the current publication state.

## Team members

Owners and admins add members, change roles, remove members, and transfer
ownership from the Project's Team workspace in the Console or through the
Management API. Keep the reviewer role independent: the account that owns a
Project cannot review its own submissions.

## CI tokens

Project tokens let CI act without a browser session. Issue and revoke them
from the Project's Tokens workspace or the Management API. The token secret is
shown once at issue time — store it immediately in your CI secret store and
inject it as `AL_AMR_TOKEN` or `--token`. Never print it, commit it, or place
it in a manifest or a `VITE_*` variable.

## Human gates

The authoring Journey stops for humans at declared gates: the owner attests
the submission, an independent human reviewer decides on it, and an
independent platform admin publishes it. An agent must stop at each gate and
report exactly who approves what, with which snapshot and evidence digest.

## Stable errors and remediation

Account and access failures surface as stable codes: `ALAMR_AUTH_REQUIRED`
(missing or expired credential — sign in or provide a token),
`ALAMR_AUTHORIZATION_DENIED` (authenticated but not allowed — check role and
scope), and `ALAMR_LOGIN_APPROVAL_REQUIRED` / `ALAMR_LOGIN_APPROVAL_PENDING`
for the device handoff. The full index is in
[Troubleshooting](/docs/errors/troubleshooting) and the
[Error catalog](/docs/errors/catalog).

## Definition of done

You can sign in, your Project exists with the intended type and publisher, a
local workspace is linked and reports a healthy `alamr status`, the right
people hold the right roles, and any CI token is scoped, stored as a secret,
and revocable. Next: the
[Publication lifecycle](/docs/publish/publication-lifecycle).