Initial commit: intercompany ledger app
This commit is contained in:
@@ -0,0 +1,50 @@
|
||||
# Project Behavior Rules
|
||||
|
||||
## Product Truth
|
||||
|
||||
- Treat bank files as immutable evidence. Never rewrite, delete, or silently
|
||||
repair an imported source row.
|
||||
- Never infer a financial fact from a name alone when an account identifier,
|
||||
amount, direction, date, or balance check is available.
|
||||
- A bank-side observation is not automatically an economic transfer. Deduplicate
|
||||
both sides into one canonical event before calculating any relationship.
|
||||
- Same-company account transfers affect account cash positions but never enter
|
||||
intercompany balances.
|
||||
- Unknown, ambiguous, or incomplete input becomes an explicit exception. Do not
|
||||
guess a template, company, account, or counterparty.
|
||||
- Keep manual records separate from immutable bank rows. A manual record affects
|
||||
positions only after administrator approval and must retain its audit trail.
|
||||
- Treat cashier account registration as a request. Only administrator-approved
|
||||
accounts may identify ownership, accept uploads, or affect calculations.
|
||||
- Every balance shown in the UI must expose its cutoff date and unresolved
|
||||
amount.
|
||||
- Keep the administrator and cashier portals as independent route-level
|
||||
surfaces with different information priorities.
|
||||
- Apply the global calculation start date before any aggregation. Preserve but
|
||||
exclude earlier source rows.
|
||||
- Treat cashier no-business gap attestations as audited evidence, never as
|
||||
generated bank transactions.
|
||||
- Subject classification may be suggested by deterministic rules, but an
|
||||
ambiguous statutory subject must enter review rather than being guessed.
|
||||
|
||||
## Engineering Behavior
|
||||
|
||||
- Prefer deterministic parsing and validation for money, dates, account ids, and
|
||||
balance continuity. AI-like classification may suggest, never post silently.
|
||||
- Keep company and account master data dynamic. Do not hard-code the current
|
||||
group roster into code or fixtures outside tests.
|
||||
- Use decimal arithmetic for money. Preserve original precision and currency.
|
||||
- Changes to imported facts happen through a reversal or audited adjustment,
|
||||
never by editing the source transaction in place.
|
||||
- Add a focused regression test for every new bank template or parsing edge
|
||||
case. Run the complete test suite before reporting completion.
|
||||
- Keep UI copy operational and specific: state, action, consequence, and
|
||||
recovery belong near the control that needs them.
|
||||
- Do not expose temporary server filenames in import errors. Report the original
|
||||
filename, worksheet, scanned range, and useful candidate header rows.
|
||||
- Scope company-user reads, exports, uploads, and confirmations on the server;
|
||||
UI visibility is not a permission boundary.
|
||||
- Use accessible labels, visible keyboard focus, and status text that does not
|
||||
rely on color alone.
|
||||
- Keep changes scoped to the requested phase. Avoid speculative integrations,
|
||||
migrations, or design-system rewrites.
|
||||
Reference in New Issue
Block a user