# PyCForge coordinated development roadmap

Revision 1.12 — 2026-11-04 (America/Chicago). Development baseline: PyCForge 1.3.88.

This increment carries forward the public API priority in revision 1.11.
The capability audit and first bounded addition are implemented: public Unicode
text authoring, discoverable through the unchanged SDK 0.6.4. PCFC11 remains
0.2.34. Final release verification is recorded separately; historical 1.3.87
records retain their original evidence and scope.

This is the standing development plan for CC's three agendas: PCFC11,
Crucible, and the default conversion imports. The SDK participates whenever
engine contracts or authoring needs change. The primary goal is an open, reliable Crucible Python-to-C engine whose actual
capabilities a human or automated SDK client can discover, use and verify.
PCFC11 must compile its generated C correctly under the advertised profile.

This roadmap governs new work alongside AGENTS.md and the README guidelines.
It replaces the older separate UI/conversion sequences and the blanket pause
on import expansion. Memory correctness remains a gate for every capability.
The detailed sequence below is the working plan established from CC's stated
direction; future user instructions can reprioritize it. Stages express
dependencies, not promised dates, release numbers or completed capabilities.

## Responsibilities and common direction

| Agenda | Responsibility | How progress benefits the whole product |
| --- | --- | --- |
| PCFC11 | C language correctness, diagnostics, ABI, code generation, compiler resource limits and optimization | Compile both general C and fresh Crucible output correctly; give actionable failures and predictable build behavior. |
| Crucible | Supported Python semantics, Typed and Runtime lowering, ownership, errors, source provenance and reusable operation contracts | Make each admitted construct correct and composable, with explicit rejection outside its supported domain. |
| Default *imports | Useful, documented conversion packages built on Crucible contracts | Exercise shared capabilities through math, NumPy and JSON; expand coverage without separate semantic implementations for each library. |
| SDK support | Discover, author, verify, package and register extensions through public engine services | Prove the same capabilities work for independent authors and namespaces; update the SDK only when its own interface or behavior requires it. |

Crucible and the default imports advance together. A new import operation
needs an engine contract and regression coverage; a new reusable engine
contract needs a practical import or application example. PCFC11 receives
those generated programs as live integration tests while retaining its own
independent C test suite. Typed and Runtime support must be identified
separately rather than inferred from one another.

## Public API breadth for human and AI authors

CC's current focus is the range of useful Crucible calls that a human developer
or AI system can discover and use through the SDK to build several kinds of
*imports. Prioritize reusable public conversion capabilities and the ability to
combine them into practical programs. Math, NumPy and JSON exercise that surface;
the development objective extends to independently authored import families.

The 1.3.88 workbench exposes scalar declarations, 20 array operation choices,
two structured-value choices (JSON loads/dumps), and three Unicode text choices. Scalar
schema revisions are compatibility versions, not additional capability families.
An internal converter feature is not automatically an SDK authoring option;
workflow methods such as scan or package do not add conversion semantics.

Before selecting the next Crucible capability, review the public API against
real authoring tasks and record:

- Which operations are publicly authorable, internal only, unsupported or
  planned, with their data types and Typed/Runtime routes. Separate composing
  calls in a converted program from defining a new composite extension operation.
- Signatures, positional/named/default arguments, result types, ownership and
  lifetime rules, errors, numerical/resource limits and platform requirements.
  Keep human explanations and machine-readable contracts consistent.
- Gaps that prevent useful imports involving numeric values, arrays, text,
  containers or structured records. Rank additions by demonstrated reuse across
  distinct tasks and import families; distinguish new semantics from new aliases.
- Complete examples using independent namespaces and combinations with existing
  contracts. Verify through the installed public service, native execution and
  applicable failure/GC checks. Namespace-renaming tests establish reuse but do
  not alone establish broader authoring capability.
- Whether human and AI clients can discover an operation, author a valid
  declaration, understand a rejection, verify and register without undocumented
  engine knowledge. Preserve structured diagnostics, versioned metadata and
  compatible packages. Record unaided human and AI author trials separately from
  scripted API regression tests; do not mark either trial completed by inference.

Select one bounded public capability from that review and qualify it end to end.
API expansion must include working engine behavior, discoverable SDK choices,
examples and evidence. Use the existing engine-owned catalogue/workbench to
deliver additive options, following the SDK update rule below. Maintain this
priority alongside PCFC11 correctness and the compiler foundation work; useful
independent API additions need not wait for unrelated optimizer improvements.

