[Tracking] PowerShellBuild v1.0.0 roadmap

Goal: ship PowerShellBuild 1.0.0 — the first version with a stable public-API contract per SemVer. Treats the 0.x line as initial development per SemVer §4; 1.0.0 defines the public API per SemVer §5.

Status: planning → execution
Current version: 0.8.2
Target version: 1.0.0
Prerelease cadence: one prerelease, 1.0.0-rc1, cut in #160 and soaked ≥ 7 days before 1.0.0 (revised 2026-08-27 when Phase 3 was deferred; the earlier previewN cadence is below under Locked-in decisions). It is load-bearing rather than ceremony: several breaks this cycle are install-time — RequiredModules now demands psake 5.0.4 and Pester 6.0.0, and PlatyPS was removed from it entirely — and none of them can be observed from a branch or from this repository's CI, which builds this module rather than a consumer's. Only a real gallery install exercises them.
Branching: PRs land directly on main (allowed under 0.x); 1.0.0 cuts when scope is complete

Why 1.0.0 and not 2.0.0: there has never been a stable 1.x. Jumping to 2.0.0 would imply a prior stable 1.x existed. SemVer says go to 1.0.0.

Destination

PowerShellBuild 1.0.0 published to PSGallery. This issue is the wayfinder map for
that route: it indexes every decision already made and points at the tickets holding the
detail. The map is complete when 1.0.0 ships — not when planning ends.

Working this map

