PyCForge 1.3.65 — conversion-import startup and recovery
Qualification host: Linux x86_64, Python 3.12.14, GCC 13.3.0, Qt offscreen
Release preparation: 2026-10-29 UTC

Delivered behavior
------------------
The existing splash retains one progress bar. Conversion imports have their
own stage and a detail line showing processed, ready and unavailable counts.
A damaged, missing, incompatible or stalled optional conversion import leaves
the core workspace usable in the qualified failure scenarios. The Startup
report explains the issue and opens Register Conversion Imports for recovery.
Required core resource/dependency failures still stop startup.

A disposable host worker performs package admission, selected-package Help
and explicit registration operations. It reads data only; it does not execute
author Python, author native code, examples or SDK verification tests.
Worker bootstrap is bounded to five seconds, subsequent package operations
to two seconds, and each complete admission scan to fifteen seconds, plus
bounded cleanup. The supervisor handles blocked/partial transport, crashes,
malformed replies, cancellation and a process that cannot be reclaimed.

Startup and Refresh never rewrite the registration index or author files.
Failed keys are unavailable for the IDE session in conversion and completion.
Healthy selections still undergo fresh integrity admission; the startup
report is not a frozen catalogue or a substitute for runtime validation.
Refresh can restore repaired packages and retires assistance workers carrying
old policy. The registration dialog stays responsive and rejects stale Help
identities. Failed imports can be disabled without deleting their records.

A corrupt index is preserved and shown as a registration problem. Mutation
controls remain read-only until repair and Refresh. Safe start skips that
index and checks bundled math only. A timed-out explicit mutation may already
have committed atomically: results are invalidated and the dialog rescans;
timeout does not claim to roll back an operation or a partial folder batch.

Verification completed before distribution assembly
----------------------------------------------------
1. Selected source regressions: 414 tests and 99 subtests passed. A final
   recovery follow-up passed 59 tests. These overlap: their union is 418
   distinct source test nodes, not 473. The full engine suite was not rerun.
2. Installed-wheel external tests: 97 passed, using isolated Python outside
   the maintained source tree. These overlap the source suite and are not
   additional distinct product test cases.
3. Full application launches passed in six scenarios: normal, damaged
   package, corrupt index, safe start, worker timeout and worker crash.
   Repeated against the installed wheel; origins were asserted. Checked the
   single progress bar, actual workspace/report, conversion diagnostics and
   unavailable-import completion behavior. Separate tests cover recovery,
   cancellation/reaping, dialog destruction and idle-worker invalidation.
4. Separate installed SDK 0.3.0 completed 17 checks against installed engine
   1.3.65. The engine environment has no SDK; the SDK environment has no
   engine or Qt. Independently named wave_ops was created, scanned, verified,
   built deterministically and registered through the public service.
   Changed documentation refused stale evidence without replacing output;
   missing Help was refused while preserving an existing usable import.
5. SDK-generated math passed all 48 fixtures: 40 native executions and eight
   expected conversion rejections. Repeated verified builds were identical.
   SDK-built and bundled conversion/documentation members were byte-identical.
   This qualification package is evidence, not a replacement math release.
6. Independent custom generated C passed GCC with undefined-behavior sanitizer
   and the established warning profile: -Wall -Wextra -Werror with existing
   -Wno-unused-function, -Wno-unused-variable and -Wno-misleading-indentation
   exclusions. This is not a claim of an unsuppressed warning-clean runtime.
7. Offline Help verification passed: 31 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.
8. README rendering passed with exactly four approved images and the
   approved 320/640 banner widths. Only its top version changed from 1.3.64.
   Installed metadata, Qt application/workspace/startup/About versions and
   all Help footers agree on 1.3.65. SDK catalogue consistency passed.
9. In-memory compilation passed for 356 package, 81 tool and 267 test Python
   files; all 819 then-present JSON files parsed. Historical evidence and
   extension-language source fixtures are retained verbatim, not treated as
   ordinary Python modules. Of 3,787 maintained baseline files, 3,764 were
   unchanged, 23 intentionally changed and none were missing. Generated root
   packaging metadata is excluded from that preservation comparison.
10. Two fresh-worker timing runs admitted 64 documented synthetic packages
    plus bundled math in 2.597 and 2.519 seconds. Each synthetic package had
    128 functions and 128 constants; custom bytes totaled 32,921,038. This
    is a startup workload measurement, not native qualification or a timing
    guarantee on other machines. The Qt responsiveness tests also passed.

Attempt history and evidence
----------------------------
Evidence, logs, JUnit, installed-origin results, native SDK results and the
qualification script are included under evidence/import_startup_1_3_65.
Early full-launch probes failed because the harness edited an empty workspace
and later raced editing/shutdown. The harness was corrected to create a
document, sequence requests and drain workers. Both final source and installed
launch matrices passed; the failed attempts are retained for traceability.
An initial benchmark script had a copy-delimiter SyntaxError; it was fixed
before measurement and is covered by the maintained-source compilation audit.
An overbroad compile sweep encountered two older *import-language fixtures;
those valid transpiler inputs were retained and excluded from Python compile.

Scope and next progression
--------------------------
Math remains 0.2.1: 35 functions and five constants. SDK remains 0.3.0.
No numerical lowering, native template, public authoring schema or semantic
profile was changed. The engine-owned reference identifies engine 1.3.65.
The public SDK framework is still provisional. Qualification is finite fixture
evidence on this Linux/GCC host, not proof of all inputs, Windows qualification
or a security certificate. Local SDK evidence remains unsigned.

The next coverage priority is reusable optional/named argument contracts,
exercised by optional-base log and tolerance-bearing isclose with the SDK,
completion, diagnostics, Help and independent extension authorship together.
NumPy follows explicit shape/dtype/ownership/lifetime/aliasing and error
contracts. No new math function or NumPy support is claimed in this release.
See specifications/conversion_import_startup_1_3_65.md and the retained
PyCForge-SDK-Framework-0.3.md directive.

Distribution handoff
--------------------
This in-source report precedes archive assembly to avoid self-referential
hashes. The accompanying final verification report adds final artifact byte
sizes and SHA256 hashes, strict Twine/public-distribution results, rebuild
equivalence and installed payload identity. Only CC publishes to PyPI;
nothing was published from this environment.
