The trip changes

Corpus repair

A tools/dedupe-provenance.py that runs dry by default, reports every file, and collapses identical adjacent records. Blocked on your DC edits landing — every task here touches entry files you were editing tonight.

Provenance becomes real

It's written for every category and declared by none — envelope-shaped (who changed this, when, why), not category-shaped. So it goes beside sources and visuals.

• provenance joins ResolvedSchema.envelopeKeys
• One record shape: { date, source, note } — source is claude-code | import | app | hand
• Append guard in ImportService.apply; a shared appendProvenance helper so app edits stamp too (today they stamp nothing)
• Renders in the inspector envelope; the most recent three ride in every packet

Trip rules as dated data

Split the rules discovered on the road out of editorial_notes, which keeps the pre-trip stance — the admission test, the voice, the standing conventions. A rule learned on Tuesday wants a date, an id, and the ability to be retired.

"trip_rules": [
  { "id": "pacing", "date": "2026-08-03",
    "rule": "Any block over ~3 hours on foot needs a real sit-down inside it.",
    "why": "This party needs materially more sitting than the plan allowed.",
    "scope": null, "retired": false }
]

The packet renders them under their own heading, newest first, below the editorial notes — so a session can tell "this is how we write" from "this is what Wednesday taught". Retired rules get a one-line "no longer in force" list, so nothing gets re-derived after being tried and dropped.

Proposed split of the DC notes: PACING, PHOTO WINDOWS, THE CAR and PRICE CEILING move to trip_rules. BROWSABLE AND BUYABLE and ROSTERS RENDER IN THE DAY stay — they're conventions about how the guide is written, not things the road taught.

Outcome — what actually happened

On plan_item only: outcome (done · partial · skipped · moved · replaced) and a one-line outcome_note ("closed; Andy's Pizza instead").

Renders as a quiet mark in the timeline gutter and a muted italic line — a past day should read as history, not as an alert. Not rendered on the phone. Validation is prompt-not-block, matching how checked staleness already behaves.

Replan From Here — one door

A new session phase, itinerary-only, that knows what a replan is instead of making you assemble one out of the generic revision door. Renamed from "Evening Replan" on your note: a morning that goes wrong is the same operation from a different starting point.

The pool is the piece that's missing today. A replan draws from places that exist but aren't scheduled, and there is currently no way to see them without carrying the whole guide.

Four questions, pre-written in the sheet — inferred from six days of your commit messages. The first is worded to read correctly whether the day is over or halfway through:

Contract additions on top of the existing direct-edit contract:

• Stamp outcome on every plan item above the cut point — an unstamped item is the one outcome that says nothing
• Stamp provenance with a one-sentence account on every entry touched
• Propose any new standing constraint as a trip rule, never by editing editorial_notes prose
• Don't touch past days except to record their outcomes; don't touch pick or lock

The two edits a replan actually makes

The same two operations appear over and over in the log. Both are currently multi-step hand edits.

• Move to Day… — sets day, appends to the target day's order, stamps provenance
• Promote alternate to the plan — clears alt/alt_kind across that named alternate and offers to demote what it displaces into an alternate named for what was dropped. This is "Tysons abandoned at 12:15", which took a whole session

Know when the live page has gone stale

Record published on a successful publish; when the newest entry updated is ahead of it, the publish control fills and turns amber — exactly the machine-target drift pattern that already exists. Hover names the count. No auto-publish; publishing pushes to a live site and stays deliberate.

An hour of work, independent of everything else. Arguably do it first.

The Post-Mortem new

{ "id": "beckett", "name": "Beckett", "dietary": "vegetarian",
  "palate": "picky", "loves": [], "avoids": [], "notes": "" }

Three pieces, and conflating them would be the design error: the changelog is evidence (mechanical, no judgment), the post-trip fields are impression (authored by you), and the analysis is the argument between them.

7A — The changelog, derived and never authored

tools/trip-changelog.py, reading path-scoped git log plus provenance plus outcomes. Path-scoping matters: the log carries both live(dc): … and bare refactor: 16 revised entries, and only the path says which guide a generic commit touched.

7B — The post-trip fields, authored by you

postmortem: { completed, verdict, what_worked, what_to_change, per_traveler } on guide.json. per_traveler is keyed by profile id, so "Beckett refused every sit-down dinner" has somewhere to go. The section appears only once the last day is past — before that it isn't a form to ignore, it's absent. Runs before the existing freeze-snapshot step, since a frozen guide is read-only.

7C — The analysis, arguing with the evidence

A session phase carrying your account first, then the changelog, the outcomes, the trip rules, the brief as written before departure, the profiles as they stand, and the schema. What it returns, in order:

1. Where the evidence disagrees with your account. First, because it's the only thing memory cannot produce. "You said Georgetown went well; three of its six items were replaced on the day."
2. Recurring causes, counted, with entry ids — closure/hours · ran out of time · preference · logistics · weather. If half the replans are "ran out of time", the next itinerary carries fewer items per day, and that's a claim the corpus can support.
3. Preference signals per traveler, as proposed edits to profiles/<id>.json.
4. Which planning conventions held. Did if_time (○) stops actually happen? Did anchors survive? Did early items survive better than late ones? A convention that never predicts anything is decoration.
5. Brief gaps. DC's brief captured travel_mode: driving but never asked is the car available during the day? — which is exactly what day 3 learned the hard way.
6. Framework gaps — fields never filled, fields filled but rendered nowhere, and keys written that no schema declares. That last check would have caught provenance on day one instead of on trip three.
7. Which trip rules should graduate, and where to.

Every claim cites entry ids, dates or commits. A pattern without evidence is a guess, and beating memory is the entire point.

7D — Where an insight actually goes

The gap gets one small field: default_editorial_notes on CategoryConfig, seeding a new guide at creation — the same shape as default_design_system and default_publish_path, which already work exactly this way. A rule proven across two trips graduates there. One trip is an anecdote, and the framework shouldn't encode an anecdote.

Capture on the ground deferred

Written down so the design exists when it's wanted, and so Phase 4 isn't quietly assumed to cover it.

Each plan row gets three taps — did it · skipped it · note — into localStorage, exactly as stars already do. A "Today's marks" button composes a plain-text block and copies it. That block pastes into the Replan sheet's question field, where Phase 4's contract already knows what to do with it.