# Enterprise
Source: https://docs.rootaccess.ai/enterprise

Hideout for teams building firmware in regulated industries

Building firmware under DO-178C, ISO 26262, IEC 62304, or other regulatory standards?

Hideout uses deterministic algorithms to parse schematics and datasheets, with outputs tagged to MISRA, CERT, AUTOSAR, and DO-178C — repeatable, auditable results across both Platform (orchestration, requirements, verification) and the Seb CLI (code authoring and on-target debug).

## Deployment options

For programs with stricter requirements:

* **VPC** — single-tenant deployment in your own cloud
* **On-premises** — fully self-hosted
* **GovCloud / air-gapped** — for classified or export-controlled work

Tenant data is isolated. **Zero data retention (ZDR)** is available for enterprise deployments — your prompts and code are processed only to serve the request and aren't retained by the underlying model providers. Your code is never used to train models, and IP for generated code is fully assigned to you.

## Silicon coverage

First-class support for \~1,200 MCU parts across eight major vendors and toolchains beyond GCC — IAR, Keil MDK, Green Hills MULTI, Wind River Diab, and Tasking. New silicon onboarded within two weeks on request.

[Contact us](mailto:support@rootaccess.ai) to learn more about our enterprise plans.


# Apply diff locally
Source: https://docs.rootaccess.ai/features/apply-locally

Write an agent's proposed change straight into your local checkout from chat, through the CLI daemon — no copy-paste, no manual patching.

When Seb shows a diff in chat, **Apply locally** writes that change directly into your working copy on disk — so you can build, run, and inspect it locally without copying the patch by hand.

