You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(payroll): driver settlements, Dash driver portal, and instant pay
Payroll & settlements:
- Driver settlement lifecycle (draft -> approve -> post -> paid) with GL
posting, batches, workspace, disputes, escrow ledger (49 CFR 376.12(k)),
pay advances, recurring earnings/deductions, pay codes, and YTD summaries
- Instant pay: payWorkerNow builds an off-cycle settlement from selected
accrued events and drives approve/post/paid in one pass; recurring items
skipped by default to avoid double-dipping the period settlement
- Driver expenses with receipt capture and a back-office review queue that
applies approved reimbursements to the driver's open settlement
Dash driver portal (second Vite entry at /dash):
- Me-rooted GraphQL security model with permission-less Driver role and
invitation-based activation
- Loads with stop-level arrive/depart, POD/BOL capture, realtime chat,
accept/decline with dispatch alerts, and pay estimates
- Settlement statements, disputes, escrow/advances, PTO requests, expense
submission, DQ-file compliance profile with document upload
- Web push (VAPID) notifications and a driver notification center
- Credential expiry sweep (Temporal) with driver reminders and compliance
alerts; detention candidate alerts for dispatch
Dash Control (org feature toggles):
- Per-org toggles for every driver-facing capability (load refusals, stop
actions, uploads, messaging, pay visibility, expenses, disputes, PTO,
contact edits, credential reminders, detention alerts) enforced
server-side with realtime propagation to active drivers
Also: worker autocomplete owner-operator filter (Contractor type or
effective OwnerOperator pay profile), driver_settlement sequence type,
overflow tab lists, Office/Driver login split.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Dtt7xTGRTj51u87Vgezhh5
- Keep functions small and explicit; avoid introducing `encoding/json` in Go where project lint rules disallow it.
31
31
- Bun ORM: use the [docs](docs/bun/) for help.
32
+
-**Repositories**: When writing repositories, always use the generated column helpers in `services/tms/pkg/buncolgen/` — never hand-write column references. Read [docs/bun/buncolgen.md](docs/bun/buncolgen.md) for the full method reference, canonical repository patterns, and regeneration workflow before writing any repository code.
32
33
-**Function signatures**: When a Go function has more than ~3-4 parameters, define a params struct instead of a long parameter list.
33
-
-**Utility functions go in `shared/`**: Do NOT place generic utility/helper functions inside domain, service, or handler files. The `shared/`directory (`shared/stringutils`, `shared/sliceutils`, `shared/intutils`, etc.) is the home for all reusable utilities. Create new sub-packages there if needed.
34
+
-**Utility functions go in `shared/` (backend) and `client/src/lib/` (frontend)**: Do NOT place generic utility/helper functions inside domain, service, or handler files, nor inline in React components/hooks/routes. Backend utilities live in `shared/` (`shared/stringutils`, `shared/sliceutils`, `shared/intutils`, etc.) — create new sub-packages there if needed. Frontend utilities live in `client/src/lib/` (`utils.ts`, `date.ts`, etc.). If a utility that does the same thing already exists, reuse it — never write a duplicate.
34
35
-**Performance**: Write efficient, allocation-conscious code. Preallocate slices/maps when sizes are known. Avoid unnecessary copies. Use appropriate data structures for the problem.
35
36
-**Code quality**: Prefer clarity and correctness. No dead code, no unused imports, no TODO placeholders left behind. Every function should have a single clear responsibility.
36
37
@@ -65,9 +66,15 @@ Use service-local commands from each module.
65
66
66
67
## Code Quality Non-Negotiables
67
68
68
-
-**No "v1" or placeholder code**: This is an enterprise TMS application. Implement features fully and completely on the first pass. No stubs, no TODO comments, no "we can improve this later" shortcuts, no simplified versions of what was asked. Handle all edge cases, error states, validation, and integration points. If the feature is complex, that's fine — implement the full complexity.
69
+
-**No "v1", "MVP", or placeholder code**: This is an enterprise TMS application. Never write a "v1", "MVP", or simplified version of what was asked. Implement features fully and completely on the first pass. No stubs, no TODO comments, no "we can improve this later" shortcuts. Handle all edge cases, error states, validation, and integration points. If the feature is complex, that's fine — implement the full complexity.
70
+
-**Secure and bug-free**: All code must be secure — no injection vectors, no unvalidated input, no leaked secrets, proper authorization checks — and free of bugs. Follow DRY & SOLID principles in every implementation.
69
71
- Never deviate from the established code style in the repository. Match the patterns already in use.
70
72
- Do not introduce new dependencies without justification.
71
73
- Do not leave commented-out code, TODO comments, or placeholder implementations.
72
74
- Prefer the simplest correct solution. Do not over-engineer.
73
75
- All error paths must be handled explicitly — no swallowed errors.
76
+
77
+
## Do Not
78
+
79
+
- Do not run high usage tasks that will max out CPU, Disk and/or memory usage.
80
+
- Do not run mockery against the entire codebase — manually adjust mocks in the codebase.
Copy file name to clipboardExpand all lines: CLAUDE.md
+9-2Lines changed: 9 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -149,11 +149,12 @@ Supports nested paths (`user.address.street`) and array indices (`items[0].name`
149
149
## Code Style
150
150
151
151
### General Principles
152
-
-**Production-grade, fully featured code**: This is an enterprise application. Every feature must be implemented completely — no stubs, no "v1" shortcuts, no "can be improved later" placeholders. If a feature needs error handling, edge cases, validation, proper UX states, or integration with existing systems, implement all of it in the first pass. Do not simplify or reduce scope unless explicitly told to.
152
+
-**Production-grade, fully featured code**: This is an enterprise application. Never write "v1", "MVP", or simplified versions of a feature. Every feature must be implemented completely — no stubs, no shortcuts, no "can be improved later" placeholders. If a feature needs error handling, edge cases, validation, proper UX states, or integration with existing systems, implement all of it in the first pass. Do not simplify or reduce scope unless explicitly told to.
153
+
-**Secure and correct**: All code must be secure (no injection vectors, no unvalidated input, no leaked secrets, proper authz checks) and free of bugs — handle every error path and edge case explicitly.
153
154
-**DRY**: Do not repeat yourself — extract shared logic rather than duplicating code
-**Performance**: Write the most efficient and performant code possible — avoid unnecessary allocations, prefer stack over heap, minimize copies, use appropriate data structures
156
-
-**Utility functions**: Place reusable utility functions in the `shared/` package (e.g., `shared/stringutils`, `shared/sliceutils`, `shared/intutils`). Do NOT scatter utility/helper functions in domain or service files. If a utility package doesn't exist for the category, create one in `shared/`
157
+
-**Utility functions**: Never duplicate a utility — if a function that does the same thing already exists, reuse it. Backend: place reusable utilities in the `shared/` package (e.g., `shared/stringutils`, `shared/sliceutils`, `shared/intutils`); do NOT scatter utility/helper functions in domain or service files; if a utility package doesn't exist for the category, create one in `shared/`. Frontend: place reusable utilities in `client/src/lib/` (`utils.ts`, `date.ts`, etc.); do NOT define them inline in components, hooks, or routes
157
158
158
159
### Go
159
160
- Follow the [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md) as the baseline for all Go code
@@ -179,3 +180,9 @@ Supports nested paths (`user.address.street`) and array indices (`items[0].name`
179
180
## Bun ORM
180
181
181
182
For help with Bun ORM, look in the [docs](docs/bun/).
183
+
When writing repositories, always use the generated column helpers in `services/tms/pkg/buncolgen/` — never hand-write column references. Read [docs/bun/buncolgen.md](docs/bun/buncolgen.md) for the full method reference, canonical repository patterns, and regeneration workflow before writing any repository code.
184
+
185
+
## DO NOT
186
+
-**Processes**: Do not run high usage tasks that will max out CPU, Disk and/or memory usage.
187
+
-**Mockery**: Do not run mockery against the entire codebase — manually adjust mocks in the codebase.
0 commit comments