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

# Engineering process

> How Darpan changes are traced, implemented, verified, and documented.

Darpan engineering work starts from product behavior and follows it through the real routes, services, entities, tests, logs, and documentation. The areas below are the checkpoints that keep a single workflow change traceable end to end.

## Work areas

| Area | Contribution |
| - | - |
| Codebase discovery | Traces a product behavior from app route to API client, facade service, entity, backend helper, and test. |
| UI implementation | Keeps custom UI in the Vue app while reusing shared page and workflow patterns. |
| Backend implementation | Keeps service contracts explicit in Moqui XML, writes service bodies as XML actions by default, and places dense processing in testable Groovy helpers. |
| Reconciliation logic | Preserves the split between Spark dataset work and Drools-backed decisioning. |
| Verification | Runs focused checks, reports what passed, and calls out remaining risk. |
| Documentation | Updates product and engineering docs from implemented behavior instead of planned architecture. |

## Tracking and branching

Every feature or bug fix starts from an item in Darpan's internal backlog. Each item has an ID of the form `DAR-<SURFACE>-<n>` (`DAR-UI-<n>` for app work, `DAR-BE-<n>` for backend work), and the backlog holds its status, priority, and next action.

* Commit messages and pull request titles reference the item ID when code work starts.
* The code repositories work directly on `main`. There are no long-lived topic branches.
* Progress, verification, and closeout notes are recorded on the backlog item, not in an external tracker.

## Engineering principles

Darpan changes preserve repository ownership boundaries, keep backend behavior contract-first and Moqui-native, and use tests, logs, and runtime behavior as evidence.

## Why it matters for Darpan

A single visible workflow can touch saved setup, schema selection, source data, tenant access, JSON-RPC services, Spark comparison, Drools rules, generated output, and result review. Good engineering keeps that chain visible and verifies the specific link it changes.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.