Develop a measurement application
=================================

This entry point is for developers who configure an existing workflow or
extend mpylab with measurement logic, instruments, or a user interface.

1. Select the appropriate extension layer
-----------------------------------------

Check in this order:

#. Can an existing measurement class be adapted using only a new ``conf.py``
   and :doc:`DOT <../configuration/dot>` and :doc:`INI and DAT files
   <../configuration/instrument-data>`?
#. Is a concrete driver missing for an existing instrument-family base class?
#. Is a new technical measurement class actually required?
#. Does the existing workflow only need another UI adapter or report module?

The :doc:`framework architecture <../framework/architecture>` describes the
responsibility boundaries.

2. Follow the end-to-end example
--------------------------------

The :doc:`developer tutorial <../framework/tutorial>` uses a virtual
amplifier test to connect ``conf.py``, DOT, and INI configuration with path
corrections, autosave, tests, and UI integration.

3. Preserve the contracts
-------------------------

* Measurement classes derive from ``Measure`` and separate acquisition from
  evaluation.
* Hardware protocols remain in instrument drivers.
* ``MGraph`` receives DOT conditions and physical context controllers through
  an explicit context. Custom applications handle detected state mismatches
  without automatically switching the hardware back.
* Measurement values remain SCUQ quantities.
* Blocking calls run in a worker when using Qt.
* RF-off, instrument limits, and manual intervention remain reachable.

See :doc:`measurement classes <../framework/measurement-classes>`,
:doc:`drivers <../framework/drivers>`,
:doc:`DOT context controllers <../configuration/dot>`,
:doc:`path corrections <../framework/path-corrections>`, and
:doc:`UI workers <../framework/ui-workers>` for details.
The :doc:`EUT monitoring guide <../framework/eut-monitoring>` covers custom
monitor development, threaded isolation, and integration through
``EUTMonitoringSession``.

For deliverable results, the :doc:`report guide <../results/reports>`
separates TOML presentation configuration from custom Python report modules.
The curated :doc:`report API <../../api/reports>` documents their lifecycle
and integration.

4. Verify without hardware
--------------------------

New workflows require pure-logic tests, instrument-contract tests, a virtual
configuration, a short end-to-end run, and safety and resume tests. The
:doc:`testing guide <../framework/testing>` puts these layers into context.

5. Consult the API
------------------

The curated :doc:`API and CLI reference <../../api/index>` documents the
recommended extension surface. Undocumented names beginning with an
underscore should be treated as internal implementation.

When updating older application code, use the :doc:`tool-module migration
guide <../framework/tool-modules>` to replace imports from the historical
``mpylab.tools.util`` facade with focused modules.