New Feature or Structural Change

Pantry Pal's users want to save favourite dinners and see them on any device. That means accounts, a new database table, new server routes and new screens. Asked for in one line, it would produce a diff too large to review, and possibly a change to stored data that cannot be undone.

The rule

Plan it first, agree the plan, then build it in checked steps.

A change is structural when it touches several parts of the app at once, changes how data is stored, or changes something many features rely on. Most new features are structural. For these, ask the assistant for a plan before any code:

• Which files and parts change, and which new ones appear.
• What changes in the data — new tables, renamed fields — and what happens to the data that already exists.
• The order of steps, each ending in something you can check.
• The risks, and how each step could be undone.

Read the plan like a brief in reverse: does it match what you asked for, and is anything missing or surprising? Fixing a plan costs a sentence. Fixing built code costs an afternoon.

Data changes deserve extra care. A commit can roll back code, but user data that was deleted or reshaped may not come back. Back it up first, and try the change on a copy of the database before the real one.

Expect the plan to change as you build. If step 2 reveals something the plan missed, stop, update the plan and then continue. Do not let the assistant quietly improvise a different design halfway through.

The shortcut

Plan → approve → slice → check → save. It is the slicing habit from generation, applied to an app people already use.

Drills

Answer fast — trust the rule.

Remember

• Plan it first, agree the plan, then build it in checked steps.
• Plan → approve → slice → check → save. Data changes get a backup and a trial on a copy.
• Trap: a one-line request for a structural change, producing a diff and a data change nobody reviewed.