[1.0.0-alpha1] Upgrade to psake 5.0.0 with task caching and LLM output

[HeyItsGilbert]

Summary

• Upgrade to psake 5.0.0 with declarative task syntax, content-addressed caching, and structured PsakeBuildResult output
• LLM-optimized Pester output — new OutputMode setting (Detailed/Minimal/LLM) where LLM mode emits structured JSON with only failure details, suppressing verbose console noise
• External PesterConfiguration file support — $PSBPreference.Test.PesterConfigurationPath loads a .psd1 as the base config with explicit overrides layered on top
• Task caching — StageFiles, Analyze, Pester, GenerateMarkdown, GenerateMAML, GenerateUpdatableHelp all declare Inputs/Outputs for incremental build skipping
• Format-PSBuildResult — new public function formatting PsakeBuildResult for Human, JSON, or GitHubActions consumers
• Invoke-Build parity — IB.tasks.ps1 updated with matching Inputs/Outputs caching and new Pester parameter passthrough

Breaking Changes

Change	Migration
Minimum PowerShell raised from 3.0 to 5.1	Ensure PS 5.1+ runtime
psake dependency raised from 4.9.0 to 5.0.0	./build.ps1 -Bootstrap will install
Invoke-psake returns PsakeBuildResult object	Replace $psake.build_success with $result.Success

New $PSBPreference Keys

Key	Default	Purpose
Build.EnableTaskCaching	$true	Toggle psake 5 content-addressed caching
Test.OutputMode	'Detailed'	Detailed / Minimal / LLM output modes
Test.PesterConfigurationPath	$null	Path to external .psd1 PesterConfiguration

Files Changed (20)

New files (5): ConvertTo-PSBuildLLMOutput.ps1, Format-PSBuildResult.ps1, LLMOutput.tests.ps1, PesterConfig.tests.ps1, FormatBuildResult.tests.ps1

Major rewrites (1): PowerShellBuild/psakeFile.ps1 — all 16 tasks converted to declarative hashtable syntax with Inputs/Outputs caching

Modified (14): manifest, requirements, build.ps1, root psakeFile, build.properties, Test-PSBuildPester, IB.tasks, Messages.psd1, PowerShellBuild.psm1, CI workflow, CHANGELOG, CLAUDE.md, Manifest.tests, TestModule psakeFile

Known Risks

• PreCondition in declarative syntax — psake 5.0.0's hashtable Task syntax support for PreCondition key is inferred from the commit, not confirmed by docs. If it fails, mitigation is to move precondition logic into guard clauses at the top of Action scriptblocks.
• $psake.context.Peek().Tasks.Keys — used by the ? task; may need updating if psake 5.0.0 changes this internal API.

Test plan

• ./build.ps1 -Bootstrap installs psake 5.0.0 successfully
• ./build.ps1 -Task Build compiles with declarative task syntax
• ./build.ps1 -Task Test passes all existing + new tests
• Verify task caching: second ./build.ps1 -Task Build skips cached tasks
• Verify LLM output mode produces valid JSON with failure schema
• Verify PesterConfigurationPath loads external config
• Verify Format-PSBuildResult -Format JSON produces valid structured output
• Cross-platform CI green (ubuntu, windows pwsh, windows PS 5.1, macOS)
• TestModule builds with both psake and Invoke-Build

🤖 Generated with Claude Code

To fix the problem, explicitly declare the GITHUB_TOKEN permissions in the workflow using the permissions key, granting only the minimal scopes required. Since these jobs just check out code and run tests/build via build.ps1 and do not interact with issues, pull requests, or modify repository contents, they can typically operate with contents: read only.

The best way to fix this without changing existing functionality is to add a top-level permissions block to .github/workflows/test.yml (so it applies to all jobs) with contents: read. This documents the workflow’s intent and ensures least-privilege defaults if org or repo settings change later. Concretely, insert:

permissions:
  contents: read

between the on: block and the jobs: block (i.e., after line 6 and before line 7). No additional imports or methods are needed, as this is purely a YAML configuration change within the workflow file.