## Starting point

- PyCForge 1.3.87 contains pinned PCFC11 0.2.34 source. CC reports similar
  successful Windows tests for the preceding PyCForge/SDK baseline, in addition
  to earlier setup and stress feedback. CC did not run Linux tests on the
  Windows-only laptop. Exact logs/case coverage were not supplied with this
  feedback; it does not qualify the new 1.3.87 compiler increment.
- Bundled defaults are math 0.3.0, NumPy 0.5.0 and JSON 0.1.0. NumPy currently
  uses the Runtime route and finite contiguous one-dimensional float64 arrays.
  Division, including atomic in-place division, and bounded pairwise sum/mean are part of this profile.
  JSON provides a bounded structured-value codec. Registration does not imply
  compatibility with an entire Python library.
- SDK 0.6.4 supports these conversion contracts and checks the selected PCFC11 backend. Existing package identities,
  older profiles and explicit refusal of unsupported new profiles are retained.
- Runtime collection remains opt-in. Native helper scratch, resource lifetimes
  and any wider collection points need their own qualification.
- Whole-program qualification is now a maintained source procedure with fresh
  independent outcomes. Use the 1.3.84 verification record for the application
  repairs and the 1.3.88 record for the current product gates. Native Windows execution and the display check
  below still require evidence on that platform.
- Require the complete application suite to pass before a full SDK review.
  SDK 0.6.4 checks the PCFC11 backend before approval and packaging. Record
  an unaided human first-project exercise, the intervention points and the
  operator’s interpretation of verification. Automated results are repeatable
  through the public CLI and Python API.
- The Preparing-dialog resize trigger has a 1.3.77 correction; confirmation on
  the reported Windows display remains open. An oversized generated literal
  function exceeded a GCC optimization deadline. Investigate that workload
  across generation and compilation before attributing the cost to PCFC11.

The baseline evidence is recorded in
[PyCForge-1.3.87-Verification.txt](PyCForge-1.3.87-Verification.txt).
The roadmap describes planned work; its recorded increments identify actual changes.

## Coordinated progression

| Stage | PCFC11 | Crucible and default imports | Exit condition |
| --- | --- | --- | --- |
| 1. Consolidate trust | Continue the C11 constraint/diagnostic audit; preserve output on failed builds; broaden fresh generated-C and native platform checks. | Reconcile actual coverage, errors, evaluation order, memory and import behavior; retain reduced reproductions of current failures. | A shared, versioned baseline with reproducible defects, exact supported domains and explicit platform gaps. |
| 2. Deepen useful coverage | Qualify the scalar, pointer, conversion, floating-point and ABI behavior used by the chosen capability at supported optimization levels. | Strengthen reusable numeric, call, container and error contracts; extend math, NumPy and JSON through those contracts. | A complete practical capability works through conversion, native execution and independent SDK authoring. |
| 3. Expand data models | Verify layouts, indexing arithmetic, bounds, calling conventions and larger generated programs. | Introduce richer arrays and structured workflows in bounded steps, with ownership and failure behavior defined first. | Each new representation composes with existing operations and survives allocation failure, aliasing and collection tests. |
| 4. Improve measured performance | Extend verified IR, then live ranges/register allocation and bounded scalar/loop transformations; retain conservative fallback. | Reduce measured code growth, redundant work, copying and allocation; optimize shared kernels without changing their contracts. | Correctness is retained and representative measurements demonstrate a benefit without unexplained regressions. |
| 5. Broaden qualification | Expand real C/application workloads, platform evidence, debugger/toolchain behavior and long-run reliability. | Grow practical workflows and additional defaults where shared contracts justify them; qualify SDK stability against independent authors. | Repeatable release evidence supports the exact advertised scope on each claimed platform. |

Correctness and diagnostics continue through every stage. Performance
measurement starts in stage 1, even though larger optimizer changes come
later. Work that has no dependency on an unavailable platform may continue;
its platform qualification remains explicitly pending.

### Stage 1: establish one reliable baseline

Maintain two connected suites: independent C inputs for PCFC11 and freshly
transpiled applications for the complete PyCForge path. Keep historical fixtures,
but do not let them substitute for current conversion and installed-product tests.
Compare defined behavior against independent references and compiler profiles;
compiler agreement alone is not proof of language or numerical correctness.

