Skip to main content

​
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: 
curl -fsSL "https://argentos.ai/install.sh?channel=dev&ref=develop" | bash
Equivalent explicit form: 
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: 
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.