Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

Phase 4: Current-State Understanding Handoff

Diagram coverage

Purpose and confidence of the handoff

The evidence supports a partially implemented stores7 order-management demonstration with two related but distinct evidence streams: the translated Java application under demo/target/java, and the original or parallel Informix-4GL programs under demo/source. They should not be treated as one proven, behaviorally equivalent implementation. The Java stream establishes a runnable Swing-oriented application shell, database call sites, customer and order-entry code, and several explicit stubs. The 4GL stream provides fuller historical workflows, data-loading routines, forms, reports, and additional order-maintenance behavior, but its correspondence to the Java target remains unresolved. E0012 E0014

This handoff therefore records what a subsequent specification may safely rely on, what remains conditional, and which questions must be answered before claims are converted into authoritative requirements. Detailed journeys and state transitions belong in C04, business rules in C05, data definitions in C06, interfaces and database exchanges in C08, security-sensitive behavior in C09, and runtime configuration in C10.

Behavior established for the current Java application

D4_Main.main creates the application through AppFactory.create("D4_Main", args). D4_Main.run() selects the stores7 database alias, configures the Swing look and feel, loads states and stock, and exposes Customer, Orders, Stock, Reports, and Exit commands. The application also exposes a bang command that passes user-entered text to _app.execute(true, Str.valueOf(cmd)); the source provides no visible allowlist or sanitization. This is an established call path, while its exact execution scope depends on the absent framework implementation. E0002 E0012

The Java order flow has substantive support for adding orders. D4_Orders.add_order() selects or creates a customer, collects order header information, accepts line items, looks up stock details, calculates line totals, begins a transaction, inserts the order and items, commits on the success path, and generates an invoice. Explicit rollback is attempted when the order insertion reports failure or insert_items() returns false. The evidence does not establish rollback for every exception after beginTransaction(), because the broad exception handler calls _eh.handleException(_e) without visibly rolling back. E0012

Customer behavior is supported by demo/target/java/src/com/ais/demo/D4_Cust.java, which provides add, many-add, query/browse, update, delete, help, and state-selection paths. Customer browsing includes Next, Previous, First, Last, Select, and Quit choices, and update interruption reloads the selected database row. Deletion counts matching orders before prompting for confirmation. However, one synthesis report locally lacked D4_Cust.java and therefore could not independently confirm it; that local limitation does not override the positive evidence from the supplied target source. E0009 E0012

The deletion condition requires particular care in later specification. The Java query is reported as SELECT COUNT(*) FROM orders WHERE customer_num = ?, while the user message says that the customer has “active orders.” The query, as evidenced, counts all matching orders rather than demonstrably only open, unpaid, or active orders. The intended definition of an active order remains unresolved and should not be silently converted into a stronger rule. E0002

The Java application does not provide all capabilities suggested by its menus or broad inventory descriptions. D4_Orders.update_order() and delete_order() display "This option has not been implemented". D4_Stock.add_stock(), query_stock(), update_stock(), and delete_stock() are also stubs. In D4_Report, print_labels() and print_ar() contain report logic, while print_backlog() and print_stock() explicitly report that they are unimplemented. The current Java handoff must therefore distinguish exposed menu entries from delivered behavior. E0002 E0012

Historical and parallel 4GL behavior

The 4GL sources describe fuller behavior in some areas, but these findings belong to the 4GL programs named in the evidence and must not be attributed automatically to D4_Orders. In demo/source/ordmenu.4gl.main, order Add, Query, Modify, and Delete are implemented as menu operations. Modify can replace order items, and Delete removes an order and its items after confirmation. In contrast, demo/source/d4_orders.4gl explicitly leaves Update-order and Delete-order unimplemented. These are different programs or variants with similarly named concepts, not a resolved contradiction within one implementation. E0009 E0010

