# [Missions rename B10 — missions slice] Finalize Woodpecker pipeline + missions-internal docs for `azaion/missions:*-arm`

> **Local-file split**: this is the missions-repo slice of B10. The suite-repo slice (deploy compose image-ref flips) is `azaion-suite/_docs/tasks/todo/AZ-549b_missions_rename_b10_suite_compose.md`. Both file specs reference the single umbrella Jira ticket **AZ-549**; the operator may convert AZ-549 to a parent Story with two Jira sub-tasks if independent transitions are needed, otherwise both slices close as one ticket once both files are `done/`.

**Task**: AZ-549a_missions_rename_b10_pipeline
**Name**: Finalize `${REGISTRY_HOST}/azaion/missions:<tag>` publication from this repo; clean up missions-internal docs that still describe the legacy `azaion/flights` image as the current state
**Description**: As of HEAD, `.woodpecker/build-arm.yml` already pushes `${REGISTRY_HOST}/azaion/missions:$TAG`. What remains in this repo is (a) verify one successful publish happened on `dev` so the suite-side slice (`AZ-549b`) can flip its compose image refs against a real image, and (b) clean up the forward-looking "today's pipeline pushes `azaion/flights`" NOTE stubs in `_docs/02_document/**` that are now stale.
**Complexity**: 1 point
**Dependencies**: AZ-544 (B5) — namespace + csproj rename done (assembly that the image wraps is `Azaion.Missions.dll`)
**Component**: refactor — `02-baseline-cleanup` / missions repo internal docs + CI pipeline verification
**Tracker**: [AZ-549](https://denyspopov.atlassian.net/browse/AZ-549) (umbrella; suite slice = AZ-549b)
**Epic**: [AZ-539](https://denyspopov.atlassian.net/browse/AZ-539)

## Problem

The `.woodpecker/build-arm.yml` in this repo was updated to push `${REGISTRY_HOST}/azaion/missions:$TAG` (verified at HEAD). However:

1. There is no recorded evidence in `_docs/` that a successful push of `azaion/missions:dev-arm` to the registry has actually occurred — the suite-side compose flip (AZ-549b) cannot land until that image exists in the registry.
2. Several `_docs/02_document/**` files contain "forward-looking" NOTE blocks that still describe `azaion/flights:*-arm` as the *current* state of this repo. With the pipeline already updated, those notes are now misleading — they describe a state that no longer exists.

Files with stale "forward-looking" notes (live `rg` hits at HEAD):

- `_docs/02_document/glossary.md:125` — Pre/Post column in the rename table
- `_docs/02_document/deployment/environment_strategy.md:3` — note block
- `_docs/02_document/deployment/containerization.md:3` — note block
- `_docs/02_document/deployment/ci_cd_pipeline.md:3` — note block
- `_docs/02_document/components/07_host/description.md:7` — note block
- `_docs/02_document/04_verification_log.md:23` — verification row (status flip)
- `_docs/00_problem/restrictions.md:48` — E6 row (status flip)
- `_docs/02_document/architecture.md:113` — already says "post-B10" (cross-check)

## Outcome

- A successful Woodpecker build of this repo's `dev` branch publishes `${REGISTRY_HOST}/azaion/missions:dev-arm` to the registry. The build log link or pipeline run ID is recorded in `_docs/02_document/04_verification_log.md`.
- All `_docs/02_document/**` "forward-looking" NOTE blocks listed above are rewritten to describe the new state as the *current* state (drop "today's pipeline pushes `azaion/flights`" wording).
- `_docs/02_document/04_verification_log.md` AZ-549 (B10) row flips from pending → done with the build-log reference.
- `_docs/00_problem/restrictions.md` E6 row reflects the post-B10 reality (drop the "post-B10" parenthetical that implied "not yet").
- `rg -F 'azaion/flights' missions/` returns ZERO hits, EXCEPT in `done/` task specs that historically reference the rename (changelog hits are acceptable).

## Scope

### Included

- One `git push origin dev` (or a manual Woodpecker re-run of the latest `dev` commit) to confirm the pipeline produces `azaion/missions:dev-arm` end-to-end.
- Editing the ~7 internal docs listed in Problem to flip their "forward-looking" wording to "current state" wording.
- Verification-log row flip for AZ-549.

### Out of scope (explicit)

- The suite-repo compose flip (`_infra/deploy/{jetson,webserver}/docker-compose.yml`) — that's `AZ-549b` in the suite workspace.
- Suite `_infra/ci/README.md:162` example string — also in AZ-549b.
- Deleting the legacy `${REGISTRY_HOST}/azaion/flights:*` images from the registry — separate housekeeping ticket, post-B11 stage-green.
- Anything else in the AZ-539 Epic (B6/B11 service-name rename, B12 default-vehicle rule, etc.).

## Acceptance criteria

- A Woodpecker pipeline run on `dev` (or `manual`) of this repo produces `${REGISTRY_HOST}/azaion/missions:dev-arm` in the registry. The run ID is captured in `04_verification_log.md`.
- All listed `_docs/02_document/**` NOTE-block files no longer describe the legacy image name as the current state.
- `rg -F 'azaion/flights' missions/ | grep -v done/` returns ZERO hits in active config.
- `04_verification_log.md` AZ-549 row reads as completed (not pending).

## Risks & Mitigation

**Risk 1: The `dev` push for verification accidentally triggers Watchtower on a fielded device**
- *Risk*: A push to `dev` builds + publishes the renamed image. If any production Jetson has Watchtower configured to auto-pull `${REGISTRY_HOST}/azaion/missions:dev-arm`, it would start the renamed service before B11 cutover.
- *Mitigation*: Today no deploy compose references `azaion/missions:*` yet (AZ-549b not done; that's the whole point of the sequencing). Watchtower can't pull what compose doesn't reference. Verification publish is safe.

**Risk 2: Forward-looking notes contain context that is useful to keep**
- *Risk*: The "forward-looking NOTE" blocks contain history (which child ticket renamed what) that a reader might want.
- *Mitigation*: Reword to past-tense ("Renamed under B10 [AZ-549]") rather than deleting outright. Preserve the audit trail in a single line per note.

## Notes for the implementer

- The pipeline change itself appears to have landed during B5 work (AZ-544) — bumping the `-t` tag is a one-line edit and was bundled with the csproj/namespace rename PR. Double-check the git log on `.woodpecker/build-arm.yml` to confirm the chain of changes before flipping verification-log statuses.
- Today the spec assumes the dev-arm image is the verification target. If your Woodpecker is configured to build only on push and you don't have a fresh `dev` push to test against, a "manual" trigger from the Woodpecker UI on the latest commit is acceptable.