Development

Current state

The repository currently contains architecture, documentation, a pitch deck, and a backlog. There is no installable toolkit, deployable cmdlet, released provider, or production-ready behavior.

Repository boundaries

Path	Responsibility
architecture/	Committed system design, contracts, decision records, and trust boundaries
src/	Reserved for the PowerShell module, Core, and extensions
tests/	Reserved for unit, contract, integration, live deployment, and teardown tests
docs-site/	Current Astro/Starlight documentation and Slidev pitch deck
.github/workflows/	Current documentation checks and future module, security, release, and deployment checks

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. When public cmdlets and schemas exist, breaking changes will 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.