CHAPTER 05 / 13 · READ → DECIDE → BUILD

Make important rules hard to break.

Design records, ownership, and permissions before real data arrives.

22 min + practiceA data and access modelJump to practice ↓

Choose the record that owns the truth

For the learning board, a task has an ID, title, creator, and optional claimant. A claim must be made against an available task and must derive the volunteer's identity from authentication. One possible implementation is a conditional database update that changes claimant only where claimant is still empty and reports whether a row changed. Another is a claims table with a uniqueness constraint on task ID. Ask your agent to compare them against your chosen database and lifecycle requirements.

A disabled button cannot enforce ownership

Two browsers can both show Available before either request finishes. Both users may submit. The server and database need a rule that holds even under that overlap. Likewise, hiding an admin button does not prevent someone calling an endpoint directly. Write a permission matrix for anonymous visitors, volunteers, and coordinators. Decide who can read, create, claim, unclaim, and delete. Keep the practice scope small enough to test each rule.

Treat migrations as changes to existing data

A migration should work on representative old records, not only an empty database. Use a disposable database and synthetic fixtures. Check nulls, duplicate candidates, foreign keys, and how old code behaves during deployment. Plan deletion and retention for both records and uploaded files if your project has them. A backup is useful only when you have demonstrated a restoration path.

SEE THE DIFFERENCE

A small example. A better decision.

THE INITIAL APPROACH

Read available=true, then later write claimant=user. Two requests can both read the same value.

THE MORE USEFUL APPROACH

Perform one atomic conditional write, or enforce a unique task claim in a transaction. Treat a losing concurrent claim as an expected conflict.

The specific query depends on the database. The lesson is to enforce the invariant at the boundary that sees competing writes.

Your build steps

Draw entities and ownership fields for your first slice.
Write a role-by-action permission matrix.
Ask the data prompt to propose and explain an atomic claim design.
Run migration and competing-claim checks in an isolated database and record the results.

FROM THE PROMPT LIBRARY

A useful brief for this step.

Model entities from business rules ↗Avoids tables that cannot represent the product's real constraints.Protect a database invariant ↗Stops invalid states from slipping past application validation.Design tenant isolation ↗Prevents one customer from reading or changing another customer's records.All data & permissions prompts

MAKE THE CALL

Think like the reviewer.

Two volunteers click Claim at the same time. Where must the one-claim rule ultimately hold?In the button's disabled state.In a warning in the user guide.In an atomic data operation or constraint, with a clear conflict response.

BUILD YOUR WORKBOOK

A data and access model

0/3 notes ready

Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.

1. Entities and invariantAdd a specific note of at least 20 characters.2. Permission matrixAdd a specific note of at least 20 characters.3. Concurrency evidenceAdd a specific note of at least 20 characters.

Before moving on

The key invariant is enforced beyond the UI.I used synthetic users to check allowed and denied actions.I recorded a concurrency check or clearly labeled why it is still unverified.

Loading your workbook…