QUICK START — TWO SNAPSHOTS, ONE EVENT

WHEN TO USE
You have an earlier guest-meal snapshot and an updated one for the same plated meal event. You want a numerical change list before manually revising the handoff. If your RSVP platform already gives you everything needed, use that platform; this free utility is optional.

PREPARE
Make a copy of both source lists. Assign a stable ID such as G001 to each person in both copies. Do not generate IDs from row positions after sorting. Keep the ID-to-name mapping separately. Every plus-one, child, vendor or staff member included in this particular count needs their own row and your caterer's agreed label. Use separate scenarios if their categories are managed outside this count. Do not silently omit them and treat the result as a complete event order.

Required first line: guest_id,status,meal
Example attending row: G001,GOING,Chicken
Example pending row: G002,PENDING,
Example declined row: G003,NOT_GOING,

The only statuses are GOING, NOT_GOING and PENDING, in capitals. GOING requires a meal label. Pending or declined rows need an empty meal field. If an attending person's choice is unknown, resolve it first; do not invent a meal or exclude the person to make the validation pass.

IDs use 1-32 letters/digits/underscores/hyphens. Meal labels use at most 80 characters and no tabs/newlines/control characters. Fields are trimmed at both ends; IDs and labels remain case-sensitive. Beef, beef and Steak stay separate. Agree one set of labels with the caterer. A case-only label variation produces a review note but is not merged.

The parser accepts comma-separated text, UTF-8 BOM, LF/CRLF and CSV quotes. For a label containing a comma, use quotes: G004,GOING,"Chef, Special"
For a literal quote inside a quoted label, double it. Use a plain-text editor or a permitted spreadsheet workflow to prepare the file. This is not a platform export importer; extra columns and wrong header order are rejected. Empty internal lines are rejected. A header alone means no people, useful for comparison tests but not evidence of a canceled event.

RUN
Paste or open the older prepared input on Baseline, newer on Latest. Opening a file validates it before a confirmation prompt replaces that side. Comparison ignores row order and matches exact IDs. Duplicate IDs are errors rather than guesses. It accepts up to 500 people / 64 KiB per side.

READ
The attending cards show GOING totals. The meal table shows old count, new count and signed delta per label. The record table lists added records, removed records, status and meal changes. A newly added PENDING person appears in the change list but adds no meal. A removed row is not a confirmed cancellation: filtered data, accidental omission or changed IDs can produce the same result.

FICTIONAL EXAMPLE
G001 changes Chicken -> Vegetarian. G002 declines, removing Beef. G004 changes PENDING -> GOING, adding Chicken. G005 is a new PENDING record. Total GOING stays 3, yet Beef drops 1 and Vegetarian rises 1. Four records change. This is arithmetic using fictional inputs, not a customer case or a savings claim.

SAVE / HANDOFF
Save both input text files while inputs are valid. The browser may require permission for two downloads; copying each box into its own text file is an alternative. Download the TXT report after comparison. Print report generates a text-style printable handoff; a large scenario can use many pages. Report label is for your own version reference; no dates or vendor acceptance are inferred. Check both source versions, pending people and removed rows; separately reconcile allergies/dietary notes, vendor/staff/child meals and table/place-card instructions. Identify the last accepted version and obtain explicit caterer acknowledgement of any revision. Follow your actual agreement and deadline.

WHAT ZERO CHANGES MEANS
The two prepared snapshots have identical IDs/status/meal values. It does not mean the original source lists are complete or correct, the event is ready, allergies are handled or the caterer accepted an update.