<Note>
  **Where:** the **Apply locally** button on a diff card in chat ([Agents page](/guide/run-agents)). Requires [`seb connect`](/reference/cli-commands#seb-connect) running on the machine with your checkout.
</Note>

## How it works

The button sends the edit to your local **CLI daemon** — the background process `seb connect` keeps running — which applies it to the file on disk.

* **Daemon offline** — if `seb connect` isn't running, you'll see *"Your local daemon isn't connected — run `seb connect`."*
* **Branch mismatch** — if your local checkout is on a different branch than the one Seb is reading, you get a heads-up before it applies, so a change never lands on the wrong branch.
* **No auto-commit** — the change lands in your working tree only; you review and commit it yourself (or ask Seb to).

## See also

* [Run agents](/guide/run-agents) — where diff cards appear
* [Review in the CLI](/guide/review-in-cli) — the other half of the local review loop
* [`seb connect`](/reference/cli-commands#seb-connect)


# Memory management
Source: https://docs.rootaccess.ai/features/memory

A persistent knowledge store Seb reads before every task — project memory and organization-wide conventions — so it doesn't relearn your codebase each session.

Memory is a persistent set of facts Seb reads before every task: conventions, decisions, hardware quirks, and toolchain preferences it would otherwise rediscover each session. It's injected into every agent — in the Platform, the CLI, and background jobs.

## Two tiers

| Tier                                     | Use for                                                                  | Where to find it                                                                            |
| ---------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
| **Project memory**<br />(this project)   | Errata, design decisions, and quirks specific to this board or codebase. | **Platform:** Project Settings → Memory<br />**CLI:** `/memory` to view, `/remember` to add |
| **Organization memory**<br />(whole org) | Team-wide conventions, toolchain preferences, how Seb should behave.     | **Platform:** Profile → Memory<br />**CLI:** `/memory` to view                              |

Both are read by every agent. Organization memory is shared with all org members, so keep it to genuinely org-wide facts.

## How facts get saved

* **Seb saves project memory automatically** as it works — when it learns something durable, it writes it to project memory.
* **Organization memory needs your approval.** When Seb proposes an org-wide fact, a confirmation chip appears in chat; nothing is saved until you approve it.
* **You can add facts yourself** — in the CLI with `/remember <fact>` (project memory), or by editing organization memory directly in **Profile → Memory**.

View what's stored with `/memory` in the CLI (org memory + project memory), or in the Platform — project memory under **Project Settings → Memory**, organization memory under **Profile → Memory**.

## Isolated projects

Project owners can mark a project **memory-isolated** in project settings. On an isolated project, Seb's project memory still works, but nothing is ever promoted to organization memory — use it for NDA-bound, export-controlled (ITAR/EAR), or per-client work where facts must not leak across the org.

## Guardrails

* **Secrets are refused.** Writes containing key material, private keys, tokens, or verbatim code/file contents are rejected — keep memory at the level of facts and conventions, not data.
* **Size cap.** Each store is capped (\~32k characters); prune stale entries before adding more.
* **Audited.** Every write is logged with who wrote it and when, for org oversight.

## See also

* [Slash commands](/reference/slash-commands) — `/remember`, `/memory`
* [Guide → 3. Run agents](/guide/run-agents)


# System
Source: https://docs.rootaccess.ai/features/system-diagram

An auto-generated hardware block diagram of your project — subsystems, components, and the buses between them — built from your BOM and schematics.

Seb builds a block diagram of your hardware from files you've already uploaded, so you can see the whole system — subsystems, components, and the buses wiring them together — at a glance.

<Note>
  **Where:** Platform → **System** page (`/system`).
</Note>

<Frame>
  <img alt="The System page — a hardware block diagram with components, buses, and a bus filter" />
</Frame>

## What you need

The diagram is generated from your [hardware context](/guide/hardware-context):

* **BOM** or **schematic** — at least one is required. Without either, the page points you to the Context page to upload one.
* **Datasheets** and **requirements** — optional, used to infer connections the schematic doesn't spell out.

## Generate it

Press **Generate diagram**. Generation runs in the background — it can take a couple of minutes — and the diagram appears when it's ready. A model picker lets you choose which model builds it (defaults to Claude Sonnet).

Hit **Regenerate** from the toolbar whenever your hardware changes.

## Read the diagram

* **Blocks** are components, colored by role — controller, sensor, actuator, comms, power, connector.
* **Edges** are connections, labeled with the bus or protocol (CAN, ARINC 429, SPI, I²C, UART, Ethernet, power…) and direction.
* **Solid vs. dashed edges** show confidence: a **solid** line is grounded in your schematic, netlist, or ICD; a **dashed** line is **inferred** from datasheets or requirements — treat it as a suggestion to verify.

## Explore

* **Click a block** to highlight it and everything wired to it.
* **Subsystem rail** (right) groups blocks by function — click a subsystem to isolate it, or expand it to read its description and component list.
* **Bus filter** — click a protocol chip (e.g. CAN) to show only that bus.
* **Data-flow toggle** animates signals travelling along every edge at once, so you can watch the full data flow move through the system end to end.
* **Copy Mermaid** exports the diagram source for use elsewhere.

The diagram is read-only — to change it, update your BOM or schematic and regenerate.

## See also

* [Guide → 2. Add hardware context](/guide/hardware-context) — where the BOM, schematics, and datasheets that drive the diagram are uploaded.


# Worktrees
Source: https://docs.rootaccess.ai/features/worktrees

Run several seb chat sessions on the same repo at once — each in its own isolated git worktree, so they never clobber each other's branch.

A worktree is a second working copy of your repo, on its own branch, sharing the same git history. Worktrees let you run **several `seb chat` sessions in parallel** on one repo — one pairing on a feature, another reviewing an agent's PR — without them fighting over the current branch or forcing you to stash and switch.

<Note>
  **Where:** inside [`seb chat`](/reference/cli-commands#seb-chat), run `/worktree`.
</Note>

## Use it

* **`/worktree`** — open a menu to create a new worktree or switch to an existing one (type to filter the list).
* **`/worktree <name>`** — create, or jump straight to, a named worktree.

Each worktree is created under `.seb/worktrees/<name>/`, branched from your current `HEAD`. Switching points the session — Seb's commands and file edits — at that directory; your main checkout is never touched. Worktrees whose directories were deleted are pruned automatically.

## A typical split

* One session runs [`/pull`](/reference/slash-commands) to review an agent's PR on its branch.
* Another runs in a fresh `/worktree feature-x` to prototype something new.

Both share the same repo and history; neither blocks the other.

## See also

* [Slash commands](/reference/slash-commands) — `/worktree`, `/pull`
* [Guide → 5. Review in the CLI](/guide/review-in-cli)


# 2. Add hardware context
Source: https://docs.rootaccess.ai/guide/hardware-context

Datasheets, BOM, schematics, supporting docs, compliance standards, and the SEB.md project brief — everything Seb needs to know before it writes a line of code.

Give Seb the knowledge it needs to make good decisions — chips, BOM, schematics, design docs, and the compliance standards you target.

<Note>
  **Where:** Platform → project **Context** page.
</Note>

## Hardware

Three upload slots:

* **Schematics** — `.SchDoc` (Altium), `.kicad_sch` (KiCAD), `.sch`, or XML.
* **Datasheets** — PDFs of the chips, sensors, and modules in your build.
* **BOM** — XLSX, CSV, or ODS. Upload kicks off a Nexar datasheet fetch per MPN; misses are reported per-line so you can fill the gap manually.

## Supporting docs

Design notes, SOPs, ICDs, test plans. PDF, DOCX, or Markdown. Seb reads them as project context whenever it reasons about your codebase.

## Target a compliance standard

Pick the standards your project is held to — DO-178C, ISO 26262, IEC 62304. These drive the traceability rules used by gap analysis.

## Requirements and gap analysis

Skip if you're not under formal compliance and have no structured spec to grade code against — the agent loop in [step 3](/guide/run-agents) works without requirements.

Upload on the Context page's **Requirements** card:

* **CSV** — a mapping preview confirms which columns are id / text / level / safety class.
* **PRD / DOCX / PDF / MD / TXT** — Seb extracts shall-statements and proposes a requirement list; you accept it before it lands.

Gap analysis runs automatically once requirements land. It walks the codebase, finds traces to each requirement, and writes verdicts on two axes:

* **Code**: `resolved` / `stub` / `broken` / `no_trace`
* **Test**: same scale

Verdicts appear on the **Verification** page (`/requirements`) as a status board with a coverage bar. Click any card to read the verdict, resolve ambiguous traces, or hit **Launch agent** to fix the gap. Launching opens the same New Agent chat as [step 3](/guide/run-agents), pre-scoped to that requirement.

Hit **Sync** to rerun. Hideout also auto-reruns when a trace points at a file that's changed since the last run.

## SEB.md

An auto-generated project brief — what the project is, the major subsystems, conventions to follow. Generated on first connect from the repo and kept current as the codebase evolves. Edit it directly as Markdown; Seb reads it before every task.

<Tip>
  Treat SEB.md like an onboarding doc for a new teammate. The more concrete it is about how *your* codebase is laid out, the less Seb has to guess.
</Tip>

## Next

[Guide → 3. Run agents](/guide/run-agents).


# 5. Review in the CLI
Source: https://docs.rootaccess.ai/guide/review-in-cli

Pull a finished agent's PR into your terminal, pair with Seb on the change, run more tests, and commit back.

The CLI runs Seb in your terminal. Its primary use is reviewing the PR an agent just produced; the same `seb chat` also pairs with you on code, runs hardware tests locally, and serves bridges back to Platform.

Reviewing in the CLI gives you a reviewer that already knows the project and branch — ask questions about the change, run hardware procedures the agent's cloud machine can't reach, and push edits back through the same chat that drafted them.

<Note>
  **Where:** your terminal, with [`seb` installed and `seb connect` previously run](/install).
</Note>

## Pull the PR

```bash theme={null}
cd path/to/your/repo
seb chat
```

Once in chat, pull the agent's PR:

```
/pull
```

`/pull` lists open PRs, checks out the agent's branch, updates your working copy, and opens the chat with the agent's summary already loaded.

<Frame>
  <img alt="/pull listing open PRs in the Seb chat" />
</Frame>

## What to do next

* **Read the diff and ask questions.** "Why this approach?" "What about the locking around line 80?" Answers are grounded in the actual change.
* **Run more tests.** Anything that runs on your machine — including hardware procedures that need your bench attached — works the same as it does on the agent's side, because `seb connect` is already up.
* **Edit the code directly.** Make changes in the file tree; Seb sees them as they happen.
* **Paste a screenshot.** Paste an image into the prompt with `Ctrl+V` — a scope capture, a board photo, an error on a display. It drops in as an `[Image #1]` placeholder and Seb reads it alongside the diff. (On WSL, paste reads the Windows clipboard.)

## Pick up on either surface

Chats sync across the CLI and Platform. A session you start in `seb chat` shows up in the Platform's chat history tagged **CLI**, and a Platform chat is resumable here with [`/history`](/reference/slash-commands) — so you can switch surfaces mid-task without losing the thread.

## Commit back

When the change is good, ask Seb to commit and push:

> Commit these changes with message "review: tighten error handling in motor\_init" and push.

The PR updates on top of the agent's branch. On Platform's Agents page, the row stays in **In Review** until you click **Complete** (or the PR merges on GitHub).

## Next

From here, cycle: launch more agents ([step 3](/guide/run-agents)), add procedures ([step 4](/guide/test-benches)). Reference: [CLI commands](/reference/cli-commands), [slash commands](/reference/slash-commands), [Platform map](/reference/platform-map).


# 3. Run agents
Source: https://docs.rootaccess.ai/guide/run-agents

Describe your task in chat, review Seb's plan, and launch an agent.

Seb runs autonomously in a dedicated VM environment — branching off your repo, writing code, running tests, and raising a PR. You launch and track agents in one place: the **Agents** page.

<Note>
  **Where:** Platform → **Agents** page. The left side is your chat with Seb; the right side is the **Agents rail**, where launched jobs live.
</Note>

## Launch an agent

You launch agents straight from chat — there's no separate form.

1. **Describe the task.** Open the Agents page and tell Seb what you want, in plain language: "Add CAN error-frame handling to the motor controller." Use **+** to start a fresh conversation, or the history dropdown to reopen an earlier one.
2. **Add context and tune the run (optional).**
   * **Mention a ticket** — with the project [linked to Jira](/integrations/jira) or [Linear](/integrations/linear), type an identifier like `KAN-42` or `ROO-1163` and Seb pulls the ticket in as context.
   * **Paste a screenshot** — drop an image into the composer (⌘/Ctrl+V).
   * **Pick the branch** — the branch pill in the composer shows what Seb is reading from; click it to switch.
   * **Choose a model** — the model picker in the composer; defaults to your global default from Profile → Model.
3. **Review Seb's proposal.** Seb replies with a proposal card showing a **plan** (the files it'll change) and a **test plan** (the checks it'll run, tagged cloud-VM or hardware). Edit the prompt on the card if you want to adjust scope.
4. **Launch.** Click **Launch** on the card. The job starts and shows up in the Agents rail.

<Frame>
  <img alt="Seb's proposal card — the prompt, the planned file changes, and a Launch button" />
</Frame>

<Tip>
  From [gap analysis](/guide/hardware-context#requirements-and-gap-analysis), **Launch agent** on a requirement card opens this page with the requirement already linked and a planning turn started — pick up at step 3.
</Tip>

## The Agents rail

Launched jobs are grouped by state on the right:

* **Queued** — proposed, or waiting to start.
* **In Progress** — running, or blocked on a dependency.
* **In Review** — Seb has a PR ready. Open the job for the summary, files changed, and PR link, plus **Send Back**, **Complete** (accept), and **Dismiss** (reject).
* **Needs Attention** — failed. A failed job has a **Relaunch** button that retries it fresh from the original prompt.
* **Done** — completed, dismissed, merged, or cancelled.

## Where tests happen

The agent runs your test bench procedures as part of its loop:

* **Software-only procedures** run on the agent's cloud machine. No setup needed.
* **Hardware procedures** reach your attached hardware to run tests and debug during implementation. See [Test benches](/guide/test-benches) for setup.

## Send Back

**Send Back** on a job in review opens a new chat seeded with that job's context, on its branch. Describe what needs to change, then launch a follow-up that continues on the same branch — so you refine the work instead of starting over.

Diff cards in chat also carry an **[Apply locally](/features/apply-locally)** button, which writes a change straight into your local checkout.

## Next

[Guide → 4. Set up HIL test benches](/guide/test-benches).


# 1. Set up a project
Source: https://docs.rootaccess.ai/guide/setup-project

Create a Hideout project, connect your GitHub or GitLab repo, and (optionally) link Jira or Linear.

A **project** groups your code, hardware context, and agent runs. Use one project per firmware codebase.

<Note>
  **Where:** Platform at [hideout.rootaccess.ai/](https://hideout.rootaccess.ai/) → home page → **New project**.
</Note>

## Create the project

The wizard walks you through four steps:

<Steps>
  <Step title="Name it">
    Pick a name. You can rename later.

    <Frame>
      <img alt="Name step of the new project wizard" />
    </Frame>
  </Step>

  <Step title="Connect a repo">
    Connect a GitHub or GitLab repo.

    <Frame>
      <img alt="Repo connect step of the new project wizard" />
    </Frame>
  </Step>

  <Step title="Invite teammates (optional)">
    If your organization already has members, pick them from the list to add with one click. You can also invite anyone by email. Everyone joins as a **member**; change roles later in Project Settings → Members. Skip it if you're working solo for now.
  </Step>

  <Step title="Pick a next move">
    Bring in project requirements, link Jira or Linear projects, or directly talk to Seb about what you want to build.

    <Frame>
      <img alt="Source step of the new project wizard — upload context, connect Jira or Linear, or chat with Seb" />
    </Frame>
  </Step>
</Steps>

## Link a work tracker (optional)

To mention Jira or Linear tickets in your messages when launching agents:

1. Profile → Integrations → **Connect Jira** or **Connect Linear**.
2. Project Settings → Integrations → link a project (Jira) or team (Linear) to this Hideout project.

Once linked, typing an identifier like `KAN-42` or `ROO-1163` when you chat with Seb on the Agents page pulls the ticket's title and description in as context. See the [Jira](/integrations/jira) and [Linear](/integrations/linear) pages for the connection and linking steps.

## Target a compliance standard (optional)

If your project is held to a formal compliance standard — DO-178C, ISO 26262, IEC 62304 — pick the standards on the Context page and set the traceability policy in Project Settings. [Gap analysis](/guide/hardware-context#requirements-and-gap-analysis) uses them to score your codebase.

## Settings, members, danger zone

Project Settings (`/project-settings`) covers rename, traceability policy per requirement level, member invites (owner / admin / member), per-project integration links, and project deletion.

## Next

[Guide → 2. Add hardware & context](/guide/hardware-context).


# 4. Set up HIL test benches
Source: https://docs.rootaccess.ai/guide/test-benches

Hardware-in-the-loop testing — define procedures and bridges that let agents validate their work on your real board while they code.

**Hardware-in-the-loop (HIL) testing** is what sets Hideout apart: while an agent writes code in the cloud, it runs your test procedures against the real board on your bench — closing the loop between a firmware change and how the hardware actually behaves. You define those procedures and hardware connections here.

<Note>
  **Where:** Platform → **Testing** page (`/testing`) — or just ask Seb to draft one from the [Agents page](/guide/run-agents) (see [Set up from chat](#set-up-from-chat)). Hardware bridges also require `seb connect` running on the host with the hardware attached.
</Note>

## Procedures

A procedure is a named verification step saved on the project. Agents run them during implementation to validate their work, giving you confidence in the code they produce.

Common shapes:

* **Smoke test** — boot the firmware, check the expected strings on serial.
* **Calibration check** — run a routine, compare results against expected ranges.
* **Regression** — replay a captured CAN sequence, assert no unexpected frames.

### Add a procedure

The quickest way is to [have Seb draft one for you](#set-up-from-chat) from chat.

You can also set one up manually: Testing page → procedure list → **+ Add procedure** opens an editor. Fill in:

* **Title and tags** — a name and optional categories.
* **Where it runs** — the agent's cloud VM, or your machine via local Seb (for licensed toolchains or hardware-bound builds).
* **Steps** — the shell commands to run, each with a working directory and timeout.
* **Output files** — path globs to capture from the run.

Saving adds the procedure to the project; it appears immediately for every member.

<Frame>
  <img alt="The procedure editor — title, execution mode, steps, and output files" />
</Frame>

### Run a procedure

Click **Run** on a procedure card. If it takes inputs, a dialog asks for them; live output streams in a side pane. Each run is recorded with timestamp, outcome, and operator.

## Bridges (hardware links)

A bridge is a live stream from a device connected to your **host machine**.

| Bridge           | Use                                                 |
| ---------------- | --------------------------------------------------- |
| Serial Console   | UART monitor                                        |
| CAN Bus          | Live CAN traffic, decoded against project DBC files |
| GDB Probe        | On-target debug (ST-Link, J-Link, CMSIS-DAP)        |
| Saleae Logic     | Stream digital + analog signals                     |
| Ethernet Capture | Capture and inspect frames                          |
| UDP Receiver     | Receive UDP log streams                             |

Add a bridge from the Testing page → bridge list → **+ Add**.

The **Connection status** pill in Platform's header shows whether a host is online. Without an active host, bridges can't stream and procedures that touch hardware won't run.

## Set up from chat

You don't have to build any of this by hand. On the [Agents page](/guide/run-agents), ask Seb and it drafts the setup for you:

> Write a procedure that builds the firmware with CMake and captures the ELF.

> Set up the serial console on USB device `A50285BI` at 115200 baud.

For a **custom procedure**, Seb reads your repo and fills in the title, steps, where it runs, and output files; for a **built-in bridge** (serial console, CAN bus, …), it fills in the connection fields. Either way it posts a proposal card — nothing is saved yet — and you click **Save to Testing tab**. The result lands on your Testing page identical to a manual setup: runnable by you and by launched agents, and editable in the procedure editor above.

## How agents use this

Agents call procedures while writing code, ensuring proper implementation of the given task. Software-only procedures run on the agent's cloud machine; hardware procedures reach your host machine through the bridges configured here — putting your real board in the loop so the agent validates against actual hardware behavior, not just a build that compiles.

## Next

[Guide → 5. Review in the CLI](/guide/review-in-cli).


# Welcome
Source: https://docs.rootaccess.ai/index



**Root Access** is an applied AI company building tools for engineering teams in regulated industries. **Seb** is our coding agent for hardware, purpose-built for embedded systems development. **Hideout** is our agent management platform for deploying, monitoring, and controlling AI agents.

## How it works

Five steps, in order:

1. [**Set up a project**](/guide/setup-project) — connect a GitHub or GitLab repo, (optionally) link Jira or Linear, and bring in your requirements.
2. [**Add hardware & context**](/guide/hardware-context) — upload datasheets, BOM, schematics, and supporting docs; target a compliance standard; tune SEB.md.
3. [**Run agents**](/guide/run-agents) — describe your tasks and launch agents. Seb automatically links relevant Jira tickets, Linear issues, or requirements.
4. [**Set up HIL test benches**](/guide/test-benches) — hardware-in-the-loop testing: agents run tests and firmware directly on your real hardware while they work.
5. [**Review in the CLI**](/guide/review-in-cli) — pull agents' work with `/pull`, review, edit, and debug with Seb.

## Platform and the CLI

| Tool         | What it's for                                                                                                                                                                           |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Platform** | Set up projects, orchestrate different instances of Seb, configure tests, and manage org and integrations.                                                                              |
| **CLI**      | Work directly with Seb on a specific task. Pull an agent's work locally with `/pull` to review, edit, and debug alongside Seb. Enable Platform hardware interaction with `seb connect`. |

## Get started

[Install Seb and create an account](/install), then continue to [step 1](/guide/setup-project).

Quick lookups: [Platform map](/reference/platform-map) · [CLI commands](/reference/cli-commands) · [Slash commands](/reference/slash-commands).


# Install
Source: https://docs.rootaccess.ai/install

Sign up for Hideout and install the Seb CLI.

## 1. Sign up

Create your account at [hideout.rootaccess.ai/login](https://hideout.rootaccess.ai/login).

## 2. Install the Seb CLI

Use the CLI to directly pull in sessions locally. Review the changes, continue working, or debug directly on hardware with Seb.

| OS      | Supported versions         |
| ------- | -------------------------- |
| macOS   | Sonoma (14), Sequoia (15)  |
| Windows | Windows 11                 |
| Linux   | Ubuntu 22.04, Ubuntu 24.04 |

<Tabs>
  <Tab title="macOS / Linux / WSL">
    ```bash theme={null}
    curl -fsSL https://seb.rootaccess.ai/install.sh | bash
    ```
  </Tab>

  <Tab title="Windows (PowerShell)">
    ```bash theme={null}
    powershell -ExecutionPolicy ByPass -c "irm https://seb.rootaccess.ai/install.ps1 | iex"
    ```
  </Tab>
</Tabs>

Close and reopen your terminal, then verify:

```bash theme={null}
seb --version
```

To update later:

```bash theme={null}
seb update
```

## Next

[Guide → 1. Set up a project](/guide/setup-project).


# GitHub
Source: https://docs.rootaccess.ai/integrations/github

Connect GitHub once at the account level; every project uses the same identity.

GitHub is one of two supported code hosts ([GitLab](/integrations/gitlab) is the other). Hideout reads your repo, opens branches, and raises PRs through this connection. Connect once at the account level; every project against a GitHub repo reuses it.

<Note>
  **Where:** Platform → **Profile → Integrations** tab. Click **Connect GitHub**.
</Note>

## What we ask for

The GitHub OAuth scope is `repo` — read and write access to the repositories you authorize. Hideout uses it to:

* Read your codebase when an agent launches.
* Push branches and open PRs.
* Read commit and branch state for the Agents page.

Organization-level admin and billing access are not requested.

## Per-repo authorization

GitHub connections are per-user, per-repo. If a teammate connected a repo you haven't, your launches against the project's primary repo still work — Hideout uses the project owner's connection instead. The only thing affected is which repos show up in the New Project wizard's picker for you.

## Disconnecting

**Profile → Integrations → GitHub → Disconnect** clears the tokens and removes Hideout's authorization. Projects you've created lose their repo link; teammates' connections to the same repo aren't affected.

## Troubleshooting

* **"GitHub connection expired"** — your OAuth token was revoked or rotated. Reconnect from Profile → Integrations.
* **Agent unable to read codebase** — check that the project's connected repo is still accessible to the connecting user and that branch permissions allow Hideout to push.


# GitLab
Source: https://docs.rootaccess.ai/integrations/gitlab

Use GitLab as your code host. Connect once at the account level; every project you create on GitLab uses the same identity.

GitLab is an alternative to [GitHub](/integrations/github) as your code host. Connect once at the account level; every Hideout project against a GitLab repo reuses that connection.

`gitlab.com` is supported today. Self-hosted GitLab is on the roadmap — the connection routes through `gitlab_base_url`, so a single config change will enable it.

<Note>
  **Where:** Platform → **Profile → Integrations** tab. Click **Connect GitLab**.
</Note>

## What we ask for

The GitLab OAuth scope is `api` — read and write access to the resources you authorize. Hideout uses it to:

* Read your codebase when an agent launches.
* Push branches and open Merge Requests.
* Read commit and branch state for the Agents page.

## Per-user authorization

GitLab connections are per-user — the connection sees every group and project your account can access. The project picker in the New Project wizard lists what's visible to you; pick a repo and a branch and Hideout uses that combination for clones and MRs.

## Disconnecting

**Profile → Integrations → GitLab → Disconnect** clears the tokens and removes Hideout's authorization. Projects you've created against GitLab repos lose their repo link; teammates' connections to the same repo aren't affected.

## Troubleshooting

* **"GitLab connection expired"** — your OAuth token was revoked or rotated. Reconnect from Profile → Integrations.
* **Agent unable to read codebase** — check that the project's connected repo is still accessible to the connecting user and that branch permissions allow Hideout to push.
* **Repo not in the picker** — the OAuth token only sees what your GitLab account sees. If a teammate connected the repo originally and you can't, check your GitLab group membership.


# Jira
Source: https://docs.rootaccess.ai/integrations/jira

Connect Jira so you can mention Jira issues directly in your messages when launching agents.

Jira integration is two steps: connect once per user, then link a specific Jira project to each Hideout project. Once linked, mention Jira issues directly in the New Agent chat.

<Note>
  **Where:** Platform → **Profile → Integrations** for the account connection, then **Project Settings → Integrations** to link a project.
</Note>

## 1. Connect Jira (account-level)

Profile → Integrations → **Connect Jira**. You'll be sent to Atlassian to authorize the workspace, then dropped back on Project Settings with a "Connected" badge.

Permissions requested: `read:jira-work`, `read:jira-user`, and `offline_access` (so the connection refreshes itself).

## 2. Link a Jira project (per Hideout project)

On Project Settings → Integrations, the Jira card now shows every Jira project visible to your account. Pick the one this Hideout project should mirror.

## What you get

In the [New Agent](/guide/run-agents) chat, type a Jira identifier (e.g. `KAN-42`) anywhere in your message. Seb pulls in the issue's title and description as context and tags the launch with it.

Tickets resolve on demand at agent-launch time, against live Jira.

## Disconnecting

**Profile → Integrations → Jira → Disconnect** clears tokens. Projects you own that linked to a Jira project lose the link; teammates' links survive until they disconnect themselves.

## Troubleshooting

* **"Jira connection expired"** — token was revoked or refresh failed. Reconnect from Profile.
* **Project picker is empty** — your Jira account doesn't have access to any projects. Check Atlassian permissions.
* **"Couldn't find ticket KAN-42"** — the identifier doesn't exist in the linked Jira project, or your account doesn't have permission to see it. Check the project link on Project Settings → Integrations.


# Linear
Source: https://docs.rootaccess.ai/integrations/linear

Connect Linear so you can mention Linear issues directly in your messages when launching agents.

Linear integration is two steps: connect once per user, then link a specific Linear team to each Hideout project. Once linked, mention Linear issues directly in the New Agent chat.

<Note>
  **Where:** Platform → **Profile → Integrations** for the account connection, then **Project Settings → Integrations** to link a team.
</Note>

## 1. Connect Linear (account-level)

Profile → Integrations → **Connect Linear**. You'll be sent to linear.app to authorize the workspace, then dropped back on Project Settings with a "Connected" badge.

## 2. Link a Linear team (per Hideout project)

On Project Settings → Integrations, the Linear card lists every team visible to your account. Pick one. You can also optionally pick a project within that team to narrow the imported issue set.

## What you get

In the [New Agent](/guide/run-agents) chat, type a Linear identifier (e.g. `ROO-1163`) anywhere in your message. Seb pulls in the issue's title and description as context and tags the launch with it.

Issues resolve on demand at agent-launch time, against live Linear.

## Disconnecting

**Profile → Integrations → Linear → Disconnect** clears tokens. Projects you own that linked to a Linear team lose the link; teammates' links survive until they disconnect themselves.

## Troubleshooting

* **"Linear connection expired"** — your credentials were revoked or rotated. Linear connections don't auto-refresh, so this always means reconnecting from Profile.
* **Team picker is empty** — your Linear account doesn't have access to any teams. Check workspace permissions.
* **"Couldn't find ticket ROO-1163"** — the identifier doesn't exist in the linked Linear team, or your account doesn't have permission to see it. Check the team link on Project Settings → Integrations.


# CLI commands
Source: https://docs.rootaccess.ai/reference/cli-commands

Reference for the `seb` command-line tool.

Most `seb` commands run inside a directory linked to a Hideout project via `seb connect`.

## `seb chat`

Chat with Seb, the AI coding agent. Scoped to whichever Hideout project the current directory is linked to. Supports [slash commands](/reference/slash-commands).

```bash theme={null}
seb chat
```

<Tip>
  Paste an image into the prompt with `Ctrl+V` (a scope capture, board photo, or error screen) — it attaches as an `[Image #1]` placeholder Seb can see. Delete the placeholder to drop the attachment.
</Tip>

## `seb connect`

Authenticate the CLI with your Hideout account and link the current directory to a project.

```bash theme={null}
seb connect
```

What it does:

Stays running in the background to serve hardware bridges back to Platform's Testing page and let agents reach attached hardware — leave the terminal open while you want it live.

Run once per machine + per repo. Persists across reboots if started with `seb connect --service` (where supported).

<Note>
  You don't need to run `seb connect` for everything — only for the steps that require it (test benches on real hardware, and the CLI review loop). Platform works on its own.
</Note>

## `seb update`

Update the Seb CLI to the latest released version.

```bash theme={null}
seb update
```

## `seb --version`

Print the installed version.

```bash theme={null}
seb --version
```

## See also

* [Slash commands](/reference/slash-commands) — what's available inside `seb chat`
* [Install](/install) — fresh-install steps
* [Guide → 5. Review in the CLI](/guide/review-in-cli) — the main CLI workflow


# Organization management
Source: https://docs.rootaccess.ai/reference/organization

How organizations, members, and roles work — and how project access stays scoped to the people you add.

Your account lives in one **organization** — the billing and membership boundary. Credits are pooled across it, and everyone you invite shares it. Projects belong to the org, but access to each one is granted per project, not org-wide.

## Members and roles

An org **owner** or **admin** invites people by email; accepting the invite adds them to the org. Every member holds one role:

| Role       | Can                                                                                            |
| ---------- | ---------------------------------------------------------------------------------------------- |
| **Owner**  | Everything — edit org settings and billing, invite or remove members (any role), change roles. |
| **Admin**  | Invite members (member or admin) and revoke invites.                                           |
| **Member** | Belong to the org and to the projects they're added to.                                        |

<Note>
  **Where:** Platform → **Profile** → **Organization** — invite and manage org members.
</Note>

## Projects aren't shared by default

Adding someone to the org does **not** hand them your projects. Each project is private to the people explicitly added to it — so teammates in the same org can work on entirely different projects without seeing each other's.

To grant access to a specific project, its **owner** invites the person from **Project Settings → Members** — by email, or one-click for existing org members during the [project wizard](/guide/setup-project). Project roles are **owner** and **member**.

This keeps work compartmentalized: bring a contractor or teammate into just the one project they need, without exposing the rest of the org's. For work whose context must not even reach shared org memory, see [memory-isolated projects](/features/memory#isolated-projects).

## See also

* [Set up a project](/guide/setup-project) — invite teammates during setup


# Platform map
Source: https://docs.rootaccess.ai/reference/platform-map

Quick reference: every Platform page and what it's for.

Every Platform route at a glance.

| Route               | What it does                                                                                                                                                                         |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `/`                 | Home — list of your projects + **New project** button                                                                                                                                |
| `/project`          | **Context page** — code, hardware uploads, compliance, SEB.md                                                                                                                        |
| `/system`           | **System** page — auto-generated [hardware block diagram](/features/system-diagram) from your BOM and schematics                                                                     |
| `/requirements`     | **Verification** page — gap analysis verdicts (CSV/PRD-based). See [Requirements and gap analysis](/guide/hardware-context#requirements-and-gap-analysis).                           |
| `/agents`           | Chat with Seb and launch/track agents — chat sessions on the left, the Agents rail (Queued / In Progress / In Review / Needs Attention / Done) on the right. `/chat` redirects here. |
| `/testing`          | Procedures + hardware bridges                                                                                                                                                        |
| `/project-settings` | Owner-only project config — general / traceability / members / integrations / memory / danger zone                                                                                   |
| `/profile`          | Account / Organization / Memory / Preferences / Model / Billing / Usage / Integrations                                                                                               |

## Where common things live

* **Connect GitHub or Jira** → `/profile` → Integrations tab
* **Link a Jira project to this Hideout project** → `/project-settings` → Integrations tab
* **Upload requirements** → `/project` → Project section (Requirements card)
* **Run gap analysis** → automatic on requirements upload; **Sync** button on `/requirements` re-runs
* **Configure a hardware bridge** → `/testing` → bridge list → **+ Add**
* **Generate the system diagram** → `/system` → **Generate diagram**
* **Edit project memory** → `/project-settings` → Memory tab. See [Memory](/features/memory).
* **Edit organization memory** → `/profile` → Memory tab. See [Memory](/features/memory).
* **Check credits & usage** → `/profile` → Usage tab; manage your plan on the Billing tab.
* **Invite a teammate** → `/project-settings` → Members tab
* **Delete a project** → `/project-settings` → Danger zone

## Header pills

* **Connection status** — green when a `seb connect` host is online for the current project. Required for hardware bridges and hardware-procedure runs.
* **Project picker** — switch between projects without leaving your current page.


# Slash commands
Source: https://docs.rootaccess.ai/reference/slash-commands

Commands you can run inside a `seb chat` session.

Slash commands run inside `seb chat`. They control the session, switch modes, or run one-off actions without breaking the conversation.

| Command         | What it does                                                                                                                                                         |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/plan`         | Enter plan mode for the next message — Seb proposes a plan before acting.                                                                                            |
| `/debug`        | Browse hardware sources to attach (serial, GDB, Saleae, UDP, CAN). Use `/debug <name>` to attach directly.                                                           |
| `/pull`         | Pull a completed agent's PR into a local worktree so you can review and iterate on it.                                                                               |
| `/worktree`     | Create or switch to an isolated git worktree without touching your current branch. Use `/worktree <name>` to go straight to one, or `/worktree` to pick from a menu. |
| `/remember`     | Save a fact to this project's [memory](/features/memory) — `/remember <fact>`.                                                                                       |
| `/memory`       | Show this project's memory — organization memory plus project memory.                                                                                                |
| `/history`      | Browse and resume previous chat sessions (including chats started in the Platform).                                                                                  |
| `/more`         | Load more messages from the current session.                                                                                                                         |
| `/context`      | Show remaining LLM context window usage.                                                                                                                             |
| `/compact`      | Compact the context window by summarizing older messages.                                                                                                            |
| `/login`        | Log in to your Hideout account.                                                                                                                                      |
| `/logout`       | Log out of the CLI.                                                                                                                                                  |
| `/subscription` | Manage your subscription on Platform.                                                                                                                                |
| `/help`         | Show available commands.                                                                                                                                             |
| `/exit`         | Exit the chat session.                                                                                                                                               |

You can also type `exit`, `help`, or `quit` without the `/` prefix.

## See also

* [CLI commands](/reference/cli-commands) — top-level `seb` invocations
* [Guide → 5. Review in the CLI](/guide/review-in-cli) — the main use case for `/pull`