SetupScope

A compact Windows desktop developer toolkit. Five purpose-built tools help you inspect projects, troubleshoot build failures, review development environments and understand local processes. Developer dependencies, diagnostic export and recovery are integrated into those workflows.

1.0.0.0 released · Windows 11 x64 · MIT · No account · No telemetry

Downloads

Download	Choose it when	SHA-256
Portable ZIP — Windows x64 · approximately 11.9 MiB	You want to extract and run without installation, keeping data beside the app.	ZIP checksum
Installer EXE — Windows x64 · approximately 10.2 MiB	You want a per-user installation, optional shortcuts and a Windows Installed Apps entry.	Installer checksum

Both contain the same GUI and console binaries. Optional developer toolchain payloads are downloaded separately. The Source code archives generated by GitHub are for building the project; use one of the two downloads above to run it.

Release notes and all assets · Source and executable provenance · Installer validation · Testing limits

Verify your download

Save the selected download and its matching .sha256 file in the same folder. In PowerShell, open that folder and run:

function Test-SetupScopeDownload([string]$File) {
    $expected = ((Get-Content -LiteralPath ($File + '.sha256') -Raw).Trim() -split '\s+')[0]
    if ($expected -notmatch '^[a-fA-F0-9]{64}$') { throw 'Invalid checksum file.' }
    $actual = (Get-FileHash -LiteralPath $File -Algorithm SHA256).Hash
    if ($actual -ne $expected) { throw 'Checksum mismatch. Do not run or extract this file.' }
    "Verified: $File"
}

# Run the line matching your chosen download:
Test-SetupScopeDownload '.\SetupScope-1.0.0.0-win-x64.zip'
Test-SetupScopeDownload '.\SetupScope-Setup-1.0.0.0-win-x64.exe'

A matching checksum establishes agreement with the published checksum, not an Authenticode signature or a clean-machine certification. Both packages are unsigned.

Guide: Start here · Requirements · Five tools · Dependencies · Build/test · CLI · Recovery · Troubleshooting · Build from source · Verification

Start here

Choose SetupScope-1.0.0.0-win-x64.zip for portable use: unpack it into a writable local location and run SetupScope.exe. Choose SetupScope-Setup-1.0.0.0-win-x64.exe for a per-user installation with optional Start Menu and desktop shortcuts and an Apps uninstall entry. Both include SetupScope-cli.exe. Neither changes PATH or installs developer toolchains automatically. Verify each download against its adjacent .sha256 file. See installation and recovery.

The application itself needs Windows, not a separate .NET runtime, Python installation or Visual C++ Redistributable. The MSVC C runtime is statically linked. A compatible Windows graphics driver is required. Developer toolchain installers are optional downloads selected inside the application; their payloads are not included by default.

The unsigned packages can trigger Windows reputation warnings. There is no certificate/signing claim. Administrator access is not needed to open the toolkit, install it for the current user or perform ordinary passive checks. Vendor installation and some system observations have their own permission requirements, explained where used.

First project in five steps

1. Open Project Readiness, choose an existing absolute local project folder and select the intended x64 or ARM64 target.
2. Inspect explicitly. Review requirements, toolchain/PATH evidence, unknowns and partial observations; selecting a folder starts nothing.
3. For missing tools, open Dependencies and review the exact package or native vendor setup. Downloading, verification and installation are separate actions.
4. For a build failure, inspect a saved log in Build Troubleshooting, or separately review an executable and arguments before running a build/test. Use Environment Profiles when a project needs a different environment.
5. Reinspect after changes. Preview the redacted diagnostic JSON before saving a file to share. A completed inspection is not a successful-build verdict.

The main Workflow Board has six cards in a 3-column × 2-row grid: the five tools and a read-only System And OS card with Windows build, architecture, CPU threads and RAM. Tool features appear as lists. It starts without maximizing. Its header reads Windows Software Development Toolkit, with Settings at the far right. Opening/focusing a tool hides the board. Each tool has a top-right Workflow Board button that shows the main window while leaving every tool open and its work running. Closing the last tool also restores the board. Each tool has its own independently resizable window and taskbar entry; selecting it again focuses the existing window. One GUI instance runs per Windows session. Launching another copy restores the existing board. The status bar shows Windows build, host/application architecture, CPU threads and available/total RAM.

Requirements and offline use

