Workspaces and identity
Workspace, repository and checkout
Section titled “Workspace, repository and checkout”A workspace groups coordination state under an explicit identity. Its identity lives in .majlis/majlis.toml: a committed workspace ID and named repository IDs.
A repository identifies a shared Git history. A checkout identifies one working tree, by canonical path plus a persisted checkout ID. Two worktrees can share a repository while holding separate checkout resources.
Branch names and working directories are metadata, never proof of identity. Git remote and root-commit heuristics can suggest membership, but they never silently assign it. Registration associates a supplied checkout reference with verified local state.
Actors and sessions
Section titled “Actors and sessions”An actor identifies a participant. A registered session binds that actor to its native harness session and checkout, and issues a private credential. Display handles help people read a screen; credentials and registered IDs decide authority.
Select the exact issued session with MAJLIS_SESSION_FILE. Supplying a different --actor or --incarnation flag cannot turn that session into another participant: identity flags assert identity, they never grant it.
majlis session register "$NATIVE_SESSION_ID" \ --actor "$ACTOR_REFERENCE" --checkout "$CHECKOUT_ROOT" \ --harness "$HARNESS_NAME" --idempotency-key "$REGISTRATION_KEY"For manual CLI coordination, use an explicitly identified --harness cli session rather than pretending it is a native harness session.
Incarnation and context epoch
Section titled “Incarnation and context epoch”An incarnation identifies one execution lifetime. Leases and outstanding writers belong to that lifetime. Fencing an incarnation prevents it from starting new work; it does not prove an already running tool stopped. A lost or unresolved writer keeps its resources quarantined until explicit reconciliation or verified recovery.
A context epoch tracks which briefing a participant has seen. Compaction advances the epoch without fencing a running tool.
These three answer different questions and cannot substitute for one another:
| Question | Answered by |
|---|---|
| Who is acting? | Actor |
| Which lifetime is acting? | Incarnation |
| What context has that lifetime seen? | Context epoch |
Human authority
Section titled “Human authority”Human operator authority is provisioned separately, with an explicitly chosen principal. It is never inferred from Git email, the OS display name, a branch or a message. Registering a worker grants no review or operator permissions. See Operator and reviewer setup.