Route steps are sub-issues of this issue (and of #105 for the PlatyPS chain), wired
with GitHub's native dependency edges, so the tracker itself shows what is takeable.

Frontier — open route tickets with zero open blockers and no assignee. These are
takeable right now, in any order, by anyone.
Claim before working — assign the ticket to yourself first, so parallel sessions
skip it. An open, unassigned route ticket is unclaimed.
Resolve — post the answer or outcome as a comment, close the issue, and add a line
to this map's decision index if it settled something.
Umbrellas are not takeable. #105 is a container for the PlatyPS chain. Neither are
folded issues — #99, #100, #101 close as part of their parent PR, and #147 rides along
with #144. Only children of this issue and of #105 are route tickets.

Read the frontier without a script by opening this issue: blocked children render with a
blocked marker, and the rest are the frontier.

Locked-in decisions

Decision	Choice
Version	1.0.0 (not 2.0.0)
Tracking	This issue + `v1.0.0` milestone + GitHub Project board
AIM deployment	Phase 0 (first PR)
Branching	PRs to `main` + `1.0.0-previewN` prereleases
Breaking changes	Hard cut + migration guide
Migration guide	`docs/migration-v0.8-to-v1.0.md`; per-PR entries; AI-assisted prompt at top
Auto-migration tool	None
Deprecation cycle	None (skip 0.9.0)
psake 5.x	In scope for 1.0.0
Minimum PS version	Windows PowerShell 5.1; PowerShell 7.4+ for PS 7 (decided 2026-07-21; PlatyPS 1.x validated on 5.1, Pester 6 floor drives the 7.4+)
Consumer Pester minimum	Keep ≥ 5.x (decided 2026-07-22; `RequiredModules` stays at 5.6.1 — `Test-PSBuildPester` supports Pester 5 and 6, verified by the #137 integration matrix)
Preview numbering	Decoupled from phase numbers (decided 2026-07-22). No preview is cut after Phase 1 — it shipped only two small changes (`Test-PSBuildPester` fixes #102 + the manifest floor #141), nothing risky to soak. The first preview is `preview1`, cut after Phase 2, and it carries the Phase 1 shipped changes along with it.
Migration guide scope	Breaking changes plus behavioral changes that can require action on upgrade (decided 2026-07-25). The guide previously said "breaking changes only", which excluded fixes like #143 that can turn a passing consumer build red. Preamble widened to match.
Destination	1.0.0 published to PSGallery (decided 2026-08-19). The route is done when the release ships, not when the planning does.
Route tracking	This issue is the map (decided 2026-08-19). Route steps are sub-issues wired with native dependency edges rather than checkboxes, so the frontier is visible in the tracker and claimable by parallel sessions.
psake 5.x	In scope, clean re-spike (decided 2026-08-19) — #155. The extras that sank #117 (task caching, LLM Pester output, external `PesterConfiguration` file, `Format-PSBuildResult`) are 1.1.0 features, not part of a dependency bump.
psake 5.x outcome	MIGRATE (#155, resolved 2026-08-19). Consumer-facing `psakeFile.ps1` needs zero changes under 5.0.4 — no task renames, no `$PSBPreference` change — so the abort criterion did not fire. All four breaking changes in psake's own v4→v5 guide were checked and none apply. Full suite 428/0 under 5.0.4, matching the 4.9.1 baseline. psake 5.x does differ behaviorally — `Invoke-psake` returns a `PsakeBuildResult` where v4 returned nothing, and `Set-BuildEnvironment` in a Pester `BeforeAll` fails the container — but neither is triggered by upgrading PowerShellBuild, so neither is documented here. Migration filed as #161.
BuildHelpers break escape	Found by the #155 spike, undocumented upstream (2026-08-19). `Set-BuildEnvironment` in a Pester `BeforeAll` leaks an escaping `break` from `Get-BuildVariable`'s switch blocks; psake 4.9.x absorbs it, psake 5.x does not, and Pester fails the whole container. Guarding the call on `$env:BHProjectName` fixes it. Affects any consumer whose Pester tests call `Set-BuildEnvironment`.
psake abort criterion	Fixed in advance, before the spike runs (decided 2026-08-19). Migrate if the consumer-facing `PowerShellBuild/psakeFile.ps1` needs only mechanical changes; cut psake 5.x to 1.1.0 and ship 1.0.0 on 4.9.0 if task names or the `$PSBPreference` contract must change. Set ahead of the findings so the call is made on evidence rather than sunk cost.
Phase 2 ordering	PlatyPS and psake chains run in parallel (decided 2026-08-19), gated by a single `preview1` cut. They touch disjoint files, so serializing them buys nothing and halves the frontier.
`FailBuildOnSeverityLevel`	#144 option 3, extended to cover #147 (decided 2026-08-19): fold `ParseError` into the `Error` threshold and add `'Any'` wired to the catch-all branch. The `ParseError` half is a behavior change and needs a migration-guide entry. Corrected 2026-08-20: this row originally also said the gate should fail on analyzer-level errors "so a crashed rule no longer reads as 'no findings'". That premise was wrong — #147 measured that a crashed rule does not cost findings (100 cold runs, never fewer than the known-good count). #163 therefore implements #147's preferred fix, a retry on `RULE_ERROR` that leaves failure semantics untouched, rather than a hard failure that would have cost some consumers a red build to help others. Implemented in #163.
#83 design	Grilling ticket first (#156, decided 2026-08-19). Precedence between a supplied `PesterConfiguration` and `$PSBPreference.Test.` is public API and must settle before implementation. The former pointer to "joshooaj's design in #80" was stale* — #80 is a different, closed request.
Phase 4 milestone discrepancy	Resolved 2026-08-19 — milestone stripped, then partly reversed 2026-08-28. #94 and #95 stay out (both closed). #98 and #103 are back in `v1.0.0` and block #160: they are the only two public functions with no coverage of their own, and the compile-mode test that appeared to cover `Build-PSBuildModule` asserts on file text only — it passes over a module that exports nothing (#201). Verifying code that already ships is a different question from adding features; see the note under Phase 4.
Changelog and guide scope	Internal changes get neither (decided 2026-08-20, applied to #162). `CHANGELOG.md` records user-facing changes only, and the migration guide covers changes triggered by upgrading PowerShellBuild. A build-toolchain pin in `requirements.psd1` is neither, even when the upgraded dependency behaves differently — that belongs in the dependency's own migration guide. Sharpens the existing "Migration guide scope" row: the test is who is affected by this upgrade, not how interesting the change is.
Scope additions	#124 and #138 pulled in (decided 2026-08-19). Both touch the public surface freezing at 1.0.0: #124 adds a PlatyPS setting to functions Phase 2 already rewrites, #138 is a correctness bug in a public function's output.
PlatyPS 1.x updatable help	Survives, and now ships (resolved 2026-08-24, delivered 2026-08-26 in #176). `New-HelpCabinetFile` maps onto the old call one-for-one — `CabinetFilesFolder` / `MarkdownModuleFile` / `OutputFolder` against `CabFilesFolder` / `LandingPagePath` / `OutputFolder`. The port was small; the three defects in #169 were the work, because the function had never succeeded in 0.8.x either. One contract change fell out of it: a cabinet now requires `HelpInfoUri` in the consumer's manifest, because without one `New-HelpCabinetFile` writes the cabinet and skips the `HelpInfo.xml` that `Update-Help` resolves it through — output that looks complete and cannot be used. The function refuses rather than half-producing.
PlatyPS module coexistence	Never both, at any point (corrected twice, settled 2026-08-24). Command names do not collide, but each module ships its own `YamlDotNet.dll` with a different assembly identity (`0.0.0.0` unsigned vs `15.0.0.0` signed) loaded via `NestedModules`, so importing the second fails in either order on PowerShell 7; only a separate process escapes it. Verified by adding both to a `requirements.psd1` and running the bootstrap, which fails. The first correction concluded "install both, never import both" and had #149 add the module to an install-only requirements file. That was still wrong: with an atomic migration (next row) there is no window in which both are needed, so the dependency swap belongs in the migration commit and nothing installs 1.x ahead of it. #149 keeps only its test half; #153 folded into the migration and is closed.
PlatyPS chain shape	Two pull requests to `main`, split at the Markdown/MAML seam (decided 2026-08-24). 2b/2c/2d cannot land as three independent merges: a build after #150 alone would need `New-MarkdownCommandHelp` and `New-ExternalHelp` in one psake session, which the loader forbids, and #150 also changes the on-disk markdown schema that an unmigrated `Build-PSBuildMAMLHelp` would be handed. Rejected: one combined pull request (800+ lines, past the size where review stays careful) and a stacked integration branch (intermediate sub-pull-requests would carry red CI, discarding the gating that made stacking attractive). `main` requires linear history, so every option squashes to one commit anyway — the choice was review ergonomics only. PR 1 migrates `Build-PSBuildMarkdown` and `Build-PSBuildMAMLHelp` together, the coupled pair, and carries the dependency swap. PR 2 migrates `Build-PSBuildUpdatableHelp` and fixes #169. Both green; `main` stays shippable throughout.
PlatyPS PR 1 intermediate	`Build-PSBuildUpdatableHelp` is knowingly left dangling between the two pull requests (decided 2026-08-24). After PR 1 it still calls `New-ExternalHelpCab`, from a module no longer installed. This costs nothing observable: the function has never worked (#169) and its tests are already skipped. Its psake PreCondition is deliberately left checking `Get-Module platyPS`, which is then false, so `GenerateUpdatableHelp` skips with a warning instead of crashing — better than today, where it throws on parameter binding. PR 1 must state this rather than leave it to be discovered.
Docs task coverage	Partly wrong as originally recorded — corrected 2026-08-26. This row claimed no test source exercised the three help functions. That was false. `tests/build.tests.ps1` builds `tests/TestModule` through `-FromModule PowerShellBuild`, whose `Build` task depends on `BuildHelp`, so `GenerateMarkdown` and `GenerateMAML` had been running end to end all along, and `Has MAML help XML` was pinning the output layout in two contexts. That existing coverage is what settled the layout contract the migration preserves — had it been noticed earlier, the flatten-versus-nest question would have answered itself. What was true: the functions had no coverage of their own, with specific options, and `GenerateUpdatableHelp` was genuinely unobserved because it is not in the default `Build` chain. #149 added the unit coverage; #152 added the task-level coverage.

Migration guide

Lives at docs/migration-v0.8-to-v1.0.md. Every breaking-change PR must add an entry
using the standard structure (What changed / Why / Detection / Migration / Notes). Enforced
through instructions/git-workflow.instructions.md (AIM) plus reviewer catch — not a PR
template checkbox, which Phase 1 explicitly skipped. The top-of-file section includes a
canonical AI prompt users can paste into their agent to migrate their build.ps1
automatically; #159 tests that prompt before release.

Phase 0 — Foundation

Deploy AIM to the repo (#122, merged 2026-05-18)
- Add AGENTS.md, aim.config.json, instructions/
- Migrate CLAUDE.md content → instructions/repository-specific.instructions.md
- Modules to include: agent-workflow, shorthand, git-workflow, testing, powershell, markdown, releases, github-cli, readme, contributing, update, repository-specific
- Fix stale version reference (CLAUDE.md says 0.7.3; actual is 0.8.0)

Phase 1 — Conventions & guardrails ✅ complete (2026-07-22)

Add PR template — skipped: PowerShellBuild inherits a PR template from the org-level psake/.github repo, which is sufficient for general PR structure. The migration-guide entry rule for breaking-change PRs is enforced through instructions/git-workflow.instructions.md (AIM) + reviewer catch, not a checkbox. Repo-level override would only add value if drive-by external contributors became likely during the cycle.
Initialize docs/migration-v0.8-to-v1.0.md skeleton (#123, merged 2026-07-03)
Create v1.0.0 milestone, link this issue
Create GitHub Project board (Status: Todo / In Progress / Done — kept GitHub defaults; tests don't trigger version bumps so milestone state is the only prioritization axis needed)
Investigate minimum PowerShell version for v1.0.0 — decided 2026-07-21: Windows PowerShell 5.1, or PowerShell 7.4+. Microsoft.PowerShell.PlatyPS 1.x validated end-to-end on Windows PowerShell 5.1 (net472 assembly, no manifest floor, functional test of the markdown→MAML pipeline); Pester 6 supports 5.1 and 7.4+ only, which sets the pwsh floor. Details: https://github.com/psake/PowerShellBuild/issues/120#issuecomment-5028978464
Audit PowerShellVersion in PowerShellBuild.psd1 and CI matrix — done via #141 (merged 2026-07-22): PowerShellVersion = '5.1' (was '3.0'); no CI change needed — the org ModuleCI.yml already runs Windows PowerShell 5.1 plus current pwsh on Linux/Windows/macOS. Migration-guide entry and changelog entry included in #141.
Refresh non-breaking dependency versions (psake and platyPS deferred to Phase 2, breaking):
- PSScriptAnalyzer 1.24.0 → 1.25.0 in requirements.psd1 (#129, merged 2026-07-03)
- Pin Pester build dependency to 5.8.0 in requirements.psd1 — was floating via MinimumVersion = '5.6.1', so CI installed whatever was newest at bootstrap (#129) — superseded: repo suite now pins Pester 6.0.0 (#132), with 5.9.0 installed side-by-side via requirements.pester-matrix.psd1 for the Test-PSBuildPester compatibility matrix (#137)
- Pester consumer-facing minimum in PowerShellBuild.psd1 RequiredModules — decided 2026-07-22: keep ≥ 5.x; stays at 5.6.1, no manifest change. Test-PSBuildPester supports Pester 5 and 6, and the #137 integration matrix verifies both majors; requiring 6.0 would force an upgrade on consumers for no functional gain.
- InvokeBuild 5.8.1 → 5.14.23 (#142, merged 2026-07-22)
- actions/checkout in publish.yaml v2 → v4 (#142, merged 2026-07-22)
- Add CompatiblePSEditions = @('Desktop','Core') to PowerShellBuild.psd1 (#141, merged 2026-07-22)
Confirm branch protection on main — done 2026-07-22 via the repo-level "Default" ruleset: require a pull request before merging (1 approval; merge/squash/rebase allowed); require status checks — CI / Run Pwsh Tests (ubuntu-latest / windows-latest / macOS-latest), CI / Run Tests (Windows PowerShell 5.1), CI / Run Linters — with branches up to date before merging; require linear history; require signed commits; restrict deletions; block force pushes. Bypass: Organization admin = always allow; Repository admin = pull requests only (admins cannot push directly to main; they may merge a PR without waiting for an approval — maintainers and outside contributors need 1 approval + green CI).

No preview cut after Phase 1. Phase 1 was conventions/guardrails: the only consumer-facing changes since v0.8.2 are the Test-PSBuildPester bug fixes (#102) and the manifest version floor (#141) — nothing risky enough to warrant a prerelease soak. These ride along in preview1 (cut after Phase 2). See the Preview numbering decision above.

Phase 2 — Breaking dependency upgrades

Both chains below are open in parallel — they touch disjoint files — and both gate the
same preview cut.

PlatyPS migration (#105)

Three pull requests total, not six. 2a lands first and alone; 2b and 2c land together; 2d
lands with #169. See the PlatyPS chain shape decision above. The tickets stay separate because
they are separate units of work, not separate merges.

#149 — 2a baseline the three Build-PSBuild*Help functions against current platyPS
0.14.2 behavior, so the migration has a red-before-green target. Test-only; carries no
dependency change. Open as #170, all CI legs green.
#150 + #151 — 2b/2c, one pull request. Migrate Build-PSBuildMarkdown and
Build-PSBuildMAMLHelp together (closes #99 and #100); they are coupled by the markdown
schema and cannot be split. Carries the dependency swap — requirements.psd1, the
RequiredModules manifest entry, the Markdown and MAML PreConditions, and the
migration-guide entry for the breaking RequiredModules change.
#152 — 2d, second pull request. Migrate Build-PSBuildUpdatableHelp (closes #101) and
fix #169, unskipping its tests and updating its PreCondition. The riskiest link:
Windows-only, makecab.exe-dependent, and non-functional today — a port plus three
fixes, not a port.
#154 — 2e ~~convert committed docs/ markdown to the 1.x schema~~ → document the
conversion for consumers. Re-scoped 2026-08-24: git ls-files docs returns only
docs/migration-v0.8-to-v1.0.md, so there is nothing here to convert. Now blocks #159
rather than the chain.
~~#153 — 2f remove the old platyPS 0.14.2 dependency~~ — closed 2026-08-24, folded
into 2b. Removing the old dependency is not a step after the migration; it is the
migration's dependency swap.

psake 5.x bump

#155 — spike: assess breakage under psake 5.0.4. Resolved 2026-08-19: MIGRATE.
The consumer-facing PowerShellBuild/psakeFile.ps1 needs zero changes, so the abort
criterion did not fire.
#161 — migration: bump the pin to 5.0.4 and carry the Set-BuildEnvironment test
guard. A single small PR, not a chain — and an internal one: no changelog or migration-guide
entry, since the manifest floor stays at psake 4.9.0. Open as #162, all CI legs green —
including Windows PowerShell 5.1, which settles the last open question about psake 5.x on
the v1.0.0 support floor. Awaiting review.

Gate

#157 — cut 1.0.0-preview1 — closed as superseded 2026-08-27. With Phase 3
deferred, the break surface was complete, so preview1 and rc1 would have soaked an
identical surface. The cycle cuts one prerelease: the rc1 in #160. The Phase 1 changes
(#102, #141) ride along in it.

Phase 3 — API improvements — deferred to 1.1.0 (2026-08-27)

PesterConfiguration support is additive: $PSBPreference.Test.Configuration defaults
to unset, so shipping it in 1.1.0 breaks nobody who upgrades to 1.0.0 first. The precedence
design does not get harder either — the surface it must interact with, $PSBPreference.Test.*,
has been frozen since 0.8.2 regardless of the next version number. What it was doing was
holding a finished break surface (PlatyPS 1.x, psake 5.0.4, Pester 6.0.0, the 5.1 floor)
unreleased behind a design conversation that had not started. 1.0.0 means stable and
supported, not feature complete. Milestone removed from both; see #83 for the full reasoning.

~~#156 — design: precedence contract for a consumer-supplied PesterConfiguration~~
— deferred to 1.1.0, still the right five questions
~~#83 — PesterConfiguration object support, built to that contract~~ — deferred to 1.1.0,
first in the queue after 1.0.0
#144 — settle the FailBuildOnSeverityLevel contract, with #147 (analyzer rule crashes
escaping the gate) folded in
#124 — scope PlatyPS to specific paths; waits on the function migrations so it is written
against the 1.x API
#138 — fix the coverage-percentage truncation in Test-PSBuildPester
Close #80 as superseded by #83 — already closed
#158 — cut 1.0.0-preview2 — closed as superseded 2026-08-27. Phase 3 is
empty, so there is nothing for a second prerelease to soak.

Phase 4 — Test infrastructure

In v1.0.0:

#97 — shared fixture module at tests/fixtures/PSBuildTestFixture/ (closed via #135, 2026-07-09)
#102 — Test-PSBuildPester integration tests (closed via #137, 2026-07-09)
#99, #100, #101 — folded into PR 2b, 2c, and 2d respectively, and reparented
under them. They are written against the new PlatyPS API so the tests are not written
twice, and they close with their parent PR rather than independently.
#98, #103 — restored to scope 2026-08-28, and they block #160. These are the
only two of twelve public functions with no coverage of their own.
Publish-PSBuildModule has no test references at all and is the function that pushes to
a package repository. Build-PSBuildModule appears covered — build.tests.ps1 has a
compile-mode context with eight assertions — but every one of them asserts on file text,
none imports the built module, and the fixture's source .psm1 is a one-line comment
that structurally cannot carry a dot-sourcing loader. So the test passes over the
failure in #201, where compiling produces a module exporting nothing.

Deferring a new feature costs users nothing they already have — that is why #83
moved to 1.1.0 on the same day. Skipping verification of code that already ships is
what makes "stable" unearned. Different arguments, opposite conclusions.

Related test-infra work that landed during the cycle: #128/#133 (fail the build on Pester
block/container failures, not just failed tests), #140 (code-coverage tracking in the
Pester task), #143 (severity gate actually fails the build; also closed #125).

Tracked but not blocking 1.0.0 — see "Out of scope" below.

Phase 5 — Release

#159 — the only open item on the critical path. Finalize
docs/migration-v0.8-to-v1.0.md, test the AI migration prompt against a real sample
consumer build.ps1 (it has never been exercised), write the CHANGELOG.md 1.0.0 entry.
Its gate was preview2; that is satisfied by scope rather than by a release, since Phase 3's
deferral means nothing further breaks anything. The guide is 747 lines across 12 sections —
a coherence pass, as anticipated.
#160 — bump ModuleVersion to 1.0.0, cut 1.0.0-rc1, soak ≥ 7 days, publish 1.0.0

Not yet specified

In scope, but not yet sharp enough to ticket. Graduates as the frontier advances.

The shape of #124's path scoping — whether it needs a new $PSBPreference.Docs.*
setting or the 1.x API makes it inferable is unknown until 2b–2d reveal the new surface.
Consumer guidance for the docs/ schema conversion. This repo commits no command
markdown, so 2e cannot learn the answer by doing it here (see #154 above). What a
consumer with a committed docs/ tree must do on upgrade still needs an answer, and it
is a migration-guide entry rather than a code change. #154 is the natural home for it.
Whether psake 4.x compatibility stays continuously tested. #162 bumps the toolchain to
psake 5.0.4 while the manifest still claims psake >= 4.9.0. Both majors were verified
locally (428/0 each), but CI now exercises only 5.0.4, so the claim is asserted rather than
tested. Options are a side-by-side matrix like requirements.pester-matrix.psd1, raising the
manifest floor to 5.x, or accepting the gap. Not sharp enough to ticket until #162 lands.
rc1 blocker triage. If the soak surfaces blockers, the response is a route decision.

Out of scope

Ruled beyond this destination. These do not graduate; they return only if the destination
is redrawn.

#136 — intermittent PSScriptAnalyzer crash in CI's Analyze task. Upstream defect
(PSScriptAnalyzer#1538/#1351, both deferred to 2.0), transient, and re-running succeeds.
CI hygiene, not consumer-facing.
#139 — publish the repository's coverage results. CI reporting; needs a change to the
psake org's shared workflow. No SemVer impact.
#145 — pin GitHub Actions to commit SHAs. Supply-chain hardening, orthogonal to the
release.
#17 — "additional Pester tests needed" umbrella. Open-ended; would never close.
~~#94~~, ~~#95~~ — test backfill for Clear-PSBuildOutputFolder and
Initialize-PSBuild. Both closed; #95 closed 2026-08-24 via #164, a first outside
contribution from @pttydou.
~~#98, #103~~ — moved back INTO scope 2026-08-28, see Phase 4.
The #117 extras — task caching via Inputs/Outputs, LLM-mode Pester output,
external PesterConfiguration file support, and a public Format-PSBuildResult. These
are 1.1.0 features that were bundled into a dependency bump; keeping them out is why the
psake spike is being re-run clean.

Definition of done

Every route ticket under this map is closed, or explicitly ruled out of scope above
The Phase 4 milestone discrepancy is resolved — done 2026-08-19, milestone
stripped from #94/#95/#98/#103; #98 and #103 restored 2026-08-28 on evidence that
the existing coverage cannot fail
Every public function has coverage of its own, and the compile-mode assertions actually
import the built module rather than reading its text
The migration guide is complete and its AI prompt has been tested against a sample
consumer build.ps1
~~1.0.0-rc1 has soaked ≥ 7 days with no blocker reports~~ — dropped 2026-09-04 by maintainer decision; replaced by #229, a local-repository install test that covers the install-time class this gate existed for. Reasoning in the comment of that date.
#229 passes in CI on both editions, and has been shown able to fail
1.0.0 is published to PSGallery

AI-assisted-development notes

Keep PRs small (≤ ~400 lines diff where feasible) so they fit in agent context
Each PR description should reference this tracking issue and the relevant phase
The AIM instructions/ files are the canonical guide for any agent working in this repo — agents must read agent-workflow.instructions.md first
Conventional commit prefixes (feat:, fix:, docs:, chore:, BREAKING CHANGE:) to keep history machine-parseable

[Tracking] PowerShellBuild v1.0.0 roadmap

Description