Evidence

What the check caught

Every conversion of the demo apps was written by a coding agent, and every one was checked against recordings of the running original. What the check found that the agent had missed:

Three of the causes in plain words:

• Orders opened on a query instead of a new numbered record. The original form draws the next order number as it opens and is ready for a new order; the conversion showed existing orders.
• The record counter. Forms shows "1/?" until it has fetched the last record, in batches of the rows on screen; the conversion showed the total at once (40 values in HR).
• Line keys typed, not drawn. In the original the user types each order line's key; the conversion drew it from a sequence and made the item read-only. The stored keys agreed only because a fresh sequence starts at 1.

Why this matters at scale. These are small sample apps, retail with 6 forms, HR with 3, CareWell with 5 and the student forms with 3, and agents still missed behaviour like this. A large application maintained for many years carries far more undocumented behaviour, and nobody has a full list of it. That is where checking against the running original pays off: the recording is the list.

Migration trails

Rewrites that changed nothing

Both apps were later restyled, and their navigation rewritten (a visible call stack, Back as the way out of a called form). Three fresh-database runs of every scenario after each change gave diffs byte-identical to the evidence before it: the check confirmed that nothing the user or the database sees had changed. Files: restyle retail, HR; navigation retail, HR.

What database and API checks missed

An independent evaluator checked a .NET/PostgreSQL rebuild of the retail app, written by an ordinary coding agent, through its database and its API: it passed four of five finding groups (13 of 16 SQL observations, 7 of 10 API checks). The first recorded scenario (create an order with two lines, change a quantity, save) replayed against the same build found 9 defects, covering 71 values, none of them among the evaluator's findings:

1. No order ID on open. Forms draws ORD_SEQ on opening, shows 16 and saves 17; the target shows nothing until save and saves 16. (11 values)
2. ORDER_DATA saved with the clock time. Forms stores NULL; the target lets the column default apply. (4 values)
3. ITEM_ID cannot be entered; the target draws it from item_seq. Stored values agree only because the fresh sequence starts at 1. (26 values)
4. Line total computed while typing, not when the quantity is validated. (5 values)
5. Adding a line blanks the total of the earlier lines. (3 values)
6. Save shows no alerts. Forms shows FRM-40400, then the trigger's success message. (10 values)
7. Status line shows 'No records...' from opening until save; Forms' message line is empty. (10 values)
8. Focus after opening stays on the menu button; Forms puts it on CUSTOMER_ID. (1 values)
9. Tab from QUANTITY goes to UNIT_PRICE; in Forms it goes to ITEM_ID. (1 values)

Further ORDERS scenarios found data-level faults in the same build: it overwrote an existing order instead of inserting a new one, saved an order Forms refuses (a required field empty), and updated a line where Forms rejects a duplicate key.

Which number is which. The 9 defects (71 values) are one scenario, order-two-lines, against the agent's first build. They were repaired first; the repaired build then became round 0 of the retail rounds, where all 17 scenarios found 403 defect values (164 groups) in the other 16. The 403 in the write-up is that round 0.

Retail: coverage

Decision branches: 18, of which 14 covered, 2 unreachable (retirement candidates) and 2 blocked. Database PL/SQL: 1 unit(s) in the coverage report, 1 of 1 blocks covered. Exit check: PASS.

Report: retail-coverage.md.

HR: coverage

Decision branches: 32, of which 24 covered, 4 unreachable (retirement candidates) and 4 blocked. Database PL/SQL: 11 unit(s) in the coverage report, 13 of 13 blocks covered. Exit check: PASS.

Report: hr-coverage.md. Of the schema's 11 PL/SQL units, the four the Forms app runs are fully covered (13 of 13 blocks); the other seven cannot run from Forms (a policy function that ships disabled, its helper, the APEX side and audit triggers on tables the app never writes).

CareWell: coverage

Decision branches: 30, of which 24 covered, 5 unreachable (retirement candidates) and 1 blocked. Database PL/SQL: 2 unit(s) in the coverage report, 0 of 0 blocks covered. Exit check: PASS.

Report: carewell-coverage.md. The menu module's items and the library's units are counted with the forms' triggers.

Student: coverage

Decision branches: 14, of which 10 covered, 4 unreachable (retirement candidates) and 0 blocked. Database PL/SQL: 10 unit(s) in the coverage report, 2 of 3 blocks covered. Exit check: PASS.

