# Synology Snapshot Admin Final Execution One-Pager

Use this sheet on the NAS during the live verification run.

## Goal

Confirm that `snapshot_admin_server_v1.py` runs on Synology with loopback binding, DSM reverse proxy exposure, and Basic Auth protection.

## Required values

- Project root: `/volume1/projects/data_feed`
- Launcher: `/volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh`
- Local URL: `http://127.0.0.1:8787/api/state`
- Public URL: `https://admin.example.com/api/state`
- Public UI URL: `https://admin.example.com/`
- Public tables URL: `https://admin.example.com/tables`

## Execution order

1. Start the service.
   - `bash /volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh start`
2. Confirm the healthcheck.
   - `bash /volume1/projects/data_feed/tools/run_snapshot_admin_synology.sh healthcheck`
   - Expected: `healthcheck ok`
3. Confirm local loopback.
   - `curl -i http://127.0.0.1:8787/api/state`
   - Expected: `200 OK`
   - Expected JSON field: `version.app = snapshot-admin-web-v7`
4. Confirm unauthenticated external access.
   - `curl -i https://admin.example.com/api/state`
   - Expected: `401 Unauthorized`
   - Expected header: `WWW-Authenticate: Basic`
5. Confirm authenticated external access.
   - `curl -u 'snapshot-admin:<password>' https://admin.example.com/api/state`
   - Expected: `200 OK`
   - Expected same `version.app` as local loopback
6. Confirm tables page.
   - `curl -i https://admin.example.com/tables`
   - Expected: `200 OK`
   - Expected: Tabler grid HTML
7. Confirm browser render.
   - Open `https://admin.example.com/`
   - Open `https://admin.example.com/tables`
   - Expected: Basic Auth prompt, then render
8. Confirm persistence.
   - Restart the task or NAS
   - Re-run steps 2-7
   - Expected: identical response pattern after restart

## Queue check

If the deployment workflow stays queued for more than a few minutes:

1. Confirm the runner is registered with the host label.
   - `RUNNER_LABEL=snapshot-admin-host`
   - Re-register with `bash tools/re_register_act_runner_synology.sh` after setting the registration token.
2. Confirm the runner daemon is running.
   - `bash tools/start_act_runner_synology.sh`
3. Confirm the queue target is the host runner label.
   - Deploy workflow uses `runs-on: [self-hosted, snapshot-admin-host]`
4. If another job is occupying the runner, wait for it to finish or cancel the stale workflow from Gitea.
5. Re-dispatch `snapshot_admin_deploy.yml` after the runner is idle.

## Pass criteria

- Loopback `200` confirmed.
- External unauthenticated `401` confirmed.
- External authenticated `200` confirmed.
- `/` and `/tables` browser render confirmed.
- Restart persistence confirmed.
- DSM reverse proxy and firewall screenshots archived.

## Workflow success evidence

If you need the deploy-job proof from the NAS runner before the full external closeout:

- `healthcheck` retried after startup and passed on the NAS runner.
- `snapshot-admin-web-v6` was returned by the deploy verification step.
- The workflow finished with `Job succeeded`.

This proves the deploy job can launch, wait for readiness, and validate locally on Synology.
It does not replace the external reverse-proxy/browser closeout evidence above.

## Do not close WBS-7.9 unless

- The `401`/`200` curl pair is saved.
- Both browser screenshots are saved.
- The DSM reverse proxy rule screenshot is saved.
- The completion wording in `docs/SYNOLOGY_SNAPSHOT_ADMIN_DEPLOYMENT_CHECKLIST.md` is used only after evidence is archived.