Area	Current scope
Packaged platform	Windows 11 x64. Local runtime checks used Windows build 26300; other Windows builds are not certified.
ARM64	Source cross-build passes GitHub CI. No native ARM64 runtime certification or ARM64 download is claimed. Selecting an ARM64 project target is distinct from running the app on ARM64.
Graphics	A compatible Windows graphics driver is required. A broad GPU/DPI matrix and minimum hardware specification have not been certified.
Application runtimes	No separate .NET, Python, Node.js or Visual C++ Redistributable is required to run the packaged toolkit. Developer projects have their own requirements.
Permissions	Standard-user operation by default. Restricted process/system evidence can remain incomplete. Vendor setup can request its own elevation.
Offline workflows	Project inspection, saved-log triage, environment previews, ports/process observations and passive WSL/container checks use local evidence. Cached installer verification/import/export can work offline when Windows cached trust is sufficient.
Explicit network activity	Selected dependency downloads and opening vendor/source links. A build or vendor installer you separately launch can use its own network access, credentials and subprocesses.

No developer compiler, SDK workload, container engine or complete air-gapped toolchain is included by default. Offline bundles contain only the selected, verified catalog installers; project package restores and transitive prerequisites remain separate.

Languages

Settings → Language offers English plus all ten existing catalogs: Spanish, German, French, Brazilian Portuguese, Italian, Russian, Simplified Chinese, Japanese, Korean and Polish. Each catalog covers 600 owned UI strings plus 58 preserved technical identifiers, including tooltips, safety guidance and statuses. Original diagnostic evidence, commands, vendor reviews/output and CLI help retain their original wording. Independent native-speaker review remains welcome. See language coverage and limits. No translation service or account is required.

Settings and language previews

Screenshots show local read-only observations and explicitly synthetic saved-log examples. System/tool details vary by PC. Captures precede the final terminology review; some wording has since improved.

The five tools

Tool	Workflow	Important boundary
Project Readiness	Select a project, target and profile; inspect bounded requirements, prerequisites, PATH/version evidence and optional saved-log hints. Requirements, Toolchain / PATH, Export and Dependencies remain in this one window.	Presence/metadata is not proof of a successful build. Project scripts and commands never run as diagnostics.
Build Troubleshooting	Separately review a build/test command, capture bounded logs, inspect saved-log hints and export reviewed redacted JSON.	Execution runs project code with your account/environment and requires acknowledgment. Cancellation cannot undo side effects. Log inspection remains read-only.
Environment Profiles	Edit project paths/variables, preview a process environment, then separately review a child launch or persistent user-environment change. Inspect recorded recovery in the same tool.	Launch is not a sandbox. Persistent edits require review; undo refuses conflicting current values.
Ports And Processes	Inspect listeners and explicitly selected file owners; filter/page evidence.	No connections, process termination, unlocking, handle closure or firewall edits. Access restrictions and races can make observations incomplete.
WSL And Containers	Explicit passive inspection of host, virtualization, CLI-file and service metadata.	No distribution/container/engine/service starts or daemon connections. Installed metadata does not prove runtime health.

Each window has a custom instrument mark, workflow cues, compact controls and an operation-boundary badge. Readiness uses a project dossier; troubleshooting a log waveform; environments a branching profile; ports an endpoint map; containers a host stack. Dependencies uses its own download/package workspace and Review First badge.

What the tools inspect and configure

• Project Readiness: bounded Rust, .NET, Node and Python declarations/pin files, plus CMake presets, .vsconfig, vcpkg.json, Directory.Build.props and root-level MSBuild project declarations. PATH candidates, embedded Windows version metadata and PE architecture are evidence; tools are not executed to discover versions. Dynamic imports, inherited configuration, wrappers and unsupported constraints can remain unknown. Mixed stacks can require separate profile scans.
• Build Troubleshooting: selected saved UTF-8 or BOM-marked UTF-16 logs, up to 2 MiB. Fixed offline rules group hints for Rust, MSVC/MSBuild, .NET/NuGet, Node/TypeScript, Python, CMake, storage and access failures. Oversized, malformed and unsupported inputs are reported; a hint is not a root-cause guarantee. Reviewed execution is a separate workflow below.
• Environment Profiles: explicit project directory, PATH prefixes and supported developer path variables; bounded JSON import/export, process-only preview/launch, and separately reviewed persistent current-user edits with saved recovery. Profile import does not activate it. Arbitrary secrets, activation scripts and unrestricted environment-variable editing are outside this workflow.
• Ports And Processes: TCP listeners and UDP bound endpoints, port/PID filtering, paged evidence, and owner investigation for an explicitly selected local file. PID reuse, access restrictions and process exits can limit attribution. File-owner inspection does not terminate processes or release locks.
• WSL And Containers: candidate WSL/Docker/Podman/nerdctl executable metadata, conventional service states, virtualization hints and the presence of fixed configuration override names. It does not enumerate guest distributions, run client commands, connect to engines or start services. Custom/non-PATH installations can be missed.

