The Emerging Economics of Iteratively Solving CICS → Java Transpilation: a generated cost / blocker / convergence analysis and infographic

Open
  • Is something wrong?
#5,052 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
18/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
data, data-visualization

Research direction

Start with the inputs the stage must join: handoffs/churn-state.json (usage.log), churn-runs/*/meta.json, field_testing.json, and the evidence records, then read field_testing.py report as the model for the staleness check. The port-blocker ledger from #5051 is a dependency that is not in this payload, so confirm it has landed first. Done means the scheduled stage publishes econ.json and the infographic to the generated branch, and the page states its counting rules.

Written by the indexing model from the issue text.

Description

documentation legacy-modernization metrics priority: low scope:frontier

Claim to show. The software factory has turned CICS → Java translation into an iteratively solvable problem: each estate exposes blockers, each blocker is a bounded, priced fix, and the cost of the next estate falls. Today that rests on numbers pulled together by hand in a chat session. It should be a standard, generated analysis in the data-flow pipeline, published as an infographic with the data behind it: "The Emerging Economics of Iteratively Solving CICS → Java Transpilation."

Today's numbers (hand-pulled 2026-10-13, to be replaced by the generated report):

  • Per-issue worker cost (churn spend ledger, 51 issues since 2026-10-11): median $1.96, mean $3.36, IQR $1.18–$3.73, p90 $6.18; 27 of 51 needed more than one run. Tail = new CICS API areas (#4950 async $24, #4767 WEB $18).
  • Daily: Oct 12, 2 workers ~$124 → 14 mainframe PRs merged; Oct 13, 1 worker $76 → 12 merged ($6 per merged mainframe fix all-in; orchestrator ~20%).
  • Estate-specific port blockers (keyword-attributed, ±25%): CardDemo 40, CBSA 17, GenApp 11, zECS 5, DBB 3, async credit card 2 → ~1.3 → 0.6 → 0.4 → 0.25 per program in port order (zECS the exception: new API areas).
  • Discovery vs. closure: issues opened ≈ closed on 2026-10-13 (11/11); opened > closed Oct 8–12 (much of it sibling-sweep filing, not estate discovery).

Proposal. A pipeline stage (scheduled, like the evidence refresh) that joins:

  1. the churn spend ledger (handoffs/churn-state.json usage.log: model, tokens, cost_usd, issue, run_id) and churn-runs/*/meta.json; agy runs with their real quota cost, not $0;
  2. the port-blocker ledger from #5051 (estate, side, class, programs blocked, new_class, refused_by_name) and field_testing.json defects (scan side);
  3. GitHub issues/PRs (opened/closed/merged, links issue → PR → run);
  4. the evidence records (programs proven whole per estate).

Outputs (bot-written to the generated branch, per #4963, never to main):

  • econ.json: the joined, versioned dataset (one row per fix: estate, class, cost, runs, model, wall time, PR, merged date).
  • A rendered infographic page (HTML + SVG) for the public site/README:
    • cost per fix: distribution + trend over time, split by model;
    • blockers per estate, cumulative, and blockers per ported program in port order (the convergence curve);
    • new-class vs repeat blockers per estate (the key convergence signal);
    • cost to bring an estate whole ($ and days per estate, per program);
    • discovery vs closure (backlog), with estate-found vs sibling-filed separated;
    • throughput per worker (1 vs 2 workers);
    • a projection for the next estate (blockers, $, days) with its error band.
  • CI/report staleness check like field_testing.py report.

Honesty rules (must be on the page, not in a footnote nobody reads):

  • Costs are list-price agent cost; owner review time, CI minutes and subscription pricing are not included (say what is and isn't counted).
  • Ledger coverage starts 2026-10-11; entries with no cost are counted and shown as missing, not zero.
  • Attribution is from the #5051 ledger only; no keyword guessing in the published numbers.
  • Development estates (CardDemo, CBSA, …) are training data; first-try numbers on fresh estates (#3803) are reported separately, with the caveat that public code may be in model training data.
  • Refusals by name are counted as refusals, not as fixes.

Done when.

  • The stage runs on schedule from the ledgers above and publishes econ.json + the infographic on the generated branch.
  • The page shows all charts listed, with the counting rules stated on it.
  • The next fresh estate's actual blockers/cost can be compared against the page's projection.

Depends on #5051 (estate-tagged port-blocker ledger). Related: #4963 (bot output to the generated branch), #3803 (fresh-estate trials), docs/language_status/cics_field_testing.md.

Dominant language
Python
Stars
57
Forks
11
Avg merge
1h 35m
Merged PRs (30d)
975

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from squid-protocol/gitgalaxy

All issues in squid-protocol/gitgalaxy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.