Introduce Cmdlet Maturity Model for FabricTools

[NowinskiK]

Background

FabricTools currently contains a large and growing number of cmdlets (~300), developed over time by multiple contributors. These cmdlets vary significantly in terms of quality, testing coverage, stability, and production readiness.

At the moment, there is no explicit way to communicate:

• how mature a given cmdlet is,
• what guarantees (if any) it provides,
• or what is required to improve its quality level.

This makes it harder for:

• users to know which cmdlets are safe to use in production,
• contributors to understand expectations,
• maintainers to prioritize improvements.

---

Proposal

Introduce a formal Cmdlet Maturity Model that categorizes each cmdlet into a clearly defined maturity level, based on objective and verifiable criteria.

The proposed maturity levels are:

Level	Name
0	Experimental
1	Prototype
2	Standardized
3	Unit Tested
4	Integration Tested
5	Production Ready

Each level defines specific characteristics such as:

• adherence to PowerShell and FabricTools coding standards,
• presence and quality of comment-based help,
• parameter validation and error handling,
• unit and integration test coverage,
• CI enforcement,
• stability and backward compatibility guarantees.

---

Goals

• Provide clear expectations for cmdlet quality and stability
• Make cmdlet maturity transparent to users
• Give contributors a clear path for improving cmdlets
• Improve overall consistency and maintainability of the module
• Enable future CI checks and quality gates

---

Scope (Initial)

• Define and document the maturity model in the repository
• Agree on objective criteria for each maturity level
• Decide how maturity is represented (e.g. metadata, comments, docs)
• Mark existing cmdlets with an initial maturity level (best-effort)

---

Out of Scope (for this issue)

• Refactoring all existing cmdlets to higher maturity levels
• Enforcing maturity levels via CI (can be a follow-up issue)
• Removing or deprecating cmdlets

---

Acceptance Criteria

• Maturity levels and their characteristics are documented in the repo
• A single source of truth exists (e.g. docs/maturity-model.md)
• Contributors understand how to move a cmdlet from one level to another
• The model is agreed upon by maintainers

---

Follow-up Ideas (Optional)

• CI validation of claimed maturity level
• Filters or documentation views by maturity level
• Contributor checklist per maturity level
• “Production Ready” quality badge for cmdlets