Article templates and review workflow

Approved editors can use these templates in guides, troubleshooting, and community namespaces. Protected command, feature, lobby, and release pages need maintainer review. Start unfamiliar material in drafts:your_topic. Drafts are visible to approved editors and maintainers; they are not private to one contributor.

====== Descriptive article title ======

Explain the player's situation and who this guide applies to.

===== Steps =====
  - Give the first action.
  - Explain the expected response.
  - Link to the relevant command or concept.

===== If it does not work =====
Explain restrictions and link to troubleshooting.

===== Verification =====
Checked against: vX.Y.Z on YYYY-MM-DD.
State whether this is current, historical, or an upcoming proposal.

Describe the visible symptom first. Separate a command typo, missing permission, a vote without enough agreement, and a server problem. Include a safe example and the expected response. Do not paste raw player logs or private reports.

1. Verify the supported command and its room restrictions against current behavior.
2. Distinguish the current map, visible queue, and future selections.
3. Identify whether an action is a vote, a preference, or an informational lookup.
4. Mark experimental models and configurable policy accurately.
5. Label staged features as upcoming until deployment is confirmed.
6. Check linked pages and aliases; preview on a narrow screen.
7. Save with an edit summary explaining what changed and why.

There is no automatic approval plugin. Ask a maintainer to review a draft through the existing community channel. Maintainers should preserve revision history and contributor attribution when publishing, and use the actual latest article rather than restoring an old seed copy.

Link every published page from a relevant guide or index. Wiki accounts do not grant bot moderator access. See contribution rules, editing instructions, and formatting syntax.

Begin with a one-paragraph definition, then an availability/status/reference table. Use the same headings as the Jack command page:

• Usage and examples — valid input, including canonical aliases.
• Limitations and timing — eligibility, room mode, votes, and when changes take effect.
• Related articles — concepts, troubleshooting, and worked guides.

Begin with a short summary and the same reference table. Keep the detailed explanatory sections, then add a worked example, limitations, and related articles. See Mania styles or queues.

The behavior reference records a dated source review, not a live-service guarantee. If a contributor changes behavior details without verifying them, mark the status as “Needs review” rather than retaining a misleading verification date. Keep current, upcoming, historical, and experimental claims distinct. A recent edit timestamp alone does not prove current behavior.

Link the original pattern diagrams where useful. They use time downward, numbered columns, purple taps, and teal holds, with explanatory prose and image descriptions. Do not present an illustrative passage as a classifier acceptance test or a screenshot of an actual map.