missions/_docs/tasks/done/AZ-549a_missions_rename_b10_pipeline.md

[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 (umbrella; suite slice = AZ-549b) Epic: 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.