Contribute to Helm

Begin with the existing architecture and the relevant feature’s actual contract. A good contribution fixes a concrete behavior without introducing another financial write path or unrelated scope.

Contribution sequence

1. Describe the user trigger and expected result.
2. Read the route, client helper, service and tests involved.
3. Make a bounded change in the owning layer.
4. Run checks that establish the changed contract.
5. Review the resulting user flow and explain its practical limits.

Use coding standards and project structure for implementation conventions.

Financial changes

Preserve per-currency balance, owned resources, date semantics, idempotency and evidence. A numeric result can be balanced but still misclassified, so review both money and meaning.

Schema changes require forward migrations and corresponding runtime/type verification. Do not hide deployed drift behind a cast or direct browser table access.

Documentation changes

Teach the actual task with current controls, expected result and useful recovery. Preserve published links when possible. Label future capabilities clearly and use explicitly fictional examples with dates and currencies.

Do not publish private user records, credentials, internal inventories or unsupported hosted claims. A source file is not proof a planned feature is available.

See testing to match the evidence to the contribution.