Project Readiness

Build Troubleshooting

Environment Profiles And Recovery

Ports And Processes

WSL And Containers

Developer Dependencies

Open Project Readiness → Dependencies. Choose architecture and a preset, or individual packages. The initial pinned catalog provides .NET SDK 10.0.402, .NET Desktop Runtime 10.0.13 and CMake 4.4.4 for x64 and ARM64. .NET Development selects the SDK without a redundant runtime; CMake configures builds and does not include a compiler/Windows SDK.

1. Review package details: exact version, payload size, official source URL, expected publisher, pinned hash, licensing link and exclusions. Optionally choose a short local library folder.
2. Download Selected explicitly contacts official vendor hosts over OS-validated HTTPS. Size and SHA-256/SHA-512 are checked before atomic publication; Authenticode and signing-certificate organization are checked afterward. Existing cache files are preserved and reverified.
3. Verify Cached Files performs the same local checks without downloading or installing. Signature validation uses cached Windows trust and does not query online revocation status.
4. Offline Bundle exports selected installers to a new directory after licensing review. A bounded manifest is written last. Import accepts only the compiled catalog's IDs and revision, then rechecks every installer. External commands, URLs/digests and arbitrary archive extraction are rejected.
5. Select exactly one cached package and Prepare Exact Install Review. Inspect the held file, hash, publisher, fixed command, elevation request and recovery limits. Acknowledge that exact review before Launch Reviewed Vendor Installer becomes available. Changing inputs clears review. Hash/signature are rechecked and a durable receipt is required before launch.

Vendor installers stay interactive. No silent switches, arbitrary install commands, automatic repair or automatic rollback are supported. Vendors can change PATH, registry, shared runtimes and Program Files, remove earlier vendor versions and require a reboot. Use their UI to configure/cancel installation. Closing SetupScope cannot cancel or undo a vendor installer. Recover through the vendor uninstaller/Installed Apps, considering other projects that use shared components. Exit success is not proof of build readiness; reinspect separately.

Pinned offline bundles exclude workloads, project packages, NuGet restores, MSVC, Windows SDK and transitive prerequisites. MSVC / Windows SDK / CMake / Ninja — Vendor Setup handles native components and vendor-managed offline layouts separately, using an officially downloaded local Microsoft bootstrapper, observed hash, publisher checks and separate launch review. It does not promise pinned or complete air-gapped native toolchains. The full-installer catalog is fixed. Details: Developer Dependencies.

Reviewed Build And Test

Inside Build Troubleshooting, expand Reviewed Build / Test. Choose a project folder, trusted .exe, literal arguments, log folder and timeout. Presets cover Rust, .NET, CMake/CTest and MSBuild. Prepare and acknowledge the review before running. Project inspection never executes commands. Execution inherits your account/environment/network access and is not a sandbox.

Logs stay below 2 MiB, with explicit truncation status. Cancellation/timeout stops the contained tree; remaining descendants stop on root exit. Files, downloads and remote effects cannot be automatically undone. Select the captured log for separate triage. Workflow and limits.

Project workflow

Start with Project Readiness and choose an absolute local project folder. Attach a saved log only if useful. Inspect explicitly, then review partial, unknown or stale evidence before following a next step. Toolchain / PATH includes numeric version metadata comparisons; unsupported constraints remain unknown.

For build failures, choose the saved log in Build Troubleshooting. Use Environment Profiles if the intended project environment differs from the current process; preview first. Follow file-owner or host-prerequisite questions into their dedicated tools. Before sharing diagnostics, preview the exact redacted JSON and save it as a new file. Nothing uploads.

Readiness bounds recognized files to 256 KiB per manifest, 2 MiB total and up to 32 ancestors. Log analysis is bounded and reads selected files only. Inaccessible files, unsupported declarations, cancellations and filesystem races are reported; passive evidence is never promoted to a successful-build claim.

Configuration and accessibility

Settings offers High Contrast and Interface Scale. Window heights fit content on opening and when sections/results change, with normal padding and a monitor-height cap; longer content scrolls. Manual resizing remains available until content changes. Widths are tailored to each tool and controls wrap. Review gates and uncertainty remain explicit. Tab/Shift+Tab navigate controls, Enter/Space activate focused actions and Escape closes transient menus/dialogs. Accessible names, roles, states and tooltips supplement visible instructions. Actual screen-reader and broad DPI acceptance remain environment-limited; see release checks.

