Clarify ATR beta status and hybrid mode in runbook

[dave2wave]

Updated release management instructions to reflect ATR's beta status and clarify hybrid mode.

Summary

• ATR is now Beta software and this playbook must be updated.
• A draft start to try to nudge a conversation

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other:

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:

RFC-AI-0004 compliance

• HITL — any new mutation is gated on explicit user confirmation
• Sandbox — no new unrestricted host access; network reach declared in the adapter
• Vendor neutrality — placeholders (<PROJECT>, <tracker>, <upstream>, <security-list>) used in all skill / tool prose (the check-placeholders prek hook is the mechanical gate)
• Conversational + correctable — agentic-override path documented if behaviour is adopter-tunable
• Write-access discipline — no autonomous outbound messages; drafts only, sent on confirmation
• Privacy LLM — private content does not reach a non-approved LLM; redactor invoked where needed

Linked issues

Notes for reviewers (optional)

[potiuk]

Thanks for flagging this @dave2wave — you were right that the playbook needed updating, and the nudge worked.

Picked up in #1181, which does the full sweep: the ATR runbook alone stated the status in four places, and manual-release-process.md, projects/magpie/release-management-config.md and the adopter template projects/_template/release-management-config.md each repeated it.

While doing that sweep, one thing seemed worth separating out. Several passages made our hybrid stance a consequence of ATR's maturity — "because ATR is still alpha, Magpie does not yet let it host or publish releases" — which reads as though the policy moves on its own when the status moves. It doesn't: whether ATR hosts and publishes our releases is a PMC decision. So #1181 corrects the status, states the policy as a governance decision, and notes that the ratification vote on dev@ is now the only remaining blocker. The policy itself is unchanged.

#1181 is deliberately held as a draft, because your PR raised a question larger than the wording. #1182 asks which alpha-era assumptions still hold under beta — client/API stability, which host to target, the hosting-trust argument, dual staging, and the [VOTE] template that we had to hand-assemble during 0.1.0. You and @sbp are cc'd there, and your input would be welcome; whatever comes back gets folded into #1181 before it lands.

Closing this one in favour of #1181. The prompt for the conversation is much appreciated.