# Task Plan

## Checklist

- [x] Inspect the published managed-portal installer and release manifest under `root@10.8.0.1:/var/www/html/ai_deploy`.
- [x] Confirm the registry tags currently published for `managed-portal`, `managed-portal-web`, `people-flow-project`, and `store-dwell-alert`.
- [x] Prepare `10.8.0.14` for an installer-aligned rollout of the four-service managed-portal stack.
- [x] Recreate the four target containers on `10.8.0.14` using the published release version and corresponding Compose layout.
- [x] Verify the running stack on `10.8.0.14` uses the published registry images and the installer-managed Compose project.

## Scope And Risks

- Scope: use the published managed-portal release artifacts on `10.8.0.1` as the source of truth for image names, tags, and Compose topology.
- Scope: update the four-service managed-portal group on `10.8.0.14`: `managed-portal`, `managed-portal-web`, `people-flow-project`, and `store-dwell-alert`.
- Scope: keep unrelated stacks, especially the `iot-main` video-recognition project, untouched.
- Risk: the current four containers on `10.8.0.14` are not managed by one Compose project, so installer-based recreation will conflict on fixed container names unless the old containers are replaced cleanly.
- Risk: the published installer seeds config, data, outputs, and weights under `/opt/managed-portal-releases`; switching to it changes the runtime paths from the current ad hoc directories.
- Risk: service recreation causes a brief interruption for the portal and both child-service APIs.

## Validation Intent

- Read the published installer and `release-manifest.env` to confirm the exact release version and image references.
- Verify the registry exposes the four target tags before rollout.
- Use the installer-aligned Compose files and environment from the published bundle, not a hand-built local variant.
- Confirm the final containers are recreated from the published registry images and are running under the installer-managed release directory.

## Review

- Status: complete.
- Result:
  - Confirmed the published managed-portal installer source of truth is `root@10.8.0.1:/var/www/html/ai_deploy/install-managed-portal-20260519-f3f40b5-11.sh`.
  - Confirmed the published registry images in `release-manifest.env` are:
    - `ota.zhengxinshipin.com:5443/managed-portal:20260519-f3f40b5-11`
    - `ota.zhengxinshipin.com:5443/managed-portal-web:20260519-f3f40b5-11`
    - `ota.zhengxinshipin.com:5443/people-flow-project:20260519-f3f40b5-11`
    - `ota.zhengxinshipin.com:5443/store-dwell-alert:20260519-f3f40b5-11`
  - Confirmed all four image tags exist in the registry on `10.8.0.14`.
  - Extracted the published release bundle to `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11`.
  - Generated `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/managed-portal.runtime.env` from the published release, while keeping the host-specific data and output directories on `10.8.0.14`.
  - Replaced the ad hoc `managed-portal`, `managed-portal-web`, `people-flow-project`, and `store-dwell-alert` containers with the installer-managed Compose project under `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/docker-compose.ota-release.yml`.
  - Migrated `store-dwell-alert` to a schema-compatible config under `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/managed/store_dwell_alert/config/local.yaml` while preserving the current `192.168.0.5` RTSP source.
  - Kept the current people-flow config/output/weights directories, but removed `gpus: all` from the release Compose file because the host currently fails `nvidia-container-cli` startup with an NVML driver/library mismatch. The new image falls back to CPU at runtime and still reports healthy.
- Verification:
  - Published release manifest from `10.8.0.1` resolves to the four `20260519-f3f40b5-11` image tags above.
  - Registry presence checks from `10.8.0.14` succeeded for all four image tags via `docker manifest inspect`.
  - `sudo docker compose --env-file /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/managed-portal.runtime.env -f /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/docker-compose.ota-release.yml ps` showed:
    - `managed-portal` -> `ota.zhengxinshipin.com:5443/managed-portal:20260519-f3f40b5-11`, `Up`
    - `managed-portal-web` -> `ota.zhengxinshipin.com:5443/managed-portal-web:20260519-f3f40b5-11`, `Up`
    - `people-flow-project` -> `ota.zhengxinshipin.com:5443/people-flow-project:20260519-f3f40b5-11`, `Up (healthy)`
    - `store-dwell-alert` -> `ota.zhengxinshipin.com:5443/store-dwell-alert:20260519-f3f40b5-11`, `Up (healthy)`
  - `sudo docker inspect` confirmed the four containers use the published registry image references; `people-flow-project` and `store-dwell-alert` report healthy.
  - `curl -fsS http://127.0.0.1:13000` succeeded.
  - `curl -fsS http://127.0.0.1:13000/api/managed-services` returned both managed services with `status: "running"`.
  - `curl -fsS http://127.0.0.1:13000/api/managed-services/store_dwell_alert` returned the `192.168.0.5` RTSP source and `status: "running"`.
  - `curl -fsS http://127.0.0.1:13000/api/managed-services/people_flow_project` returned the `192.168.0.4` RTSP source and `status: "running"`.