azure/pull_request_template.md
The same checklist, worded for Azure DevOps, written whole by redline init when the repo has none, merged into an existing one otherwise.
What this is
The Azure DevOps equivalent pull request template — the same Launch readiness checklist, worded for Azure's exemption flow instead of GitHub's.
How to onboard it
- Installed as:
.azuredevops/pull_request_template.md - Installed by: redline init — written whole only when the repository has no template the host would serve; merged into an existing one otherwise.
How to use it
Tick every box honestly. Unlike GitHub, an unticked box here isn't independently gate-checked on Azure — the discipline is on the reviewer.
- redline init searches .azuredevops/, .vsts/, docs/, then the repository root (all four, matched case-insensitively) for an existing template, plus any branch-specific template under pull_request_template/branches/ — Azure serves those in preference to the default, so one added after onboarding is merged into as well.
- Same merge behaviour as GitHub: written whole with no template present, otherwise the gated sections are appended inside REDLINE:BEGIN/END markers and the rest of the file is kept untouched.
- Same gated Launch readiness section and the same seven checklist items as the GitHub template.
- Because Azure's entire gate is one step (redline verify --gate), there is no separate checklist job parsing this file the way GitHub's redline-gate.yml does — the checklist is process discipline for the team, not something the Azure pipeline itself enforces item by item.
Expected output
.azuredevops/pull_request_template.md. Unlike GitHub, nothing parses it: Azure's whole gate is one redline verify --gate step, so the checklist is process discipline for the reviewer rather than something the pipeline enforces item by item.
How to edit it
The real source: This template file, with the same marker-merge behaviour as the GitHub one.
- Check whether the CLI reads this file at allSeveral of these are reference shapes: the CLI generates the equivalent in code and never opens the checked-in copy. Editing one of those changes nothing about what redline init writes. The onboarding section above says which kind this is.
- Edit the real sourceFor a generated artifact that is cli/commands/init.ts; for a file installed verbatim it is the template itself.
- npm test && node scripts/validate.mjsThe install path is unit-tested against a fake host client, and validate.mjs pins the shapes the merge gate's required check name depends on.
The full file
# Summary
<!-- What and why, 2-3 sentences. Link the ticket. -->
Ticket:
## Change type
<!-- Tick the one that applies. This section is NOT gated — pick one and move on. -->
- [ ] Feature
- [ ] Bugfix
- [ ] Refactor (approved beforehand)
- [ ] Chore/config
<!-- REDLINE:BEGIN — generated by Redline. Do not edit inside this block. -->
## Launch readiness
<!--
GATED SECTION. `redline-gate` fails while any box here is unticked.
If an item genuinely does not apply, delete the line and say why in the Summary.
Do not delete the heading — the gate fails if the section is missing.
-->
- [ ] No secrets, keys, or customer data in code, logs, or fixtures
- [ ] Input validated at boundaries touched by this change
- [ ] Typecheck and lint pass with no new errors
- [ ] Tested on: <!-- iOS / Android / web / staging -->
- [ ] Error states handled (network failure, empty, loading)
- [ ] Rollback is safe (no destructive migration, no breaking contract change)
- [ ] No unrelated changes in the diff
## Architecture decision
<!-- If this PR makes a non-obvious technical choice, add an ADR and link it. Otherwise delete this section. -->
ADR: `docs/adr/NNNN-*.md`
## Redline exemption
<!--
Only fill this in if a process check above is failing and you are asking to merge anyway.
Delete the whole section otherwise. A label alone no longer exempts anything: the gate
reads THIS block, and an exemption with no reason and no end date is an opt-out, not an
exemption.
- reason: what is being accepted and why, in a sentence a reader in three months
can act on. "Needed for release" is not one.
- until: YYYY-MM-DD, at most 90 days out. Longer than that is a standards change,
not an exemption — raise it in the Redline source repo.
- scope: which checks it covers (checklist, adr). Omit to cover both.
This can never exempt dependency review or the secret scan. Those do not soft-fail.
-->
- reason:
- until:
- scope:
<!-- REDLINE:END -->
## Automated review
- [ ] Review comments addressed, or dismissed in-thread with a reason
<!--
Gate stuck on a process check you cannot satisfy? Add the `redline-exempt` label to
this pull request and leave a comment explaining why. That downgrades the checklist
and ADR checks to warnings. It does NOT bypass dependency review or the secret scan —
those never soft-fail.
-->