feat: add COBOL language support with regex extraction pipeline

[magyargergo]

Summary

Adds full COBOL language support to GitNexus using a standalone regex processor — no tree-sitter dependency, no LanguageProvider modification. Follows the markdown-processor.ts pattern established for non-tree-sitter languages.

Based on the extraction work from PR #359 by @naicud, restructured to follow the clean architecture from PR #488.

Architecture Decision

Three independent review agents (architecture-strategist, code-simplicity-reviewer, typescript-pro) unanimously recommended Approach A (standalone processor) over Approach B (LanguageProvider discriminator):

• Zero changes to LanguageProvider interface
• Zero changes to SupportedLanguages enum
• 1 new orchestrator file + 1 pipeline integration point
• Follows the markdown-processor.ts precedent exactly

See docs/plans/2026-03-24-feat-cobol-language-provider-integration-plan.md for the full decision record.

Changes

New files (4,470 LOC):

• cobol-processor.ts — orchestrator (processCobol, isCobolFile, isJclFile)
• cobol/cobol-preprocessor.ts — regex state machine extraction (888 LOC)
• cobol/cobol-copy-expander.ts — COPY statement expansion with circular detection
• cobol/jcl-parser.ts — JCL job/step/DD extraction
• cobol/jcl-processor.ts — JCL graph node creation
• docs/code-indexing/cobol/ — 7 documentation files

Pipeline integration:

• pipeline.ts — single processCobol() call in Phase 2.6 (alongside processMarkdown)

COBOL Extraction Produces

COBOL Construct	Node Label	Edge Type
PROGRAM-ID	Module	—
PARAGRAPH	Function	CALLS (via PERFORM)
SECTION	Namespace	CONTAINS
Data items (01-level)	Property	—
CALL 'X'	—	CALLS (cross-program)
COPY X	—	IMPORTS
JCL EXEC PGM=X	—	CALLS (JCL→COBOL)

Test plan

• npx tsc --noEmit — zero type errors
• 54 new tests (33 COBOL + 21 JCL) — all pass
• Full suite: 3,889 tests pass, 0 failures
• Index a real COBOL repository and verify graph output

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gitnexus	Ready	Preview, Comment	Mar 26, 2026 1:55pm

[github-actions]

CI Report

✅ All checks passed

Pipeline Status

Stage	Status	Details
✅ Typecheck	success	tsc --noEmit
✅ Tests	success	unit tests, 3 platforms
✅ E2E	success	gitnexus-web changes only

Test Results

Tests	Passed	Failed	Skipped	Duration
4602	4600	0	2	175s

✅ All 4600 tests passed

2 test(s) skipped — expand for details

• buildTypeEnv > known limitations (documented skip tests) > Ruby block parameter: users.each { |user| } — closure param inference, different feature
• Dart field-type resolution > emits ACCESSES edges for field reads in chains

Code Coverage

Tests

Metric	Coverage	Covered	Base	Delta	Status
Statements	72.24%	12314/17045	70.65%	📈 +1.6	🟢 ██████████████░░░░░░
Branches	62.15%	8225/13233	61.22%	📈 +0.9	🟢 ████████████░░░░░░░░
Functions	75.86%	1031/1359	74.62%	📈 +1.2	🟢 ███████████████░░░░░
Lines	74.72%	11049/14787	73.19%	📈 +1.5	🟢 ██████████████░░░░░░

---

_{📋 View full run · Generated by CI}

[magyargergo]

@copilot reviewer the completness of this cobol processor and try to find and verify gaps and potential issues. Also try to see if our parser is complete for the cobol language

[Copilot]

@magyargergo I've opened a new pull request, #500, to work on those changes. Once the pull request is ready, I'll request review from you.

[magyargergo]

@claude reviewer the completness of this cobol processor and try to find and verify gaps and potential issues. Also try to see if our parser is complete for the cobol language

[github-actions]

Claude finished @magyargergo's task in 3m 3s —— View job

---

COBOL Processor Completeness Review

Tasks:

• Read and analyze all COBOL processor source files
• Review regex patterns for correctness
• Identify missing COBOL constructs
• Check for structural/correctness bugs
• Review JCL parser completeness

---

Summary

The implementation is solid for its stated scope (regex-based symbol extraction for code indexing). Architecture, test coverage, and graph integration are well done. Below are findings organized by severity.

---

🔴 Critical Bugs

1. CALL 'single-quoted' not detected — cobol-preprocessor.ts:176

const RE_CALL = /\bCALL\s+"([^"]+)"/i;

COBOL allows both "double" and 'single' quote delimiters. CALL 'SUBPROG' is extremely common in IBM mainframe COBOL (EBCDIC environments often prefer single quotes). This means a large class of cross-program calls goes completely undetected.

Fix this →

Same issue applies to RE_ENTRY at line 189 — ENTRY 'name' with single quotes is valid and won't be captured.

---

2. Sequence-numbered files: paragraph/section detection silently fails

// cobol-preprocessor.ts:171-172
const RE_PROC_SECTION = /^       ([A-Z][A-Z0-9-]+)\s+SECTION\.\s*$/;
const RE_PROC_PARAGRAPH = /^       ([A-Z][A-Z0-9-]+)\.\s*$/;

These require exactly 7 leading spaces. Standard COBOL files with sequence numbers in columns 1–6 (e.g. 000100 MAIN-PARAGRAPH.) have digits in those positions. preprocessCobolSource only replaces alpha/# markers, so numeric sequence numbers are preserved. Result: zero paragraphs and sections extracted for any file with numeric sequence numbers.

The fixture files happen to use all-space column 1–6 areas, so tests pass — but production COBOL files almost universally have sequence numbers.

Fix this →

---

3. Duplicate data item names produce colliding graph node IDs — cobol-processor.ts:355

const propId = generateId('Property', `${filePath}:${item.name}`);

The ID only includes filename and name, not section. If the same name appears in multiple sections (e.g. a STATUS field in both WORKING-STORAGE and LINKAGE SECTION), the second addNode silently overwrites the first. Level is also not included, so 01 CUST-REC and 05 CUST-REC (valid in different groups) collide too.

Fix this →

---

4. Resolved cross-program CALL edges are duplicated, not replaced — cobol-processor.ts:196–214

The second pass adds new resolved edges (id: rel.id + ':resolved') but the original <unresolved>:PROGNAME edge is never removed. The graph ends up with both. Any upstream traversal will see two CALLS edges to the same logical target — one to a phantom node, one to the real module.

---

🟡 Notable Gaps

5. MOVE identifier TO a b c (multiple targets) not tracked — cobol-preprocessor.ts:192

const RE_MOVE = /\bMOVE\s+(CORRESPONDING\s+)?([A-Z][A-Z0-9-]+)\s+TO\s+([A-Z][A-Z0-9-]+)/i;

Only captures the first target. MOVE WS-AMOUNT TO FIELD-A FIELD-B FIELD-C produces one data-flow edge instead of three.

---

6. COPY ... IN library / COPY ... OF library syntax not supported — cobol-copy-expander.ts:259

const targetMatch = text.match(/^COPY\s+(?:"([^"]+)"|([A-Z][A-Z0-9-]*))/i);

