ディープリンクで列車種別をカスタム指定できるようにする

[TinyKitten]

概要

ディープリンクで列車種別 (TrainType) を任意のフィールドで上書き指定できるようにしたい。
現状は head 駅にひもづく station.trainType がそのまま navigationState.trainType に流れるため、
サーバに登録されていない種別や独自色の種別をシェアできない。

すべてのディープリンク形式 (sids / sgid+lid / ?id= 短縮コード) で動くようにする。

クライアントが TrainType として受理するフィールド

ディープリンク経由 (sids / sgid+lid のクライアント側 URL パラメータ、および
?id= のサーバ側短縮コード解決結果) から渡される TrainType 構造は、クライアント側で
以下のフィールドセットのみを受理する。

フィールド	必須	制約
name	✅	非空文字列
color	✅	/^#[0-9a-fA-F]{6}$/ (#RRGGBB)
kind	任意	TrainTypeKind enum 値 (Default / Express / Rapid / CommuterRapid / Branch / BusRoute など)
direction	任意	TrainDirection enum 値 (Both / Inbound / Outbound)
nameRoman	任意
nameKatakana	任意
nameChinese	任意
nameKorean	任意
nameIpa	任意	TTS 発音用
nameRomanIpa	任意	TTS 発音用

受理しないフィールドと理由

• id / typeId / groupId: サーバ由来の TrainType 同一性判定 (useTypeWillChange, useCurrentTrainType ほか) や lineGroupId クエリのキー。任意値を埋めると関係ない lineGroupId で fetch が走るなどの害がある
• line / lines: LineNested の入れ子構造。経路情報のシェアとは別問題
• nameTtsSegments: TTS 用の構造データ。発音補正は nameIpa / nameRomanIpa で代替する

制約に違反する値 (color が #RRGGBB (# から始まる 6 桁 HEX) 形式以外、
kind / direction が定義済み enum 外の文字列など) が含まれていた場合は、
中途半端な TrainType を作らないためにディープリンク全体を no-op にする。

ディープリンクパラメータ仕様 (sids / sgid+lid)

クライアントがクエリパラメータから経路を組み立てる sids 形式 / sgid+lid 形式では、
上記フィールドに対応する tt* プレフィックスのクエリパラメータを追加する。

パラメータ	対応フィールド
ttname	name
ttcolor	color
ttkind	kind
ttnameroman	nameRoman
ttnamekatakana	nameKatakana
ttnamechinese	nameChinese
ttnamekorean	nameKorean
ttnameipa	nameIpa
ttnameromanipa	nameRomanIpa

direction は URL パラメータ化しない (sids は駅順序、sgid+lid は既存 dir で進行方向を表現しており、
URL で同じ情報を重複記述する必要がないため)。?id= 経由のリモート解決結果に含まれる direction のみ
クライアントは受理する。

動作

• ttname と ttcolor が両方そろっている場合、head 駅にひもづく trainType を上書きして navigationState.trainType に反映する
• ttname または ttcolor を欠いた状態で他の tt* だけ指定された場合はリンク全体を reject
• いずれかの tt* が上記フィールドの制約に違反した場合もリンク全体を reject

想定 URL

• sids 形式: trainlcd://?sids=1130224,1130225&ttname=快速&ttcolor=%23ff0000&ttkind=Rapid
• sgid+lid 形式: trainlcd://?sgid=1130224&lid=11302&dir=0&ttname=快速&ttcolor=%23ff0000&ttkind=Rapid

短縮コード形式 (?id=) の対応

短縮コード形式 (?id=<code>) は resolveSidsFromShortId でサーバ側から経路情報を引いてくる
完結した解決方式で、クライアントの URL に tt* を後付けで並走させる構造になっていない。
本機能を ?id= 形式でも動かすため、サーバ側の短縮コード発行・解決スキーマに上記
「クライアントが TrainType として受理するフィールド」を含めるスキーマ拡張を行う。

• 短縮コード発行時: ユーザーが指定したカスタム TrainType フィールド (name/color 必須、他任意) をサーバ側で永続化
• 短縮コード解決時: resolveSidsFromShortId の戻り値に TrainType フィールド一式を含め、クライアントは sids/skipIndices と一緒に受け取って navigationState.trainType に反映
• クライアント側のフィールド制約 (色フォーマット、kind / direction enum など) はサーバ側でも同じく適用し、違反値が含まれていればクライアントは解決結果を no-op にする

受け入れ条件

• sids / sgid+lid 両形式で ttname + ttcolor 指定時、head 駅由来の trainType ではなく URL のパラメータが反映される
• ?id= 形式で、サーバ解決結果に含まれるカスタム TrainType フィールドが navigationState.trainType に反映される
• ttcolor (および解決結果の color) が #RRGGBB 以外、ttkind (および解決結果の kind) が TrainTypeKind enum 外、解決結果の direction が TrainDirection enum 外のとき、それぞれリンク全体が no-op になる
• ttname または ttcolor を欠いた状態で他の tt* が渡された場合もリンク全体が no-op になる
• navigationState.trainType が上書きされても useCurrentTrainType / useTypeWillChange / TypeChangeNotify などの既存挙動が壊れないこと (typeId/groupId が無くても問題が出ないこと)
• ユニットテストで上記の優先度・reject ケースを全形式で網羅

[TinyKitten]

Route Builder 側で送信側を実装しました (TrainLCD/RouteBuilder@dbe7249)。

• direct URL (sids=形式): ttname + ttcolor をクエリに付与。ユーザがピッカーで選んだ route.color が最優先、未指定なら先頭区間の路線色にフォールバック、いずれも小文字 #RRGGBB に正規化。name / color のどちらかでも欠ける場合は両方とも省略（spec 準拠）。
• 短縮URL (?id=形式): バックエンドの RouteRecord に trainType: { name, color } を同梱保存し、短縮IDのハッシュ入力にも name|color を含めて同じ sids でも 列車種別 違いは別IDに。GET /api/routes/<id> のレスポンス JSON はそのまま { sids, skips?, trainType? } を返します。
• kind / direction / nameRoman 等の任意フィールドは現状 Route Builder では UI が無いので送出していません。将来追加するときは同じ trainType payload に追記する形を想定。