# 2026-09-19 physical-host systemd deployment smoke

## Scope

This evidence validates the new upload/install path for the Go Agent and
Dispatcher on a Debian 13 host. It does **not** approve G0/P1, start a
production service, or prove SIP/AI/OSS/MQ acceptance.

Production deployment is physical-host systemd. Docker was not used for this
installation path; the earlier Docker/SIPp activity is a disposable ECS smoke
and remains outside the production package.

## Locked release and package

- Release: `0.1.0-p1.20260919`
- Target: `linux/amd64`
- Go: `1.27.1`
- OS: Debian 13 (Trixie) amd64
- Init: systemd
- Cell boundary: Asterisk `22.10.1`, separately installed/owned by the
  management-approved physical Cell artifact
- Package:
  `deploys/packages/sip-go-agent-0.1.0-p1.20260919-linux-amd64.tar.gz`
- SHA-256:
  `4567afe7ea2155549c278b23f4456bab88cd18beea157772d76079d5f322960e`

The package contains only the SIP Agent/Dispatcher business binary, release
manifest, module checksums, locked versions, hardened systemd units, safe
environment templates, endpoint template and installer. It contains no
credentials, certificates, broker URL, SIP credentials, phone-log key, audio,
provider payload or SaaS infrastructure.

## Owner-authorized ECS smoke

- Host: Debian 13 ECS `i-2zegf59q5yqbrp3igj3m`
- Fixed EIP: `123.56.71.98`
- Installation command: `install.sh --allow-nonproduction`
- Checks passed: package `sha256sum -c`, Debian/amd64 gate, binary install,
  systemd unit install/enable, `systemd-analyze verify`, and state permissions.
- State paths were verified as `rogee:rogee`, mode `0700`:
  `/var/lib/sip-go-agent/agent`, its spool, and
  `/var/lib/sip-go-agent/dispatcher`.
- Runtime services were deliberately **not started** because the package
  manifest records `source_dirty=true` and `production_approval=false`, and
  the host still requires approved PKI, broker ACL, and static Cell artifact.
- The temporary sudo grant used only to validate the installer was removed;
  the persistent sudo allowlist remained restricted to deployment/diagnostic
  commands.

## Native Asterisk validation

The pinned Asterisk `22.10.1` source and third-party cache were built directly
on the same Debian 13 host with one compiler job, staged without Docker, and
installed as `/usr/sbin/asterisk` plus the physical systemd unit
`asterisk.service`. The service was active and `provider-second` reported an
available contact before a bounded real-provider probe. That probe produced 13
SIP packets and 1 non-SIP UDP packet but a 0-byte fixed-name recording, so it
remains signaling/installation evidence rather than RTP/recording acceptance.
The native stage is also retained locally under
`deploys/packages/asterisk-22.10.1-native/`; the versioned
`deploys/cell/install-asterisk-native.sh` was executed on the same host with
`start=false`, verified the stage checksum, preserved `/etc/asterisk`, and
left `asterisk.service` active. Management-owned SIP/ARI/RTP configuration
remains outside the Go package.

## Remaining gates

The Asterisk source input is also staged locally and hash-verified; the
management-owned native Cell build/install and systemd unit remain a separate
release step. A clean reproducible release and external production approval are still
required. The management-owned physical Asterisk/ARI/SIP media, SaaS-provided
AI/MQ/OSS application receipt and verified handoff, two Cells, capacity/N+1 and
cutover remain separate acceptance gates; no MQ/OSS/AI service is packaged here.