CardDemo CBEXPORT / CBIMPORT: RECORD KEY outside the file's record (source IBM rejects), frontier #5866

Owner decision 2026-10-21: frontier. CardDemo app/cbl/CBEXPORT.cbl (7 holes) and app/cbl/CBIMPORT.cbl (3 holes) stay at L0 because their source is not valid Enterprise COBOL: SELECT EXPORT-OUTPUT/EXPORT-INPUT ... ORGANIZATION IS INDEXED ... RECORD KEY IS EXPORT-SEQUENCE-NUM names a key item defined in WORKING-STORAGE (COPY CVEXPORT), not in the file's own record. IBM requires the RECORD KEY item in a record description of that file (Enterprise COBOL Language Reference, RECORD KEY clause), the oracle refuses to compile it, and the det translator refuses the OPEN / READ / WRITE / CLOSE of that file by name (#4804). (The JCL's IDCAMS DEFINE also gives KEYS(4 28) while the key sits at offset 27.)

These are source defects of the estate, not translator gaps: no honest port exists until the source is fixed. They count in the 129-program ladder denominator but are not core work toward this finish line.

• (frontier) The ladder / progress page reports a program held by a source defect separately from translator holes (evidence report source_defects is empty for these today; the holes carry the IBM reason) (Generated progress page + README numbers that can't drift: burned-estate ladder, per-tool %, core burn-down with ETA, Gap Atlas #5280)
• (frontier) Customer-facing: the readiness scanner names such programs as "fix the source first" with the IBM citation (Epic: estate readiness scanner — a deployable scan that tells each customer what GitGalaxy can translate and prove, and what it must learn #4721 / Blocker report: a full version for the customer plus an anonymized version they can send us to feed the engine-fix loop #5054)

Scope: frontier (Gap Atlas). Filed from the 2026-10-21 translation-blocker audit.