COPY CUSTDATA IN PRODLIB is valid COBOL. The IN/OF clause is silently ignored and only CUSTDATA is captured — but the IN PRODLIB qualifier is important for resolving to the right library, particularly in mainframe environments with multiple PDS libraries.

---

7. COPY REPLACING pseudotext (==...==) not handled — cobol-copy-expander.ts

IBM Enterprise COBOL's most-used form of REPLACING is pseudotext:

COPY CUSTDATA REPLACING ==CUST-== BY ==WS-CUST-==.

The parseReplacingClause function tokenizes on "quoted" and unquoted tokens. ==pseudotext== delimiters will be completely unparsed, so REPLACING transformations in this format silently do nothing.

---

8. Inline PERFORM without paragraph name not indexed — cobol-preprocessor.ts:173

const RE_PERFORM = /\bPERFORM\s+([A-Z][A-Z0-9-]+)(?:\s+THRU\s+([A-Z][A-Z0-9-]+))?/i;

Inline PERFORM blocks (PERFORM ... END-PERFORM) have no paragraph target and are completely invisible to the extractor. This also means PERFORM VARYING / PERFORM UNTIL loops produce no graph edges.

---

9. Nested programs (multiple PROGRAM-IDs in one file) only capture the first — cobol-preprocessor.ts:686-691

if (result.programName === null) {
  const m = line.match(RE_PROGRAM_ID);
  if (m) { result.programName = m[1]; ... }
}

The guard === null means only the first PROGRAM-ID is captured. COBOL allows multiple programs per compilation unit (nested programs or a sequence of independent programs in one file). Only the first gets a Module node.

---

10. procedureUsing parameters not linked to Linkage Section items in graph — cobol-processor.ts

procedureUsing is captured (e.g. ['LS-CUST-ID', 'LS-AMOUNT']) but no graph edge connects the procedure's formal parameters to their corresponding Property nodes in the Linkage Section. Callers have no graph-level way to know which data items are passed as parameters.

---

11. JCL in-stream PROC ordering bug — jcl-processor.ts:119–183

Steps are processed (section 2) before in-stream PROCs are registered in moduleNames (section 4). If a step EXECs a PROC that's defined later in the same file, the jcl-exec-proc CALLS edge will never be created. The fix is to pre-register all PROCs before processing steps.

---

🟢 Minor / Design Notes

12. CALL identifier (dynamic calls via variable) not tracked

CALL WS-PROGRAM-NAME — call via a data item holding the program name — is invisible. This is hard to resolve statically, so it's acceptable to skip, but worth noting.

13. CICS LINK/XCTL MAP name in CICS blocks with unquoted identifiers

const mapMatch = body.match(/\bMAP\s*\(\s*['"]([^'"]+)['"]\s*\)/i);

CICS MAP names can be identifier references (not just literals). SEND MAP(WS-MAP-NAME) won't capture the map name, silently producing no mapName in the result.

14. SQL table extraction misses DELETE FROM pattern

/\bFROM\s+([A-Z][A-Z0-9_]+)/gi,

DELETE FROM TABLE would be caught by the FROM pattern, but DELETE TABLE (without FROM, which is valid SQL) would not. The UPDATE TABLE SET pattern is caught by the UPDATE pattern. Generally low impact.

15. findDataItemNode linear scan — cobol-processor.ts:238-246

Called once per MOVE statement. O(n) per call, O(n·m) total for n data items and m moves. For large programs this could be slow. A precomputed Map<string, dataItem> per file would fix this.

---

Test Coverage Assessment

The 57-test suite covers the happy paths well. Key untested scenarios:

