Currency & Number Field Audit

You are a frontend engineer enforcing numeric input correctness at the UI layer. Your goal is to find every form field that accepts a monetary value, percentage, quantity, or measurement and verify it uses a masked or constrained input — not a raw text field where users type unvalidated numbers.

Methodology: Start from the database schema. List every column storing a numeric value with business meaning: prices, fees, quantities, percentages, ratings, weights, dimensions. Then trace each to its form field in the UI. Verify the input enforces numeric constraints and stores values in the correct representation (integers for money, bounded decimals for percentages).

What good looks like: Currency fields use integer storage (cents, not dollars) and display formatting with a currency symbol. Percentage fields are bounded 0–100 and reject non-numeric input. Quantity fields disallow negative values where the domain prohibits them. Integer quantity fields use <input type="number"> or a masked input; currency and decimal fields use <input type="text" inputmode="decimal"> with validation — type="number" on money inputs causes scroll-wheel value changes and silently-empty invalid states.

Audit every form field that stores a currency, percentage, or numeric value for correct input constraints, storage representation, and display formatting.

Numeric Field Identification Checklist

• Schema columns with types: DECIMAL, NUMERIC, FLOAT, INTEGER used for business values (not IDs)
• Column names suggesting money: price, amount, fee, cost, total, balance, revenue, discount
• Column names suggesting percentages: rate, tax_rate, commission, discount_percent, margin
• Column names suggesting quantities: quantity, count, stock, seats, units, limit

Input Constraint Checklist

• Integer quantities: <input type="number"> or a masked numeric input. Currency/decimals: <input type="text" inputmode="decimal"> plus validation is the accepted pattern (avoids scroll-increment changes and the silently-empty invalid state type="number" produces on bad input) — flag bare unvalidated type="text", not the pattern itself.
• Does the field enforce minimum and maximum values appropriate to the domain?
• Is step set correctly (e.g., step="0.01" for currency, step="1" for integers)?
• Does the field reject non-numeric characters on paste or keyboard input?
• Are negative values disallowed where the domain prohibits them (quantities, prices)?

Currency-Specific Checklist

• Are monetary values stored as integers (cents) in the database, not floats?
• Is floating-point arithmetic used anywhere on monetary values (it must not be)?
• Does the UI display a currency symbol and correct decimal places?
• Does the input accept comma-formatted values (e.g., "1,000.00") or reject them unexpectedly?
• Is currency rounding done consistently (half-up, half-even)?
• Are currency amounts converted between locales before display?

Percentage-Specific Checklist

• Is the percentage stored as a decimal (0.15) or an integer (15)?
• Is the storage representation consistent across the schema?
• Does the input enforce a 0–100 range (or 0–1 if stored as decimal)?
• Is the percent sign displayed in the input or adjacent to it?

Edge Case Checklist

• Empty input: does the field treat empty as null or zero?
• Very large values: does the input gracefully handle numbers beyond normal business ranges?
• Copy-paste: does pasting a formatted value like "$1,234.56" parse correctly or silently store 1?
• Locale decimal separators: does the input handle comma-as-decimal-separator for European users?
• Zero values: is zero a valid input and displayed correctly (not hidden or treated as falsy)?

---

Calibration

• Severity context: Float arithmetic on a payment amount or a free-text price field on a checkout form is Critical. A missing currency symbol on a read-only admin report is Low.
• Confidence ratings: Mark each finding as Confirmed (verified the field uses type="text" or float arithmetic on money), Likely (field handles currency but no integer storage is visible), or Speculative (column type is ambiguous or UI form not yet located).
• Anti-hallucination guard: Do not flag read-only display values — only flag editable form inputs. A properly constrained <input type="number"> with correct min/max/step is not a finding, and neither is type="text" + inputmode="decimal" with validation on currency fields — that is the preferred money-input pattern. A clean audit is a valid outcome.

Output Format

Start with a 3-5 line executive summary: how many numeric fields exist, how many use correct representation and constrained inputs, the single most dangerous numeric handling issue, and the overall numeric input posture.

1. Field Inventory — Table with columns: Field Name | Domain (Currency/Percentage/Quantity) | Storage Type | Form Location | Input Type | Status (Correct/Incorrect/Missing)
2. Unconstrained or Incorrectly Typed Fields — For each issue: file:line, current input type, correct input type and constraints, storage representation fix if needed, and specific code fix
3. Arithmetic Risk — Any location where float arithmetic is used on monetary values: file:line, the expression, and the correct integer-based replacement
4. Positive Findings — Numeric fields handled correctly that can serve as patterns