Build a Live API-Connected DAG Workflow for Late-Order Refund Requests

Design a working local demonstration of an order-status and support-decision workflow. Separate components must communicate through real API calls, and the system must keep running so its behavior can be observed repeatedly. ### Requirements and Constraints - Build an API representing order status. - A workflow component queries that API and follows a rule set represented as a directed acyclic graph (DAG). - The minimum working path checks whether an order is late; a late order triggers a refund request and then ends. A nonlate order can end without a refund. - No real money must move, but the refund request must be observable. - Other actions, such as closing or escalating a request, are extensions rather than prerequisites for the minimum demonstration. - AI coding tools may be used to accelerate implementation. The engineer remains responsible for understanding, running, and validating the result. - Favor a working end-to-end system over elaborate class hierarchies or abstraction. ### Part 1 — Define and Connect the Components Choose a minimal order-status contract, a DAG representation, and a refund-request boundary. #### What This Part Should Cover - An explicit definition of a late order and the status data needed to evaluate it. - The role of a condition node, action node, branch edge, and terminal node. - Actual API communication between running components rather than only in-process function calls or a one-shot script. ### Part 2 — Demonstrate the Workflow Show how a late order results in an observable refund request and how a nonlate order avoids that action. #### What This Part Should Cover - A repeatable way to start services, trigger evaluation, and inspect responses or recorded refund requests. - Basic handling of API failure, unknown order state, and repeated evaluation. - An explanation of what each manual request proves, including evidence that the action was reached. ### Part 3 — Use AI and Report the Result Explain how you would guide an AI coding tool, review its output, and summarize the completed demonstration. #### What This Part Should Cover - A bounded implementation plan and prompts that preserve the minimum requirements. - Human review of assumptions, API contracts, and test results. - A final summary of the problem, architecture, decisions, trade-offs, tests, and known incomplete work. ```hint The action needs observable evidence A workflow response saying "refund" is not enough if the action component never receives a request. Expose a record or response that shows the API boundary was crossed. ``` ### What a Strong Answer Covers The minimum late-order path works through separate continuously running components, with a clear DAG interpretation and a visible refund-request record. The demo has defined semantics and basic retry safety, and its completion summary distinguishes verified behavior from planned extensions. ### Follow-up Questions 1. What should happen if the order-status API is unavailable rather than reporting that the order is not late? 2. How would you prevent repeated evaluation from creating multiple refund requests for the same minimum-demo action? 3. What additional contract would be needed before a workflow could issue partial refunds or move real funds?