> ## Documentation Index
> Fetch the complete documentation index at: https://docs.argentos.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Developer Branch Installs

> Install ArgentOS from the private develop lane to test release candidates before promotion to main.

## Why This Exists

Production installs should not be the first place we discover regressions.

ArgentOS now supports a private developer lane so release-facing changes can be:

* merged into `develop`
* installed from a test channel
* regression tested by operators
* explicitly signed off before promotion to `main`

Use this path when you want to validate installer changes, update behavior, dashboard changes, agent workflow changes, or any release-facing integration before it becomes public.

## When to Use the Developer Branch

Use the developer branch install flow when:

* you are testing a release candidate
* you need to validate installer or updater changes
* you want to verify a bug fix in a realistic install environment
* you are checking for regressions before public release

Do not use it for normal operator installs or public customer installs. Those should stay on the production path.

## One-Line Developer Install

Use the public installer entrypoint with a test channel and explicit git ref:

```bash theme={null}
curl -fsSL "https://argentos.ai/install.sh?channel=dev&ref=develop" | bash
```

Equivalent explicit form:

```bash theme={null}
curl -fsSL https://argentos.ai/install.sh | bash -s -- --channel dev --git-ref develop
```

Both forms install from the private `develop` lane instead of production.

## What It Does

The developer install path:

1. uses the normal public installer entrypoint
2. selects the `dev` channel
3. resolves the requested git ref, with `develop` as the default dev lane
4. installs the runtime from that ref
5. persists the install on the dev update channel

After install, `argent update` on that machine should continue tracking the dev lane unless the channel is changed.

## Release Flow

The intended release flow is:

1. implementation happens on `codex/*`
2. Threadmaster merges validated work into `develop`
3. operators install and test from the dev lane
4. operator sign-off is recorded
5. the tested commit is promoted from `develop` to `main`
6. public release/export happens from `main`

This keeps `main` from becoming the first install surface for release-facing changes.

## Example Test Cases

Good reasons to use the developer branch install:

* hosted installer changes
* `argent update` behavior changes
* PostgreSQL or Redis bootstrap changes
* dashboard onboarding changes
* gateway auth or bootstrap changes
* public-doc changes that need validation alongside product behavior

## Switching Back to Production

To return a machine to the production lane:

```bash theme={null}
argent update --channel stable
```

If you want a completely clean production validation environment, use a separate machine, worktree, or state directory rather than reusing a dirty dev install.

## Notes

* The dev lane is for operator and internal testing.
* Public docs and operator runbooks should be updated before Threadmaster handoff when user-visible behavior changes.
* If a feature needs special test instructions beyond `develop`, include the exact ref and validation notes in the Threadmaster handoff packet.