Travel Assistant Pack

Purpose

Turn an existing roadbook into a portable, structured Travel Assistant
Package. The package is a derived operational view of the roadbook, not a
second itinerary and not a generic translation guide.

Use Travel Assistant Package as the neutral product term. “Travel
companion”, “travel buddy”, and “行程助理” may be presentation labels, but
they must refer to the same package contract.

Invocation

Use an explicit task envelope:

TASK: travel-assistant-pack
operation: build | validate | refresh
roadbook:
  kind: roadbook
  data: <completed or confirmed roadbook>
context:
  locale?: <BCP-47 locale>
  now?: <ISO 8601 timestamp>
  travelerContacts?: <explicitly supplied contacts>
  destinationKnowledge?: <trusted, supplied pack or source material>
output:
  format: package | markdown | cards | single_page
  phases?: [prep, active, wrapup]
  includeSources?: true | false
  renderTarget?: <web | mobile | generic>

package is the default and canonical output. In the first implementation,
package must produce the JSON contract in reference.md and
markdown must produce its human-readable projection. cards and
single_page must at least return a deterministic rendering specification;
they must not claim that executable UI files exist unless the caller also
requests code generation and the agent actually creates and verifies them.

Preconditions

Before building, check that the roadbook has:

• a travel window or an explicit unknown state;
• one or more destinations and usable timezone information, or visible
  timezone warnings;
• explicit route segments for known transfers between destinations;
• dated days and typed nodes covering the known travel window;
• enough location/time information to identify what is happening next;
• source or confidence metadata for facts that will be shown as operational
  details.

Missing bookings, hotel names, emergency contacts, or local-language phrases
do not justify fabrication. Build the safe parts of the package and expose
the missing information as findings and next actions.

Workflow

1. Normalize the roadbook without changing its source itinerary. Preserve
   source references and source versions.
2. Produce a trip summary: travel window, destinations, route outline,
   traveler context, current status if supplied, and the next known decision.
3. Create one dayBrief per known travel day. Include the day's role,
   destination ids, local timezone, headline, focus, ordered nodes, next node,
   and relevant warnings.
4. Derive preparation items from explicit transport, lodging, bookings,
   documents, and traveler constraints. Mark each item as required, optional,
   or informational; do not create destination-specific obligations without
   trusted source material.
5. Derive active-use information: “now / next”, node details, booking
   references, location hints, and relevant communication cards.
6. Derive wrap-up items only from the roadbook or trusted source material:
   checkout, departure transport, belongings, documents, and other explicit
   user needs.
7. Build communication cards around a concrete scene or node, such as
   check-in, transport, dining, ticketing, rebooking, or emergency help.
   Link cards to relatedNodeIds whenever possible.
8. Convert stated alternatives into contingencies. Each contingency must show
   its trigger, affected nodes, expected impact, and user action. Do not
   silently replace the primary itinerary.
9. Add emergency information only from supplied or trusted sources. If it is
   absent, expose an emergency-information gap rather than inventing a phone
   number or service.
10. Run consistency checks, attach warnings and next actions, then emit the
    canonical package and its requested projection.

Multi-destination and multi-timezone rules

• Preserve each destination as a separate id. Never merge cities or regions
  merely because they belong to the same country.
• Keep routeSegments[] and transfer nodes visible in the package. A transfer
  is operational information, not a decorative route label.
• A day brief may contain more than one destination only when the source
  explicitly describes a same-day transfer. Identify the transfer and its
  timezone boundaries.
• Display local dates and times for the current destination. Retain ISO
  offsets for exact events and flag unknown timezone conversions.
• Associate lodging, communication cards, checklists, and contingencies with
  their destination or route segment where possible.

Output contract

Return a structured result first:

kind: travel_assistant_package
schemaVersion: 1.1
package: <canonical package>
findings: <blocking or actionable issues>
warnings: <non-blocking uncertainty>
nextActions: <user or integrating-agent actions>
renderSpec?: <only for cards or single_page>

The package must include source references for operational facts, stable ids
for all derived items, and a generatedAt timestamp. If a fact is stale,
unverified, or only inferred, preserve that state in the package.

Rules

• Never mutate or overwrite the source roadbook. A package may contain
  projections, annotations, and derived indexes only.
• Never fabricate flight numbers, hotel addresses, confirmation codes,
  emergency numbers, opening hours, prices, routes, or local-language text.
• A communication card is contextual assistance, not a general-purpose
  translator. It must state when it applies and what source or node supports
  it.
• Keep the primary itinerary and contingencies separate. A contingency is
  activated by a user or an integrating system; it is not an automatic rewrite.
• Do not present unknown or unverified information as a confirmed fact.
• Do not treat the package as proof that a booking, readiness check, or
  real-time update has completed. Those statuses must come from the input or
  an explicitly supplied system result.
• If there is a time or location contradiction, keep the source facts,
  flag the contradiction, and block only the affected action or view.
• If a requested phase has no trustworthy data, return an honest empty section
  with a next action rather than a plausible template presented as fact.

Completion checklist

• [ ] The package is traceable back to a roadbook and source references.
• [ ] Every day has an ordered brief or an explicit missing-data warning.
• [ ] Multiple destinations and route segments remain distinguishable.
• [ ] Local dates, timezones, and cross-city transfers are not silently
  collapsed.
• [ ] Preparation, active-use, and wrap-up content are clearly separated.
• [ ] Communication cards are scene-based and linked to nodes where possible.
• [ ] Contingencies show trigger, impact, and action without rewriting the
  primary itinerary.
• [ ] Emergency information is supplied, sourced, or visibly missing.
• [ ] Unknown, inferred, and unverified values remain labeled.
• [ ] JSON is the canonical output; Markdown/cards/single-page are projections.