PyCForge 1.3.70 and PyCForge SDK 0.6.2
Crucible-owned workbench, Help and automatic SDK startup
Work date: 2026-10-30. Unpublished development handoff; CC alone publishes.

IMPLEMENTED CONTRACT

The installed pycforge/crucible/landscape directory owns the SDK's versioned
workbench definition, JSON schema, SDK guide and bundled conversion-import
manuals. Existing index.json, api.xml and authoring.json remain authoritative.
The index inventories every resource by size and SHA256. workbench.json declares
authoring profiles, fields, operation choices, default imports and Help topics.
Import metadata and manuals derive from the engine's admitted bundled packages;
form explanations and operation choices derive from its authoring reference.

The independent SDK renders this data and uses the existing public engine
workflow. No converter, library-name dispatch or downloaded executable UI enters
the SDK. CLI workbench and SDK.workbench() expose the same forms and documents
for human and AI clients. F1 shows the connected engine guide and import Help,
with an explicit engine/version or offline label and a 28-pixel scrollbar.
Minimal first-run and recovery guidance remains local to the SDK.

Contract pycforge.sdk-workbench/1.MINOR permits compatible additive profiles,
fields, choices, imports and Help. Unknown optional metadata is ignored. Unknown
major versions, required features or control types are rejected before cache
replacement. The last compatible snapshot remains available offline; cached
reference never authorizes execution. Existing engines without workbench.json
retain a clearly identified legacy path. SDK 0.6.1 still connects to 1.3.70,
lists all five starters, creates and inspects a project.

This design makes ordinary compatible engine expansion independent of SDK
releases. It does not promise that an unchanged client can understand arbitrary
future protocols, incompatible semantics or new required widget types. Resource
budgets remain explicit. See the workbench 1.0 specification for precise bounds.
This revision adds no conversion operations or new production default libraries:
the defaults remain math 0.3.0 and bounded NumPy 0.2.0.

STARTUP AND PRESENTATION

The desktop opens a custom-titlebar startup panel with the original code-bracket
and copper-slash mark, copper SDK accents and one progress bar. It validates the
last successful engine first, then known Python/environment locations. One valid
installation connects automatically; multiple distinct installs offer a choice.
Only a live successful connection updates the remembered interpreter.

Recovery offers Locate PyCForge, Search again and Continue offline. Custom drive,
Home, Up and Go navigation accepts an interpreter, environment or installed
support folder. A selected support folder must match the live engine catalogue;
an unrelated nearby interpreter is not accepted. Source-only folders require a
working installed engine. Filesystem browsing executes no candidate.

Discovery is shared by desktop, CLI and Python. It is bounded (48 candidates,
3 seconds per probe, 20 seconds per search by default), cancellable and does not
replace the cache. Common paths include active environments, absolute PATH,
Windows registry/user installs, pyenv/pipx/Conda and macOS roots. Whole drives are
not recursively searched. Unresponsive filesystem operations are outside the
subprocess time budget. Windows descendant-process termination retains the
existing documented limitation.

An isolated launch helper permits a selected interpreter's ordinary per-user
site-packages without executing user .pth files or importing from the working
directory/PYTHONPATH. Isolated virtual environments do not inherit user packages.
Custom launch arguments and editable user installs requiring .pth execution are
outside this route. No installation or publication occurs during discovery.

The workspace uses a copper connection card and collapsed advanced settings.
The original icon is present on the application, main window and dialogs. The
521 copied PyCForge presentation resources retain their original byte hashes.
The scanner scrolls at small window sizes; action and status meanings remain
unchanged. The GUI worker starts through a queued connection after its QThread
event loop begins, retains wrappers through cleanup and manages cyclic GC on
the GUI thread while workers are active. Normal reference counting stays active.

COMPLETED QUALIFICATION

* Complete installed SDK headless suite: 120 passed, no failures or skips, in
  three disjoint groups (22 conversion-contract, 54 workflow/editing/documentation,
  44 discovery/boundary/workbench/engine-upgrade tests). All 11 test modules are
  included. The headless environment has no Qt, NumPy or PyCForge installed.