Prioritize wrong results, crashes, incorrect acceptance, data loss and lifetime
faults. Retain small reproductions for signed/unsigned conversion, overflow,
evaluation order, floating-point edges, aliasing and failure cleanup as relevant.
Follow up the Windows dialog report and native GC/compiler matrices. Keep
ordinary build failures, cancellation and failed-output preservation covered.

Record transpile time, generated C size, compile time, peak memory and runtime
separately for the large-function case. This identifies whether the next fix
belongs in Crucible lowering, PCFC11, or a particular external compiler path.

### Stage 2: deepen shared conversion capabilities

Audit the implemented surface before adding APIs. Prioritize gaps that block
real programs and improvements reused by multiple operations or packages.

- Numeric work: deepen one-dimensional array operations and reductions. Bounded sum/mean is implemented in 1.3.79 with explicit accumulation,
  rounding, cancellation, overflow, empty-input and absolute-error contracts.
  Further reductions must receive the same numerical qualification.
  It must not silently relax the current finite-value policy or promise bitwise
  agreement with every NumPy implementation.
- Calls and errors: improve reusable argument binding, optional/named arguments,
  source-order evaluation and precise source diagnostics where coverage gaps
  remain. Preserve profile-specific errors and the existing fatal resource policy.
- Structured values: strengthen composition among JSON, strings, containers and
  functions, including malformed inputs, Unicode, nesting/size limits, round
  trips and cleanup. Reuse the existing value representation and public services.
- Memory: qualify live roots, temporary ownership, aliases and rollback for each
  new operation. Extend active collection boundaries only after the affected
  helper scratch and resources can be traced safely.

Each increment includes its matching PCFC11 cases and a default-import example.
The SDK must also exercise the contract under an independent namespace; no
library-name special case belongs in SDK dispatch.

### Stage 3: expand representations in dependency order

Use owned contiguous two-dimensional arrays as the preferred next array model
after one-dimensional numeric contracts are sound. Define rank, shape, storage
size, layout, indexing, copying and error behavior before admitting new syntax.
Qualify construction, access, arithmetic and reductions together within the
declared subset; do not advertise general multidimensional NumPy support.

Treat views/strides, wider dtype and promotion rules, and general broadcasting
as separate later capabilities. Slicing must retain its documented ownership
semantics: do not implement a NumPy view expression as an undisclosed copy.
Views require parent lifetime, overlap/mutation, bounds and GC contracts first.
Native resources additionally require deterministic release and explicit ABI
and deployment contracts; collection must not become an implicit finalizer.

In the same stage, deepen structured records, containers, function boundaries
and supplied-module workflows according to demonstrated gaps. Keep Typed and
Runtime representations and interoperability promises explicit. Add another
bundled library only when it contributes a useful, maintainable capability;
the default set remains small, with no fixed library-count ceiling.

### Stage 4: optimize with evidence

For PCFC11, extend typed IR and effect verification before broader live-range
allocation, spills/reloads, scalar simplification and loop work. Bound analysis
cost and preserve working fallback paths. Investigate transformations using
both general C programs and current Crucible output.

For Crucible, measure generated-function size, repeated helper work, temporary
arrays, copies and GC costs. Apply shared kernels, bounded code generation or
helper extraction only where evaluation order, failure timing, ownership and
observable results remain correct. Record both small and large workloads.

Keep strict floating-point behavior as the default. Reassociation, contraction,
SIMD and other numerical transformations need explicit policies and accuracy
evidence. Separate compiler-generated kernels, calls into the same native
numeric library, and full application costs when benchmarking. BLAS/LAPACK
integration is conditional on real ABI, layout and deployment qualification;
it is not implied by a larger NumPy profile. PGO/LTO and new targets remain later
work. Do not promise speed multipliers before measurements exist.

### Stage 5: turn progress into repeatable releases

Broaden realistic application inputs, long-running workloads, compiler
hostile-input checks, diagnostics, debugger behavior and supported toolchain
interfaces. Record native Windows and Linux results separately, including exact
versions, flags, skips and known limits. Retain self-compilation, independent
compiler/reference checks and sanitizer coverage where supported.

Keep installation, compiler discovery, explicit build/cancel/failure, import
registration and old/new package compatibility in release qualification.
SDK general stability remains conditional on independent author use and the
arrays/views/native-resource contracts it claims. None of these stages implies
complete C11, arbitrary Python or full third-party-library compatibility.

## SDK update rule

