Build conversion extensions through the same backend used by the Python API and console.
The copper connection panel identifies the live engine and its reference. Refresh reloads compatible capabilities after updating PyCForge. Engine and tools contains the interpreter, Find installed, This Python and the compiler used for explicit native verification. The SDK and engine may use separate environments. PyCForge’s About → Distribution → SDK Python shows its exact interpreter. Windows environments normally use Scripts/python.exe; Linux/macOS uses bin/python. A wheel or installer is not a running environment.
Discovery checks known locations without scanning drives: the SDK’s Python, active environments, Python directories on PATH, registered Windows Python installations, common virtual environments, Conda environments and pipx installations. Unusual locations may need Locate. Searches have time and candidate limits; Activity records checked candidates and failures. An explicit --engine-python selection is checked without silently substituting another installation. A failed selection does not replace the last working connection.
Command-line clients can use pycforge-sdk --json discover, optionally with --location. Python and AI clients use pycforge_sdk.discover_engines() for the same result. SDK.connect(offline=True) reads cached reference without probing an interpreter. Discovery checks live support files and compatible interfaces; cache data alone cannot authorize execution.
This guide, the bundled conversion-import manuals, authoring fields, operation choices and starter projects are supplied by the selected PyCForge installation. Use the Help topic selector to read each bundled import’s exact conversion coverage. Updating PyCForge and refreshing the SDK replaces this information together.
The installed Crucible landscape contains index.json, api.xml, authoring.json, workbench.json, workbench.schema.json and the listed HTML guides. The manifest binds every resource by size and hash. The workbench contract describes authoring forms and Help without executable UI plugins or a fixed list of library names. The engine remains responsible for conversion semantics and validation. Compatible additions use the same SDK; a new required contract feature or incompatible major version requires an explicit SDK update.
Needs attention: authoring fields, Help or required fixtures need correction.
Ready to verify: authoring checks pass, but native results have not been established.
Verification needed: evidence is missing, failed, incomplete, canceled or no longer matches the project or environment.
Ready to package: every required fixture passes, every export and its linked Help example is covered, and exact project, SDK, engine, compiler and host identities match.
Scan never compiles or executes fixture programs. When checking existing evidence, it runs the compiler's version command to confirm identity. After matching evidence, the engine validates the archive in memory, including metadata; Scan writes no package file. Build repeats the same evidence gate before replacing output.
Readiness is an unsigned, local workflow result for these explicit fixtures. Source-call coverage does not prove every branch ran or every input is correct. Authors remain responsible for expected results and explanations.
The array form has four fields: stable identity, editor name, operation and summary. The engine supplies signatures, types, storage and cleanup. Read the displayed operation contract before choosing it. Scalar details are in More contract settings.
Help needs an overview, usage, limitations, release notes, parameter meanings, return meaning, details and a native example for every function. Every constant needs an explanation. Tools → Add missing Help fields preserves existing prose and adds blank fields for you to complete.
Fixtures records exact expected stdout, stderr and exit code, or an expected conversion diagnostic. Save project edits before opening Edit fixture source. Source saves are separate atomic changes. Advanced project data edits the full JSON document; create new fixture files in the project before referencing them there.
Changing project fields, Help, source or expectations clears readiness. Save, scan and verify again. Changing engine or compiler clears approval. Outside file changes require Reload from disk; conflicting saves preserve existing files. Results arriving after editor changes cannot approve newer edits.
A failed refresh preserves valid cached reference with an OFFLINE label. It cannot approve conversion, verification, packaging or registration. Viewing starters or method examples never executes them.
Activity contains diagnostics. Fixture results shows each comparison; activate a fixture for expected and actual details. Evidence shows identities, coverage and scope. Failed builds preserve existing packages. Starting verification retires the prior passing report even if canceled.
Closing during work requests cancellation and stays responsive until the worker stops. Process supervision enforces deadlines and output limits. POSIX cancellation stops the process group. Windows direct-process termination remains the inherited limitation; Windows descendant-process qualification is not claimed.
Native verification currently uses the selected engine's GNU-style compiler profile on Linux. This desktop does not add Windows native qualification or new compiler flags. Choose a compatible external compiler. This engine provides scalar profiles and bounded one-dimensional finite float64 arrays. General broadcasting, views, other dtypes, external buffers and arbitrary native dependencies remain unsupported. Read the engine reference and extension Help for exact coverage.
In PyCForge, register the conversion package, confirm Ready and select Runtime to use its *import. Packaging and registration do not publish releases. Only CC publishes.
Ctrl+N: New; Ctrl+O: Open; Ctrl+S: Save; F5: Scan; F6: Verify fixtures; Ctrl+B: Package; F1: Help. Standard Tab navigation, menu mnemonics and window controls are available.