REA version comparison: what did the update change?

01. Make the regression specific

“The update broke export” leaves too much room for guesses. Write down the input, the action and the difference: for example, a title containing a quotation mark exported correctly before the update and now produces a malformed CSV row.

Put the two application versions in separate folders. Record their release labels and artifact hashes. Compare equivalent artifacts: a development source tree and a production minified bundle are not the same kind of evidence.

npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json

02. Compare the retained analysis evidence

Keep the complete original JSON outputs. The comparison workflow expects authenticated application evidence; a manually edited summary or a list of filenames is not a substitute.

Ask your connected agent to inspect the available compare_application_versions schema and supply the two results accordingly. This avoids guessing nested input fields that may change between releases. The CLI can show the same contract.

npx -y rea-agents@6.4.0 compare-application-versions --schema

Use REA compare_application_versions with the complete application evidence in before.json and after.json. Check the installed tool schema first. Focus the report on CSV export: changed modules, related call paths and unresolved matches. Do not interpret a missing node in partial coverage as proof of deletion.

03. Compare the feature, not the minified names

Start at the button, IPC channel or formatter you already know. Follow that feature in both versions and inspect the changed code. Minified variable names often change during a rebuild without changing behavior.

A module digest can establish exact identity. A renamed function or a newly numbered bundle chunk cannot establish a semantic change by itself. Keep unmatched or partially parsed regions visible in the report.

• Do both versions contain the relevant feature entry?
• Which source region actually differs?
• Does the changed branch affect the failing input?
• Could packaging, configuration or missing coverage explain the difference?

04. Replay the same input in both versions

Use separate disposable data folders so opening the newer app does not migrate the older version’s test state. Run exactly the same operation against the same test content. Save the output file or a focused behavior record from each run.

For a CSV regression, parse the resulting rows and compare fields. Byte differences such as line endings can matter, but a changed timestamp should not drown out the actual quoting failure. Document every normalization used in the comparison.

Create a regression test for the exact input we observed. Compare parsed exported fields from the old and new output. Show both the raw difference and any normalized comparison. Keep the suspected source change separate from the behavior actually reproduced.

05. Write a useful bug report

Include the two version identities, one failing input, exact reproduction steps, observed old/new outputs and the smallest relevant source difference. State whether the behavior was reproduced or only predicted from static code.

A good comparison gives you a next action: a regression test, a compatibility workaround or a narrowly scoped replacement. This tutorial is a workflow; it does not claim a regression in a named commercial release.