First test every additive engine capability with the unchanged SDK. Engine-owned
catalogues, forms, signatures, templates and Help should carry ordinary additions.
Release an SDK update when it needs a new protocol/format, required field or
widget, verification/result behavior, or a client bug fix. Define compatibility
and refusal behavior before changing a contract; retain old profile meanings.

Exercise the installed engine and SDK in separate environments: discovery,
authoring, verification, deterministic packaging, registration, stale evidence,
old-package admission and prior-engine refusal of unsupported new profiles.
SDK verification and PyCForge admission remain distinct. Browsing metadata must
not execute examples. Avoid version bumps that merely mirror a PyCForge release.

## Selecting and completing the next increment

The 1.3.78 reliability increment fixes Classes & Functions, source outlines and
function folding for valid *import declarations. It preserves original editor
text, nested definitions, copy/jump positions and inert package handling. The
current engine/default-import inventory and platform gaps are recorded together.

The retained 68,135-byte literal workload emits 2,016,111 bytes of C in about
2.15 seconds on the measured Linux host. PCFC11 O0/O1 compile it in about 2.9
seconds and its results match the Python/NumPy reference. GCC O0/O1 exceed the
30-second observation deadline. The compact loop workload and a practical
math/NumPy/JSON class workflow compile and run correctly on all four profiles.
These are single diagnostic observations; giant-function code growth remains
open and there is no general speedup or native Windows claim. Reproduce them
with tools/benchmark_conversion_pipeline.py; detailed evidence is under
evidence/navigation_1_3_78. The harness currently requires POSIX supervision.

The 1.3.79 capability increment adds fixed pairwise sum/mean to the shared
array service and NumPy 0.5.0. Prior array profiles retain their meanings.
The numerical matrix covers 104 arrays and checks exact-rational absolute error
bounds. GCC O0/O1 and PCFC11 O0/O1 agree on all 208 scalar outputs; 52 differ
bitwise from NumPy 2.3.5, including cancellation cases. This is a documented
bounded numerical policy, not a bitwise NumPy claim. Complete class/function/JSON
and supplied-module applications and independent C probes pass all four profiles.
The unchanged installed SDK 0.6.3 qualifies both NumPy and independently named
operations: 62 cases per starter, deterministic packaging, registration, stale
evidence, prior-engine refusal and admission of four historical array packages.
The release report records the exact installed-package evidence.
CC reports the 1.3.78 navigation fix is much better on their installation;
this remains user-reported Windows feedback, not an inspected native matrix.

The 1.3.80 compiler increment follows CC's CFG review. PCFC11 0.2.28 now
models compound truth conditions explicitly in its verified integer CFG and
separate backward liveness graph. Existing data-flow solvers retain facts along
short-circuit paths. Direct graph/fact/liveness checks, allocation and resource
refusal, ordered-effect execution and current Crucible applications qualify the
bounded change. Value-context merges, a unified graph, dominance, SSA, general
alias analysis, new flow warnings and full allocation are not implemented by it.
The verification record identifies completed gates and native Windows limits.
Crucible, math 0.3.0, NumPy 0.5.0, JSON 0.1.0 and SDK 0.6.3 contracts are unchanged.

The 1.3.81 increment adds shared integer CFG topology, structural reachability,
reverse postorder and immediate dominators. Copy, conditional-constant and
known-bit solvers use the shared analysis; their effect/lattice contracts remain.
Independent graph-deletion oracles and full compiler/application checks qualify
this foundation. Backward liveness remains separate, and no new jump/switch
admission, SSA or dominance-based transformation is enabled.

The 1.3.82 increment admits direct statement labels/goto to the shared integer
CFG, including forward/backward edges and entry into structured regions. Constant
pruning preserves labeled branches/loops. Switch and expression-contained jumps
retain conservative fallback; backward liveness remains separate. The maintained
WHOLE_PROGRAM_QUALIFICATION.md report defines exact-source/input/platform acceptance,
with a fresh application runner, independent expected outcomes and retained
diagnostics. Crucible/default-import semantics and SDK 0.6.3 are unchanged.

The 1.3.83 operator review exposed a compiler invocation failure and a wrong
observable result. Both took precedence over admitting another CFG form. PCFC11
0.2.31 accepts explicit strict floating-point options. Crucible emits the
canonical positive quiet NaN for scalar declarations. Its XML operation
inventory now covers every bundled export and publishes array profile 0.5.
All seven SDK starters passed with both native drivers. A separately authored
extension also ran in a supplied-module program alongside two independent
packages. See PyCForge-1.3.83-SDK-Operator-Review.md for the operator findings.

