bleeding-edge

name	bleeding-edge
description	Biases technology choices toward the newest viable option while preserving maintainability, live verification, reversibility, and decided constraints. Use when selecting or upgrading a dependency, runtime, tool, language feature, or AI model.
license	Unlicense OR MIT

Bleeding edge

Prefer the newest viable technology inside the requested work. This is a bias, not permission for an unrelated upgrade sweep or novel architecture. software-engineering-excellence remains the governor; maintainability wins ties.

Stability ladder

Rung	Policy
Newest stable	Default, including newly released majors
RC, beta, canary	Only for a concrete need or low-risk reversible trial
Nightly	Only for a documented blocker it resolves

Adoption contract

For every choice:

• Verify version and release status from the registry or official release notes.
• Read relevant migration notes and check known blockers for the use case.
• Pin any pre-release or nightly exactly.
• Record the reason, tradeoff, rollback path, and fallback when climbing beyond stable.
• Run the project's real validation gate without weakening it.
• Prefer the newer option only when capability, security, performance, developer experience, or longevity outweighs instability and churn.

Existing decisions

Project AGENTS, stack skills, and recorded decisions remain authoritative. Advance within an already chosen tool; never silently replace it. If another tool now appears materially better, present the evidence and tradeoff for human decision.

When the choice remains uncertain, state the rung and unresolved risk instead of quietly choosing the most novel option.