congruency-launch

The downstream launcher for congruency — ONE python script, lives OUTSIDE the crank tree so it never dirties it.

Native (no docker, no x86 emulation). congruency 4.092+ provisions a php for the host's own arch (macOS arm64 → a native arm64 php with pdo_sqlite), so this serves the CMS directly via setup.py up.

python3 congruency_up.py up          # provision native php, wire state, serve (persistent)
python3 congruency_up.py down        # stop the server
python3 congruency_up.py status      # process + HTTP status + state db
python3 congruency_up.py logs        # tail the server log
python3 congruency_up.py reset       # move state aside (never deleted), re-seed, serve
python3 congruency_up.py up --port 9000

How it works

up = retire any legacy container → clone/fetch our gitlab into source_dir and check out the newest version-* tag → provision native php → ensure/seed persistent state → symlink the deploy tree's gitignored checkouts/current/state/congruency.sqlite at the persistent live DB (state_dir, the native equivalent of the old bind-mount) → inject CONGRUENCY_AUTH_TOKEN from the jazz_wallet → setup.py up (which self-backgrounds + writes logs/serve.pid).

State is persistent. The live DB (tickets / api_routes / api_keys / agents) lives at state_dir (~/bin/config/congruency) and is never re-seeded (present → kept); up serves without install, so rebuilds preserve it. reset moves state aside (never deletes) and re-seeds.

Config is registry.json beside the script (refuses to run without it); any failure appends a timestamped record to bug_reports.jsonl. No shell scripts.