Both 1.3.82 and 1.3.83 aborted in the pending-restore/window-deletion workflow
on Linux offscreen Qt. In 1.3.84 a Qt owner cancels and joins its active
compiler worker before destruction. The formerly aborting module and a new
test that forces this ordering passed in three separate processes. The repair
record also accounts for the original 51 cases, current import admission and
the regenerated GC fixture kit. See PyCForge-1.3.84-Verification.txt.

The 1.3.85 increment closes the reported SDK 0.6.3 backend gap. PCFC11 0.2.32
reports the command actually selected for assembly and linking. SDK 0.6.4 pins
the backend invocation path for fixture builds. It checks the resolved path and
file hash when validating evidence and after package construction. A missing
backend, a different path with identical bytes, and same-path replacement each
block approval and preserve the last package. Direct GCC verification remains
available on older compatible engines.

Structured-value method cards now expose the engine’s operations to JSON
clients. Failed verification identifies the first fixture and its location;
invalid CLI arguments in JSON mode return a structured diagnostic. Current
inventory tests compare the connected engine’s declarations and tool choices.
See PyCForge-1.3.85-SDK-Operator-Review.md for the observed workflows and
remaining operator and platform evidence.

The 1.3.86 increment admits statement-level switch dispatch and fallthrough to
PCFC11 0.2.33's shared integer CFG. Selector evaluation, case ownership, nested
exits, direct-label entry and source-order fallthrough are explicit. All cases
and the default/no-match path remain possible to the analysis. Computed jumps,
expression-contained switches/transfers and over-budget graphs retain fallback.
No SSA, reaching definitions, shared backward liveness or general alias analysis
is implied. Fresh qualification is recorded in the 1.3.86 verification record.
Crucible/default-import contracts and SDK 0.6.4 are unchanged.

Both README guidelines now require purposeful section categorization. The
1.3.78 editor-navigation correction has moved out of the conversion bug tracker;
current behavior is described with editor features, and its historical fix
record remains in the engineering history. Routine updates change only applicable
version references unless actual product information needs correction.

The 1.3.87 increment implements bounded reaching storage definitions and
bidirectional use chains in PCFC11 0.2.34. Entry unknowns and opaque clobbers
are explicit; opaque operations conservatively consume incoming definitions.
The analysis uses the shared topology, reaches a fixed point before publishing
and refuses invalid/resource-exhausted work without mutation. Independent
backward-path oracles and source-builder cases qualify the foundation. Current
code-generation transformations remain unchanged. Shared backward liveness,
SSA/value merges and broader memory effects remain separate next contracts.
Crucible/default-import semantics and SDK 0.6.4 are unchanged; the 1.3.87
verification record identifies the actual full release and platform results.

Next observe an unaided author using the documented workflow. Record any
assistance needed to select the engine and compiler, diagnose a failed fixture,
reverify and register an extension. Native Windows GUI/compiler and GC evidence
also remain open. Continue to run both compiler paths after changing the
conversion engine, native profile or compiler driver.

The next development queue, incorporating the public API priority above, is:

1. Continue public authoring breadth from the completed four-family audit and
   Unicode text increment. Prioritize practical gaps demonstrated by a human or
   independent AI author: operation selection, named/default calls, diagnostic
   correction and composing capabilities. Current declarations contain one
   family; mixed-family packages require a separate reviewed contract. Do not
   imply that arbitrary internal Runtime methods, callbacks or native
   dependencies are publicly authorable. Keep usable examples and machine-readable
   coverage aligned with each new kernel. Unaided author trials remain pending.

2. Make backward liveness reuse the verified shared topology and the explicit
   read/clobber contracts. Definition/use chains are implemented in 1.3.87.
   Compare the shared analysis against independent path oracles and the existing
   separate liveness implementation before changing dead-store decisions or
   allocation. Preserve bounded solvers, conservative effects and fallback.
   SSA/value-context merges and broader memory analysis remain separate work.
   This compiler priority accompanies conversion and native-platform work below.

3. Investigate bounded lowering for large literal-generated functions using the
   recorded phase costs. Preserve evaluation order, allocation/error behavior
   and ownership before adopting helper extraction or another transformation.
   Continue PCFC11 correctness/diagnostic work and native Windows compiler/GC
   qualification; retain the Preparing-dialog display follow-up.