Command-line use

Run SetupScope-cli.exe from PowerShell, Windows Terminal or a script. It provides a normal console entry point with stdout, stderr and exit codes. No PATH modification is needed when using its full or relative path. Replace the example project/log paths with your own:

.\SetupScope-cli.exe --help
.\SetupScope-cli.exe system --json
.\SetupScope-cli.exe readiness 'C:\Dev\Example' x64
.\SetupScope-cli.exe triage 'C:\Dev\Logs\build.log'
.\SetupScope-cli.exe ports 8080 - 0
.\SetupScope-cli.exe containers
.\SetupScope-cli.exe dependencies catalog

These examples inspect evidence or list catalog metadata. Explicit download, offline transfer and verification commands are also available. Vendor installation, build/test execution and persistent environment apply/undo display reviews and require interactive confirmation; there is no noninteractive confirmation bypass. Process-only environment overlay launch and native Visual Studio component/layout setup remain GUI workflows.

--json normally returns a schema-1 envelope containing a text report or error; individual findings are not a typed JSON schema. Raw CLI reports can contain paths or selected values. Only the diagnostic bundle workflow applies its documented redaction allowlist. Exit 0 means the command completed, 1 an operational/review/execution failure, and 2 invalid command syntax/count; exit 0 does not certify compatibility or build success. CLI identifiers/help remain English. See full CLI syntax, examples and confirmation rules.

Privacy, storage and recovery

Core diagnostics are local. Dependency downloads and explicit vendor/source links are the only user-initiated network workflows in the current interface; vendors may have their own behavior. No account, tracking, diagnostic upload, credential collection or remote service is required.

With the portable marker beside the executable, saved settings, profiles, logs and receipts live in SetupScopeData there. Without it, data normally lives in %LOCALAPPDATA%\SetupScope. Preserve saved data when replacing the executable. Library Roots can be chosen separately for dependency caches and installation receipts. Reports/receipts can contain local paths and are not encrypted.

Environment changes retain reviewed receipts and conflict-checked undo. Diagnostic export uses an allowlist, excludes raw paths, environment values, secrets and source text, requires exact-preview acknowledgment, and refuses overwrite. Recovery metadata is not a system backup. Dependency installations use vendor recovery, with the limits described above.

To remove the portable application, close its windows and remove its program folder; retain any saved data or offline bundles you need first. SetupScope does not register a service, startup task, shell extension or driver in this release. Removing the toolkit does not uninstall developer dependencies you installed through vendor setup.

Update or uninstall

Package	Update	Remove
Portable ZIP	Close the app and CLI processes, back up SetupScopeData, then replace program files from a verified ZIP while preserving that data folder and any offline bundles.	Retain the data/bundles you need, then delete the portable program files.
Installer	Close the app and CLI processes, then run the verified installer against the existing installer-owned folder. An unrelated nonempty folder or a portable destination is refused.	Use Windows Installed Apps → SetupScope → Uninstall, or its Start Menu uninstaller. Packaged files, shortcuts and Apps registration are removed; saved user data and unknown files remain.

The default installed program location is %LOCALAPPDATA%\Programs\SetupScope; installed data is separate at %LOCALAPPDATA%\SetupScope. Switching package types does not migrate data automatically. Installer repair/retry is not a transactional rollback. For silent deployment, completion behavior, ownership checks and recovery, see installation details.

Troubleshooting

• Cannot open a window: verify Windows 11 x64 and graphics drivers; record the exact startup error. No graphics/clean-machine compatibility beyond the recorded checks is implied.
• Existing instance: selecting an open tool focuses it. A second GUI launch exits after requesting focus for the existing board.
• Missing/corrupt cached installer: inspection blocks use. Preserve the suspect file for investigation or choose a clean library folder; existing files are never silently repaired/replaced.
• Signature/chain unavailable offline: cached Windows trust may be insufficient. Do not bypass the check; validate Windows trust/network policy separately and retry.
• Incomplete bundle: a completed export requires its final manifest. Inspect the folder and select a new destination; no partial directory is declared complete.
• Prepared/pending receipt: installer launch/completion is not confirmed. Check vendor state before retrying. A final exit code still does not establish project readiness.
• Denied/partial observations: some system/process evidence requires permissions or disappears during inspection. Review the partial result rather than assuming an absence.
• Installer refuses a destination: close every GUI/tool window and choose an empty or installer-owned folder; do not install over a portable copy. Keep saved data before changing package type.
• Update/uninstall cannot remove a file: close terminals or other processes using the installation folder, then retry. Unknown files and saved user data are deliberately retained.
• No hints in a build log: rules are bounded textual heuristics; unsupported languages, formats and error variants can be missed. Inspect the original log separately.

