Revenue & Cost Monitoring System for the Power Industry

Parse the Mind Map

The instruction states the role, material, step-by-step tasks, core requirements, delivery criteria and self-check gate in one pass. The first thing after sending is not to start work — it is to confirm the input is really at hand:

Parse and organize: deeply parse the node hierarchy in the XMind and convert the mind map’s "keywords" into a standardized product feature structure tree.

Verifies the input first: no XMind file in the current turn → proactively checks the workspace and finds the .xmind and an existing unpacked directory
→ The xmind package is not installed → installs nothing, reads the unpacked content.json directly
→ fs.exec environment pitfalls (sh instead of cmd, absolute paths banned) → switches to relative paths to call Python
→ Reads the full tree: root = Revenue & Cost Monitoring – Early-Warning System, 5 top-level modules, cost and progress are empty nodes
→ Writes tools/xmind_parser.py to parse into a standardized feature structure tree, saved as feature_tree.json

Generate the Prototype

With the feature tree in hand, the instruction’s "first show me a runnable interface demo" points at a single HTML file. The key to generation is not writing code but where the mock data comes from:

Interface prototype: based on the organized feature structure, generate a high-fidelity visual preview of the admin interface (if you support code, generate HTML/CSS/JS; if you only support drawing, produce an ASCII layout or the corresponding SVG/chart layout). Core requirements: the interface must include the core modules of the top-level directory; the layout should lean industrial/enterprise style, emphasizing data visualization (charts, status lights, lists). Delivery standard: first show me a runnable interface demo (in one HTML file or a clear rendered image). For now do not write backend logic or database connection code — at this stage only static display and interaction demos.

Plans 15 hash-routed pages: Comprehensive Analysis Center / Revenue Management, 6 pages / Cost Management / Progress Management / Early-Warning Center / System Configuration, 4 pages
→ Faithfulness discipline: empty nodes get placeholder hints instead of invented sub-modules; no top-level items added that the XMind does not have
→ Mock data sticks to the XMind’s real fields: a 13-field contract ledger, 7 contract-type categories, the maintenance-revenue share formula
→ Technical route: single-file index.html (ECharts CDN + dark theme + status lights)
→ Mid-run it keeps outputting design notes without acting → lands the work immediately after a system reminder
→ Delivers prototype/index.html (40.6KB)

Self-Check Gate

The second item in the instruction is a single sentence — "after the code is done it must pass the self-check gate" — yet executing it is the most winding stretch: a false alarm first, a real problem after:

2. After the code is done it must pass the self-check gate

Builds its own verify_html.py to validate → reports 11 views vs 15 menu items, suspected omissions
→ Investigation: the grep pattern fails to match dotted syntax → each item confirmed present, false alarm
→ The gate passes item by item: pytest 14/14 · ruff 0 issues after one fix · semgrep 0 findings
→ Gate table all green: HTML 40.6KB · DOCTYPE ✓ · all 15 views present

Try it yourself

After putting the customer’s XMind file into the workspace attachments/, send the instruction from the prompt above to AVL Code verbatim (structure = role + input material + step-by-step tasks + core requirements + delivery standard + self-check gate); after delivery you can re-run the gate locally:

› 1. Role: act as a senior full-stack architect and UI/UX designer. I am in the power industry and need to develop a revenue-and-cost monitoring–early-warning system. …… (full text in the prompt above; place <the customer’s XMind file> into workspace attachments/ before sending)

› python -m ruff check tools/ tests/

› python -m pytest -q

› semgrep scan <target directory>

• After delivery, re-run the self-check gate locally: once all three commands above pass, the deliverable is accepted.
• The whole session has only one user instruction; each chapter’s left column is a verbatim excerpt of the corresponding task in that instruction (unrewritten). "About 12 minutes", "80+ feature nodes" and "7 deliverable files" come from the case’s existing archive (index.ts) and do not appear directly in the session — the session’s delivery table actually lists 5 output files, so the "7 deliverable files" figure cannot be independently confirmed from the session. The session export has no separate tool-call lines; the duo right column is reconstructed from the assistant’s process narration.

Next question: Once the prototype passes acceptance, how do you connect real API data sources for integration and replace the static mock with live data?