MDF Extension Development Assistant

Problem

MDF extension work usually breaks down at concrete engineering steps. A workspace may contain multiple front-end projects, so the first issue is identifying the real MDF project root. UI metadata in .yoncode/ must be parsed from XML instead of guessed from memory. Extension scripts must land in vendor or customer-custom directories with the correct file names, object names, and lifecycle entries. Finally, generated code needs to be checked against a framework API whitelist to avoid deprecated or nonexistent methods.

How It Works

The skill follows a reviewable workflow:

• Project detection: prefer scripts/detect_target_project_root.py to lock one project root and distinguish vendor from custom development structures.
• UI metadata parsing: use yct dsl index on .yoncode/{domain}-meta/{appCode}/ui/*.xml, and yct dsl detail for node-level inspection.
• Target location and feasibility: use cSubId, cBillNo, and cBillType to choose the extension entry and decide whether the requirement can be implemented as an extension script.
• Code generation: generate *.Extend.js or customer-custom extension scripts from templates, API-INDEX.md, and API-WHITELIST.md, rather than writing from free-form memory.
• Validation and debugging: compare framework API calls against the whitelist, output pass/fail issue lists, or prepare local debug context.

Boundaries

It is aimed at front-end extension scripts for MDF bill pages. It does not manage backend metadata, fetch protocols, generate protocol summaries, or perform design review. If UI metadata is missing, the workflow may try yct metadata search to pull it into .yoncode, but failed retrieval still requires a valid domain and appCode.