Totebox session
TopicFrom the PointSav Documentation
A Totebox Session is an AI-assisted contributor session opened within a single Totebox Archive — scoped to the archive's declared repositories, unable to write outside them, and the standard entry point for all development work in Totebox Orchestration.
A Totebox Session is an AI-assisted contributor session opened within a single Totebox Archive. It is scoped to the archive's declared repositories and cannot write outside them. From the contributor's perspective, opening a Totebox Session is how every development task in Totebox Orchestration begins. The session protocol mirrors the customer experience: the contributor's entry point in the workspace and the customer's entry point through `os-console` perform the same function.
This article describes how a session is opened, what it can and cannot do, the four permission tiers, and the inbox-and-outbox protocol that coordinates work across archives.
[edit]How to open a session
The intended entry point is the open-archive console command, planned for invocation from the hub session. When invoked, it is intended to:
- Read the archive manifest at
clones/<archive>/.agent/manifest.md - Print the archive name, tetrad status, AI gateway endpoint, and count of pending inbox messages
- Check the contributor's permission tier against the personnel record (see personnel-permissions)
- Set the
FOUNDRY_ARCHIVEandFOUNDRY_MODULE_IDenvironment variables - Open an AI session at the archive's root directory
This mirrors the customer experience: a community member or customer opens a Totebox Archive through `os-console`. The development workflow uses the same entry point, adapted for the workspace.
[edit]Session scope
A Totebox Session:
- Writes to any repository declared in the archive's manifest
- Commits to the archive's staging branch (never directly to the canonical
main) - Routes inference through the shared `service-slm` access-control gateway (Doorman) using the archive's module identifier
- Sends cross-archive requests as messages to the hub session (never writes to other archives)
- Stages wiki drafts in
.agent/drafts-outbound/for the editorial pipeline
A Totebox Session does not:
- Write workspace-level configuration or tool files
- Write to the identity store
- Access the canonical source trees directly (those receive content by promotion, not direct write)
- Open connections to sibling archive sessions
[edit]The Project Tetrad
Every Totebox Archive declares four legs of the Project Tetrad. A session's work contributes to all four:
| Leg | Session writes to |
|---|---|
| vendor | Feature code in the archive's pointsav-monorepo clone |
| customer | Operational guides in the archive's woodfine-fleet-deployment clone |
| deployment | Provisioning the running instance in the deployment directory |
| wiki | TOPIC draft files staged in .agent/drafts-outbound/ |
The hub session ratifies tetrad completeness when all four legs are present.
[edit]The AI session coordination protocol
Sessions communicate through the inbox-and-outbox file protocol:
- Each archive holds
.agent/inbox.mdand.agent/outbox.mdfiles - A Totebox Session reads its inbox at session start and archives actioned messages
- Outbound requests to other archives or to the hub session are prepended to
.agent/outbox.md(newest on top) - The hub session sweeps archive outboxes during workspace review and routes messages
In the planned next phase, app-orchestration-command (CommandCentre) is intended to broker all cross-archive messages by HTTP, with each message transiting the access-control gateway and the immutable ledger automatically. The file-based protocol is intended to remain as the fallback and the development-mode mechanism.
[edit]Permission tiers
Four tiers govern what a contributor — and the session they open — can do:
| Tier | Label | Pairing set |
|---|---|---|
| P1 | System Administrator | Command + every archive + every infrastructure node |
| P2 | Package Manager | Specific archives plus Stage 6 promotion paths |
| P3 | User | Specific archives; no Command pairing; read-only cross-archive |
| P4 | Interface | Read-only API surface only |
Tiers are enforced by pairings, not string comparisons. A P3 contributor's os-console is not paired to the Command — the connection does not exist. See pairing-as-permission for the formal mechanism.
[edit]Relationship to os-console
`os-console` is the customer-facing entry point for opening a Totebox Archive. In the development workspace, the open-archive command is the equivalent. Both are intended to perform the same function: read the archive manifest, validate the contributor's permission scope, set the session context, and open a working session inside the archive. The development environment uses the same pattern the customer is intended to use.
[edit]See also
- totebox-orchestration-development
- pairing-as-permission
- personnel-permissions
- doorman-protocol
- open-first-totebox-session — step-by-step guide: open and navigate a Totebox session