PyCForge SDK 0.6.0 — scanner-led PySide6 desktop
Work date: 2026-10-29 (America/Chicago)
Engine baseline: unchanged PyCForge 1.3.67
Unpublished development handoff. Only CC publishes releases.

DELIVERED BEHAVIOR

The optional desktop, Python API and console use one SDK backend. The headless
SDK remains dependency-free and imports neither Qt, NumPy nor PyCForge. The
GUI extra installs PySide6; the selected PyCForge interpreter runs separately.
No compiler or conversion semantics were copied into the SDK.

The desktop uses PyCForge's exact 1.3.67 palette, stylesheets, icon assets,
window controls and dialog chrome. All 520 preserved presentation files have
byte hashes in docs/visual-provenance.json. The desktop has Scanner, Edit
extension, Engine reference and Activity. The editor has Project, Functions,
Help and Fixtures pages. The array form has four authored fields; its operation
choices, signatures and explanations come from the selected engine. Scalar
advanced settings are collapsed by default. F1 opens searchable offline Help.

Scan is the central packaging gate. It distinguishes needs-authoring,
ready-to-verify, needs-verification, unavailable/canceled and ready-to-package.
It checks saved inputs, the connected engine, supported declaration, complete
Help, native example links, required fixture kinds, passing results, export and
Help-example coverage, and exact project/SDK/engine/compiler/host identity.
After matching evidence it also asks the engine to validate its archive in
memory, including metadata rules. Scan writes no package, compiles no fixture
and runs no fixture. It may query the compiler version to identify it.

Only Ready to package is successful approval. Build repeats the shared evidence
gate and uses the same engine packaging service. Invalid dates, control text
or oversized metadata cannot receive a green readiness result. Failed native
cases include actionable findings and expected/actual detail. Field findings
open the relevant editor. Registration is a separate explicit action.

Readiness certifies this saved snapshot for its explicit fixtures and recorded
environment. It is unsigned local evidence, not a proof of every input, branch,
platform or security property. The author remains responsible for reference
expectations and prose. Source-call coverage does not prove every call executes.

RESPONSIVENESS AND RECOVERY

One QObject worker in a QThread serializes SDK work. Engine and native CPU work
runs in supervised subprocesses. Queued signals update GUI widgets. Cancellation
uses the existing Event/deadline/output-budget supervisor. POSIX cancellation
stops the process group. Closing requests cancellation and waits asynchronously.
Native thread cleanup is confirmed with nonblocking joins before Python worker
wrappers are released. No worker thread is forcibly terminated.

Edits and selection changes immediately clear approval. Worker results must
match both the UI revision and loaded project hash. External file/evidence
changes clear readiness; project conflicts require reload. Atomic one-file
saves reject conflicting changes and preserve original inputs. Source saves are
separate from project.json saves. Read-only draft validation never runs code.
New fixture files can be created externally and referenced in advanced project
data; this first desktop does not yet provide a full fixture-file creation UI.
Offline reference is labeled and cannot approve execution or packaging. An old
engine without authoring capability cannot enable authoring actions.

VERIFICATION OF FINAL INSTALLED CODE

* Complete headless suite: 92 passed, zero failures, zero skips, in a fresh
  SDK environment with no Qt, NumPy or PyCForge installed.
* Desktop suite: 13 passed, zero failures, zero skips, in a separate fresh GUI
  environment with PySide6 but no PyCForge or NumPy installed. Tests exercise
  actual worker-backed scan/verify/package, timer responsiveness, editable
  Help and source, field navigation, late-result rejection, outside changes,
  cancellation/close during real work, offline reference, unavailable old-engine
  actions, searchable Help, dialog chrome and 30 rapid worker lifetimes.
* Every imported product module in each suite is checked to originate from its
  installed wheel. The engine is the existing separately installed 1.3.67 wheel.
* Final installed desktop qualification creates NumPy and independent vector
  projects. Each passes all 21 cases: 13 native programs and eight expected
  conversion rejections. Each reaches Ready to package, builds identical bytes
  twice and explicitly registers into an isolated test registry. NumPy Help
  editing, scan finding navigation and re-verification also pass.
