PyCForge resource reliability — Windows acceptance

Choose the branch matching your installation. For the PCFC11 line:

  py -m pip install --upgrade .\pycforge-1.2.2-py3-none-any.whl
  py -m pycforge.ide

The separate runtime-conversion line uses pycforge-1.1.12-py3-none-any.whl.
Save files and close all PyCForge windows before upgrading. These wheels have
not been published to PyPI; installing by the downloaded filename selects the
intended build. Do not mix both branches in one Python environment.

Confirm the title bar and Help > About show the installed version. About must
have no Ting Shadow / Advisory badge. Preserve any PowerShell traceback and
include Python/PySide6 versions when reporting an issue:

  py -c "import sys,PySide6,pycforge; print(sys.version); print(PySide6.__version__); print(pycforge.__version__)"

REPEATABLE WORKLOAD

1. Start with no files open. Allow two minutes for startup, previews and any
   previous conversion work to settle. In Task Manager's Details view identify
   the PyCForge Python process. Record PID, memory/working set, CPU time, Threads
   and Handles. Record any child Python/compiler processes separately.
2. Open/close About 20 times. Open and cancel the custom Open Module dialog 20
   times and Save As 20 times. Record the same counters. Repeat the wave.
   Closed file dialogs must not add a permanent thread/handle per interaction.
   Warm caches may raise the first memory reading; later comparable waves should
   settle instead of continually climbing by the same amount.
3. Open a module, transpile it, close the final module with Generated C visible,
   and open a different module. Repeat 20 times, alternating valid conversions
   and a syntactically valid unsupported construct. Check Source Bundle, new/open
   actions and both source gutters. No stale module row or traceback should remain.
4. Edit a larger saved module, switch tabs, search, cancel a conversion and convert
   again. Repeat cancellation and immediate application close/reopen. Obsolete
   results must not replace current source/output, and conversion workers should
   disappear after cancellation or exit. In the runtime branch also try completion,
   formatting, symbol navigation and closing while an editor request is active.
5. For PCFC11: open/close the build dialog repeatedly, then leave it hidden for
   two minutes. Browse compiler/output paths, cancel a build, edit while building,
   and close the application during a build. With the actual compiler installed,
   check that compiler and assembler/linker descendants do not survive cancel/exit.
6. Run a normal editing/conversion workload for 30–60 minutes. Capture counters
   every five minutes and after closing all modules. Include sleep/wake once and
   confirm edits, folding, conversion and close/reopen still work afterward.

BATTERY COMPARISON

Compare the previous and fixed build on the same laptop with the same brightness,
power mode, refresh rate, peripherals and background applications. Let startup
finish before an equal-duration idle measurement. Repeat an equal editing workload
and an equal conversion workload separately. Record elapsed time and battery
energy/charge change if the device exposes it. Repeat the runs and alternate the
order; a small charge-percentage difference from one short test is inconclusive.
Memory footprint, CPU time, thread counts and wakeups are useful diagnostics but
are not direct battery-life measurements. Conversion intentionally uses CPU while
working. Closing/minimizing dialogs should not leave their timers doing idle work.

REPORTING

Record exact version, sequence, sample times, process counters, whether PCFC11 was
running, and any traceback. State whether growth continues after equivalent later
waves. Do not include private source unless you choose to share a minimal example.
Native Windows and battery acceptance were not executed in the Linux build host.