Build, tests and packaging

Development uses Rust 1.91+, MSVC C++ build tools and a Windows SDK. The dependency graph is locked; use a current stable Rust toolchain that satisfies it. Packaging also uses PowerShell and Python 3; installer creation requires an explicitly selected local NSIS compiler. Those build tools are not requirements for running the packaged app. Keep Cargo.lock and the documented vendored accessibility patch.

cargo build --example lockholder --locked
cargo test --locked
cargo clippy --all-targets --locked
cargo build --release --locked
.\scripts\package-local.ps1

Cargo uses semantic version 1.0.0; Windows file/product version and --version use 1.0.0.0. Launch without arguments for the board. Use SetupScope-cli.exe for diagnostics, toolchain/PATH/version checks, build-log triage, ports/file owners, passive containers, dependency download/offline bundles, environment previews and reviewed execution/install/apply/undo. Run --help for syntax; retired maintenance commands stay rejected. See Developer CLI for examples, JSON output and confirmation rules.

The package includes checksums, upstream license notices and a CycloneDX Cargo dependency inventory. The inventory covers the resolved Windows x64 graph (including build/dev dependencies), not binary reachability, vulnerabilities or certification of third-party software. Optional developer installers are not redistributed by default. Packaging and notices records the actual checks and environment limits.

Create an installer from a checksum-verified portable ZIP with python scripts/package-installer.py portable.zip path/to/makensis.exe output.exe. The builder omits the portable marker and creates explicit installation/uninstallation file lists. Use scripts/Test-Installer.ps1 in a suitable test account to exercise the lifecycle; it refuses an existing SetupScope installation/shortcut rather than replacing it. See installation/build details, CI and merge policy.

Release verification and limits

The published 1.0.0.0 source revision is 5d6268b. Its final GitHub CI run passed Test & build (Windows), Build (Windows Arm64) and Core tests (Linux). Linux testing checks shared core behavior; it does not establish Linux product support. The Windows ARM64 job establishes compilation, not native runtime acceptance.

Local release evidence records 534 passing tests, an optimized x64 build and Clippy with existing warnings, 18 packaged functional checks, 12 isolated-host checks, and 18 installer lifecycle/safety checks plus 543 installed-payload checksum checks. Published downloads were fetched again and their SHA-256 digests matched the local artifacts. The installer and ZIP use the same locally tested application binaries; the source receipt ties those hashes to the release source.

Clean-VM checks were skipped at the owner's request. The isolated-host harness runs on the existing Windows OS/account with a fresh process profile and reduced PATH; it is not a clean OS or a security sandbox. Native ARM64 runtime, broad Windows/GPU/DPI coverage, actual screen-reader behavior, human native-language certification, interactive installer-page acceptance and real vendor-install/reboot/uninstall acceptance remain unverified. Earlier GUI screenshots predate final wording and persistence-only corrections. Full evidence and limitations: release validation, clean-machine procedure, localization review.

Workflow documentation

Subject	Reference
Connected readiness workflow and evidence freshness	Project Readiness
Official downloads, integrity, offline bundles and reviewed vendor setup	Developer Dependencies
Contained build/test execution, timeouts and captured logs	Build And Test
Saved-log encodings, bounds and heuristic limitations	Build-log triage
Profile format, process environments and recovery	Project Environments
Listener and selected-file owner evidence	Ports And Locks
Passive WSL/container metadata and exclusions	WSL And Containers
Exact-preview redacted JSON export	Diagnostic Bundles
Console syntax, structured envelopes and confirmation	Developer CLI
Package locations, update/uninstall and installer build	Installation

Support, security and license

Report a minimal reproduction through the project issue tracker. Redact secrets and private paths. For sensitive findings, use GitHub's private vulnerability reporting if enabled; otherwise request a private contact channel before sharing exploit details or personal data.

SetupScope code is MIT licensed; see LICENSE. Bundled components, fonts and notices retain their upstream terms. The desktop child-window accessibility change is documented in GUI dependency patch. Brand artwork is in Brand Assets.

The portable folder includes Test-CleanMachine.ps1 for integrity and isolated process-environment smoke tests without SDKs, installs or network access. Its name describes the intended procedure, not a claim that clean-Windows acceptance was completed.