doc-sync

目標:ドキュメントが現在のソースコードを反映していることを確認する。事実上のズレを修正する。構造やスタイルの再編成は行わない。

デフォルトスコープ:README.md、sml/README.md、および 100-overview.md にリストされている各パブリックパッケージの doc.go です。引数で範囲を絞ることができます。docs/secs1/*.md の設計ノートは読み取り専用の履歴です。現在の動作を誤って表現している場合のみフラグを立ててください。

手順

1. ソースをリストアップする。 スコープ内の各パッケージについて、エクスポートされたシンボル、ファンクショナルオプション、パッケージレベルのコメントをリストします。internal/ からパブリック API の事実を導き出してはいけません。
2. ドキュメントをリストアップする。 スコープ内のファイルから、すべてのコードブロック、シグネチャ、オプション名、ショートカットコンストラクタ(A、I4、L など)、および SEMI 標準的なリファレンスを抽出します。
3. 差分を取得する。 各不一致について、分類します。
   • stale — 存在するが別の方法で説明されている(間違ったシグネチャ、オプション、デフォルト値、動作)。
   • missing — ソースシンボル/オプション/エラー/動作が述べられていない。
   • phantom — ドキュメントが存在しなくなったものを説明している。
4. 修正する。 対象を絞った編集のみ。シグネチャを逐語的に一致させます(パラメータ名、型、可変長)。オプション名を修正します。ファントムシンボルについては、そのセクションを削除します(置き換えが存在する場合は 1 行の「X に名前変更」を追加)。欠落しているシンボルについては、400-documentation.md に従ってスタブエントリを追加します。
5. 修正しない 作成者の意図が必要な場合(曖昧な文法、設計ノートの決定、複数の妥当な言い換え) —「注意が必要」としてフラグを立てます。

ルール

• ドキュメントの主張を編集する前に、ソースファイルを読んでください。
• SML スニペットが現在のパーサーモード(strict/non-strict)で解析されることを確認します。
• 散文のトーン、セクションの順序、設計ノートには触れないでください。
• API の動作を捏造しないでください。ソースが曖昧な場合は、主張とソースの両方を引用します。

レポート

## doc-sync レポート

### 適用済み
- README.md:SendDataMessage シグネチャを修正; secs1 例に WithValidateDataMessage を追加。
- hsmsss/doc.go:指数バックオフ再接続をドキュメント化; WithLinktestFailureThreshold を追加。

### 注意が必要
- README.md L300:SML ラウンドトリップ例が strict/non-strict の間で曖昧 — 作成者の入力が必要。

### 変更なし
- gem/doc.go、logger/doc.go