feat(plc): generate isolated CODESYS application bundles

Author: moqui-industrial

agent-skills/skills/moqui-plc-designer/SKILL.md

@@ -1,11 +1,6 @@
 ---
 name: moqui-plc-designer
 description: Use when generating or refining PLC code from Moqui automation data. This skill reads devices, parameters, device requests, status flows, and related metadata, then fills reusable templates for IOFacade, DeviceFacade, DeviceManager, DeviceDiagnostics, MainStatus, Main, and MainRuleEngine.
-compatibility: Requires Python 3.14+
-license: ../../LICENSE.md
-metadata:
-  author: moqui-induatrial
-  version: "1.0"
 ---
 
 # Moqui PLC Designer
@@ -46,20 +41,30 @@ Use this skill when the task is to define or generate a data-driven automation m
 
 ## Output Layout
 
-Generated PLC files should be written into an `output/<component-name>/` tree that mirrors the `mantle-hvac` structure in [moqui/moqui-plc](https://github.com/moqui/moqui-plc).
+Generate one isolated bundle for each top-level CODESYS Application. Each bundle
+contains a dedicated framework copy and one runtime component that mirrors
+`mantle-hvac`.
 
 In a saved parent session, prefer:
 
-- `output/sessions/<session-id>/generated-plc/<component-name>/...`
+- `output/sessions/<session-id>/generated-plc/codesys-applications/<application-id>/...`
 
-Preferred layout:
+Application layout:
 
-- `output/<component-name>/data/`
-- `output/<component-name>/src/main/<namespace>/<component-name>/`
+- `framework/`
+- `runtime/component/<component-name>/data/`
+- `runtime/component/<component-name>/src/main/<namespace>/<component-name>/`
+- `application-manifest.json`
+- `plc-traceability.md`
+
+Runtime component layout:
+
+- `data/`
+- `src/main/<namespace>/<component-name>/`
   - `MainStatus.dut`
   - `Main.pou`
   - `MainRuleEngine.pou`
-- `output/<component-name>/src/main/org/moqui/device/`
+- `src/main/org/moqui/device/`
   - `IOFacade.dut`
   - `DeviceFacade.dut`
   - `DeviceManager.pou`
@@ -88,22 +93,26 @@ CODESYS device-tree objects remain external to the Moqui seed model:
 - `InputSignalUpdate` and `OutputSignalUpdate` stay manual
 - `DeviceManager` and `DeviceDiagnostics` are auto-generable only when every listed device is blocking for the machine
 - complex redundancy, backup, standby, or non-blocking `DeviceGroup` roles are out of scope
-- `Main.pou` and `MainRuleEngine.pou` intentionally remain in standby until real project test cases are available to validate the final generation rules
+- `MainRuleEngine.pou` computes boolean transition requests; `Main.pou` alone consumes those requests and applies same-flow state changes
+- every top-level controlled system is generated as a separate CODESYS Application with its own framework copy
+- subsystem controllers execute sequentially by unique ascending `call_sequence`; `DeviceManager` executes once afterwards
+- cross-flow transitions require reviewed `request_assignments` and `apply_assignments`; generation stops if either side is missing
 - the repository should currently be treated as a semilavorato/base framework that each development team may further specialize
 
 ## Workflow
 
 1. Read the seed XML and related Moqui model files.
 2. Decompose the machine into subsystems and levels.
-3. Identify the main orchestration FSM and the atomic devices at the last level.
+3. Identify the flat orchestration FSMs owned by systems/subsystems; introduce nesting only when required.
 4. Collect or derive the physical signal catalog for `IOFacade`.
 5. Collect or derive the logical parameter and device catalog for `DeviceFacade`.
 6. Select or derive the `StatusFlow`.
 7. Run a guided survey for each FSM state to collect the output function of `Main`.
 8. Run a guided survey for each `StatusFlowTransition` to collect predicates, boolean conditions, and precedence for `MainRuleEngine`.
-9. Fill the PLC code templates.
-10. Write the generated files into the component output tree instead of a flat scratch directory.
-11. Cross-check the generated PLC artifacts back against the seed-derived catalog before treating them as reviewable output.
+9. Require `outputs_reviewed: true` for every state and `code_generation_approved: true` for every FSM.
+10. Generate one Application per top-level system and order its subsystem controllers by `call_sequence`.
+11. Fill the PLC code templates without unresolved orchestration placeholders.
+12. Cross-check the generated PLC artifacts back against the seed-derived catalog before treating them as reviewable output.
 
 Useful helper scripts:
 
@@ -114,6 +123,10 @@ Useful helper scripts:
   - both helpers support `--session-dir` for session-aware output and status updates
 - `scripts/validate_generated_plc_against_seed.py`
   - verifies that the generated PLC declarations still match the seed-derived device, parameter, request, and status-flow catalog
+- `scripts/render_codesys_applications.py`
+  - generates all isolated CODESYS Application bundles from the reviewed session
+  - copies the framework unless `--no-copy-framework` is used
+  - validates orchestration fields and writes invocation-order traceability
 
 Important distinction:
 
@@ -216,6 +229,7 @@ Read these files when generating code or collecting inputs:
 - `references/plc-codegen-templates/MainRuleEngine.template.pou`
 - `references/main-rule-engine-input-schema.md`
 - `references/main-rule-engine-input-schema.yaml`
+- `references/codesys-application-architecture.md`
 - `references/device-manager-full-call-signatures.md`
 - `references/moqui-seed-xml-workflow.md`
 - `references/moqui-seed-template.xml`

agent-skills/skills/moqui-plc-designer/agents/openai.yaml

@@ -1,3 +1,3 @@
 display_name: Moqui PLC Designer
-short_description: Generate PLC skeletons and supporting code from Moqui devices, parameters, requests, and status flows.
-default_prompt: Generate or refine PLC code from Moqui Device, Parameter, DeviceRequest, and StatusFlow data using the bundled templates and scripts.
+short_description: Generate isolated CODESYS Application bundles from reviewed Moqui PLC models.
+default_prompt: Generate and validate one isolated CODESYS Application per top-level system, with reviewed supervisor logic and sequential subsystem FSM controllers.

agent-skills/skills/moqui-plc-designer/references/codesys-application-architecture.md

@@ -0,0 +1,22 @@
+# CODESYS Application architecture
+
+Use one isolated CODESYS `Application` for every top-level controlled system.
+CODESYS permits multiple uniquely named Application objects below one PLC device;
+each Application contains its own POUs, libraries, global variables and Task
+Configuration.
+
+For every generated Application:
+
+- include one dedicated copy of `iec61131/moqui/framework`;
+- include one runtime component under `runtime/component/<component>`;
+- keep exactly one supervisor `Main`, `MainRuleEngine`, `DeviceFacade`,
+  `DeviceManager` and `DeviceDiagnostics`;
+- generate subsystem FSMs as uniquely named controller/status pairs;
+- call subsystem controllers sequentially by ascending `call_sequence`;
+- call `DeviceManager` once, after all subsystem controllers;
+- let the developer create control/communication tasks and the device tree;
+- let the developer verify connected devices and select the Application used for
+  device I/O when multiple Applications share the same PLC device.
+
+Official reference:
+https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_obj_application.html

agent-skills/skills/moqui-plc-designer/references/main-rule-engine-input-schema.md

@@ -1,88 +1,15 @@
-# MainRuleEngine Input Schema
-
-Questo schema definisce i dati minimi necessari per generare:
-
-- `${SENSOR_PREDICATES}`
-- `${STATE_TRANSITION_CASES}`
-
-nel template:
-
-- `references/plc-codegen-templates/MainRuleEngine.template.pou`
-
-## Obiettivo
-
-Separare chiaramente:
-
-- topologia della FSM, derivabile da `StatusFlow`
-- semantica dei predicati, da fornire o confermare
-- precedenza delle transizioni
-
-## Struttura
-
-Lo schema YAML di esempio e' in:
-
-- [main-rule-engine-input-schema.yaml](./main-rule-engine-input-schema.yaml)
-
-## Sezioni principali
-
-### `context`
-
-Informazioni generali:
-
-- `component_name`
-- `status_enum`
-- `main_status_flow_id`
-- `initial_state`
-
-### `request_reset_block`
-
-Elenca quali request vanno resettate all'inizio di ogni scan.
-
-### `predicate_groups`
-
-Raggruppa i predicati per dominio:
-
-- `process`
-- `environment`
-- `safety`
-- `timing`
-- `custom`
-
-Ogni predicato ha:
-
-- `name`
-- `target`
-- `expression`
-- `comment`
-- `depends_on`
-
-### `transitions`
-
-Una voce per ogni arco di `StatusFlowTransition`.
-
-Campi principali:
-
-- `from_status`
-- `to_status`
-- `transition_name`
-- `priority`
-- `condition`
-- `request_assignments`
-- `comment`
-
-### `global_fault_gate`
-
-Specifica eventuali condizioni globali che causano `faultRequest`.
-
-## Regole di generazione
-
-- `${SENSOR_PREDICATES}` si genera concatenando i `predicate_groups`
-- `${STATE_TRANSITION_CASES}` si genera raggruppando le `transitions` per `from_status`
-- l'ordine degli `ELSIF` deriva da `priority`
-- se manca `condition`, lo skill deve chiedere chiarimenti all'utente
-- lo skill puo' precompilare parti dello schema leggendo:
-  - seed XML `StatusFlowItem`
-  - seed XML `StatusFlowTransition`
-  - seed XML `ParameterDef`
-  - seed XML `Parameter`
-  - seed XML `DeviceRequestItem`
+# MainRuleEngine input
+
+Use `main-rule-engine-survey.yaml` as the code-owned semantic input paired with
+the topology in `main-fsm-survey.yaml`.
+
+- Define every predicate with an Application-global `name` and IEC 61131-3 ST
+  `expression`.
+- Define every transition condition and unique precedence for its source state.
+- For same-flow transitions, omit `request_assignments` to use the generated
+  target-state request.
+- For cross-flow transitions, provide `consume_condition` plus reviewed
+  `request_assignments` and `apply_assignments`; generation must stop when any
+  part is absent.
+- Keep these expressions in the saved session and generated PLC source. Do not
+  persist them in `StatusFlowTransition.conditionExpression`.

agent-skills/skills/moqui-plc-designer/references/main-rule-engine-input-schema.yaml

@@ -1,70 +1,22 @@
-context:
-  component_name: hvac
-  status_enum: MainStatus
-  main_status_flow_id: HvacMainStatusFlow
-  initial_state: Standby
-
-request_reset_block:
-  assignments:
-    - "dev.faultRequest := FALSE;"
-    - "dev.standbyRequest := TRUE;"
-    - "dev.heatingRequest := FALSE;"
-    - "dev.coolingRequest := FALSE;"
-    - "dev.ventilationRequest := FALSE;"
-    - "dev.dryingRequest := FALSE;"
-    - "dev.surfaceThawingRequest := FALSE;"
-    - "dev.coreThawingRequest := FALSE;"
-
-predicate_groups:
-  process:
-    - name: tempInRange
-      target: dev.tempInRange
-      expression: "(dev.tempFeedback >= dev.tempMin + dev.tempHysteresis) AND (dev.tempFeedback <= dev.tempMax - dev.tempHysteresis)"
-      comment: "Process temperature inside operating window"
-      depends_on: [dev.tempFeedback, dev.tempMin, dev.tempMax, dev.tempHysteresis]
-    - name: tempOverMax
-      target: dev.tempOverMax
-      expression: "dev.tempFeedback > dev.tempMax"
-      comment: "Process temperature above maximum"
-      depends_on: [dev.tempFeedback, dev.tempMax]
-  safety:
-    - name: ductTempOverMax
-      target: dev.ductTempOverMax
-      expression: "dev.ductTempFeedback > dev.ductTempMax"
-      comment: "Supply air too hot"
-      depends_on: [dev.ductTempFeedback, dev.ductTempMax]
-
-transitions:
-  - from_status: Standby
-    to_status: Cooling
-    transition_name: Cooling
-    priority: 20
-    condition: "(dev.lastStatus = MainStatus.Cooling OR dev.lastStatus = MainStatus.Standby) AND dev.tempOverMax"
-    request_assignments:
-      - "dev.standbyRequest := FALSE;"
-      - "dev.coolingRequest := TRUE;"
-    comment: "Temperature above limit -> start/resume cooling"
-
-  - from_status: Standby
-    to_status: Heating
-    transition_name: Heating
-    priority: 30
-    condition: "(dev.lastStatus = MainStatus.Heating OR dev.lastStatus = MainStatus.Standby) AND dev.tempUnderMin"
-    request_assignments:
-      - "dev.standbyRequest := FALSE;"
-      - "dev.heatingRequest := TRUE;"
-    comment: "Temperature below limit -> start/resume heating"
-
-  - from_status: Cooling
-    to_status: Standby
-    transition_name: Standby
-    priority: 10
-    condition: "dev.tempUnderMin OR dev.isCompleted"
-    request_assignments:
-      - "dev.standbyRequest := TRUE;"
-    comment: "Cooling target reached or work complete"
-
-global_fault_gate:
-  expression: "error OR ((dev.signalMgmt.cumulativeOutputAction AND SignalOutputAction.ImmediateStop) <> 0)"
-  assignment: "dev.faultRequest := TRUE;"
-  return_after_fault: true
+fsms:
+  - fsm_id: ExampleFsm
+    status_flow_id: ExampleStatusFlow
+    predicates:
+      - name: startAllowed
+        expression: dev.enableRequest AND NOT dev.faultRequest
+        comment: Reviewed start permission
+    transitions:
+      - from_status_id: ExStandby
+        to_status_id: ExRunning
+        to_fsm_id: ""
+        name: Start
+        condition: dev.startAllowed
+        consume_condition: ""
+        precedence: 10
+        request_assignments: []
+        apply_assignments: []
+        notes: Same-flow transitions use the generated target-state request by default.
+    global_overrides:
+      fault_condition: error OR ((dev.signalMgmt.cumulativeOutputAction AND SignalOutputAction.ImmediateStop) <> 0)
+      reset_condition: ""
+      notes: ""

agent-skills/skills/moqui-plc-designer/references/plc-codegen-templates/DeviceFacade.template.dut

@@ -26,18 +26,12 @@ ${PROCESS_MODE_DECLARATIONS}
     lastStatus : ${MAIN_STATUS_ENUM} := ${INITIAL_STATUS};
 ${STATE_REQUEST_DECLARATIONS}
 
+    (* Subsystem FSM states exposed for diagnostics and upstream publication. *)
+${SUBSYSTEM_FSM_DECLARATIONS}
+
     (* ========== Atomic devices ========== *)
 ${ATOMIC_DEVICE_DECLARATIONS}
 
     (* Signal management - centralised fault / alarm / warning engine *)
     signalMgmt : SignalMgmt;
 END_STRUCT END_TYPE
-
-(* Questions for the skill/user:
- * 1. Which analog input signals and setpoints must be declared as REAL?
- * 2. Which digital signals must be declared as BOOL?
- * 3. Which computed predicates are required by MainRuleEngine?
- * 4. Which timing/process flags are needed (estimatedRuntime, minRuntime, etc.)?
- * 5. Which request flags correspond to the states in the selected StatusFlow?
- * 6. Which atomic devices exist: Actuator, ActuatorGroup, Axis, AxisGroup, ProcessPid?
- *)