> ## Documentation Index
> Fetch the complete documentation index at: https://docs.drpn.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Operations and validation

> Backend commands and review checks for engine changes.

These checks confirm engine changes before merge; run them from the Moqui framework checkout that contains the Darpan component unless a command states otherwise.

```text theme={null}
<moqui-framework>
```

## Common checks

| Check                                 | Command                                                        |
| ------------------------------------- | -------------------------------------------------------------- |
| Compile the Darpan backend component  | `./gradlew :runtime:component:darpan:compileGroovy`            |
| Run Darpan component tests            | `./gradlew :runtime:component:darpan:test`                     |
| Run one backend test class            | `./gradlew :runtime:component:darpan:test --tests <TestClass>` |
| Validate component organization rules | `./gradlew :runtime:component:darpan:verifyOrganization`       |
| Build the component jar               | `./gradlew :runtime:component:darpan:jar`                      |

## When to run broader checks

Run broader backend checks when a change touches:

* Shared facade services
* Entity definitions or seed data
* Active tenant or permission behavior
* Reconciliation run execution
* Generated output descriptors or file locations
* RuleSet compilation or execution
* JSON schema validation or inference

## Backend service review checklist

Backend engine changes are ready to merge when:

* The owning XML service contract is clear.
* Inputs and outputs are documented in the service definition.
* Access checks run before scoped data is returned or mutated.
* Entity queries include active tenant or company filters where required.
* Groovy helpers do not hide normal service orchestration.
* Generated outputs include both descriptor metadata and scoped file handling.
* Tests cover the changed contract or processing path.

## Expected service documentation

Backend service documentation includes:

* Service name
* Owning file
* Inputs and outputs
* Authentication and authorization expectations
* Runtime side effects
* Verification path

## Troubleshooting

For backend failures, read the earliest meaningful backend log entry for the request. The final exception often hides the first contract or data-shape problem.