Development

Current state

The repository contains the first installable offline module slice. It has no Azure authentication, live provider, deployment engine, or production-ready behavior.

Repository boundaries

Path	Responsibility
architecture/	Committed system design, contracts, decision records, and trust boundaries
src/	Current offline PowerShell module, schemas, provider and capability plan contributors, catalogs, templates, and future extension boundaries
tests/	Current Pester unit and contract checks plus reserved live deployment and teardown suites
docs-site/	Current Astro/Starlight documentation and Slidev pitch deck
.github/workflows/	Current documentation, Pages, and cross-platform module checks; security, release, and deployment lanes remain staged work

Contribution sequence

1. Link the change to a feature request and GitHub issue.
2. Record a decision when the change affects public contracts, security, cost, state, or provider boundaries.
3. Implement the smallest Core or extension contract first.
4. Add focused tests and failure-path evidence.
5. Update documentation with an honest status label.
6. Run security, dependency, vulnerability, build, and link checks.
7. Use a reviewed pull request; protect live Azure environments.

Compatibility

The new module is named AzureDataLabToolkit. No legacy aliases from Azure SQLVM Toolkit are planned. Public cmdlets and versioned schemas now exist, so breaking changes require explicit versioning and migration guidance.

Azure SQLVM Toolkit is an unfinished predecessor and a source of lessons. Code or documentation in that repository is not a current Azure Data Lab Toolkit feature until it is deliberately implemented, tested, and released here.

First proof point

The first implementation target is SQL Server on Azure VM. Its acceptance path must start with schema-validated YAML, then prove offline -Plan, Azure-aware non-mutating -WhatIf, cost review, guarded PowerShell deployment, probes, evidence reports, and confirmed teardown with cleanup proof.

-Plan explains configuration resolution and derived decisions without Azure access. -WhatIf compares the resolved plan with live resources after sign-in. Their outputs must be testable contracts, not console-only narration.

Architecture governance

The repository architecture document records Committed design, not shipped behavior. Architecture decision records should capture:

• context and decision;
• alternatives considered;
• security, identity, network, cost, license, and data implications;
• compatibility and migration consequences;
• test and rollback strategy.

Use this source order during development: releases for Available behavior, checked-in implementation and tests for Current behavior, accepted decisions for Committed design, and feature requests or issues for Backlog, Exploratory, and Deferred work.

See Testing Strategy and Roadmap.