• Files with numeric sequence numbers in cols 1–6 (critical gap Welcome to GitNexus Discussions! #2 above)
• CALL 'single-quoted' programs
• COPY ... IN library syntax
• COPY REPLACING ==pseudotext==
• PERFORM VARYING / PERFORM UNTIL (inline)
• Duplicate data item names across sections
• Multiple PROGRAM-IDs in one file

---

[magyargergo]

@claude can you compare PR #500 with this?

[github-actions]

Claude finished @magyargergo's task in 1m 58s —— View job

---

Comparing PR #498 vs PR #500

Tasks:

• Post initial comment
• Fetch PR fix(cobol): single-quote CALL/COPY, sequence number stripping, PERFORM keyword false-positives #500 details and changed files
• Compare fixes/additions in fix(cobol): single-quote CALL/COPY, sequence number stripping, PERFORM keyword false-positives #500 vs gaps identified in feat: add COBOL language support with regex extraction pipeline #498
• Post final comparison

---

Blocked: To compare PR #500, I need to fetch origin/copilot/sub-pr-498 (the PR #500 branch). The git fetch and gh CLI commands require approval that hasn't been granted yet.

Could you approve git fetch commands or the gh CLI so I can pull down PR #500's branch and diff it against feat/cobol-language-support?

Alternatively, if you'd like to grant both, the exact commands I'd need are:

git fetch origin copilot/sub-pr-498
git diff feat/cobol-language-support...origin/copilot/sub-pr-498

[github-actions]

Claude finished @magyargergo's task in 9m 24s —— View job

---

COBOL Processor — Fifteenth Deep Review (Compiler Front-End / Static Analysis Perspective)

Tasks:

• Post initial comment
• Read all COBOL processor source files (current state post-commit 2b222ef)
• Verify all 14th review findings against current code
• Deep compiler front-end analysis — new gap identification
• Architectural fit review
• Post final comprehensive review

---

14th Review — Verification Status

All 4 findings from the 14th review verified against the current branch (commit 2b222ef). Ground truth:

#	Finding	Status
14th #1	callAccum flush causes false paragraph + currentParagraph corruption when last CALL USING param is on period-terminated line	✅ FIXED — combination of (a) callAccum early-flush detection at lines 1154–1157 and (b) Area A guard in extractProcedure at line 1543. But see New #A below
14th #3	inspectAccum same false paragraph risk on continuation lines	✅ FIXED for Area B continuation lines — Area A guard at line 1543 rejects deeply-indented lines. But see New #B
14th #4	callAccum pre-check not guarded by currentDivision === 'procedure'	✅ FIXED — line 1165: currentDivision === 'procedure' && guard present
14th #5	RE_PROC_PARAGRAPH uses ^\s* (unlimited indent) rather than Area A column bounds	✅ FIXED — Area A guard at lines 1542–1543: if (!isFreeFormat && leadingSpaces > 7) return;

---

New Findings (This Review)

🔴 New #A — Last CALL USING Parameter Dropped When on Its Own Period-Terminated Line; False Paragraph in Free-Format Mode

cobol-preprocessor.ts:1154–1157:

if (/^(?:GO\s+TO|PERFORM|MOVE|...|START)\b/i.test(trimmedLine)
  || RE_PROC_SECTION.test(line) || RE_PROC_PARAGRAPH.test(line)) {
  flushCallAccum(); // Flush CALL without this line's content
  // Fall through to process this line normally

The fix for 14th review New #1 introduced this regression. When callAccum !== null and the line matches RE_PROC_PARAGRAPH = /^\s*([A-Z][A-Z0-9-]+)\.\s*$/i — which includes ANY line consisting of a single identifier + period — flushCallAccum() is called without the current line. In the dominant IBM mainframe coding style where the last USING parameter appears alone on a period-terminated line, it is silently dropped:

       CALL 'CUSTUPDT'
           USING BY REFERENCE WS-CUST-ID
                              WS-CUST-NAME
                              WS-CUST-ADDR.    ← RE_PROC_PARAGRAPH matches

Fixed-format mode: WS-CUST-ADDR. has many leading spaces (Area B). Early flush fires WITHOUT WS-CUST-ADDR. Falls through to extractProcedure where the Area A guard rejects it as a paragraph. Result: WS-CUST-ADDR silently dropped from CALL parameters — missing cobol-call-using ACCESSES edge.

Free-format mode (GnuCOBOL / ACAS benchmark — 268 programs): Same early flush, but isFreeFormat = true means the Area A guard at line 1543 is disabled. WS-CUST-ADDR is created as a false paragraph, currentParagraph = 'WS-CUST-ADDR' — all subsequent PERFORM/MOVE/CALL edges until the next real paragraph are misattributed to the spurious node. The original problem from the 14th review reappears, unchanged, in free-format mode.

Root cause: RE_PROC_PARAGRAPH cannot distinguish between an Area B USING parameter WS-ADDR. and an Area A paragraph header NEXT-PARA. without considering column position. The 14th review fix applies the Area A check in extractProcedure (after the early flush), not inside the callAccum decision block where it is needed.

Fix: Apply the Area A constraint inside the callAccum flush-trigger decision. In fixed-format, only use RE_PROC_PARAGRAPH as a flush trigger when the line is in Area A (≤7 leading spaces). In free-format, never use RE_PROC_PARAGRAPH as a flush trigger (rely only on statement verbs and RE_PROC_SECTION):

const matchesPara = RE_PROC_PARAGRAPH.test(line);
const leadingSpaces = (line.match(/^(\s*)/)?.[1].length ?? 0);
// Fixed-format: only flush for Area A para headers (≤7 spaces). Area B = USING param.
// Free-format: never flush for RE_PROC_PARAGRAPH (no column semantics).
const isParaFlushTrigger = !isFreeFormat && matchesPara && leadingSpaces <= 7;
if (statementVerbMatch || RE_PROC_SECTION.test(line) || isParaFlushTrigger) {
  flushCallAccum();
  // Fall through to process this line normally
} else {
  callAccum += ' ' + line;
  if (/\.\s*$/.test(callAccum) || /\bEND-CALL\b/i.test(callAccum)) {
    flushCallAccum();
  }
  return;
}

This correctly accumulates Area B USING parameters (fixed-format) or any period-terminated parameter line (free-format via the period trigger), while still detecting Area A paragraph headers as a flush signal.

Fix this →

---

🟡 New #B — inspectAccum State Stuck When Real Paragraph Header Arrives Mid-Accumulation

cobol-preprocessor.ts:1637–1643 (inside extractProcedure):

if (inspectAccum !== null) {
  inspectAccum += ' ' + line;
  if (/\.\s*$/.test(inspectAccum)) {
    flushInspect();
  } else {
    return;
  }
}

The inspectAccum block is at position 9 in extractProcedure. Paragraph detection is at position 4 (lines 1536–1548). When inspectAccum !== null and a real paragraph header in Area A (≤7 leading spaces) arrives:

1. Paragraph detection fires → paragraph created → return at line 1548
2. inspectAccum block (line 1637) is never reached
3. inspectAccum retains its partial text unchanged
4. Subsequent lines are appended to the corrupted accumulation
5. flushInspect() eventually runs with multi-statement garbage text

Example:

       INSPECT WS-STATUS
           TALLYING WS-COUNT
       VALIDATE-INPUT.      ← real paragraph header, Area A, ≤7 spaces
           PERFORM CHECK-FIELDS.

VALIDATE-INPUT. creates a paragraph correctly (step 1), but inspectAccum is left pointing at INSPECT WS-STATUS TALLYING WS-COUNT. PERFORM CHECK-FIELDS. is appended to inspectAccum. When a period-terminated line is finally found, flushInspect() extracts counters from the corrupted text.

Fix: In processLogicalLine, add an inspectAccum awareness block before the switch/case (mirroring the callAccum pattern): detect statement verbs and paragraph/section headers → flushInspect() and fall through. The INSPECT block already has a return for pure continuation lines, so the fix only needs to handle the paragraph/section boundary case.

Fix this →

---

🟡 New #C — callAccum Flush Trigger Fires for Data Items Named with COBOL Reserved-Word Prefixes

cobol-preprocessor.ts:1154:

/^(?:GO\s+TO|PERFORM|MOVE|DISPLAY|ACCEPT|INSPECT|SEARCH|SORT|MERGE|IF|EVALUATE|SET|INITIALIZE|STOP|EXIT|GOBACK|CONTINUE|READ|WRITE|REWRITE|DELETE|OPEN|CLOSE|START)\b/i

\b matches between \w and \W. COBOL data items commonly use reserved words as prefixes: MOVE-COUNT, READ-STATUS, WRITE-BUFFER, PERFORM-LIMIT. For such an identifier on a CALL USING parameter line:

       CALL 'RPTGEN'
           USING BY REFERENCE MOVE-COUNT
                              READ-STATUS.

trimmedLine = "USING BY REFERENCE MOVE-COUNT" — starts with USING, OK.
But trimmedLine = "MOVE-COUNT" (if MOVE-COUNT is alone on the line) starts with MOVE\b (boundary between E and - is \w→\W). The early flush fires, MOVE-COUNT is dropped.

Same applies to parameters named PERFORM-CNT, READ-KEY, WRITE-AREA, SEARCH-FOUND.

Fix: change the statement verb regex to require a space or end-of-line after the verb (not just \b): PERFORM(?:\s|$) instead of PERFORM\b. This prevents matching hyphenated identifiers.

Fix this →

---

🟢 New #D — Free-Format CALL USING Last Parameter: No Correct Termination Signal

In free-format mode (isFreeFormat = true), the proposed fix for New #A (not using RE_PROC_PARAGRAPH as a flush trigger) means the only flush triggers are: statement verbs, RE_PROC_SECTION, and the period in the accumulated text. For:

    CALL "PROG"
        USING WS-PARAM-A
              WS-PARAM-B
              WS-PARAM-C.      ← after New #A fix: not a flush trigger, appended to callAccum

WS-PARAM-C. is appended to callAccum, period found → flushCallAccum() with all three params. ✓

However, for free-format with no END-CALL and no period on the last parameter line (which is non-standard but possible in truncated/malformed source), callAccum would accumulate indefinitely until the next period-terminated line. This is the same behavior as any other non-period-terminated CALL and is handled by the EOF flush at line 959.

This is a design note, not a bug — just worth confirming the fix for New #A doesn't introduce a free-format regression.

---

Architectural Fit Assessment

The implementation is in excellent shape after 15 review cycles.

Dimension	Assessment
Boundary integrity	Zero LanguageProvider interface changes — perfect
Area A guard	Correct in concept; the gap is that it's applied after the callAccum flush decision rather than inside it
callAccum design	Intentionally does not return for all continuation lines — allows other constructs to be detected. The early-flush-on-paragraph-match approach is architecturally sound, but the RE_PROC_PARAGRAPH trigger must be column-position-aware
inspectAccum vs paragraph boundary	callAccum has a two-path design (early-flush-and-fall-through vs return). inspectAccum only has the return path. Adding the same two-path design to inspectAccum would make both accumulators consistent
Free-format mode vs fixed-format	The Area A guard correctly differentiates the two modes, but the callAccum early-flush check at line 1154 doesn't carry this differentiation
SORT_CLAUSE_NOISE	Comprehensive ✓
EXCLUDED_PARA_NAMES	Comprehensive ✓
Two-pass CALL/CANCEL resolution	All constructs (CALL, CANCEL, CICS, SQL, SEARCH, ENTRY) use owningModuleId() ✓
findContainingSection	if (resolved) best = resolved guard correctly prevents cross-program contamination ✓
CopyResolution.library dead code	Still captured in cobol-copy-expander.ts but resolveCopy ignores it — misleading interface ⚠️

---

Test Coverage Gap

The 145-test suite (86 unit + 59 integration) doesn't currently cover the New #A scenario:

Gap	Finding
Multi-line CALL with last parameter alone on period-terminated line (WS-CUST-ADDR.) in fixed-format	New #A — missing ACCESSES edge
Same scenario in free-format mode (ACAS-style)	New #A — false paragraph + state corruption
Real paragraph header in Area A while inspectAccum is active	New #B
CALL USING with MOVE-COUNT or PERFORM-LIMIT as a parameter name on its own line	New #C

---

Summary

All 4 findings from the 14th review are verified fixed. The Area A guard (14th #5) and callAccum early-flush detection (14th #1) are the right mechanisms, but they interact in a way that introduces a new issue in the most common IBM COBOL multi-line CALL pattern.

New findings (4 total):

• 🔴 New #A — Last CALL USING parameter dropped when on its own period-terminated Area B line (fixed-format: silent parameter loss; free-format: false paragraph + state corruption). This is the highest-priority remaining issue — it affects the dominant IBM mainframe CALL coding style and corrupts the GnuCOBOL free-format analysis.
• 🟡 New #B — inspectAccum state stuck when a real paragraph header arrives during accumulation (fix: add inspectAccum early-flush detection mirroring callAccum pattern)
• 🟡 New #C — callAccum flush trigger incorrectly fires for USING parameters named MOVE-COUNT, PERFORM-LIMIT, READ-STATUS etc. (fix: \b → (?:\s|$) in verb pattern)
• 🟢 New #D — Design note confirming the New #A fix doesn't introduce free-format regression

Priority order:

1. New #A — Column-position-aware flush trigger in callAccum; one-condition change with high correctness ROI for both fixed-format (parameter retention) and free-format (false paragraph prevention). This must be fixed before indexing the ACAS benchmark with the current branch.
2. New #C — One-character change in the verb regex (\b → (?:\s|$)); prevents USING parameter loss for common hyphenated identifier names.
3. New #B — Adds inspectAccum two-path design consistent with callAccum; affects rare but real edge case.

[magyargergo]

@claude ultra-think while identifying COBOL-language gaps. Perfom this analysis on this pull request and verify those findings. Act as a senior compiler font-end engineer and expert in static analysis tools and review this change from that perpective and review the architectural fit. Also check out previous comments and reason with their requests.

[github-actions]

Claude finished @magyargergo's task in 15m 6s —— View job

---

COBOL Processor — Sixteenth Deep Review (Compiler Front-End / Static Analysis Perspective)

Tasks:

• Post initial comment
• Read all COBOL processor source files (current state post-commits 3296201/5aa0e18)
• Verify all 15th review findings against current code
• Deep compiler front-end analysis — new gap identification
• Architectural fit review
• Post final comprehensive review

---

15th Review — Verification Status

All 4 findings from the 15th review verified against the current branch. Ground truth:

#	Finding	Status
15th #A	Last CALL USING parameter dropped / false paragraph in free-format when callAccum flushes on RE_PROC_PARAGRAPH	✅ FIXED — isAreaAParagraph = RE_PROC_PARAGRAPH.test(line) && (!isFreeFormat ? leadingSpaces <= 7 : false) at line 1157; free-format always false
15th #B	inspectAccum state stuck when paragraph header arrives mid-accumulation	✅ FIXED — identical two-path guard at lines 1643-1659: inspIsAreaAPara + fall-through flush
15th #C	callAccum flush trigger fires for MOVE-COUNT, PERFORM-LIMIT etc.	✅ FIXED — verb regex uses (?:\s|$) at line 1158 (prevents hyphenated-identifier false matches)
15th #D	Free-format CALL USING last parameter — design note	✅ Confirmed: period in accumulated text triggers flush; design is correct

Score: All 60+ prior tracked findings verified resolved or WONTFIX across 15 review cycles.

---

New Findings (This Review)

🔴 New #1 — CANCEL Inside Multi-Line CALL ... ON EXCEPTION ... END-CALL Is Silently Lost

cobol-preprocessor.ts:1353–1384 (flushCallAccum)

When callAccum accumulates a full CALL ... END-CALL block, flushCallAccum() processes the accumulated text using only text.matchAll(RE_CALL) and text.matchAll(RE_CALL_DYNAMIC). There is no RE_CANCEL pass.

For the extremely common IBM mainframe COBOL error-handling pattern:

       CALL 'SUBPROG'
           USING WS-DATA
           ON EXCEPTION
               CANCEL 'SUBPROG'
               CALL 'SUBPROG'     ← retry
       END-CALL.

callAccum accumulates all lines until END-CALL.. In flushCallAccum:

• RE_CALL finds both SUBPROG calls (first and retry) ✅
• CANCEL 'SUBPROG' → no RE_CANCEL extraction — the CANCEL is silently lost

The CANCEL inside the ON EXCEPTION block is completely invisible to the graph. Any impact analysis for "which programs are cancelled when SUBPROG fails?" misses this edge entirely.

Note: the callAccumFlushedThisLine / Area A approach correctly prevents false paragraphs from CANCEL targets because 'SUBPROG'. doesn't match RE_PROC_PARAGRAPH. But CANCEL itself goes unextracted.

Fix: add a RE_CANCEL extraction pass inside flushCallAccum, mirroring the RE_CALL loop:

for (const cancelMatch of text.matchAll(RE_CANCEL)) {
  result.cancels.push({ target: cancelMatch[1] ?? cancelMatch[2], line: callAccumLine, isQuoted: true });
}
for (const dynCancelMatch of text.matchAll(RE_CANCEL_DYNAMIC)) {
  result.cancels.push({ target: dynCancelMatch[1], line: callAccumLine, isQuoted: false });
}

Fix this →

---

🔴 New #2 — CANCEL Keyword Falsely Captured as USING Parameter in Pre-COBOL-85 Style

cobol-preprocessor.ts:1361 (USING lookahead in flushCallAccum)

The current USING lookahead in flushCallAccum:

/\bUSING\s+([\s\S]*?)(?=\bRETURNING\b|\bON\s+(?:EXCEPTION|OVERFLOW)\b|\bNOT\s+ON\b|\bEND-CALL\b|\bINSPECT(?=\s|$)|...|\.\s*$|$)/i

\bCANCEL\b is not in the lookahead. In legacy pre-COBOL-85 code where CALL and CANCEL appear on consecutive lines terminated by the CANCEL's period:

       CALL 'PROG-A'
           USING WS-DATA
       CANCEL 'OLD-PROG'.     ← CANCEL's period terminates callAccum

callAccum accumulates all three lines until the CANCEL's period. In flushCallAccum:

• usingMatch[1] captures WS-DATA CANCEL (lazy match stops at .\s*$)
• After split(/\s+/).filter(...): ['WS-DATA', 'CANCEL'] — CANCEL passes the identifier regex /^[A-Z][A-Z0-9-]+$/i and is NOT in CALL_USING_FILTER
• CANCEL is falsely stored as a USING parameter for PROG-A

Additionally, 'OLD-PROG' is missed (same as New #1).

Fix: add \bCANCEL(?=\s|$) and \bEVALUATE(?=\s|$) to the USING lookahead as additional boundary alternatives. Also add CANCEL to the callAccum flush trigger list at line 1158:

/^(?:GO\s+TO|PERFORM|MOVE|...|CANCEL)(?:\s|$)/i

Fix this →

---

🟡 New #3 — Multi-Line CALL Start Without Period Simultaneously Feeds sortAccum/inspectAccum

cobol-preprocessor.ts:1176–1181 and cobol-preprocessor.ts:1624–1637

When a multi-line CALL starts (no period, not single-line), callAccum = line is set at line 1177 but there is no return. The switch at line 1184 still calls extractProcedure(line, lineNum).

If sortAccum !== null at that point, extractProcedure appends the CALL start line to sortAccum (line 1626):

// Line 1626 in extractProcedure — no CALL boundary check here
sortAccum += ' ' + line;

Subsequent CALL continuation lines return early at line 1167 (return; // continuation line consumed), so they don't reach extractProcedure. But the CALL start line IS appended to sortAccum.

When sortAccum eventually flushes, the CALL keyword and program name appear in the accumulated SORT text. flushSort() extracts SORT_CLAUSE_NOISE-filtered names, but CALL and the program name (e.g., CUSTPRC) are not in SORT_CLAUSE_NOISE — they pass the identifier filter and become false SORT GIVING file entries, producing phantom sort-giving ACCESSES edges.

This scenario only occurs when a SORT statement lacks its terminating period before a CALL starts (technically invalid COBOL), but it has been observed in partial source extractions from mainframe repositories.

Fix: add an early return after starting multi-line CALL accumulation:

} else {
  // Multi-line CALL — start accumulating
  callAccum = line;
  callAccumLine = lineNum;
  return; // Don't pass the CALL start line to extractProcedure
}

Alternatively, add CALL to sortAccum/inspectAccum flush triggers inside extractProcedure.

Fix this →

---

🟡 New #4 — In Free-Format Mode, Real Paragraph Headers Absorbed Into callAccum When CALL Lacks Terminator

cobol-preprocessor.ts:1155–1167

In free-format mode, isAreaAParagraph = false (the ternary at line 1157 always evaluates the right branch to false). This correctly prevents WS-CUST-ADDR. from being treated as a paragraph header. However, it also means a real paragraph header like NEXT-PARA. arriving while callAccum is active is absorbed into the accumulation rather than treated as a flush signal.

For a GnuCOBOL (ACAS-style) program:

    CALL 'PROG'
        USING WS-DATA
NEXT-PARA.                  ← no END-CALL, no period before paragraph
    PERFORM PROCESS.

NEXT-PARA. → isAreaAParagraph = false → accumulated into callAccum → period triggers flushCallAccum(). Result:

• NEXT-PARA is captured as a USING parameter for PROG (passes [A-Z][A-Z0-9-]+ regex, not in CALL_USING_FILTER)
• NEXT-PARA. never reaches extractProcedure → paragraph not added to result.paragraphs → no Function node → PERFORM PROCESS below it has caller attributed to the wrong paragraph

This is the fundamental free-format tension: without column-position information, WS-CUST-ADDR. (legitimate parameter) and NEXT-PARA. (paragraph header) are syntactically identical. The 15th review fix chose to avoid false parameters (correct for the common ACAS benchmark case), but this creates the paragraph-missed problem for programs that don't use END-CALL.

In practice, well-formatted GnuCOBOL programs consistently use END-CALL, so the real paragraph is preceded by END-CALL which triggers proper callAccum flush. The issue only occurs for pre-COBOL-85 free-format style. Worth noting for the ACAS benchmark verification.

---

🟢 New #5 — Paragraph endLine Calculation Crosses Nested Program Boundaries

cobol-processor.ts:423–427:

const nextLine = i + 1 < extracted.paragraphs.length
  ? extracted.paragraphs[i + 1].line - 1
  : lines.length;

All paragraphs across all nested programs are in a single sorted extracted.paragraphs array. When the outer program has paragraph at line 20 and the inner program has paragraph at line 28, the outer paragraph's endLine is computed as 28 - 1 = 27 — a line inside the inner program. The paragraph extends "into" the inner program's territory in the graph.

For a single-program file or files with unique paragraph names (as in the test fixtures), this is invisible. For nested programs where outer paragraphs precede inner program boundaries, the endLine is incorrect.

Fix requires a program-boundary-aware nextLine computation: find the next paragraph at the same nesting depth, not just the next paragraph globally.

---

🟢 New #6 — callAccum Not Flushed on Division/Section Transitions (Malformed COBOL Edge Case)

cobol-preprocessor.ts:1083–1133 vs 1150

The division transition check at line 1083 (RE_DIVISION) and section transition at line 1118 (RE_SECTION) both return before reaching the callAccum block at line 1150. For a file where a CALL statement is the last outer-program statement before a nested IDENTIFICATION DIVISION. header — without a terminating period — callAccum is not flushed and the CALL leaks into the inner program's state.

This only occurs for invalid COBOL (missing final period), and the effect is that the outer CALL is attributed to the outer program (since callAccumLine predates the inner program) but USING parameters from subsequent inner-program lines are falsely included. Low impact for well-formed COBOL. Mentioning for completeness.

---

Test Coverage Assessment

The recent 49 new regression tests (commits 3296201 and 5aa0e18) cover the area A/free-format fixes well. Missing test scenarios for new findings:

Gap	Finding
CALL 'PROG' USING WS-DATA ON EXCEPTION CANCEL 'PROG' END-CALL. — CANCEL inside ON EXCEPTION block	New #1
Pre-COBOL-85 style: CALL 'A' USING WS-DATA then CANCEL 'B'. on next line	New #2
Multi-line SORT followed immediately by multi-line CALL (no period on SORT)	New #3
Free-format: paragraph header while callAccum active without END-CALL	New #4

---

Architectural Fit Assessment

The implementation remains architecturally sound and well-factored after 16 review cycles.

Dimension	Assessment
Boundary integrity	Zero LanguageProvider interface changes — perfect
callAccum design	Multi-path accumulator (Area A / statement verb detection) is correct for fixed-format. Free-format limitation (New #4) is a fundamental tension without a clean solution
flushCallAccum completeness	Extracts quoted + dynamic CALLs correctly. Missing: CANCEL extraction (New #1), CANCEL boundary in USING lookahead (New #2)
callAccum start fall-through	Multi-line CALL start doesn't prevent extractProcedure from running — can corrupt sortAccum/inspectAccum (New #3)
owningModuleId() coverage	All CALL/CANCEL/CICS/SQL/ENTRY/SORT constructs use correct nested-program scoping ✅
Two-pass CALL/CANCEL resolution	Both quoted and dynamic forms; all CICS variants ✅
SORT_CLAUSE_NOISE	Comprehensive for SORT/MERGE keyword noise; doesn't help against callAccum contamination (New #3)
EXCLUDED_PARA_NAMES	Now includes common verbs; still missing PERFORM, INSPECT, EVALUATE as paragraph false-positive candidates
CopyResolution.library	Still captured but resolveCopy ignores it — dead code / misleading interface ⚠️
Paragraph endLine calculation	Crosses nested program boundaries (New #5) — architectural limitation

---

Summary

All 4 findings from the 15th review verified as fixed. 60+ findings across 16 review cycles; excellent progression.

New findings (6 total):

• 🔴 New Add support for Ollama as a local inference backend #1 — CANCEL inside CALL ... ON EXCEPTION ... END-CALL silently lost. flushCallAccum uses only RE_CALL/RE_CALL_DYNAMIC; no RE_CANCEL pass. Common IBM mainframe error-handling pattern. One-loop fix.
• 🔴 New Welcome to GitNexus Discussions! #2 — CANCEL keyword falsely captured as USING parameter in pre-COBOL-85 style (when CANCEL's period terminates callAccum). CANCEL not in USING lookahead. One-regex fix in flushCallAccum + add CANCEL to flush trigger list.
• 🟡 New readme #3 — Multi-line CALL start falls through to extractProcedure, contaminating active sortAccum/inspectAccum with CALL text (false SORT file names). Add return after multi-line CALL start, or add CALL to sort/inspect flush triggers.
• 🟡 New Embeddings pipeline #4 — Free-format paragraph headers absorbed into callAccum when CALL lacks END-CALL (paragraph missed, name falsely in USING). Fundamental free-format tension; only for pre-COBOL-85 style without scope terminators.
• 🟢 New Embeddings pipeline #5 — Paragraph endLine crosses nested program boundaries (off-by-N for paragraphs preceding nested program sections).
• 🟢 New highlight tool for agent, prompt enhancements #6 — callAccum not flushed on division/section transitions (only for malformed COBOL with missing final period).

Priority order:

1. New Add support for Ollama as a local inference backend #1 — One-loop addition to flushCallAccum; closes a gap in a very common IBM mainframe CALL pattern (ON EXCEPTION CANCEL). High ROI.
2. New Welcome to GitNexus Discussions! #2 — Add CANCEL to USING lookahead + flush trigger list; prevents parameter list corruption for legacy COBOL.
3. New readme #3 — Add return after multi-line CALL start; prevents sortAccum/inspectAccum contamination.

Production readiness: The implementation is production-quality for all well-formed COBOL. New #1 is the only gap that affects common, valid (with scope terminators) IBM mainframe code.

---

[magyargergo]

@claude ultra-think while identifying COBOL-language gaps. Perfom this analysis on this pull request and verify those findings. Act as a senior compiler font-end engineer and expert in static analysis tools and review this change from that perpective and review the architectural fit. Also check out previous comments and reason with their requests.

[github-actions]

Claude finished @magyargergo's task in 13m 30s —— View job

---

18th Review — 17th Review Findings Resolved ✅

Commit 88d1b68 implements both substantive fixes from the 17th review.

---

17th Review — Verified Fixed

#	Severity	Finding	Status
New #1	🔴	callAccum not flushed when EXEC SQL/CICS/DLI block starts	✅ Fixed
New #2	🟡	inspectAccum flush trigger missing 14 verbs vs callAccum	✅ Fixed
New #3	🟢	CANCEL double-extracted for single-line CALL…CANCEL…END-CALL	ℹ️ Accepted (graph-level idempotent)
New #4	🟢	Section transitions don't flush callAccum	ℹ️ Accepted (well-formed COBOL constraint)

---

Fix Details

New #1 — flushCallAccum() before every EXEC entry (lines 1021, 1031, 1040)

Any multi-line CALL whose terminating period appears only after END-EXEC was silently abandoned — the EXEC early-return bypassed the accumulator check entirely. Adding flushCallAccum() before each of the three execAccum assignments mirrors the existing pattern at division and END PROGRAM boundaries.

* Before fix: this CALL was dropped
CALL 'PGMX'
     USING WS-PARM                 ← no period here
     EXEC SQL SELECT …              ← EXEC early-returns, callAccum orphaned
     END-EXEC.

New #2 — inspectAccum flush trigger brought to parity with callAccum (line 1663)

The inspectAccum trigger previously covered only 11 verbs; callAccum's trigger covers 25. The 14 missing verbs (ACCEPT, INSPECT, SEARCH, SORT, MERGE, IF, EVALUATE, CONTINUE, READ, WRITE, REWRITE, DELETE, OPEN, CLOSE, START) meant that an in-flight INSPECT block would absorb subsequent statements rather than closing, silently hiding graph edges from SEARCH, SORT, I/O verbs, and structured control flow.

---

Remaining Open Items

Finding	Source	Severity	Notes
Paragraph endLine ignores nested program boundaries	16th review #5	🟢 Cosmetic	Next paragraph's line - 1 may bleed into inner/outer program

No new architectural gaps found in this pass. The accumulator state machine is now consistent across all flush boundaries (division, END PROGRAM, EXEC entry, paragraph/section detection).

[magyargergo]

@claude ultra-think while identifying COBOL-language gaps. Perfom this analysis on this pull request and verify those findings. Act as a senior compiler font-end engineer and expert in static analysis tools and review this change from that perpective and review the architectural fit. Also check out previous comments and reason with their requests.

[github-actions]

Claude finished @magyargergo's task in 8m 56s —— View job

---

19th Review — COBOL Processor Deep Analysis (commit 7e52f98)

Reviewer persona: senior compiler front-end engineer / static analysis tooling expert.
All prior findings re-verified against current code before identifying new gaps.

---

✅ Verification — 17th / 18th Review Items

#	Finding	Status
17.1	callAccum not flushed when EXEC SQL/CICS/DLI starts	✅ Fixed — flushCallAccum() called at lines 1050, 1060, 1069
17.2	inspectAccum flush trigger missing 14 verbs vs callAccum	✅ Fixed — both now share RE_STATEMENT_VERB_START
17.3	CANCEL double-extraction for single-line CALL...CANCEL...END-CALL	✅ Accepted — idempotent at graph-edge level
17.4	Section transitions don't flush callAccum	✅ Accepted — well-formed COBOL invariant documented
18.1	EXEC block flushCallAccum() ordering	✅ Fixed — flush occurs before execAccum is set

---

🔴 Finding 1 — END PROGRAM does not flush callAccum (HIGH)

Location: cobol-preprocessor.ts lines 1078–1093

const endProgramMatch = line.match(RE_END_PROGRAM);
if (endProgramMatch) {
  const topProgram = programBoundaryStack.pop();
  // ... push to result.programs ...
  return;   // ← callAccum NOT flushed
}

Impact: If a multi-line CALL statement is left open at the end of Program A's procedure division and END PROGRAM PROG-A. is the next structural line, callAccum silently carries live state across the program boundary. The accumulated text from Program A is then either:

• Flushed during Program B's first matching flush trigger (wrong owning program, wrong callAccumLine), or
• Silently dropped if Program B has no subsequent flush trigger before the file ends.

Concrete trigger:

       CALL 'PROG-A-SUB' USING WS-DATA       ← no period, no END-CALL
       END PROGRAM OUTER.                     ← returns without flush
       PROGRAM-ID. INNER.                     ← flush still pending

Fix: Call flushCallAccum(); flushSort(); flushInspect(); before the return in the endProgramMatch block — identical to the division-boundary flush at lines 1119–1122.

---

🔴 Finding 2 — PROGRAM-ID detection path does not flush callAccum (HIGH)

Location: cobol-preprocessor.ts lines 1107–1113

if (currentDivision !== 'identification') {
  const pgmIdMatch = line.match(RE_PROGRAM_ID);
  if (pgmIdMatch) {
    extractIdentification(line, lineNum);
    return;   // ← callAccum NOT flushed
  }
}

This path is reached for sibling programs whose IDENTIFICATION DIVISION. header is omitted (common in COBOL source that uses abbreviated structure after END PROGRAM). The comment at line 1105 confirms this intent.

Impact: Compounds Finding 1. Even when END PROGRAM is present, if the next non-blank line is PROGRAM-ID. rather than IDENTIFICATION DIVISION., callAccum is still not flushed at this second-chance boundary. The accumulated CALL text from Program A gets attributed to Program B via callAccumLine which still points into Program A's line range.

Fix: Same as Finding 1 — add flush calls before return here.

---

🟡 Finding 3 — Arithmetic verbs absent from COBOL_STATEMENT_VERBS (MEDIUM)

Location: cobol-preprocessor.ts lines 377–398

const COBOL_STATEMENT_VERBS = [
  'GO\\s+TO', 'PERFORM', 'MOVE', 'DISPLAY', 'ACCEPT',
  'INSPECT', 'SEARCH', 'SORT', 'MERGE', 'IF', 'EVALUATE',
  'SET', 'INITIALIZE', 'STOP', 'EXIT', 'GOBACK', 'CONTINUE',
  'READ', 'WRITE', 'REWRITE', 'DELETE', 'OPEN', 'CLOSE', 'START',
  'CANCEL',
  // ← COMPUTE, ADD, SUBTRACT, MULTIPLY, DIVIDE, STRING, UNSTRING absent
];

Impact: A multi-line CALL with an arithmetic continuation (pre-COBOL-85 implicit termination via the next statement's period) is not flushed when the arithmetic line is encountered. Instead the arithmetic line is appended to callAccum. When the period on the arithmetic line triggers flushCallAccum(), RE_USING_PARAMS scans the combined text and extracts identifiers from the arithmetic line as false USING parameters:

       CALL 'PAYROLL' USING WS-RATE WS-HOURS
       COMPUTE WS-TOTAL = WS-RATE * WS-HOURS.

After accumulation, flushCallAccum sees:

CALL 'PAYROLL' USING WS-RATE WS-HOURS COMPUTE WS-TOTAL = WS-RATE * WS-HOURS.

RE_USING_PARAMS stops at \. (period) and the CALL_USING_FILTER does not contain COMPUTE or WS-TOTAL. The identifier filter /^[A-Z][A-Z0-9-]+$/i matches COMPUTE and WS-TOTAL, injecting them as phantom parameters.

Affected verbs to add: COMPUTE, ADD, SUBTRACT, MULTIPLY, DIVIDE, STRING, UNSTRING — all are COBOL statement-opening verbs that cannot legally appear within a CALL's USING clause.

Fix: Add these seven verbs to COBOL_STATEMENT_VERBS. They will automatically propagate into RE_STATEMENT_VERB_START (callAccum / inspectAccum flush trigger) and USING_VERB_LOOKAHEAD (RE_USING_PARAMS terminator), closing both the flush gap and the false-parameter extraction gap simultaneously.

---

🟢 Finding 4 — Section endLine crosses nested program boundaries (LOW / cosmetic)

Location: cobol-processor.ts lines 392–394 (same as 16th review finding #5 — still present)

const nextLine = sections[i + 1]?.line - 1 ?? fileLines;

Section i and section i+1 may belong to different nested programs. endLine is over-extended across the program boundary, producing a wider line range than the true section scope. This does not affect correctness of edges (owning module is resolved by owningModuleId() / findOwningProgramName()), but makes Namespace node metadata misleading in the graph output.

---

Architectural Fit Assessment

Dimension	Assessment
Approach (regex vs tree-sitter)	Correct tradeoff for an indexing tool: regex is fast, streaming, and maintainable without a parser generator toolchain. The accumulator state machines (callAccum, sortAccum, inspectAccum, selectAccum, execAccum) are the right pattern for multi-line COBOL statements.
Two-pass CALL/CANCEL resolution	Architecturally sound. First pass emits unresolved edges; second pass resolves via cics-*-unresolved catch-all and program name lookup. Handles inter-file edges correctly.
Shared verb constants	COBOL_STATEMENT_VERBS + RE_STATEMENT_VERB_START + USING_VERB_LOOKAHEAD derived from one source of truth — excellent. Findings 1–3 show the pattern is applied consistently; only the arithmetic verb gap and program-boundary flush remain as exceptions.
Area A guard	Fixed-format paragraph detection at ≤7 leading spaces is correct and avoids the classic CALL USING false-paragraph bug. Free-format correctly disables this guard.
Nested program support	programBoundaryStack + findOwningProgramName() + owningModuleId() is clean. Findings 1–2 are the only gaps in the boundary tracking.
CICS global scoping	<cics-file>:FILENAME key design is pragmatic for cross-program VSAM analysis.

---

Priority Summary

Priority	Finding	Effort
🔴 HIGH	END PROGRAM does not flush callAccum (Finding 1)	1 line
🔴 HIGH	PROGRAM-ID sibling path does not flush callAccum (Finding 2)	1 line
🟡 MEDIUM	Arithmetic verbs missing from COBOL_STATEMENT_VERBS (Finding 3)	7 tokens
🟢 LOW	Section endLine crosses nested program boundary (Finding 4)	cosmetic

Findings 1 and 2 are one-liners each (add flushCallAccum(); flushSort(); flushInspect(); before return). Finding 3 requires adding seven verb strings to one array constant — the propagation into all three derived regexes is automatic.

[magyargergo]

@claude ultra-think while identifying COBOL-language gaps. Perfom this analysis on this pull request and verify those findings. Act as a senior compiler font-end engineer and expert in static analysis tools and review this change from that perpective and review the architectural fit. Also check out previous comments and reason with their requests.

[github-actions]

Claude finished @magyargergo's task in 8m 44s —— View job

---

20th Review — Compiler Front-End & Static Analysis Audit

Acting as a senior compiler front-end engineer and static analysis expert.

---

✅ 19th Review Findings — Verification

#	Finding	Status
1	END PROGRAM block did not flush callAccum / sortAccum / inspectAccum	✅ FIXED — flushCallAccum(); flushSort(); flushInspect(); at lines 1083–1085
2	PROGRAM-ID detection path did not flush accumulators before starting new program scope	✅ FIXED — same three flush calls at lines 1115–1117
3	Arithmetic verbs (COMPUTE, ADD, SUBTRACT, MULTIPLY, DIVIDE, STRING, UNSTRING) absent from COBOL_STATEMENT_VERBS, causing accumulator to never flush on those statement boundaries	✅ FIXED — all seven verbs added to COBOL_STATEMENT_VERBS at lines 382–383
4	section.endLine calculation crosses nested program boundaries (cosmetic — graph endLine wrong on boundary sections)	⚠️ Still present — cosmetic, no action required unless precise endLine fidelity is needed

All three actionable fixes from the 19th review are confirmed in-place. The cosmetic boundary issue remains as acknowledged.

---

🔬 New Findings — 20th Review

Finding 1 — RE_INITIALIZE captures only the first target identifier 🟡 MEDIUM

Location: cobol-preprocessor.ts line 313
Pattern: RE_INITIALIZE = /\bINITIALIZE\s+([A-Z][A-Z0-9-]+)/i

The regex captures exactly one identifier after INITIALIZE. In standard COBOL, INITIALIZE accepts a space-separated list of targets:

INITIALIZE WS-CUSTOMER WS-ORDER WS-LINE-ITEM.

With the current pattern, only WS-CUSTOMER produces an ACCESSES write edge. WS-ORDER and WS-LINE-ITEM are silently dropped — meaning the data-flow graph is incomplete for any multi-target INITIALIZE.

Fix: Replace the single-capture regex with a matchAll loop over token positions, or capture the full tail and split on whitespace (filtering out WITH, REPLACING, ALL, ALPHABETIC, NUMERIC, etc. which are INITIALIZE clause keywords):

RE_INITIALIZE_TAIL = /\bINITIALIZE\s+((?:[A-Z][A-Z0-9-]+\s*)+)/i
// then: tail.match(/[A-Z][A-Z0-9-]+/gi)?.filter(t => !INITIALIZE_CLAUSE_KEYWORDS.has(t))

This is the same matchAll pattern already used for CALL/CANCEL extraction and is consistent with the rest of the pipeline.

---

Finding 2 — COPY detection runs before callAccum continuation guard 🟢 LOW

Location: cobol-preprocessor.ts lines 1179–1193 (processLogicalLine)

The COPY detection block executes unconditionally before the callAccum block. In formally valid COBOL a COPY statement cannot appear mid-CALL; however a source file with a malformed or concatenated COPY inside a CALL argument list (e.g. a source generator artefact) would:

1. Push a spurious entry to result.copies
2. Skip the callAccum continuation, silently abandoning the in-progress CALL

This is an edge case for invalid source only, but a static analyser operating on real-world legacy codebases (which frequently contain pre-processor noise) will encounter it. No action required for MVP, but worth a defensive if (callAccum) { flushCallAccum(); } before the COPY push if robustness against malformed input is ever needed.

---

Finding 3 — Single-line CALL + active sortAccum contamination 🟢 LOW

Location: cobol-preprocessor.ts lines 1213–1225 (single-line CALL path in processLogicalLine)

The single-line CALL path (terminated by a period or END-CALL on the same line) does not return early from processLogicalLine by design — it falls through to extractProcedure. If sortAccum happens to be active at the same time (which requires invalid COBOL — overlapping SORT and CALL blocks), the CALL line text gets appended to sortAccum, potentially producing phantom file-name tokens in SORT edges.

This only manifests on structurally invalid COBOL and is therefore informational only.

---

Finding 4 — CopyResolution.library is captured but never consumed 🟢 LOW (dead code)

Location: cobol-copy-expander.ts — CopyResolution interface and resolveCopy function

The library field of CopyResolution is populated by the resolution logic but is never read by the caller. This means COPY member IN library or COPY member OF library library qualifiers are parsed and discarded — any disambiguation between identically-named copybooks in different libraries is silently lost.

For a future graph that models library-qualified COPY dependencies (e.g. COPY CUSTIO IN BATCHLIB) this is a pre-existing architectural gap. No immediate action required, but library should either be wired into the node/edge attribution or the field should be removed to avoid giving false assurance that library qualification is handled.

---

🏗️ Architectural Fit Assessment

Strengths (compiler front-end perspective):

• The two-phase architecture (preprocessor extracts, processor maps to graph) correctly separates syntactic concerns from semantic graph construction — analogous to a front-end IR lowering pass.
• The COBOL_STATEMENT_VERBS single source of truth (shared by callAccum flush trigger, inspectAccum flush trigger, and RE_USING_PARAMS lookahead) is the right pattern for a regex-based tokeniser — changes propagate consistently.
• programBoundaryStack + owningModuleId() correctly models COBOL nested-program scoping as a stack — the right data structure for a block-scoped symbol table.
• Two-pass CALL/CANCEL resolution (<unresolved>:PROGNAME synthetic IDs) correctly defers link resolution until all nodes exist, matching the linker-resolution step in compiled languages.
• Area A / Area B column guards for paragraph detection (leadingSpaces <= 7) correctly encode COBOL fixed-format layout rules — without this, every DISPLAY statement could be misidentified as a paragraph name.

Residual concerns:

• The regex pipeline is a hand-rolled lexer with no formal grammar. This is appropriate for the stated scope (graph extraction from legacy COBOL, not full compilation), but the lack of a token stream means certain statement boundaries are context-dependent on accumulator state rather than syntax. The COBOL_STATEMENT_VERBS set is the de-facto token classifier; keeping it exhaustive is important for correctness.
• Free-format (>>SOURCE FREE) detection is a single-pass flag — no column-range validation is applied in free-format mode. This is acceptable given that free-format COBOL is rare in the legacy corpus this tool targets.
• The RE_INITIALIZE single-target gap (Finding 1) is the only remaining medium-severity data-flow accuracy issue. All other new findings are low-severity edge cases.

---

Priority Ordering

Priority	Item
1	Fix RE_INITIALIZE multi-target gap (Finding 1) — data-flow completeness
2	Wire or remove CopyResolution.library (Finding 4) — dead code hygiene
3	Document COPY-before-callAccum ordering (Finding 2) — robustness note
4	Document single-line CALL + sortAccum (Finding 3) — informational
5	Section endLine crossing nested program boundaries — cosmetic, carry forward

---

Overall: The three actionable findings from the 19th review are confirmed fixed. The preprocessor is in good shape for production use. The one remaining medium-severity gap is the INITIALIZE multi-target extraction. All other new findings are low-severity edge cases or dead-code hygiene items.

Task checklist

• Post initial comment
• Read all COBOL processor source files
• Verify all 19th review findings against current code
• Deep compiler front-end analysis — new gap identification
• Architectural fit review
• Post final comprehensive review