cix

Reproduced product workflow

One contract.
Three views.

This is real output from a disposable Cix daemon—not a website mock-up. A CLI write changes API-owned state; an independent REST read and the first-party dashboard show the same result.

Source revision4d5f4ffa
Captured1 September 2026
DaemonCurrent source, built with TCC
FixtureDisposable local data directory

The workflow

Change identity.
Read it back.

The site identity is a small example chosen because it is safe to reproduce. The same client boundary applies throughout Cix: cixctl and the dashboard call the REST API rather than private control paths.

01 / Baseline

Read through the CLI.

$ cixctl site show
instance_name=cix
site_name=(none)
domain_suffix=internal
02 / Mutation

Write through the CLI.

$ cixctl site set \
  --instance-name=demo \
  --site-name=cix \
  --domain-suffix=invalid

instance_name=demo
site_name=cix
domain_suffix=invalid
03 / Independent read

Confirm through REST.

$ curl -s \
  http://127.0.0.1:18766/v1/system/site

{"instance_name":"demo",
 "site_name":"cix",
 "domain_suffix":"invalid"}

The first-party dashboard

The same state reaches the browser.

The dashboard header below rendered demo.cix.invalid from the same daemon after the CLI write. The capture is intentionally narrow: it proves the product surface without exposing host inventory.

Cix dashboard showing the site identity demo.cix.invalid after it was set through cixctl
Actual Cix dashboard · disposable daemon · no reconstructed interface

Follow the evidence

Inspect the exact contract.

GET /v1/system/site and PUT /v1/system/site are defined in the OpenAPI document and described in the API guide. The CLI and dashboard implementations are in the same source tree.

Open OpenAPI Read the API guide