Testing, Logging, and Deploy

Step 1: Write relational tests

The existing test suite covers the inventory and order endpoints from the last project. Now add tests for the relational features.

These are integration tests -- they verify behaviour across table boundaries, not within a single component. The testing pyramid says unit tests are cheapest, integration tests cost more but catch what unit tests cannot. Relational behaviour (JOINs, cascade deletes, referential integrity) can only be tested at the integration level.

Direct Claude to write tests for:

• The trace query with complete data (batch has orders, farm has batches)
• The trace query with empty relationships (batch 2024-H2-05 with no orders)
• The trace query with multiple matches (farm with multiple batches)
• Customer order endpoint with valid customer (returns their orders)
• Customer order endpoint with non-existent customer (returns 400)
• Customer order endpoint for customer with no orders (returns 200 with empty array)
• Order creation with invalid customer_id (returns 400, not 500)

The empty-relationship tests are the important ones. If any test silently passes by returning fewer results than expected (because INNER JOIN dropped the empty rows), the test is wrong -- it's testing the happy path only.

Step 2: Update structured logging

In the last project, you added structured logging with request IDs, timestamps, and log levels. The log entries worked but the context was generic -- method, path, status code. That's enough to know a request happened. It's not enough to diagnose a traceability query at 2 AM.

Update the logging middleware to include relational context. When a trace query runs, the log entry should include:

• batch_id -- which batch was traced
• farm_name -- which farm the batch came from
• orders_found -- how many orders were in the trace
• customers_affected -- how many distinct customers

When an order is created, the log entry should include the customer_id and batch_id references.

AI generates structured logging with correct syntax but commonly omits these contextual fields. The log entries will parse, but they won't help you diagnose a specific traceability query. Check the generated logging code for relational context fields.

Step 3: Performance check

Run Lighthouse and the Performance profiler on the traceability view. The JOIN-heavy queries behind this page load multiple tables in a single request. Check:

• Does the page load create long tasks (>50ms) on the main thread?
• Is the data fetch blocking the UI, or does the server render complete before the browser receives the HTML?

If there are performance issues, the likely cause is the query -- too many JOINs in one request, or no index on the foreign key columns. Adding an index on order_items.product_id and orders.customer_id can significantly reduce query time.

Step 4: Deploy

Deploy the extended system to Vercel. Verify after deployment:

• The customer portal works in production (not just locally)
• The traceability view works with production data
• CORS allows the correct domains
• Structured logs appear in the production logging output with relational context fields

Step 5: Close the project

Push to GitHub. Update the README to reflect the relational extension -- the new endpoints, the customer portal, the traceability feature.

Open the chat with Marco. Send him the deployed URL. Marco responds: "My shop in Munich tested it. They can see their orders. Good." He mentions one more thing -- could there be a way to see all batches from a specific farm? Point him to the traceability view in the admin dashboard. "Check the admin dashboard, click a farm." Marco's satisfied. Short answer. That's how he works.