stay-up is a small Windows keep-awake helper. It asks Windows to keep the
system and display awake while the helper runs. It needs no installer,
administrator access or third-party Python packages. The dashboard also needs
Python and the documented Rust toolchain.
Run the Rust application from PowerShell in D:\Apps\stay-up:
python .\launch.pyFor a timed test, add --seconds N:
python .\launch.py --seconds 3The launcher checks the documented Rust paths and active toolchain. It builds to %LOCALAPPDATA%\Rust\target\stay-up. It starts only
the Rust executable. Its JSON result gives the status, process ID, executable
path, and window handle.
The application starts scripts/keep-awake.py and scripts/monitor-helper.py. Its window
shows their process IDs, output, the shared heartbeat log, and input idle time.
Use the Split slider to size the panes. Use Stop to end all three processes.
The X button minimizes the window.
If a stable-path instance already runs, the launcher reports it and does not
apply new arguments. Use Stop before you start a new timed test. The launcher
checks only the Rust process and its owned StayWatchStatusWindow.
An agent needs permission to write to the stable output path. If the sandbox denies access, authorize the same launch command. Do not change access-control lists or select a different output directory.
Run the helper by itself when you do not need the dashboard:
python .\scripts\keep-awake.py
python .\scripts\keep-awake.py --seconds 7200Press Ctrl+C to stop the helper and release its power requests.
- The helper requests
SYSTEMandDISPLAYavailability. - It does not change the registry, power plan, lock settings, or startup settings.
- It does not simulate keyboard, mouse, or touch input.
- Input in the current session resets the idle timer.
- The monitor records process liveness about once each minute.
- The heartbeat does not prove the state of each Windows power request.
- The heartbeat does not record lock, display, sleep, idle, image, or video data.
- A final
STOPPEDrecord is not guaranteed after the Rust Stop action.
Windows accepted both power requests during the recorded tests. A short helper run used about 18 MiB of memory. Device policy can still limit the result. The pending idle, sleep, and lock checks are in the observation log.
The visual refresh preserves the accepted native output panes from commit
fed8eb5. Screenshot logging and capture tests are outside the current scope.
See the visual plan and
baseline contract.
The uploaded issue media records the problem that shaped this project. It shows the helper beside the Rust window, terminal windows, idle timers, and one Windows sign-in screen. The media shows context only. It does not prove that the helper prevented lock or sleep.
The first plan proposed a passive Rust observer. It would measure input idle time, display state, session state, power state, and helper-process life. It would not make power requests, simulate input, or change Windows settings. A state gap would end a confirmed interval.
The current app uses a Python root launcher, a Rust dashboard, and two Python helpers. The Rust window shows status, helper output, the shared heartbeat log, and input idle time. It owns shutdown and keeps the output panes read-only. Screenshot and capture logging from the first plan are withdrawn.
The images and videos remain linked to their original GitHub uploads. See the media record for descriptions and limits.
- Issue #6 video 1, about 20 seconds
- Issue #6 video 2, about 8 seconds
- Issue #7 video 1, about 9 seconds
- Issue #7 video 2, about 8 seconds
The images and videos are user-submitted evidence. They are not controlled test results. Video playback and audio were not reviewed in this repository.
The repository includes the user-submitted issue media by design. It may show desktop, account, or sign-in context. The local dashboard preview is a separate repository asset.
The application does not read names, emails, credentials, account files, or network data. It uses Windows power APIs, process IDs, window handles, idle ticks, timestamps, and local log files.
The launcher requires the checkout at D:\Apps\stay-up. It also requires
%LOCALAPPDATA% and the documented Rust environment variables. These values
are machine configuration, not personal identity data.
The launcher reports an absolute executable path in its JSON result. On Windows, that path can contain the account name from the profile path. The path is diagnostic output and is not an input to the application.
The optional probes in scripts/ can inspect device names or window content.
They are not part of the application launch path.
Read the Rust environment procedure before you install, move, or troubleshoot Rust. Installation and version output do not prove that the environment can build and run this project.
The repeatable probe is in scripts/rust-install-check/. Record new machine
results in docs/observations.md. Documentation-only
changes do not require a new machine test.
| Document | Purpose |
|---|---|
| Repository layout | Current directory purposes and naming rules |
| Visual refresh plan | Current presentation scope and limits |
| Native output panes | Accepted working baseline |
| Observation log | Dated machine and application results |
| Feasibility record | Historical probes and remaining unknowns |
| Observer proposal | Historical observer design |
| Acceptance vectors | Unexecuted historical checks |
| Research record | Source provenance and earlier investigation |
| Rust migration review | Proposed Rust migration, TypeSafe matrix, gates, and staged decisions |
| Rust migration plan | Ordered Rust ports, tool decisions, first build, and acceptance checks |
The PowerToys source snapshot keeps its MIT license and third-party notices. This repository is independent of Microsoft. It is not an official PowerToys distribution.