DWScript core — compile the scripting engine (corpus rung 4)

• Type: feature (real-world Pascal corpus target)
• Track: B (build on $(PXX_STABLE); language gaps → tickets in the owning lane)
• Status: backlog — split out of [[feature-embed-dwscript-rtti]] 2026-09-06
• Upstream: github.com/EricGrange/DWScript, MPL 1.1. Not vendored.
• Rung 4 of [[feature-pascal-corpus-expansion]], beside [[feature-embed-pascal-script]].

Why this is its own ticket

The parent is named for dwsRTTIExposer, which needs Delphi extended RTTI and cannot be started — filed as [[feature-b-delphi-extended-rtti-object-model]]. The core is 94 of the 96 units, is blocked on nothing but ordinary RTL gaps, and has work available today. One ticket carrying both ranks the startable half behind the unstartable one, and the corpus ladder's rung 4 needs something it can actually point a session at.

The measured wall ladder

At 8b55d1918, compiler 5ca36ce7aae9, --mimic-fpc -Mdelphi -FuSource, probe uses dwsXPlatform (48 of 96 units name it, so it is the gate):

The empty stub is the finding. It is the probe whose right answer differs from the default: had LCLIntf been supplying anything, an empty unit would have produced a list of unknown identifiers naming it. It produced none.

Next moves, cheapest first

1. TFileName — TFileName = string in lib/rtl/sysutils.pas. One line, and every Delphi-leaning corpus target wants it.
2. IMultiReadSingleWrite / TLightweightMREW — Delphi 11+ System.SyncObjs. A real reader-writer lock in lib/rtl/syncobjs.pas.
3. Keep stubbing forward from dwsXPlatform and record each wall here. Do not commit the lclintf stub into DWScript's tree — it is a probe, and the real answer is either an RTL unit of ours or a unitalias row.

Done when

$(PXX_STABLE) compiles the DWScript core and runs a plain script with no host binding. The RTTI exposer is explicitly out of scope — that is the parent.