Engineering process - Darpan Developers

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.