Translation fidelity along the traceability map: compare each COBOL paragraph with the Java method it became

オープン
  • 何か問題がありますか？
#7,532 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java, python
領域
tooling

調査の方向性

Start from traceability.json produced by the forge/det-port, which maps each generated Java method to its COBOL source line and fact, and from the existing structural fingerprint tooling (sfs) the issue contrasts against. The new tool goes under tests/tools/; first check how traceability entries link paragraphs to methods. Done means a per-paragraph structural comparison with shuffled and unrelated controls, plus a run on the burned-estate ports in both styles.

索引モデルが issue の本文から書いたものです。

説明

enhancement legacy-modernization

Why

A structural-fidelity analysis of the det-port on the burned estates (2026-11-02; ~/gitgalaxy/cics-fidelity/ on nyx) found two things:

  • The translations are complete: 184 cases, 47,717 statements, 0 holes.
  • They keep each estate's relative structure: the between-program distance geometry is preserved (Mantel ρ 0.45-0.47, p = 0.001), and per-program function count and size correlate 0.82-0.86.

But a global fingerprint (sfs, portable or structure lens) cannot pick out a port's own COBOL source: 1-3 of 124 programs, against 0.8 % chance. A plain size matcher does better. The reason is that det-port Java is mechanical by design: byte storage, a runtime, one call per statement, dispatch methods. Every port has the same shape, a median of 32-36 Java methods against 7 COBOL paragraphs, and that shared style swamps each program's individual signal.

So whole-program fingerprints are the wrong instrument for translation fidelity. The forge and det-port already know the mapping: every generated class and method is traced to its source line and fact (traceability.json). Fidelity should be measured along that map.

Proposal

For each translated program, pair every COBOL paragraph or section with the Java method(s) traced to it, and compare their structure:

  • branch outcomes (IF/EVALUATE/PERFORM UNTIL against if/switch/loops);
  • calls out (PERFORM / CALL / LINK against invocations);
  • size, and the reads/writes of data items against field access.

Report per program, per paragraph and per estate:

  • the share of paragraphs whose structure survives within a tolerance;
  • the outliers;
  • an estate-level fidelity score.

Controls: shuffled paragraph-method pairs, and pairs from unrelated programs, so a fidelity score comes with its chance level.

Where it fits

  • The architecture roadmap's "cross-language blueprint fidelity" item.
  • A structural layer beside the equivalence proofs. Proofs say the Java does what the COBOL did; this would say the Java is shaped like the COBOL, paragraph by paragraph, which is what a reviewer reads.
  • It is measurement only: no new cases or proofs on the burned estates (that evidence work is melek's lane).

Acceptance

  • A tool (tests/tools/…) that reads a port plus its traceability.json and writes a per-paragraph structural comparison.
  • Shuffled and unrelated controls, with the score reported against them.
  • A run over the burned-estate det-ports in both styles (default, --style structured --typed --groups), with the headline numbers posted here.
主要言語
Python
スター
57
フォーク
11
平均マージ
1時間 30分
マージ済み PR（30日）
973

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

squid-protocol/gitgalaxy のほかの issue

squid-protocol/gitgalaxy の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。