[bitmaster162]

Why this change is needed

G2 R2 established that the synthetic IDL generates three C/header files. G3 verifies the next bounded step: the generated client and server C stubs compile into two unlinked AMD64 COFF objects. It does not qualify an RPC broker or authorize production use.

Changes and current identity

• Existing G2 R2 workflow is byte-identical: Git blob 32f4682a410452adf06b7b1f480e35d2ba6bbf3b.
• Adds one separate G3 workflow: .github/workflows/h3-g3-c-stubs-object-only.yml.
• The cumulative PR diff contains only the G2 and G3 workflows; G1 Draft PR ci(h3): verify Windows MIDL toolchain inventory #209 is unchanged.
• Protected master / pinned base: 719ed32a64301fc8083a5aad0c4ed7bed316040e.
• Current head: 46ac6bc46abde21b850e40f74e476a6a26d8107c.
• Current parent: 287d30cabcc395d7a4b28fa4f155a70eeed2b26a.
• Current tree: 7e119ccd1576b039065a37279a25632f0f8ce3c6.
• G3 file: 38,110 bytes, 612 lines, UTF-8 LF.
• G3 SHA-256: c2e96a0c8a5e3cf7d06e0011966a6a62c505230eac457e3d14c34475378a193a.
• G3 Git blob: c9462504ccd8ff39028f3b83adf1b020e4056758.
• Embedded synthetic IDL: 1,555 bytes, SHA-256 67915aa4c68d7bf8d8dd3a8879f7abed0c12a5262e577f4e4bf9c8c7fe87fe09, identical to G2 R2.

Resulting behavior

The G3 job uses windows-2025-vs2026, observed image 20260925.250.1, and six checked tool/file digests. It runs one MIDL stage followed by two separate cl.exe /TC /c /W3 /WX /Od invocations, with absolute source and /Fo paths. MIDL can itself invoke CL for preprocessing.

Child processes receive a closed environment, without inherited CL or _CL_ options. Arguments use ArgumentList. Each raw diagnostic stream is limited to 16 KiB while reading, with FULL/PREFIX hash scope. MIDL has a 90-second deadline, each direct CL invocation 60 seconds, and the job six minutes. The first error stops later stages; there are no retries.

Before/after manifests bind the IDL, generated files and compiled objects. Output names/counts/sizes and AMD64 COFF structure are checked. No LINK or generated program execution is performed.

Correction for the observed temporary directories

The initial native run compiled both objects successfully but correctly reported HOLD for an unidentified temporary entry. Bounded diagnostic revisions established a complete, unchanged three-directory structure after compilation:

Microsoft / VSApplicationInsights / vstel[0-9a-f]{32}

The observed structure contained no files. The final correction accepts only an empty TMP directory or exactly this fully checked empty directory chain. It rechecks every level, rejects extra entries and reparse points, and deletes only empty directories leaf-first using non-recursive Directory.Delete(path, false). Each removal is recorded after absence verification. A late file or partial failure remains HOLD. The original final-empty gate and verified whole-workspace cleanup remain in place.

The pre-deletion snapshot stays in the receipt. This is not a telemetry exemption, telemetry opt-out, or proof of the creator PID. No registry, toolchain binary, compiler flag or environment change was used to hide the directory.

Evidence of the diagnosed behavior:

• Initial object compilation with residual HOLD, head b25e5e2f9d6a130c3958a298abc7f0367d69eaaf.
• Complete directory inventory and successful object compilation, head 287d30cabcc395d7a4b28fa4f155a70eeed2b26a. Both objects validated; the old empty-TMP gate still reported HOLD; cleanup succeeded.

Validation

• actionlint 1.7.11 and real PowerShell 7.6.6 AST parser: PASS.
• Twelve process/output/manifest/COFF helper cases: PASS.
• Five bounded-inventory helper cases, including depth-4 bounds: PASS.
• Ten empty-directory correction cases: PASS, including a late file, a late reparse point and a failure after one successful deletion.
• Early-failure receipt check: PASS, zero child starts and no premature output claim.
• Previously tested helpers remain byte-identical in the final correction.
• Independent review of implementation and each corrective diff: PASS WITH CONDITIONS before the final Windows execution.
• Provider readback verified every commit's exact parent, single-file scope, blob and tree.
• Current-head Windows G3: PASS_OBJECT_COMPILE_ONLY, run 38290669436, attempt 1, job 114949710800 and actual receipt. All three stages exited 0; warnings 0; full bounded stdout/stderr hashes; both AMD64 COFF objects validated; three checked empty directories removed non-recursively; final TMP and whole-workspace cleanup verified.
• Client object: h3_r7b1c_lab_c.obj, 2,738 B, SHA-256 10d7bb5ae761612be0c5bef3644dd63fa80a796eefa63cd57252d8cb6c664a5d.
• Server object: h3_r7b1c_lab_s.obj, 2,166 B, SHA-256 3e208976eb201b5976a44497a9fe66a664a26d869ba919a2e26466470e9b8f6a.
• Final readback at 2026-10-12 18:28 UTC: current head/tree match; protected master and G1 head unchanged; cumulative diff exactly the two stated workflows. Six of seven current-head checks succeeded; only the general Windows Python 3.11 regression check was still running. This snapshot does not claim all-checks-green or merge readiness.

The native receipt above qualifies the current head. Local helper checks support its control behavior; historical results remain bound to their stated heads.

Scope and remaining limits

The G3 job performs no source checkout, artifact upload, RPC endpoint/service, owner-workstation action, production-memory access, manual dispatch/rerun, merge, deployment or branch deletion. The per-job subprocess bounds do not describe every automatic PR check: cumulative PR path filters also trigger G2 and existing repository CI.

Six digests do not claim a complete transitive SDK/compiler-backend closure. A process-tree kill request does not prove every descendant exited; unknown termination or missing cleanup evidence remains HOLD.

Success establishes only PASS_OBJECT_COMPILE_ONLY. security_C0=UNVERIFIED_HOLD, native_T11_T12=UNEXECUTED, and production=HOLD remain unchanged. PR stays draft.