Compare commits

..
4 Commits
Author SHA1 Message Date
MyDriftGitHubClaude Opus 5coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
8d3adb599f Replace the FOSS dot with a corner badge on app entries (#4924)
* Replace FOSS dot with a corner badge on app entries

- Add New-WinUtilFossBadge, the open source keyhole on a green backdrop
- Mark FOSS apps with a corner triangle instead of a dot after the name
- Give the FOSS legend a circle badge and move it below the buttons
- Sort Note entries last, they shared a rank with checkboxes before

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Update functions/private/Initialize-InstallAppEntry.ps1

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
2026-08-06 12:51:58 -05:00
OmarandGitHub f7c072341d Fix USB creation when install.wim is read-only (#4910)
* fix: allow USB WIM splitting

* test: guard USB WIM splitting fix
2026-08-04 16:01:12 -05:00
FallenGMEandGitHub 32cc623959 Teamspeak6 Added (#4915)
TS 6 is obv. better than TS3
2026-08-04 16:00:19 -05:00
Sean (ANGRYxScotsman)andGitHub b096aaa5e5 Centralize agent instructions in SPEC (#4912)
* Centralize agent instructions in SPEC

Move the full coding-agent contract and repository guidance from `AGENTS.md` into `SPEC.md`, and reduce `AGENTS.md` to a simple pointer to the canonical instructions. Add lightweight `CLAUDE.md`, `GEMINI.md`, and `.github/copilot-instructions.md` files so different assistants consistently bootstrap through the same repo-specific guidance.

* Clarify auto-generated docs path scope in SPEC

Narrowed rule #3 to specify exact auto-generated subdirectories (tweaks/ and features/) rather than the entire code-reference/ directory, and clarified that other hand-written pages (e.g. architecture.mdx) may be edited directly.

* Remove archived docs from gitignore

Drop the old `docs-old` Hugo ignore rules from `.gitignore`, reflecting that the archived docs build artifacts no longer need special handling there.

* Add local env files to docs .gitignore

Add .env.local and .env.*.local patterns to prevent local environment files from being committed.

* Clarify test and git hygiene guidance

Update `SPEC.md` to run Pester in CI mode and tighten repository hygiene instructions around ignored files. The git guidance now points contributors to the actual `.gitignore` files and clarifies that `docs/public/` contains tracked static assets rather than generated output.

* Split agent workflow from project spec

Move repository working instructions into `AGENTS.md` and refocus `SPEC.md` on the stable WinUtil project contract. This separates agent-specific guidance from architecture, build, runtime, docs, testing, and release details so both documents have clearer ownership.

* docs: clarify Pester, ScriptAnalyzer, and source-of-truth rules

Expand AGENTS.md with context on why -SkipPublisherCheck is needed for Pester installation, why winutil.ps1 should be deleted before running ScriptAnalyzer, and clarify that the source-of-truth rule applies only to compiled-script behavior — repository metadata files are edited directly.

* Clarify Pester install command and -SkipPublisherCheck reason

Expands the explanation for why -SkipPublisherCheck is needed (catalog-signed vs Authenticode-signed), clarifies it does not skip download integrity, and adds -Repository PSGallery to pin the trusted source explicitly.
2026-08-04 15:29:49 -05:00
13 changed files with 224 additions and 156 deletions
+3
View File
@@ -0,0 +1,3 @@
# Copilot Instructions
Read `AGENTS.md` in the repository root for operating instructions before doing anything else.
-5
View File
@@ -13,8 +13,3 @@ desktop.ini
.vscode/
.idea/
# hugo files (archived docs)
docs-old/public/
docs-old/.hugo_build.lock
docs-old/resources/
+47 -71
View File
@@ -4,35 +4,22 @@ Drop-in operating instructions for coding agents. Read this file before every ta
**Working code only. Finish the job. Plausibility is not correctness.**
This repository follows the AGENTS.md convention: these instructions are for Codex, Claude Code, Cursor, Windsurf, Copilot, Aider, Devin, Amp, and other coding agents that read `AGENTS.md`.
`SPEC.md` in the repository root is the project contract — read it for what WinUtil is and how it's architected. This file covers how to work on it.
## 0. Non-Negotiables
These rules override everything else in this file when in conflict:
1. **Do not edit `winutil.ps1` directly.** It is generated build output. Change source files and compile.
1. **Do not edit `winutil.ps1` directly.** It is generated build output (see SPEC.md's Build Model). Change source files and compile.
2. **Do not commit `winutil.ps1`.** It is ignored locally and generated by GitHub Actions for releases.
3. **Never fabricate.** Do not invent file paths, function names, command output, test results, commit hashes, or API behavior. Read the file or run the command.
4. **Disagree when the premise is wrong.** Say what is wrong before acting on it.
5. **Stop when genuinely ambiguous.** If two interpretations would produce materially different diffs, ask before editing.
6. **Touch only what the task requires.** No drive-by refactors, formatting sweeps, or unrelated cleanup.
7. **Verify before saying done.** A plausible-looking diff is not proof.
3. **Never touch `docs/src/content/docs/code-reference/tweaks/` or `docs/src/content/docs/code-reference/features/`.** Both are auto-generated (see SPEC.md's Docs Site). Edit the source JSON (`config/tweaks.json`, `config/feature.json`) or the relevant PowerShell function file instead. Other hand-written pages under `code-reference/` (e.g. `architecture.mdx`) are not touched by the generator and may be edited directly.
4. **Never fabricate.** Do not invent file paths, function names, command output, test results, commit hashes, or API behavior. Read the file or run the command.
5. **Disagree when the premise is wrong.** Say what is wrong before acting on it.
6. **Stop when genuinely ambiguous.** If two interpretations would produce materially different diffs, ask before editing.
7. **Touch only what the task requires.** No drive-by refactors, formatting sweeps, or unrelated cleanup.
8. **Verify before saying done.** A plausible-looking diff is not proof.
## 1. Project Context
WinUtil is a Windows PowerShell utility with a WPF interface. The repository is maintained as modular source, but the distributed artifact is one compiled PowerShell script.
### Stack
- Language: Windows PowerShell / PowerShell.
- UI: WPF via `xaml/inputXML.xaml`.
- Configuration: JSON files under `config/`.
- Tests: Pester tests under `pester/`.
- Lint: PowerShell Script Analyzer with settings in `lint/PSScriptAnalyser.ps1`.
- Docs: Hugo site under `docs/`.
- Release artifact: generated root `winutil.ps1`.
### Key Commands
## 1. Key Commands
- Compile:
```powershell
@@ -42,50 +29,38 @@ WinUtil is a Windows PowerShell utility with a WPF interface. The repository is
```powershell
.\Compile.ps1 -Run
```
- Install the supported Pester version (one-time). `-SkipPublisherCheck` is required because Windows ships an inbox Pester 3.4.0 that is catalog-signed, and PowerShell Gallery's Pester 5.8.0 is Authenticode-signed — `Install-Module` refuses the upgrade without it. This does not skip download integrity (still HTTPS + NuGet package hash verification); `-Repository PSGallery` pins the trusted source explicitly rather than relying on whatever repositories happen to be registered:
```powershell
Install-Module -Name Pester -RequiredVersion 5.8.0 -Repository PSGallery -Scope CurrentUser -Force -SkipPublisherCheck
```
- Run tests:
```powershell
Import-Module Pester -RequiredVersion 5.8.0 -Force
Invoke-Pester -Path 'pester/*.Tests.ps1' -Output Detailed
Invoke-Pester -Path 'pester/*.Tests.ps1' -Output Detailed -CI
```
- Run Script Analyzer with project settings when available:
- Run Script Analyzer with project settings when available. If a locally compiled `winutil.ps1` exists, delete it first — `lint/PSScriptAnalyser.ps1` only excludes rules, not files, so `-Recurse` would also lint the generated script and produce noise against line numbers that don't map to any source file:
```powershell
Invoke-ScriptAnalyzer -Path . -Settings .\lint\PSScriptAnalyser.ps1 -Recurse
```
- Docs site dev server (run from `docs/`):
```powershell
npm install
npm run dev
```
- Docs site production build (run from `docs/`):
```powershell
npm run build
```
Prefer the narrowest useful verification while iterating. Use the full relevant check before finishing.
## 2. Source Of Truth
Make durable changes only in files consumed by `Compile.ps1` or in documentation/test files:
For changes that affect the compiled WinUtil script, make them only in the source files described in SPEC.md's Repository Layout — never in `winutil.ps1` itself. If behavior changes require the compiled script to change, update the source files and run `.\Compile.ps1` only to verify generation.
- `scripts/start.ps1` for startup/bootstrap code.
- `functions/public/*.ps1` for UI-facing and user-facing workflows.
- `functions/private/*.ps1` for internal helpers.
- `config/*.json` for applications, tweaks, features, DNS, presets, navigation, themes, and related declarative data.
- `xaml/inputXML.xaml` for the WPF UI layout.
- `tools/autounattend.xml` for the embedded unattended Windows setup template.
- `scripts/main.ps1` for the final entrypoint and GUI initialization logic appended during compile.
- `pester/*.Tests.ps1` for automated checks.
- `docs/` for Hugo documentation.
This scoping applies to compiled-script behavior only. Repository metadata — `AGENTS.md`, `SPEC.md`, `CLAUDE.md`/`GEMINI.md`/`.github/copilot-instructions.md`, `.github/workflows/`, and the root `.gitignore` — is edited directly when a task requires it, per the other sections of this file.
If behavior changes require the compiled script to change, update these source files and run `.\Compile.ps1` only to verify generation.
## 3. Build Model
`Compile.ps1` combines the repository sources into `winutil.ps1` in this order:
1. Read `scripts/start.ps1` and replace `#{replaceme}` with the current `yy.MM.dd` build date.
2. Append every file under `functions/` recursively.
3. Convert each `config/*.json` file into embedded `$sync.configs` objects.
4. Special-case `config/applications.json` so keys receive the `WPFInstall` prefix in compiled config.
5. Embed `xaml/inputXML.xaml` into `$inputXML`.
6. Embed `tools/autounattend.xml` into `$WinUtilAutounattendXml`.
7. Append `scripts/main.ps1`.
8. Write the result to root `winutil.ps1`.
Because the final script is concatenated, do not rely on runtime module imports or source-relative dot-sourcing unless the compiled script will also contain the required code/data.
## 4. Before Editing
## 3. Before Editing
- State the plan in one or two sentences before editing. For non-trivial work, include the verification you intend to run.
- Read the files you will touch and the files that call them.
@@ -93,30 +68,29 @@ Because the final script is concatenated, do not rely on runtime module imports
- Surface assumptions when they affect behavior, compatibility, or user data.
- If two approaches have meaningful tradeoffs, name them before choosing. Trivial tasks can proceed directly.
## 5. Coding Guidelines
## 4. Coding Guidelines
- Prefer the minimum code that solves the stated problem.
- Keep PowerShell functions in one function file when practical, with the file name matching the primary function name.
- Use approved PowerShell verb-noun names and follow the existing `WPF` / `WinUtil` naming conventions.
- Keep UI event handler names aligned with XAML element names. A button named `WPFExampleButton` is typically handled by `Invoke-WPFExampleButton`.
- Use `$sync` for shared state and UI references, consistent with the existing runspace model.
- Use approved PowerShell verb-noun names and follow the existing `WPF` / `WinUtil` naming conventions; keep UI event handler names aligned with XAML element names per SPEC.md's UI And Event Contract.
- Use `$sync` for shared state and UI references, consistent with SPEC.md's Runtime Model.
- Update WPF controls through the UI dispatcher when running work in a background runspace.
- Keep config-driven features in JSON when they fit the existing schema instead of hard-coding lists in PowerShell.
- Keep config-driven features in JSON when they fit the existing schema instead of hard-coding lists in PowerShell; follow SPEC.md's Configuration Contract for required fields and key-renaming rules.
- Preserve undo/original-state data for tweaks so users can reverse changes.
- Do not add abstractions, configurability, hooks, or "future extensibility" unless the task needs them now.
- Clean up orphans created by your own changes, such as unused variables or functions made obsolete by the edit.
- Avoid broad formatting-only edits, especially in JSON config files, XAML, docs, and generated output.
## 6. Runtime And Safety Rules
## 5. Runtime And Safety Rules
- WinUtil performs system-level Windows changes. Treat registry, services, AppX removal, package manager, Windows Update, ISO, and unattended setup changes as high-risk.
- WinUtil performs system-level Windows changes; treat registry, services, AppX removal, package manager, Windows Update, ISO, and unattended setup changes as high-risk (see SPEC.md's Safety Requirements).
- Prefer existing helper functions for WinGet, Chocolatey, registry, services, progress, and UI updates.
- Keep tweaks reversible where the schema supports it by including original values or original states.
- Never modify a user's original ISO in-place; follow existing copy/mount/export patterns.
- Avoid storing credentials, secrets, or machine-specific paths in repo files.
- Preserve logging and user feedback patterns for long-running or destructive operations.
## 7. Surgical Changes
## 6. Surgical Changes
- Do not improve adjacent code, comments, formatting, imports, or docs unless required.
- Do not refactor working code because you are already in the file.
@@ -124,7 +98,7 @@ Because the final script is concatenated, do not rely on runtime module imports
- Keep diffs reviewable. Every changed line should trace to the user's request.
- If a change starts spreading across unrelated areas, pause and reassess the plan.
## 8. Verification
## 7. Verification
Define success in terms that can be checked, then check it.
@@ -136,26 +110,28 @@ Define success in terms that can be checked, then check it.
- Read command output. Do not report tests as passing unless they actually passed.
- If verification fails, fix the cause rather than weakening the test.
If a check cannot be run, say exactly why and what residual risk remains.
If a check cannot be run, say exactly why and what residual risk remains. See SPEC.md's Testing And CI for what GitHub Actions runs on every push.
## 9. Generated Files And Git Hygiene
## 8. Generated Files And Git Hygiene
- Treat local `winutil.ps1` changes as disposable compile output.
- Never stage or commit `winutil.ps1`, `docs/public/`, `docs/resources/`, `binary/`, editor folders, or other ignored build artifacts.
- Never stage or commit `winutil.ps1`, `binary/`, or anything else ignored by the root `.gitignore` or `docs/.gitignore` — read those files rather than assuming. `docs/public/` is tracked source for static assets, not generated output.
- Do not remove `.gitignore` rules that keep generated artifacts out of Git.
- Before finishing, check `git status --short` and separate your changes from pre-existing user changes.
- Do not revert user changes unless explicitly asked.
- Commit messages, when requested, should be descriptive: short subject under 72 characters, body explaining why when needed.
- When committing, split changes into small, logical commits rather than one large commit, so each commit's diff is reviewable as a single group of related changes.
## 10. Documentation Expectations
## 9. Documentation Expectations
- Update `docs/content/` when user-facing behavior changes.
- Update developer docs when architecture, build flow, config schema, or contribution workflow changes.
- Update `docs/src/content/docs/guides/` when user-facing behavior changes.
- Update `docs/src/content/docs/code-reference/architecture.mdx` and other hand-written developer docs when architecture, build flow, config schema, or contribution workflow changes — but never hand-edit the auto-generated `code-reference/tweaks/` or `code-reference/features/` subfolders (see Non-Negotiables).
- Keep sidebar entries in `docs/astro.config.mjs` in sync with page slugs (see SPEC.md's Docs Site).
- Keep README changes brief and high-level.
- Put detailed user and developer documentation under `docs/`.
- Keep `SPEC.md` aligned with build/runtime contract changes.
- Keep SPEC.md aligned with project/architecture changes, and this file aligned with process changes.
## 11. Communication Style
## 10. Communication Style
- Be direct and concise. Start with the answer or action.
- No flattery, filler, ceremonial closings, or fake certainty.
@@ -163,7 +139,7 @@ If a check cannot be run, say exactly why and what residual risk remains.
- Report what changed, how it was verified, and anything not done.
- If the user asks for a review, lead with findings and file/line references.
## 12. When To Ask
## 11. When To Ask
Ask before proceeding when:
@@ -178,7 +154,7 @@ Proceed without asking when:
- Ambiguity can be resolved by reading the code or running a local command.
- The user already answered the question in this session.
## 13. Project Learnings
## 12. Project Learnings
When the user corrects an agent approach, add or tighten one concrete rule here before ending the session. Keep this section short and prune rules that no longer matter.
+3
View File
@@ -0,0 +1,3 @@
# CLAUDE.md
Read `AGENTS.md` in this repository root for operating instructions before doing anything else.
+3
View File
@@ -0,0 +1,3 @@
# GEMINI.md
Read `AGENTS.md` in the repository root for operating instructions before doing anything else.
+64 -58
View File
@@ -1,10 +1,37 @@
# SPEC.md
## Project Contract
Project contract for WinUtil — what the project is, how it's built, and how it runs. Written for anyone, human or AI, who needs to understand the project itself.
WinUtil is a Windows PowerShell utility with a WPF interface. The repository is maintained as modular source files, but the released artifact is a single generated `winutil.ps1` script.
`AGENTS.md` in the repository root points here for these facts, and separately covers how an agent should behave while working in this repo. This file does not change based on who's reading it.
The compiled `winutil.ps1` is not source code for editing or review. It is generated by `Compile.ps1` and produced during release automation. All durable changes must be made to the source files that feed the compiler.
## Project Context
WinUtil is a Windows PowerShell utility with a WPF interface. The repository is maintained as modular source, but the distributed artifact is one compiled PowerShell script.
### Stack
- Language: Windows PowerShell / PowerShell.
- UI: WPF via `xaml/inputXML.xaml`.
- Configuration: JSON files under `config/`.
- Tests: Pester tests under `pester/`.
- Lint: PowerShell Script Analyzer with settings in `lint/PSScriptAnalyser.ps1`.
- Docs: Astro + Starlight site under `docs/`, built independently of `Compile.ps1` (its own `package.json`/`node_modules`).
- Release artifact: generated root `winutil.ps1`.
### Repository Layout
- `Compile.ps1`: build script that creates `winutil.ps1`.
- `scripts/start.ps1`: startup/bootstrap segment used at the beginning of the compiled script.
- `scripts/main.ps1`: main entrypoint appended at the end of the compiled script.
- `functions/public/`: public/UI-facing PowerShell functions.
- `functions/private/`: internal helper PowerShell functions.
- `config/`: JSON configuration consumed at compile time and embedded into `$sync.configs`.
- `xaml/inputXML.xaml`: WPF UI markup embedded into the compiled script.
- `tools/autounattend.xml`: unattended setup XML embedded for Windows ISO workflows.
- `pester/`: Pester tests for config and function checks.
- `lint/PSScriptAnalyser.ps1`: PowerShell Script Analyzer settings.
- `docs/`: Astro + Starlight documentation site, with its own `package.json` and build independent of `Compile.ps1`.
- `winutil.ps1`: ignored generated build artifact.
## Goals
@@ -21,85 +48,64 @@ The compiled `winutil.ps1` is not source code for editing or review. It is gener
- The GUI is not a separate packaged desktop application in this repository's normal release path.
- Generated files should not be reviewed as source changes.
## Repository Layout
## Build Model
- `Compile.ps1`: build script that creates `winutil.ps1`.
- `scripts/start.ps1`: startup/bootstrap segment used at the beginning of the compiled script.
- `scripts/main.ps1`: main entrypoint appended at the end of the compiled script.
- `functions/public/`: public/UI-facing PowerShell functions.
- `functions/private/`: internal helper PowerShell functions.
- `config/`: JSON configuration consumed at compile time and embedded into `$sync.configs`.
- `xaml/inputXML.xaml`: WPF UI markup embedded into the compiled script.
- `tools/autounattend.xml`: unattended setup XML embedded for Windows ISO workflows.
- `pester/`: Pester tests for config and function checks.
- `lint/PSScriptAnalyser.ps1`: PowerShell Script Analyzer settings.
- `docs/`: Hugo documentation site.
- `winutil.ps1`: ignored generated build artifact.
`Compile.ps1` combines the repository sources into `winutil.ps1` in this order:
## Compile Specification
1. Read `scripts/start.ps1` and replace `#{replaceme}` with the current `yy.MM.dd` build date.
2. Append every file under `functions/` recursively.
3. Convert each `config/*.json` file into embedded `$sync.configs` objects.
4. Special-case `config/applications.json` so keys receive the `WPFInstall` prefix in compiled config.
5. Embed `xaml/inputXML.xaml` into `$inputXML`.
6. Embed `tools/autounattend.xml` into `$WinUtilAutounattendXml`.
7. Append `scripts/main.ps1`.
8. Write the result to root `winutil.ps1`.
`Compile.ps1` must produce a standalone root `winutil.ps1` by combining all required project files.
The compile flow is:
1. Initialize shared state with `$sync = [Hashtable]::Synchronized(@{})` and `$sync.configs = @{}`.
2. Read `scripts/start.ps1`.
3. Replace `#{replaceme}` in startup code with the current `yy.MM.dd` build date.
4. Append raw content from all files under `functions/` recursively.
5. For every file in `config/`, parse JSON and embed it into `$sync.configs.<basename>`.
6. Special-case `config/applications.json` so application keys are emitted with the `WPFInstall` prefix.
7. Embed `xaml/inputXML.xaml` as `$inputXML`.
8. Embed `tools/autounattend.xml` as `$WinUtilAutounattendXml`.
9. Append `scripts/main.ps1`.
10. Write the combined script to `winutil.ps1`.
11. If `-Run` is supplied, execute the generated script.
The generated script must have everything it needs from repository sources embedded or appended by this process.
Because the final script is concatenated, code cannot rely on runtime module imports or source-relative dot-sourcing unless the compiled script will also contain the required code/data.
## Runtime Model
- WinUtil runs in PowerShell on Windows and uses WPF for the UI.
- Shared mutable state is stored in `$sync`, including configs, UI element references, runspace state, selections, and progress.
- Long-running operations should use runspaces or existing async patterns so the UI remains responsive.
- UI updates from background work must be dispatched back to the WPF UI thread.
- Declarative features such as apps, tweaks, presets, DNS providers, and navigation should stay in `config/*.json` unless code is required.
- Long-running operations use runspaces or existing async patterns so the UI remains responsive.
- UI updates from background work are dispatched back to the WPF UI thread.
- Declarative features such as apps, tweaks, presets, DNS providers, and navigation stay in `config/*.json` unless code is required.
## UI And Event Contract
- UI layout lives in `xaml/inputXML.xaml`.
- Named WPF controls are discovered and stored in `$sync`.
- Button/action wiring follows existing naming conventions, where an element named like `WPFThingButton` maps to a function named like `Invoke-WPFThingButton`.
- When adding controls, ensure the XAML name, config key, and PowerShell function names line up with the existing event system.
- Button/action wiring follows a naming convention: an element named like `WPFThingButton` maps to a function named like `Invoke-WPFThingButton`.
## Configuration Contract
Config files must remain valid JSON and compile cleanly through `ConvertFrom-Json`.
`config/applications.json` defines installable applications. Each application entry should include the fields expected by tests and UI code, such as package manager IDs, category, display content, description, and link.
`config/tweaks.json` defines Windows tweaks. Registry and service changes should include original values or original states when applicable so undo workflows can restore user systems.
Preset and navigation files should reference valid config keys. Avoid renaming config keys unless all presets, UI references, docs, and code paths are updated together.
- Config files must remain valid JSON and compile cleanly through `ConvertFrom-Json`.
- `config/applications.json` defines installable applications; each entry includes the fields expected by tests and UI code, such as package manager IDs, category, display content, description, and link.
- `config/tweaks.json` defines Windows tweaks; registry and service changes include original values or original states when applicable so undo workflows can restore user systems.
- Preset and navigation files reference valid config keys. Renaming a config key requires updating all presets, UI references, docs, and code paths together.
## Safety Requirements
- Registry, service, package manager, Windows Update, AppX removal, and ISO operations can affect the host system. Changes must be explicit, reversible where practical, and consistent with existing logging and confirmation patterns.
- Tweak changes should include undo metadata when the schema supports it.
- Package installation should prefer existing WinGet and Chocolatey helper functions.
- ISO workflows must not modify the user's original ISO file; they should work on copied/mounted content following existing patterns.
- Registry, service, package manager, Windows Update, AppX removal, and ISO operations affect the host system and are treated as high-risk.
- Tweak changes include undo metadata when the schema supports it, so changes stay reversible.
- ISO workflows never modify the user's original ISO file; they work on copied/mounted content.
## Docs Site (Astro)
- `docs/` is an Astro + Starlight site, independent of `Compile.ps1`'s build (its own `package.json`/`node_modules`, deployed via the `docs.yaml` GitHub Actions workflow to GitHub Pages).
- Pages live under `docs/src/content/docs/` (`.mdx`), organized into `guides/`, `code-reference/`, plus top-level pages like `faq.mdx`, `knownissues.mdx`, `contributing.mdx`, `index.mdx`.
- `docs/src/content/docs/code-reference/tweaks/` and `.../features/` are auto-generated by `tools/devdocs-generator.ps1` from `config/tweaks.json`/`config/feature.json` and the relevant PowerShell function files. Other pages under `code-reference/` (e.g. `architecture.mdx`) are hand-written and untouched by the generator.
- Sidebar entries in `docs/astro.config.mjs` must match actual page slugs under `docs/src/content/docs/`.
- `docs/public/` is tracked source for static assets (favicons, etc.), not generated output. Generated/ignored paths are listed in `docs/.gitignore` (`dist/`, `.astro/`, `node_modules/`, local env files).
## Testing And CI
Expected validation for source changes:
- `.\Compile.ps1` verifies the compiler can generate `winutil.ps1`.
- `.\Compile.ps1 -Run` compiles and launches the generated utility for manual GUI verification.
- `Install-Module -Name Pester -RequiredVersion 5.8.0 -Scope CurrentUser -Force -SkipPublisherCheck` installs the supported Pester version.
- `Import-Module Pester -RequiredVersion 5.8.0 -Force; Invoke-Pester -Path 'pester/*.Tests.ps1' -Output Detailed -CI` runs the Pester suite.
- GitHub Actions also runs a compile check and PowerShell Script Analyzer with `lint/PSScriptAnalyser.ps1`.
The generated `winutil.ps1` may appear locally after compile. It remains ignored build output and must not be committed.
- Pester 5.8.0 runs the suite under `pester/*.Tests.ps1`. GitHub Actions (`unittests.yaml`) installs Pester 5.8.0 fresh and runs with `-CI`, which produces `testResults.xml` and exits non-zero on failure.
- GitHub Actions also runs PowerShell Script Analyzer with `lint/PSScriptAnalyser.ps1` on every push.
- The generated `winutil.ps1` may appear locally after compile. It remains ignored build output (see root `.gitignore`) and must not be committed.
## Release Artifact
GitHub Actions is responsible for producing the release `winutil.ps1` from repository sources. A release should be considered valid only if the generated script came from the compile process, not from direct manual edits to `winutil.ps1`.
GitHub Actions is responsible for producing the release `winutil.ps1` from repository sources. A release is considered valid only if the generated script came from the compile process, not from direct manual edits to `winutil.ps1`.
+9
View File
@@ -1510,6 +1510,15 @@
"winget": "TeamSpeakSystems.TeamSpeakClient",
"foss": false
},
"teamspeak6": {
"category": "Communications",
"choco": "na",
"content": "TeamSpeak 6",
"description": "TEAMSPEAK. YOUR TEAM. YOUR RULES. Use crystal clear sound to communicate with your teammates cross-platform with military-grade security, lag-free performance & unparalleled reliability and uptime.",
"link": "https://www.teamspeak.com/",
"winget": "TeamSpeakSystems.TeamSpeakClient.Beta.6",
"foss": false
},
"telegram": {
"category": "Communications",
"choco": "telegram",
+2
View File
@@ -16,6 +16,8 @@ pnpm-debug.log*
# environment variables
.env
.env.production
.env.local
.env.*.local
# macOS-specific files
.DS_Store
@@ -21,8 +21,9 @@ function Initialize-InstallAppEntry {
$border.Tag = $appKey
$border.ToolTip = $app.description
$border.Add_MouseLeftButtonUp({
$childCheckbox = ($this.Child | Where-Object {$_.Template.TargetType -eq [System.Windows.Controls.Checkbox]})[0]
$childCheckBox.isChecked = -not $childCheckbox.IsChecked
# Resolve through $sync because the border's child is a layout Grid for FOSS entries
$childCheckbox = $sync.$($this.Tag)
$childCheckbox.IsChecked = -not $childCheckbox.IsChecked
})
$border.Add_MouseEnter({
if (($sync.$($this.Tag).IsChecked) -eq $false) {
@@ -48,15 +49,16 @@ function Initialize-InstallAppEntry {
# Store the original appKey in Tag
$checkBox.Tag = $appKey
$checkbox.Style = $sync.Form.Resources.AppEntryCheckboxStyle
# The checkbox sits inside the entry layout Grid, so the border is one level further up
$checkbox.Add_Checked({
Invoke-WPFSelectedCheckboxesUpdate -type "Add" -checkboxName $this.Parent.Tag
$borderElement = $this.Parent
Invoke-WPFSelectedCheckboxesUpdate -type "Add" -checkboxName $this.Tag
$borderElement = $this.Parent.Parent
$borderElement.SetResourceReference([Windows.Controls.Control]::BackgroundProperty, "AppInstallSelectedColor")
})
$checkbox.Add_Unchecked({
Invoke-WPFSelectedCheckboxesUpdate -type "Remove" -checkboxName $this.Parent.Tag
$borderElement = $this.Parent
Invoke-WPFSelectedCheckboxesUpdate -type "Remove" -checkboxName $this.Tag
$borderElement = $this.Parent.Parent
$borderElement.SetResourceReference([Windows.Controls.Control]::BackgroundProperty, "AppInstallUnselectedColor")
})
@@ -88,15 +90,6 @@ function Initialize-InstallAppEntry {
$appName = New-Object Windows.Controls.TextBlock
$appName.Style = $sync.Form.Resources.AppEntryNameStyle
$appName.Text = $app.content
# Add FOSS label after the name if FOSS
if ($app.foss -eq $true) {
$fossRun = [System.Windows.Documents.Run]::new(" $([char]0x25CF)")
$fossRun.Foreground = [Windows.Media.SolidColorBrush]::new([Windows.Media.Color]::FromRgb(110, 255, 114))
$fossRun.FontSize = 11.5
[void]$appName.Inlines.Add($fossRun)
}
[void]$contentPanel.Children.Add($appName)
$checkBox.Content = $contentPanel
@@ -104,7 +97,20 @@ function Initialize-InstallAppEntry {
$checkBox.SetValue([Windows.Automation.AutomationProperties]::NameProperty, $app.content)
$border.SetValue([Windows.Automation.AutomationProperties]::NameProperty, $app.content)
$border.Child = $checkBox
# Keep the same layout for every entry so the checkbox handlers can reach the border
$entryLayout = New-Object Windows.Controls.Grid
[void]$entryLayout.Children.Add($checkBox)
# Mark FOSS apps with a corner badge, bled into the border padding so it sits on the edge
if ($app.foss -eq $true) {
$fossBadge = New-WinUtilFossBadge
$fossBadge.HorizontalAlignment = "Right"
$fossBadge.VerticalAlignment = "Top"
$fossBadge.Margin = New-Object Windows.Thickness(0, -4, -6, 0)
[void]$entryLayout.Children.Add($fossBadge)
}
$border.Child = $entryLayout
if ($sync.selectedApps -contains $appKey) {
$checkBox.IsChecked = $true
}
@@ -241,6 +241,7 @@ function Invoke-WinUtilISOWriteUSB {
$wimSizeMB = [math]::Round((Get-Item $installWim).Length / 1MB)
if ($wimSizeMB -gt 3800) {
Log "install.wim is $wimSizeMB MB - splitting for FAT32 compatibility... This will take several minutes."
Set-ItemProperty -LiteralPath $installWim -Name IsReadOnly -Value $false
$splitDest = Join-Path $usbDrive "sources\install.swm"
New-Item -ItemType Directory -Path (Split-Path $splitDest) -Force
Split-WindowsImage -ImagePath $installWim -SplitImagePath $splitDest -FileSize 3800 -CheckIntegrity
@@ -0,0 +1,53 @@
function New-WinUtilFossBadge {
<#
.SYNOPSIS
Creates the FOSS marker: the open source keyhole on a green backdrop
.DESCRIPTION
Returns a fresh element on every call, because a WPF element can only have one parent.
The artwork is authored in a 22x22 box and scaled by the Viewbox, so callers only pick a size.
.PARAMETER Size
Edge length of the badge in pixels
.PARAMETER Round
Use a full circle instead of the corner triangle, for the legend rather than an app entry
#>
param(
[double]$Size = 24,
[switch]$Round
)
$artwork = New-Object Windows.Controls.Grid
$artwork.Width = 22
$artwork.Height = 22
$backdrop = New-Object Windows.Shapes.Path
$backdrop.Fill = [Windows.Media.SolidColorBrush]::new([Windows.Media.Color]::FromRgb(19, 143, 83))
$keyhole = New-Object Windows.Shapes.Path
$keyhole.Stroke = [Windows.Media.SolidColorBrush]::new([Windows.Media.Color]::FromRgb(247, 247, 247))
if ($Round) {
$backdrop.Data = [Windows.Media.EllipseGeometry]::new([Windows.Point]::new(11, 11), 11, 11)
# Keyhole centred in the circle, which has room for a larger ring than the triangle does
$keyhole.Data = [Windows.Media.Geometry]::Parse("M 7.673,15.751 A 5.8,5.8 0 1 1 14.327,15.751")
$keyhole.StrokeThickness = 3.4
} else {
# Triangle filling the top right corner, its outer corner rounded to match AppEntryBorderStyle
$backdrop.Data = [Windows.Media.Geometry]::Parse("M 0,0 L 17,0 A 5,5 0 0 1 22,5 L 22,22 Z")
# Keyhole centred on the triangle's incentre (15.56, 6.44) so it keeps the same
# 1.8 clearance from all three edges
$keyhole.Data = [Windows.Media.Geometry]::Parse("M 13.61,9.225 A 3.4,3.4 0 1 1 17.51,9.225")
$keyhole.StrokeThickness = 2.4
}
$keyhole.StrokeStartLineCap = [Windows.Media.PenLineCap]::Round
$keyhole.StrokeEndLineCap = [Windows.Media.PenLineCap]::Round
[void]$artwork.Children.Add($backdrop)
[void]$artwork.Children.Add($keyhole)
$badge = New-Object Windows.Controls.Viewbox
$badge.Width = $Size
$badge.Height = $Size
$badge.Child = $artwork
$badge.ToolTip = "Free and Open Source Software"
return $badge
}
+5 -6
View File
@@ -143,11 +143,12 @@ function Invoke-WPFUIElements {
$itemsControl.Items.Add($label) | Out-Null
$sync[$category] = $label
# Sort entries by type (checkboxes first, then buttons, then comboboxes) and then alphabetically by Content
# Sort entries by type (checkboxes first, then buttons, then comboboxes, notes last) and then alphabetically by Content
$entries = $organizedData[$panelKey][$category] | Sort-Object @{Expression = {
switch ($_.Type) {
'Button' { 1 }
'Combobox' { 2 }
'Note' { 3 }
default { 0 }
}
}}, Content
@@ -364,17 +365,15 @@ function Invoke-WPFUIElements {
$textBlock.Margin = "5,5,5,5"
$textBlock.UseLayoutRounding = $true
$bulletRun = New-Object Windows.Documents.Run
$bulletRun.Text = [char]0x25CF
$bulletRun.Foreground = [Windows.Media.SolidColorBrush]::new([Windows.Media.Color]::FromRgb(110, 255, 114))
$bulletRun.FontSize = 11.5
$bulletBadge = [Windows.Documents.InlineUIContainer]::new((New-WinUtilFossBadge -Size 18 -Round))
$bulletBadge.BaselineAlignment = [Windows.BaselineAlignment]::Center
$textRun = New-Object Windows.Documents.Run
$textRun.Text = " $($entryInfo.Content)"
$textRun.SetResourceReference([Windows.Controls.Control]::FontSizeProperty, "FontSize")
$textRun.Foreground = [Windows.Media.SolidColorBrush]::new([Windows.Media.Color]::FromRgb(19, 143, 83))
$textBlock.Inlines.Add($bulletRun)
$textBlock.Inlines.Add($bulletBadge)
$textBlock.Inlines.Add($textRun)
$itemsControl.Items.Add($textBlock) | Out-Null
+12
View File
@@ -191,6 +191,18 @@ Describe "Win11 Creator setup media" {
$confirmationIndex | Should -BeGreaterThan $guardIndex
}
It "clears install.wim read-only attribute before FAT32 splitting" {
$splitGuardIndex = $script:writeUsbFunction.IndexOf('$wimSizeMB -gt 3800')
$readOnlyResetIndex = $script:writeUsbFunction.IndexOf(
'Set-ItemProperty -LiteralPath $installWim -Name IsReadOnly -Value $false'
)
$splitCommandIndex = $script:writeUsbFunction.IndexOf('Split-WindowsImage')
$splitGuardIndex | Should -BeGreaterThan -1
$readOnlyResetIndex | Should -BeGreaterThan $splitGuardIndex
$splitCommandIndex | Should -BeGreaterThan $readOnlyResetIndex
}
It "maps Windows edition names to setup edition IDs" {
. ([scriptblock]::Create($script:editionIdFunction))