* Complete installed desktop suite: 27 passed, including actual engine workflows,
  generic unknown-profile fields, all engine Help topics, startup choice/recovery,
  cancellation/close and 50 consecutive fast failure/offline window lifetimes.
* Engine catalogue/workbench/distribution tests: 34 passed and 14 subtests;
  the strengthened distribution verifier was rechecked with 11 passed and 14
  subtests. These 11 overlap the 34 and are not additional unique coverage.
* Every loaded product module in these suites originated in its installed
  environment. Engine, headless SDK and Qt SDK are separately installed. Final
  runtime freeze compares all 956 engine and 552 SDK payload files byte-for-byte
  against their tested wheels, installed packages and maintained source.
* A real synthetic engine-only upgrade adds a public method, declaration profile,
  form field, starter, default import and Help. The unchanged SDK creates,
  verifies, packages and registers that independent namespace.
  A separate engine without the SDK converts it to C; GCC execution prints 3.5.
  An incompatible workbench major is then refused without changing the cache.
  All SDK runtime file hashes are unchanged throughout. The synthetic engine
  and its third default are test fixtures only, never release contents.
* Native documentation verification passes: 31 Help pages, five categories,
  81 Python examples, 49 runtime and 32 typed native comparisons, five API
  examples, four C callers, three module examples and three README examples.
* Actual GUI entrypoint smoke passes both automatic discovery without an explicit
  engine argument and automatic opening through --project. Application icon,
  startup visibility and the selected interpreter are checked.
* Rendered startup, connected workspace, editor, engine guide, NumPy Help,
  multiple-installation choice, recovery, custom picker and offline screens pass
  at 1x and 1.5x scaling, with 1320x860, 1024x720 and 920x640 logical workspaces.
  Enlarged-font minimum-size scrolling is checked. Copper text contrast is
  9.449:1 for the checked foreground/background. Shared application QSS is intact.

ATTEMPTS, CORRECTIONS AND LIMITS

Earlier fast worker runs stalled; one diagnostic process crashed. The first GC
guard alone did not resolve all stalls. Explicit queued worker startup plus GUI
thread GC/lifetime handling passes the final repeated and complete GUI checks.
Historical diagnostic logs remain preserved, including unsuccessful attempts.

An initial headless run passed 109/110 with the old-engine fixture environment
omitted. The final runs set both historical engine paths explicitly. An initial
engine schema test needed the development-only jsonschema dependency; the final
engine suite passes after installing it. No product dependency was added.
One discovery test used an unrealistically short probe under concurrent native
load; it now uses the normal three-second budget. A support-folder rejection
assertion now checks the actual mismatch among all tried candidates.

One combined final headless session ended with partial dots and no completion
record. Another was intentionally interrupted to split the long suite. Neither
is counted as a pass; the final three disjoint groups above supply the complete
result. One visual run missed its two-installation assertion under load without
recording its reason. A direct check found both engines, and full normal/scaled
runs passed with diagnostic output retained; its exact original cause is not
established. A verifier-only invocation lacked the source tools import path;
the corrected run imported the engine from site-packages and tools from source.

Qualification is on Linux, Python 3.12.14, PySide6/Qt 6.12.0 and GCC's existing
GNU-style native profile. Windows registry paths are simulated; native Windows
and macOS desktop/compiler qualification is not claimed. Existing finite array,
resource and general extension-API limits remain. No full-library NumPy claim,
new compiler integration, source overwrite, PyPI upload or GitHub hosting occurs.

PRESERVATION AND DELIVERY

The 4,076 engine and 908 SDK baseline source members are retained. Existing
historical evidence remains in both source trees. New evidence is stored under
evidence/workbench_discovery_2026_10_30. Engine README changes only its version
heading; its four approved images are retained. SDK README uses the same approved
banner and product prose, with the corresponding plain-text guideline updated.
Detailed development information remains in this engineering record.

The final paired wheel/source checks, exact archive hashes, strict metadata
checks and rebuild-from-sdist result are recorded in the external
PyCForge-1.3.70-SDK-0.6.2-Verification.txt report. This source record intentionally
does not embed hashes of an archive containing itself.
