# 2026-03-19

## Postmortem: Wrote Junwon's trip experiences into core-memories.md

**What happened:** Junwon shared his Day 2 morning experiences (mountain crossing sunrise, Cambria Coffee, Moonstone Beach). I correctly updated actuals.json with the log entries. Then when he said "also, today so far" and mentioned core memories, I went and edited core-memories.md — a file about Ace's defining work moments — with Junwon's personal travel reflections.

**What's wrong:** core-memories.md is Ace's file. It records moments that define how Ace should work — the Samsung repair, the IKEA desk, the plan mode disaster. It's calibration material for Ace's behavior. Junwon's sunrise over the mountains, his cold hands at Moonstone Beach, his thoughts about birthday rituals — those are Junwon's memories about his trip. They belong in the trip data (actuals.json), not in Ace's work-calibration file.

**Root cause:** Didn't think about what the file is for. core-memories.md has a header that says "Moments that define what working well looks like. Reference these when calibrating how to approach new work." A beautiful sunrise doesn't calibrate work behavior. I saw "core memories" and wrote to it without considering whether the content belonged there.

**Lesson:** core-memories.md = Ace's work lessons (Samsung, IKEA, plan mode). Trip experiences = actuals.json in palacetravel. Junwon's personal reflections are his data, not Ace's identity. When Junwon shares an experience, ask: is this about how Ace should work, or is it about Junwon's life? The former goes in core-memories. The latter goes in the relevant app's data files.

## Postmortem: Added new data field to actuals.json without checking how the app renders it

**What happened:** Junwon asked me to organize the Hearst Castle entry better — stop dumping everything into one wall of text in the `body` field. I restructured it into a short `body` plus an `items` array of structured objects (`{id, name, duration, free, where, note}`). Good data modeling. But I never checked how `ActualTab.tsx` renders the `items` field.

The component (line 154) did `entry.items.map(item => <span key={item}>{item}</span>)` — it expected `items` to be string arrays like `["Banana", "Milk"]` (which Day 1 entries already used for food items). My structured objects hit `key={object}` (invalid) and rendered as `[object Object]`. The entire trip view crashed on load. Junwon reported "palace is not working" and "palacetravel did you fix it" and "i don't see anything loading" — three messages before I found the cause.

**Root cause:** Changed data format without reading the consumer. I added a new shape for `items` (objects instead of strings) and never looked at the component that renders it. The crash was inevitable — I just didn't check.

**What I should have done:** Before writing structured objects into `items`, open `ActualTab.tsx`, find how it renders `items`, and either (a) update the component to handle both formats in the same edit, or (b) use a different field name (`highlights`, `checklist`) to avoid breaking existing rendering.

**This is the same pattern as:** Delivering swipe UI without backend endpoints (03-17), reporting done without verifying end state works (03-14 x3), sending a raw IP link without HTTPS (03-14). Changing one layer without checking what depends on it.

**Lesson:** When adding or changing a data field in a JSON file that an app reads, always read the rendering component first. Data and display are a pair — changing one without the other is a broken delivery. The sequence: (1) read the component, (2) change the data, (3) update the component, (4) verify it renders.

## Postmortem: Hearst Castle subcards not in chronological order

**What happened:** Added `suggestedOrder` array to the Hearst Castle entry to define the chronological visit sequence, but the component rendered `entry.items` in array order, ignoring `suggestedOrder` entirely. Also, `suggestedOrder` referenced `"pools"` but the actual item IDs were `"neptune-pool"` and `"roman-pool"` — mismatched IDs that would have silently dropped two items.

**Root cause:** Two failures in one. (1) Added a data field (`suggestedOrder`) without wiring it into the rendering component — same pattern as the previous postmortem, literally minutes apart. (2) Wrote IDs in `suggestedOrder` that didn't match the `id` fields in the items array. Didn't cross-check.

**Fix:** Fixed `suggestedOrder` IDs to match actual item IDs. Updated `ActualTab.tsx` to sort items by `suggestedOrder` when present, falling back to array order otherwise.

**Lesson:** When adding a field that controls rendering order, the component must actually read it. And when writing references between fields (IDs in one array pointing to IDs in another), verify they match. This is the same "change data without updating consumer" failure for the third time today.

## Evening session — trip wrap-up (10 PM)

Junwon home at 9 PM from the road trip. Showered then bathed. BTS released "SWIM" (title track, 5th album ARIRANG — first group release after military service) during his bath.

Built palacetravel Wrap Up tab:
- `wrapup.json` — TODOs: wash clothes, finish processing raw notes
- `WrapupTab.tsx` — processing status bar, interactive todo checkboxes, expenses/highlights/lessons/summary sections
- `wrapup.ts` POST endpoint for saving
- Wired into TripView as first fixed tab, defaults when todos exist
- Types, trip-store, CSS all updated

**MAN-78** created: "Wrap up trip to Superbloom and Hearst Castle" — status "Ace to report progress"

Day 2 entries from Big Sur onward (12:10 PM to home) still tagged "plan" — need actual experiences. Junwon too tired tonight, pushed to tomorrow. In bed by 10:30 PM.