What problem does it solve? Writing a DIVA business object layer (Module Check) by hand means reproducing roughly 52 standard functions, correct naming tokens, and strict ISO-8859-1/CRLF encoding for every entity, which is error-prone and slow. ## Core Features & Use Cases - Module Check generation: Produces a complete .dhsp file (header, includes, Init_Module, ~52 standard functions, foreign-key checks) from a Jinja2 template and naming tokens, either computed automatically from entity parameters or supplied as JSON. - Foreign key support: Repeatable --fk CHAMP:TARGET[:ZOOM] arguments generate module imports and Check_Field validation procedures, with exemptions for accounting targets (C3-C9). - Built-in validation: validate_mchk.py checks rules M01-M05 (Init_Module, INIT record, OutputMode stacking, OverWrittenBy, encoding) plus 22 mandatory function signatures and naming coherence. - Use Case: Ask to generate the Module Check for the Retail entity FamRglt (table RtlFamRglt, key RgltFam) and receive a validated, ISO-8859-1/CRLF-encoded .dhsp file ready for the DIVA 3-file pattern. ## Quick Start Ask the assistant to generate the Module Check file for a DIVA entity by providing its domain, entity name, SQL table, key field, and description.