Report: student-coverage.md.

Repeatability

Every golden record was recorded three times from the restored baseline, and the three were byte-identical for all 17 retail, all 17 HR, all 22 CareWell and all 15 student scenarios: retail, HR, CareWell, student. Clock and run-date values are masked; the masks were checked by recording on another day (17 of 17 retail records equal) and with the Forms runtime's clock moved ten days ahead (one scenario per app). Every replay against a migrated app was also run three times from a fresh database, with byte-identical diffs: retail, HR, CareWell, student.

Retail: from first conversion to parity

The 164 defect groups came down to twelve findings, among them: the main menu's start-up state, keys typed by the user instead of drawn from sequences, record navigation and its messages, Add, Save and Delete semantics, date display, ORDERS opening on a new record with a drawn order number, the three-button save question, the refused delete of an order with lines, and the messages of a failed save. All were repaired in one round by an agent that had the diffs and golden records but not the Forms source. Files: round 0, round 1.

HR: from first conversion to parity

The HR app was converted to .NET 10 and PostgreSQL from its Forms source by one coding agent in about 20 minutes (12 files, 1809 lines), without access to the scenarios or golden records.

Round 0 defects by kind: the record indicator (40 values), focus after alerts and tab clicks (6), the message line (4), the generated employee id (2), the APEX links (13, waiver H1) and a stale department number (8, waiver H2). Files: round 0 summary, round 0 defects, round 1 summary, round 1 repair diff, final three runs. The APEX token's signing key was later moved from the source's literal to configuration; the two scenarios that use it give byte-identical diffs (re-run).

CareWell: from first conversion to parity

CareWell was converted to .NET 10 and PostgreSQL from its Forms source (the XML exports of five forms, the menu module and the library, and the schema and seed SQL) by one coding agent in about 35 minutes (9 files, 2690 lines besides the seed data), without access to the scenarios or golden records.

Round 0 by cause: the key's sequence draw, which made every save of a new appointment or payment fail (41 values); a record refused by validation as it is fetched, which stops the query in Forms (14); a payment row defaulted after an empty detail query (8); Enter Query (7); POST-QUERY and the cursor after a delete or a failed save (6); validation from a list without a match (3); the record counter (2); and 163 values of the five waivers (the collected-today gauge 114, the frame title before sign-in 46, three single values). The Oracle run later found two more: two patients of the same name came back in the other order, because the conversion's query left them tied (fixed by ordering on the key, as the original returns them), and the database's localised error text hid the constraint name the library's error message depends on. A run after midnight found a third: a new payment took its date from the browser, a day ahead of the database clock (now from the database, as Forms' server clock). Files: round 0 summary, round 0 causes, round 1 summary, round 1 repair diff, final three runs.

Student: from first conversion to parity

The three student forms were converted to .NET 10 and PostgreSQL from their Forms source by one coding agent in about 39 minutes, without access to the scenarios or golden records. The same agent then wrote the mapping and the fixture and repaired from the diffs.

Round 0 by cause: rows in key order where Forms shows storage order (941 values), the date format (120), the windows Forms shows at start-up (32), the record counter (19), audit dates with the time of day (9), a screen-reader announcement (5, waiver S1), the new course number's sequence (2), the message line (2) and four single values. Round 1 left the STUDENT table's storage order (the original's starts at student 385, 651 values) and a regression in the save (11). Files: round 0 summary and causes; round 1 summary, causes and repair; round 2 summary, causes and repair; final three runs.

Onboarding a new application

The HR app was the first application the harness had not been built on. One agent took 2 h 39 min from receiving the source to a passing coverage report:

The full loop (recording pass, diagnostics replay, three runs) takes 169 s per scenario on average.

Limits of this evidence

• Only the Forms Standalone Launcher on Forms 14.1.2 was tested; Forms 12.2.1.x, the Java plugin and Web Start are untested.
• The applications are small public samples (6, 3, 5 and 3 modules; 60, 24, 65 and 26 triggers and units).
• Parity covers the recorded scenarios of each app (17, 17, 22 and 15) and the items the mapping names. Behaviour no scenario exercises is unverified.
• Target adapters exist for a web app in a browser on PostgreSQL or Oracle (see migration trails). Files, reports, mail and HTTP calls are not recorded yet.
• Tolerance policies and waivers were drafted by the agent; agreeing them with a real customer is untested.