4. Specify the owned two-dimensional model after the one-dimensional numerical
   contracts are qualified, while deepening JSON/structured workflows and
   compiler behavior needed by actual whole-program examples.
5. Expand further reductions only with explicit numerical/empty/error policies,
   independent SDK authoring and new native compiler cases.

Prefer one bounded capability and a focused correctness batch per increment.
Urgent defects take precedence. Keep WHOLE_PROGRAM_QUALIFICATION.md and its
release evidence current; open full-suite failures remain work, not a clean
whole-program guarantee. Every implementation increment must record:

- Exact supported/rejected forms, representation, evaluation order, errors,
  ownership, aliasing, numerical policy and resource limits.
- Reproductions plus positive, negative, boundary and differential checks;
  allocation-failure/GC checks where relevant; defined reference expectations.
- Fresh conversion and native compilation/execution with PCFC11 and an
  independent compiler, at relevant optimization levels; platform gaps named.
- Applicable installed SDK compatibility evidence and updated Help, completion,
  catalogue, examples and contract identities, without rewriting old profiles.
- The actual versions, fixtures, results, remaining limitations and final
  artifact hashes. Measure performance claims against a recorded baseline.

Use focused checks while developing; run the required project release checks
for a release. Mark evidence as verified, user-reported, pending or deferred.
Do not convert a pending platform result into a pass to close a stage.

PCFC11 retains its independent test-pcfc11.sh workflow and pinned-source
provenance. PyCForge retains one wheel/source distribution, the versioned
per-user compiler destination and builds only on explicit request. No installer,
startup build or toolchain download is introduced. CC alone publishes releases.
Keep planning and verification records outside the public README and user Help.

## Governing records and preserved history

- [Project instructions](AGENTS.md) and
  [README guidelines](PyCForge-README-Guidelines.txt).
- [Conversion work map](CONVERSION_ROADMAP.md).
- [Current numerical contract](specifications/PyCForge-SDK-Framework-0.10.md),
  [division contract](specifications/PyCForge-SDK-Framework-0.9.md),
  [structured-value contract](specifications/PyCForge-SDK-Framework-0.8.md),
  [SDK workbench](specifications/PyCForge-SDK-Workbench-1.0.md) and
  [default-import/UI standards](docs/UI_IMPORT_STANDARDS.md).
- [Runtime memory contract](specifications/runtime_memory_1_3_72.md).
- PCFC11's docs/UPGRADE_OBJECTIVES.md inside the bundled
  pycforge/pcfc11/PCFC11-0.2.34-source.zip remains the detailed compiler ledger.
  Its older installer/separate-packaging proposals are superseded by current
  project instructions; its compiler engineering objectives remain useful.
- The previous [general roadmap](specifications/roadmap-history/ROADMAP-before-coordination-2026-10-31.txt)
  and [conversion roadmap](specifications/roadmap-history/CONVERSION_ROADMAP-before-coordination-2026-10-31.txt)
  are preserved verbatim as history. Paths inside those snapshots refer to
  their original project-root context. Historical priorities are not current
  instructions, and historical backlog entries require a current coverage audit.

## Public Unicode text increment — PyCForge 1.3.88

The public capability audit distinguishes scalar, owned one-dimensional arrays,
JSON codecs and the new text family from internal-only Runtime methods and SDK
workflow operations. TextFunction, TextExtension and TextTypeService expose
text-strip, text-split and text-join through data-only declarations. Authors can
choose independent namespaces/exports and positional or named arguments with
engine-owned defaults. Generated results have independent context-owned storage;
Unicode/NUL behavior, work limits, partial-allocation rollback and roots are
explicit contracts. Shared split comparisons and join work/scratch handling are
also strengthened for ordinary Runtime string calls.

The selected engine supplies the four-field SDK form, exact operation choices,
a complete text-starter, public type/diagnostic catalogue, coverage metadata and
a focused human/AI authoring guide. PyCForge completion and registered-import
Help use those same text contracts. Existing bundled math, NumPy and JSON
packages and the compiler pin are unchanged. A fourth bundled default is not
introduced. The main README changes only its version; the SDK client remains unchanged. Its standalone README receives a focused
coverage correction for the additive connected-engine text family.

See specifications/PyCForge-SDK-Framework-0.11.md and the 1.3.88 verification
record for native, whole-program, memory, application, SDK and packaging gates.
No unaided human or independent AI author trial, native Windows execution,
general regex/normalization/stream support or mixed-family declaration is claimed.
