light-travelpage

Light-TravelPage

旅行資料を、旅行グループで継続的に管理できるページに変換します。これはモデルから呼び出される機能です。標準の構成では、コードに GitHub を、ウェブサイトと共有状態に Cloudflare Pages、Functions、D1 を使用します。ローカルでのプレビューは開発工程です。

準備

提供された資料と既存の旅行情報があれば、それらを一度確認します。確定済みの旅程、日付、場所、フライト、宿泊予約、チケット、明示されたタスクを抽出し、実際に確認できる矛盾をまとめます。事実を変えずに中国語と英語の表示用翻訳を用意し、現地の地名と元の住所は保持します。ナビゲーション用に、各場所の国／地域と、確認済みのプロバイダーリンクまたは座標系／出典を記録します。すでに決定済みの内容を尊重します。重要な曖昧さの解消に必要な場合に限り質問し、不明な事実は未確定であることが分かるようにします。テンプレートを埋めるために、予約、座標、旅行に関するアドバイスを捏造しないでください。

データの準備または検証には、data-contract.md を使用します。日付、時刻、場所、予約の詳細で矛盾があるものや誤読しやすいものについて、小規模な非公開のソース索引を作成します。元の文書、抽出メモ、ローカルパスは公開しないでください。

新しいページを生成する前に、AI を有効にするかどうかがまだ不明な場合は、簡潔に確認してください。デフォルトはオフです。すでに選択されている場合は、再度確認せず、その選択を尊重します。有効にする場合は、ai-integration.md を確認してください。ページの所有者は、自身のターミナルで scripts/ai-setup.mjs を実行して、OpenAI 形式または Anthropic 形式の任意の API を接続します。そのため、キーが会話に入力されることはありません。モデルはデプロイ時に固定され、旅行者が変更することはできません。

生成または更新

• 新しいページ： node <skill>/scripts/create.mjs <new-project-directory>（AI オフ）を実行するか、許可を得た場合は --ai on を追加します。その後、trip-data.json と、明示的に提供されたチケットのアセットを入力します。ユーザーから再設計の依頼がない限り、旅行ハンドブックのテンプレートと handbook-design.md を使用して章の構成とタイポグラフィを整えます。依頼された内容に合ったモジュールを有効にします。
• 既存のページ： まず、現在のデータと実行時／デプロイ設定を確認します。旅行 ID、変更のないエンティティ ID、既存の地図選択、無関係なユーザー編集を保持した完全な次期データファイルを用意します。node <skill>/scripts/update.mjs <project-directory> <next-trip.json> で適用します。バックアップと公開の範囲については、update-and-export.md を参照してください。ソースデータを変更しても、共有される実行時状態はリセットされません。

生成したプロジェクトで npm ci、npm run build、npm test を実行します。PDF チケットのビルドには pdftoppm が必要です。元の PDF を保持し、生成した同名の PNG プレビューを同じ認証のもとで隣にデプロイします。無効な事実や参照を修正するか、未解決の入力を正確に報告してください。正常な結果を出すためにバリデーターを緩めないでください。明示的に日付未定の下書きでは、日付を null のままにできます。目的地が判明しており、WGS84 の場所を確認できる場合は、対応する実在の地理的な境界データを取得し、display-and-navigation.md の説明に従って geographic-outline を指定してビルドします。地図のスタイルを旅行者に選ばせず、旅行の事実に基づいて決定してください。実際のナビゲーションには場所のナビゲーションリンクを使用します。地理情報または利用可能な境界データがない場合は、その制限を報告し、テンプレートの地図には模式図であることを明記します。

二言語コンテンツ、フライト／宿泊カード、地域地図、デモ用フィクスチャの準備には、display-and-navigation.md を使用します。UI には、中国語／英語を切り替えるローカル設定があります。地図のデフォルトは各場所に応じて選択されます。中国本土は Amap、韓国は Kakao、ロシアは Yandex、その他の既知の地域は Google で、Apple Maps も選択肢として利用できます。Google と Apple での検索には、読みやすい現地の地名と住所を使用します。座標は地図の位置合わせに使うか、読みやすい場所情報がない場合の代替として使用します。地域が不明な場合は、サービスを選択する必要があります。実際のリンクをテストしてください。URL を生成しただけでは、ナビゲーションが正常に動作することの証明にはなりません。

共有とデプロイ

単一グループのアクセスと共有状態の契約についてはcloud-sync.mdを読み、その後deployment.mdに従ってください。既存の認可済み GitHub／Cloudflare ログインと、スコープが限定されたリソースを再利用してください。デプロイの認可は、無関係なアカウント変更を許可するものではありません。ログインまたは不可欠なデプロイの選択肢を利用できない場合は、ローカルパッケージを完成させ、残っている具体的な手順を報告してください。localhost をデプロイ済みページと呼んではいけません。

非公開情報は、ユーザーが認可した旅行用およびホスティング先にのみ保存してください。生成される Git ignore では、旅行データとチケットはデフォルトで除外されます。これらの情報の保存先として明示的に認可された場合に限り、コードリポジトリに公開してください。保護された Functions を使い、dist/ のみをデプロイしてください。グループアクセスコードとセッションシークレットは安全に生成し、ローカルのシークレット管理ツール経由で渡してください。ページに埋め込んだり、コミットしたりしてはいけません。再利用したアセットを配布する際は、ATTRIBUTION.mdとテンプレートのライセンスを保持してください。

検証と納品

実際のホスト URL、ページ上の認証、JSON、チケットのアセットと API を検証し、その後、独立した2つのセッションで次の項目を確認してください。共有メンバー／設定／請求／タスク／チケットの変更、競合時の応答、保存失敗からの復旧、冪等な再試行。Chromium と WebKit では、モーダル内の PDF iframe コンテンツがブロックされる場合があります。モバイルの狭いビューポートで、チケット PNG が実際に #ticket-dialog 内に表示されること、ズームが動作すること、元の PDF リンクが引き続き利用できることを確認してください。また、両方の言語、章の切り替え、日別ページの即時選択、日別マップの表示、航空券と宿泊施設の予約済み／未予約カード、旅程、読みやすい地域ナビゲーション、更新後も保存されている支出を確認してください。章、言語、ポーリングを切り替えても、フォームの下書きが消えないようにしてください。更新時は、無関係なチェックを繰り返すのではなく、変更した機能に焦点を絞ったテストを実行してください。

ライブリンク、リポジトリの場所、実装した共有の範囲、簡潔な検証の証拠、残っている制限を提供してください。アクセス情報は、保護されたローカルファイルまたはユーザーが選択した安全なチャネルで提供してください。ビルドログやモックだけを根拠に、デプロイ、独立したレビュー、同期を実施したと主張してはいけません。予約、支払い、新しいリリース／タグ、無関係な Skill の呼び出しは含まれません。

任意の機能

• オーナーがセルフホストまたはローカルゲートウェイ（Tunnel またはループバックアドレス）経由の AI を希望する場合 → light-travelpage-gw（リポジトリ）を呼び出してください。インストールされていない場合は、デプロイ済みページからアクセスできる HTTPS API のみをサポートし、その旨を伝えてください。