* The final all-worker desktop harness recorded 17348
  event-loop heartbeats; its largest observed gap was
  0.179 seconds on this host. This is a measured fixture,
  not a latency guarantee for every host/project. The GUI test separately checks
  sub-second heartbeat gaps during its real scan/verify flow.
* Negative gates cover missing/failed/canceled/stale/malformed evidence, SDK and
  compiler changes, missing fixture kinds/coverage, documentation fields, outside
  save conflicts, source/path budgets and package-envelope metadata failures.
  Existing successful packages and original source inputs are preserved.
* Existing math/scalar/array workflows, independent namespaces, deterministic
  packages, legacy engine migration/refusal and compatible engine additions are
  retained by the full backend suite. Existing scan/0.1 behavior stays compatible;
  readiness/0.1 is a distinct public result. Console/Python readiness agree.
* Native qualification uses GCC 13.3.0 and the selected engine's existing Linux
  GNU-style C11/UBSan profile. Python 3.12.14 and PySide6/Qt 6.12.0 were used.
  Desktop visuals were reviewed at 1320x860 and 1024x720 logical pixels, including
  starters, scanner states, four-field array editing, Help and engine reference.

ATTEMPTS AND CORRECTIONS

The initial source regression run passed 66/68; two legacy gates lacked the
explicit historical-engine environment setting. Both pass with the actual
1.3.61 interpreter selected. No test was skipped or weakened. Initial new
readiness/editing suites passed 19 and then 20 checks as coverage expanded.
An initial Qt run exposed a worker-cleanup race (native bus error). Holding
wrappers through a nonblocking join fixes it; the complete flow and repeated
lifetimes pass afterward, including the final installed suite.

One subsequent installed GUI run was interrupted after ten completed tests
because it stopped making visible progress. That incomplete run is retained
as qualified-gui.log and is not counted as a pass. Its cause was not established.
The isolated 30-operation lifetime check then passed; a full diagnostic rerun
passed all 13 tests, followed by the final confirmation run reported above.
The diagnostic timer printed a 45-second stack during a still-running native
workflow, which subsequently passed. No test deadline or assertion was removed.

Review also identified a readiness gap: successful native fixtures alone did
not establish that package metadata obeyed the engine's archive rules. The
final scanner now checks that envelope in memory. Rejection fixtures for invalid
creation dates, multiline metadata and oversized author text pass, as does the
ordinary deterministic package flow. Development logs retain these attempts.

The first visual harness included synchronous headless comparison calls on its
own main thread, so its global maximum heartbeat gap is not a desktop-worker
measurement. The later installed and final harnesses run all service work
through the desktop worker; the final measurement above is the relevant one.
Offscreen Qt reports its expected propagateSizeHints limitation. No native
Windows/macOS desktop session, Windows native fixtures, Windows descendant
termination, independent human usability study or general-resource/plugin API
qualification is claimed. Those remain future gates.

PRESERVATION, INSTALLATION AND NEXT DIRECTION

All 201 file paths from the SDK 0.5.0 source archive are retained. Framework 0.5
and earlier directives, requirements, examples, tests and prior evidence remain.
New framework 0.6 records the UI/service boundary, scanner contract and user
PCFC11 decision. Archive/RECORD/README/payload/rebuild checks and final hashes are
appended to the external handoff report after assembling the distributions.

Install the desktop extra in the SDK environment:
  python -m pip install "./pycforge_sdk-0.6.0-py3-none-any.whl[gui]"
Launch:
  pycforge-sdk-ui --engine-python /path/to/PyCForge/python
Or:
  python -m pycforge_sdk.gui --engine-python /path/to/PyCForge/python
For headless use, install the wheel without [gui].

Finish PCFC11 improvements before its dedicated PyCForge integration. It may
continue to be used externally for conversion-import verification. The future
PyCForge integration has its own Compile button beside Transpile, outside the
compiler chooser, and separate Linux/Windows installer builds. No compiler
bundling, compiler controls or installer changes were made in this SDK task.

The next useful UI gate is an independent author using a starter to explain,
repair, verify and package an extension, with observed usability feedback. Keep
new controls driven by real author needs and the same public SDK service.
Only CC publishes; no PyPI, GitHub or other public release action was performed.
