ATR is in beta — which alpha-era assumptions in our release docs still hold?

#1181 (kept as a **draft** deliberately, pending this discussion) updates our release docs to record that ATR has moved from alpha to beta — thanks @dave2wave for flagging it in #1157.

That change is deliberately narrow: it corrects the **status** and decouples our hybrid policy from it, but does **not** change the policy. `release_dist_backend = svnpubsub` and `release_vote_backend = atr` stand as they are.

What it surfaced is that our docs carry a number of assumptions written when ATR was alpha, and we don't know which of them beta invalidates. Rather than guess, we'd like to ask.

**Context:** Magpie currently runs a hybrid — SVN hosts and promotes the artefacts, ATR runs the policy checks and administers the `[VOTE]`. Full adoption (ATR also hosting/publishing via Finish) had two stated preconditions: a PMC ratification vote on `dev@`, and ATR moving beyond alpha. The second is now met.

## Questions

- [ ] 1. **What does "beta" commit to?** Is there a published definition of the alpha → beta → GA criteria for ASF Tooling, so PMCs can reason about it consistently rather than each interpreting the label?
- [ ] 2. **Client and API stability.** Our docs say the `atr` client and API schema are "not yet stable — do not pin unattended scripts to them", and tell RMs to treat documented verbs as the *shape* of an operation and confirm with `atr --help`. Does beta change that? Can automation now pin to a client version or API schema?
- [ ] 3. **Which host?** We point at `https://release-test.apache.org/` and note production "will be" `release.apache.org`. Is the test deployment still the right target under beta, and is there a timeline or migration path for the production host?
- [ ] 4. **Hosting and publishing trust.** The alpha-era reasoning was that we don't trust ATR to *host or publish* the release, so that stays on ratified SVN. What's the durability, backup and recovery story for artefacts hosted by ATR, and does beta change what a PMC should conclude here?
- [ ] 5. **Dual staging.** Under our hybrid the artefacts live in **two** places during a vote — SVN `dist/dev` (what the `[VOTE]` links) and the ATR candidate (what runs the checks). Is dual staging still required under beta, or can ATR be the single staging location while SVN remains the publish target?
- [ ] 6. **The `[VOTE]` template.** During `0.1.0` rc1/rc2 we found ATR's generated `[VOTE]` template incomplete for the hybrid case, so the body was assembled by hand. Has the hybrid case been addressed, or is a hand-assembled body still expected?
- [ ] 7. **Archive promotion.** Does ATR handle promotion to `archive.apache.org`, or does that remain an SVN concern under any ATR mode?
- [ ] 8. **Advice for adopters.** Magpie ships a template other projects adopt, which currently recommends the hybrid stance. Is that still the right default recommendation for a project starting today, or would you steer new projects differently now?

---

@dave2wave @sbp — we'd value your read on any of these, particularly 1, 2 and 4, which are the ones our ratification discussion will turn on. No urgency; we're not blocked, just trying to avoid carrying stale assumptions into the PMC vote.

The doc update in #1181 stays in draft until this thread settles, so any answers here can be folded into it before it lands.

Start with the draft documentation update in #1181 and the current release docs it changes. Research ASF Tooling's published alpha, beta, and GA criteria, then resolve the eight ATR policy questions with the project and record the agreed guidance in the release docs so the draft can proceed to the PMC vote.

Written by the indexing model from the issue text.