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

Aperta
#5,052 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
18/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
57
Fork
11
Merge medio
1h 35m
PR unite (30g)
975

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di squid-protocol/gitgalaxy

Tutte le issue di squid-protocol/gitgalaxy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.