Fullstack Builder

Fullstack Builder Skill

Vertical Slice Principle

Build one thin slice from DB to UI before expanding. Do not build the entire schema, then the entire API, then the entire UI. Build field-by-field, with each slice testable end-to-end before the next begins.

The seams between layers are where bugs hide. Making seams explicit at every step is how you catch them before integration.

Step 1 — Data Contract First

Before any code, define and confirm:

• DB schema change: exact column names, types, nullable, default, index
• API request shape: method, path, headers, body (typed interface, not prose)
• API response shape: all fields, types, nested objects, error responses
• UI state shape: what the component stores, displays, and updates

Write this as typed interfaces (TypeScript) or schema definitions. Review and get user confirmation before Step 2. This contract is the single source of truth for all subsequent steps.

Step 2 — Database Layer

• Migration script: up AND down, explicitly named with timestamp
• Model/ORM definition matching the schema exactly
• Repository/DAO layer: only DB access here — zero business logic
• Unit tests for any non-trivial query (aggregations, joins, date filters)

Step 3 — Business Logic Layer

• Service layer: receives domain objects, not raw DB rows
• Applies business rules (validation, calculation, authorization)
• No DB access directly — delegates to repository layer only
• Unit tests for every business rule: one rule = one test minimum
• For payroll: apply Decimal.js, period alignment, YTD logic here

Step 4 — API Layer

• Controller/route: maps HTTP to service calls — no business logic here
• Input validation: reject early, before service layer, with clear error messages
• Error mapping: service exceptions → correct HTTP status codes (400 bad input, 401 unauthorized, 403 forbidden, 404 not found, 500 server error)
• Response serialization: returns exactly the contract defined in Step 1
• Integration test: full HTTP request → DB → response cycle

Step 5 — Frontend Layer

• Container component: data fetching, state management, error handling
• Presentational component: display only — receives props, emits events
• API call: typed with the Step 1 contract, handles loading/error/success states
• Form validation: mirrors server-side rules (not duplicate logic — shared types)
• Accessibility: semantic HTML, ARIA where needed, keyboard navigable
• UI tests: render test + interaction test + error state test

Step 6 — Integration Verification

Run end-to-end scenario:

• Form submit → API call → DB write → response → UI update → confirm state

Error path verification:

• 400 (bad input): what does the UI show?
• 401 (unauthorized): redirect or inline error?
• 500 (server error): graceful degradation?

Double-submit prevention:

• Is the submit button disabled while request is in flight?
• Is the API endpoint idempotent or does it guard against duplicates?

File Output Convention

For each step, state explicitly:

Files created: [list]
Files modified: [list]
Files NOT touched (blast radius check): [list]

Payroll UI Specifics

• Monetary amounts: currency symbol, 2 decimal places, locale-aware formatting Use Intl.NumberFormat with style: 'currency'
• Dates: display in user's local format, always store as UTC ISO 8601
• Sensitive fields (SSN, bank account number): masked by default Explicit "reveal" user action required — never shown on page load
• Calculation results: show formula or breakdown alongside the result "Gross: $3,846.15 (annual $100,000 / 26 pay periods)" — not just $3,846.15
• Audit fields: show "Last modified by / when" on any pay-affecting record