Premier League Predictor: Django & MySQL — Chapter 1, Exercise 1
====================================================

TASK
Explain why this course reuses the 40/10 point values confirmed in
plpredict-fastapi1's own Chapter 6 rather than asking the question
fresh, and what that implies for any future variant in this same set.

SOLUTION

The point values for a correct score versus a correct result are a
real product decision about the app itself — what the Premier League
Predictor is supposed to reward, and by how much — not a technical
detail specific to any one framework or database. That decision was
genuinely open and unresolved when plpredict-fastapi1 reached its own
Chapter 6, so it was confirmed directly with the user at that point:
40 points for a correct score, 10 for a correct result. Once a real
product decision like that has actually been made, asking the
identical question again for a different technology variant of the
exact same app would be redundant — the four variants in this set are
explicitly four different architectures for one shared app, not four
separate apps that happen to look similar, so a decision about what the
app itself rewards applies equally to all of them.

This implies that any future variant in this set — the still-outlined
FastAPI + Redis and Astro courses — should also reuse the confirmed
40/10 split directly when they reach their own equivalent of "Entering
Results & Calculating Correct Score vs. Correct Result," rather than
re-opening the question. The point values are settled once, for the
shared app, not once per technology stack.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies that the point-value decision belongs to the shared app
concept rather than to any one technology variant, explains why
re-asking an already-resolved product question would be redundant, and
correctly extends the same reasoning forward to the two variants in
this set that haven't been generated yet.