# Finalization Runbook

Status as of 2026-07-26 18:00 UTC. Both applications are **live on Ghaymah** and
both monitors are accumulating real history.

| | URL |
|---|---|
| Q1 API | https://ghaymah-api-615e99f13665.hosted.ghaymah.systems |
| Q1 health | https://ghaymah-api-615e99f13665.hosted.ghaymah.systems/health |
| Q5 dashboard | https://mithal-monitor-292f00f076b1.hosted.ghaymah.systems |
| Repository | https://github.com/yassinelagamy/GHyamah-Test |

---

## Verified working

**Live deployments** (checked 17:23 UTC):

- Q1 `/health` → 200, `uptime_s: 1950`; `/` and `/metrics` valid; `requests_total: 118`
- Q5 `/index.html` → 200; `/data/metrics.json` → 31 records, exactly one per minute,
  no gaps, `ssl_days_left: 50`

**Q1 monitor dashboard** (18:02 UTC): 135 checks, 100.0% uptime, avg 900 ms,
`requests_total: 264` — all against the live deployment.

**Images**: both build clean and pass their `HEALTHCHECK`s; pushed to Docker Hub
under `agamy74`.

**CLI facts** established by direct inspection of binary `0.0.24`:

- `gy version` (not `gy --version`); `gy resource app` (not `gy resource application`)
- `gy auth login` accepts `--email` / `--password`; **no API-token flag exists**
- `gy resource app update <APP_ID>` accepts JSON or dot notation via `--set`, but
  the field that sets an external image URL is undocumented

---

## Remaining work

### 1. Add the Docker Hub token — only you can do this

The first workflow run failed after 13 s at the Docker Hub login step:
`DOCKERHUB_USERNAME` is configured, `DOCKERHUB_TOKEN` is not.

Add it at https://github.com/yassinelagamy/GHyamah-Test/settings/secrets/actions
→ *New repository secret* → name exactly `DOCKERHUB_TOKEN`, value = a Docker Hub
access token (hub.docker.com → avatar → Account settings → Personal access tokens
→ Generate, **Read & Write**).

Do this **before** the next push, so the run goes green instead of failing again.

### 2. Run the pipeline and capture the approval gate

The staging deploy step now carries `continue-on-error: true`, so the promotion
path stays intact: `build-push` → `deploy-staging` (adapter exits 78, step marked
unsuccessful, job continues) → `deploy-production` **pauses for a required
reviewer**. That pause is the Q3 evidence.

Actions tab → "Build and deploy" → Run workflow → wait for the **Review
deployments** prompt → screenshot it → approve.

The production step will then also exit 78 and the run finishes red. That is
deliberate and defensible: the image was built and pushed, and nothing claims a
deployment that did not occur. `scripts/ghaymah_deploy.sh` writes the exact image
handoff to the job summary.

### 3. Resolve the five remaining VERIFY markers

Public documentation does not contain these answers — I checked `/docs`, `/cli`,
`/products` and `/changelog`. They require the **authenticated** dashboard.

| File | What to look up | Where |
|---|---|---|
| `q2-postmortem/POSTMORTEM.md:133` | per-container memory/CPU metrics, restart counts, alert rules, notification channels | the deployed app's detail page |
| `q3-cicd/CICD.md:116` | is there API-token auth? what field does `gy resource app update` accept for an external image? | account settings / support |
| `q3-cicd/CICD.md:130` | same as above | — |
| `q4-scalability/SCALABILITY.md:108` | Block Storage snapshots: retention, encryption, restore | **Volumes** tab |
| `q4-scalability/SCALABILITY.md:112` | volume resize, classes, IOPS/throughput, attachment limits, access modes, zone binding | **Volumes** tab |

**Rule:** if the platform confirms it, state it and delete the marker. If the
platform does not expose it, rewrite the sentence to describe the general
requirement and note that platform-specific limits were not documented at the time
of writing — then delete the marker. No `VERIFY` string may survive in the
submitted repository.

The **Integrations** tab is also worth a look: if Ghaymah offers a GitHub
integration that deploys on push, that is a legitimate CI/CD answer for Q3 even
without CLI automation.

### 4. Screenshots

Save under `docs/screenshots/`:

- `q1-service-running.png` — the Ghaymah app detail page for `ghaymah-api`
- `q1-health-response.png` — the live `/health` JSON
- `q1-monitor-dashboard.png` — the Q1 dashboard with its populated latency chart
- `q3-approval-gate.png` — the Review deployments prompt from step 2
- `q5-live-dashboard.png` — the live Q5 dashboard once it has several hours of history
- `ghaymah-monitoring.png` — optional, supports the Q2 detection section
- `ghaymah-volumes.png` — optional, supports the Q4 storage section

Then link them from the root README.

### 5. Housekeeping

- Decide whether `PLAN.md`, `PROMPTS.md` and `CHECKLIST.md` ship. They document the
  internal agent workflow; graders do not need them.
- Repository variables point at `ghaymah-api-staging` and `ghaymah-api-production`,
  but the deployed application is named `ghaymah-api`. Either create those two
  applications or note in `CICD.md` that they are illustrative targets.
- Let both monitors run as long as possible before submitting. Q5's 24 h uptime
  tile only becomes meaningful after a full day.

---

## Final gate

Must print nothing:

```powershell
Select-String -Path (Get-ChildItem -Recurse -Include *.md,*.yml,*.sh -File | Where-Object FullName -notmatch '\\\.git\\') -Pattern 'VERIFY|MY_DOCKERHUB_USER|the public URL Ghaymah assigns'
```

Then verify one last time that both live URLs respond, commit, and push.