The 4GL order-entry evidence establishes an array of up to ten items, stock lookup by stock number and manufacturer code, quantity-times-unit-price calculation, generated item numbers, and insertion of the order and its items. The Java evidence independently supports a ten-item-oriented order model through p_items and invoice handling, but the exact equivalence of the Java and 4GL workflows is not proven. Form files such as order.frm, orderform.frm, and p_ordcur.frm were reported as binary or unsupported for text analysis, so their runtime identity with the .per definitions cannot be verified. E0009 E0010

The 4GL report implementation supports mailing labels and accounts receivable, with file, printer, or screen destinations selected through print_option. Backlog and stock-list reports are explicit stubs in demo/source/d4_report.4gl, matching the help documentation. The Java target similarly implements labels and accounts receivable but not backlog or stock-list. Exact report lifecycle behavior remains dependent on the report framework, and the 4GL report-abort logic appears questionable because int_flag is reset before the later post-loop abort test. That is a source-level concern, not a demonstrated runtime outcome. E0007 E0008 E0012

Constraints and dependencies carried forward

The application depends on shared mutable state obtained through Application.GLOBALS_KEY. D4_Globals provides p_customer, p_orders, arrays for p_items, p_stock, and p_state, counters, and print_option. State and stock loading is bounded at 50 and 30 retained records respectively; the source does not establish a user-visible warning when excess rows are discarded. This shared-state and bounded-reference behavior constrains interpretation of cross-screen data and belongs in the data and current-design accounts at C06 and C11. E0012

The database and framework are consequential dependencies. The Java configuration identifies the Informix JDBC driver and a stores7 connection, while other project configuration names a different host, port, server, and password. The evidence does not establish precedence, environment ownership, or which configuration is active in a particular execution. These settings establish resource dependencies, not component deployment or live-host facts. E0007 E0008 E0013

The schema is only partially evidenced through SQL statements, generated record classes, unload files, and form definitions. Customer contains customer_num, names, company, address, city, state, ZIP, and phone; P_Orders, P_Items, P_Stock, R, and X_Invoice expose corresponding order, item, stock, report, and invoice fields. Actual constraints, foreign keys, serial behavior, and precision rules remain outside the supplied evidence. The field-level account should be consolidated in C06, rather than repeated here. E0007 E0013

Several current behaviors require framework semantics before they can be treated as guarantees. These include ErrorHandler status conventions, rollback behavior after uncaught exceptions, Construct.getQuery() escaping, report buffering and finalization, Money rounding, and the behavior of Application.execute(). Prepared-statement APIs appear in report code, but query predicates are concatenated into SQL text; this is a review concern, not proof of exploitable injection. E0012

Unresolved questions for subsequent specification

The first unresolved decision is scope identity: is the Java target intended to replace, reproduce, or merely demonstrate selected behavior from d4_cust.4gl, d4_orders.4gl, ordmenu.4gl.main, and query1.4gl.main? The evidence shows naming and behavioral differences, including Java customer ordering by lname, differing menu structures, and one 4GL program with implemented order modification where another leaves modification unimplemented. No specification should merge these into a single lifecycle without an authoritative source decision. E0010

The second question concerns order totals. D4_Orders.order_total() applies 1.1d, while invoice logic separately calculates 6.5% sales tax and 3.5% shipping. The numerical relationship suggests an intended ten-percent combination, but rounding, display scope, and possible double counting are unresolved. The authoritative total, tax, shipping, and invoice rules belong in C05 and C06. E0002 E0012

The third question concerns deletion and integrity. Customer deletion is blocked when the current query finds orders, but “active” is not defined. In the 4GL order-maintenance variant, parent order deletion precedes item deletion, which may conflict with foreign keys; no schema constraints are supplied. The required deletion conditions and failure outcomes therefore remain open. E0002 E0010

Finally, the handoff must retain security and operational questions rather than infer answers. User-entered bang commands, plaintext database credentials in configuration, conflicting database endpoints, and dynamically assembled query predicates are evidenced review points. Their deployed exposure, authorization context, and operational handling are not established by source alone and should be resolved in C09 and C10, not assumed from configuration names or framework calls. E0008 E0012