ADR-32: 文字列リテラルを導入する（tz/source の字句衝突の解消。ADR-28 の追補）
判断: 引用符つき文字列リテラル "…" を字句に追加し、値型の文字列を「将来」（ADR-25・spec §2.2）
から現行に引き当てる。tz:・source: のメンバー値は文字列リテラルで書く（tz: "Asia/Tokyo"・
source: "cao.go.jp/official"）。文字列は " から次の " まで（改行を含めない・エスケープ列は当面
持たない＝引用符を含む文字列は将来拡張）。これで EBNF の member = member-key ":" value-expr が
特例なしに成立する。
背景: リファレンス実装で tz: Asia/Tokyo の / が除算、cao.go.jp の . が premise 修飾と
衝突し、メンバー値が value-expr として読めないことが顕在化した（F50）。IANA TZ 名・URL 風の出所表記は
識別子の字句に収まらない。
却下した案:
- TZ/出所専用の裸字句（メンバー値の位置に限り
/・.を含むトークンを許す）。今の字面（引用符なし）を 保てるが、字句が文脈依存になり、除算・修飾との線引きが濁る。 - メンバー値を行末までの生テキストとして読む（リファレンス実装の暫定）。最も安直だが EBNF に乗らず、 「文法と記号」章の体系を壊す。
- 文字列を導入せず TZ を列挙（
AsiaTokyo等）に写す。IANA 名との対応が崩れ、出所（URL・組織名）は そもそも列挙にできない。
帰結:
- 値型は「数値・論理・列挙・リスト・文字列」で確定（「将来の文字列」の前倒し。型の追加ではなく 予告済み枠の充足——ADR-25/30 の型体系に触れない）。
- spec §2.2・§3.2（前文の例）・§3.5（値式表）・§3.8（JPGazette 例）・§5.1/§5.5（字句）・§5.6 EBNF
（
string-literal）・draft §1.6・domain-model の例を一括修正。asof:は従来どおり列挙latestか 日付リテラル。 - 文字列の演算（連結・比較以外）は定義しない。等値比較
==のみ（ラベル同様）。