Prompt:

As this is a small project and I may be ending today, as it is a Holiday, and I will pass the day working on that, we can skip the smaller tasks. But we can talk about technical acceptance criteria. We have a small logic; this is only the frontend, and it is a practice module from a React course that I'm attending. My first thoughts were:

• A file util/api.js for the two requests that we have: - fetching the products and submitting the order.
• A Cart Context, so the ProductCard can add a product and the Cart Modal can retrieve this data.
• Maybe a hook/useFetch for managing the two requests, but they return different results, and they run only one time, so I'm really thinking of a direct component calling

Perfect — this context helps a lot 👍

Given that this is frontend-only, a practice module, and a one-day holiday project, your instincts are already very good. Let’s formalize them as technical acceptance criteria, without turning this into an enterprise architecture exercise.

I’ll do three things:

1. Validate your current ideas (and adjust only where it adds real value)
2. Define technical acceptance criteria per feature
3. Clarify the useFetch vs direct call decision in a pragmatic way

0️⃣ High-Level Technical Principles (Project Constraints)

Before per-task criteria, a Product Owner + Tech Lead would usually agree on some guardrails:

Technical Constraints

• Frontend only (no backend logic)
• React (function components + hooks)
• Focus on clarity and correctness over abstraction
• No premature optimization or over-engineering

Non-Goals

• No caching strategy
• No retry logic
• No complex global state beyond cart