feishu-doc-scraper

Feishu Doc Scraper

Feishu/Lark のソースを、忠実なローカル Markdown に抽出します。lark-cli API を優先してください。本文をプログラムで抽出するため（モデルによる言い換えはありません）、コレクションの参照グラフをたどり、エラーコードから権限の境界を読み取るため、推測に頼る必要がありません。レンダリングされたブラウザページは、信頼できる情報源ではなく、フォールバックとして扱ってください。実際のコレクション抽出では、API 経由なら一貫して処理を完了でき、ブラウザ経由が必要になることはありません。

対象範囲（最初にお読みください）

このスキルの契約は、ソースごとの忠実な Markdown と、抽出した内容の記録です。生成されたファイルの命名、インデックス作成、既存のノートとの重複排除、ナレッジベースの整理方法は決定しません。それらはホスト側の PKM またはユーザー自身の規約に委ねられます。忠実な抽出で止めることで、このスキルは他の処理と独立し、再利用可能になります。ユーザーが出力を保管庫に保存したい場合は、まず抽出し、その後、整理ワークフローにクリーンな Markdown を渡してください。

読み取る、またはアーカイブするすべてのドキュメントについて、コメントとフィードバックを読み込んでください。 本文とディスカッションを組み合わせるワークフロー、選択した範囲、本文のみを対象とする例外、 スナップショットコマンド、解釈、網羅性チェックを定めています。

抽出と永続的な保存は、別々に判断します。 ダウンロードした MP4/XLSX/DOCX/画像は作業用コピーであり、そのファイルを Git または Git LFS に含めるべき証拠ではありません。ナレッジベースにアーカイブする場合、次を既定とします。

• Git：忠実な Markdown と、構造化された CSV/JSON/HTML、ソースロケーター、リビジョン／権限の状態、バイト数、MIME タイプ、ハッシュ。
• プラットフォーム上のオリジナル：安定したドキュメント／ファイルトークンを引き続き取得できる場合、未加工のバイナリ添付ファイルの記録元は Feishu のままにします。ローカルへのダウンロードは任意のキャッシュであり、新規クローン時には存在しない場合があります。
• OSS／オブジェクトストレージ：独立した永続コピーがアーカイブに必要な場合、またはプラットフォームから長期的に確実に取得できない場合に限ります。アップロードは別途許可を要する操作であり、抽出ツールが独自に選ぶフォールバックではありません。

アーカイブを保存する前に、この区分をアーティファクトマニフェストに明記し、同梱のストレージバリデーターを実行してください。完全なスキーマと例は、**references/archive-storage-contract.md**にあります。

ローカルのオリジナルメディア、失敗したメディアのエクスポート、または Obsidian への引き継ぎについては、 オリジナルメディアとリーダーへの引き継ぎを読み込んでください。 バッチを拡大する前に、検証済みプレビューのダウンローダーと API キャプチャレンダラーを使用してください。 Delivery の完了ゲート（check_reader_delivery.py finalize）がローカルアーカイブの完了条件です。変換、バイト数、検索の成功だけでは、最新の実際のリーダーによる証拠記録の代わりにはなりません。 ユーザーが選択した個人のお気に入りの保存先については、このスキルの保存管理責任を変更せずに、ソースカタログの生成ツールから favorites-search に引き継ぎます。

パスを選択する

Is the source a Feishu/Lark URL (wiki / docx / sheets / minutes / base)?
├── YES → is lark-cli installed and authenticated to that tenant?
│        ├── YES → PATH A: lark-cli API extraction  (primary — start here)
│        │         └── hit code 131006 / 99991679 (permission denied)?
│        │              └── PATH B: owner-exported .docx → faithful Markdown
│        └── NO  → install/auth lark-cli first (it is worth it); only if
│                  truly impossible → PATH D: browser DOM fallback
├── the URL is a Minutes / 妙记 link, or a doc references one → PATH C: Minutes transcript
└── you were handed an exported .docx (not a URL) → PATH B

⚠️ base（Bitable）は、パス A ではまだ実際に運用できる状態になっていません。抽出ツールはトークンを記録するだけです（DISPATCH["url-base"]: 「Bitable API（このスキルの対象外）— トークンを記録」）。また、以下のステップ 2 にも該当する行はありません。Feishu URL が取り得る形式を網羅するために記載しており、パス A で Bitable のコンテンツを最後まで抽出できるという意味ではありません。

コレクション／ハブは、本文から他のドキュメントを参照する docx にすぎません。パス A では、ブラウザでページを訪問するのではなく、参照グラフを再帰的にたどって処理します。

パス A — lark-cli API 抽出（優先）

コマンドの全一覧、再帰エンジン、テナント間および個人スペースに関する注意点については、**references/lark-cli-api-extraction.md**を参照してください。一般的なケースでの要点は次のとおりです。

1. Feishu 国内ドメインではプロキシを無効にします。 Feishu の *.feishu.cn エンドポイントは中国本土では直接接続します。ローカルプロキシ経由にすると、認証情報がプロキシを通じて漏えいし、DNS ハイジャックを受けるおそれがあります。lark-cli 自体もこれについて警告します。必ず次のようにしてください。

export LARK_CLI_NO_PROXY=1

これは、「Claude／Anthropic のドメインはプロキシを使用する必要がある」というルールと矛盾しません。Feishu は別のホストであり、直接接続します。

2. URL を分類し、取得可能なドキュメントトークンに解決します。

• …/wiki/<node_token> — wiki ノードトークンはドキュメントトークンではありません。まず解決します：

  lark-cli wiki spaces get_node --params '{"token":"<node_token>"}'
  # → .data.node.obj_token  and  .data.node.obj_type  (e.g. "docx")
  

• …/docx/<doc_token> — すでにドキュメントトークンなので、直接取得します。
• …/sheets/<token> — スプレッドシートです。sheets コマンドを使用します（リファレンスを参照）。
• …/minutes/<token> — 議事録です。Path C に進みます。

3. 本文はプログラムで取得します。モデル経由では決して取得しないでください。 本文のフィールドは lark-cli のバージョンによって変わっているため、どちらか一方に決め打ちせず、両方を確認してください（これにより、インストールされているバージョンにかかわらず動作します）。

lark-cli docs +fetch --doc <obj_token> --format json > /tmp/fetch.json 2> /tmp/fetch.err
# ≤1.0.32: clean Markdown in .data.markdown.
# 1.0.55: body moved to .data.document.content as HTML (.data.markdown is null).
if jq -e -r '.data.markdown // empty' /tmp/fetch.json > "<sanitized-title>.md" && [ -s "<sanitized-title>.md" ]; then
  : # got clean Markdown directly
else
  jq -r '.data.document.content' /tmp/fetch.json > "<sanitized-title>.html"
  pandoc -f html -t gfm "<sanitized-title>.html" > "<sanitized-title>.md"
fi

⚠️ <sanitized-title> はドキュメントごとに異なる名前にする必要があります。「source」という文字列を複数の取得で使い回さないでください。 以下のステップ 4 では、複数のドキュメント（ハブ、続いてハブが参照するすべての子ドキュメント）を同じ作業ディレクトリに取得します。source.md／source.html をハードコードしたままこのスニペットをそのまま2回実行すると、2つ目の取得によって、確認する前に1つ目のドキュメントの保存済み本文がひそかに上書きされます。このセクションの残りの部分で「source.html」／「source.md」と記している箇所は、コレクション全体で共有する1つのファイル名ではなく、現在確認している各ドキュメント自身の保存ファイルを指す便宜的な表現です。

⚠️ この pandoc ブランチでは、pandoc -f html -t gfm が Feishu 独自の埋め込みタグをいくつかひそかに削除します。実際のドキュメントで、2026-08-16/17 に確認済みです。詳しく調べるほど、損失は深刻になります：

• whiteboard（インライン図ブロックである <whiteboard token="…">）は、痕跡を一切残さず消えます。実際のドキュメントで確認済みです。.data.document.content に生タグが3つあるのに対し、pandoc で変換した source.md には痕跡が0件でした（生 HTML では grep -c whiteboard で3件、変換後の Markdown では0件）。
• mention-doc — 実際の生タグは <cite doc-id="…" file-type="wiki|docx" title="…" type="doc"></cite> であり、このスキルが当初想定していた <mention-doc token="…" type="…">Title</mention-doc> 形式ではありません — も痕跡を一切残さず消えます。トークンやタイプが失われるだけではなく、タイトルは title="…" 属性にあり、タグ本体は空なので、pandoc は要素全体を削除し、タイトルの文字列さえ残りません。
• sheet は、どちらになるか未確認です（テスト対象となる実際のシート参照ドキュメントが見つかりませんでした）。消える可能性もあるものとして扱い、そうでないことが確認されるまでは注意してください。
• image — 実際の生タグは <image token="…"> ではなく、標準の <img src="<drive-token>" alt="…" …> です — は消えません。pandoc は生の <img> 要素をほぼそのまま通過させます（src／id／href／width／height／alt は保持され、name= は削除され、mime=／scale= は data-mime=／data-scale= に名前が変更されます）。
• lark-table は、通常の docx テーブルには実在するタグではありません。通常のテーブルにはプレーンな <table> HTML が使われており、pandoc は概ねそのまま変換します（セルが単一段落の場合はクリーンな GFM パイプテーブル構文、複数段落の場合は生の <table> HTML ブロック）。このタグは、ひそかな損失が発生する種類には含まれません。

損失は実際に発生し、タグの種類によって異なるため、この pandoc ブランチを使用した場合、抽出（ステップ 4）と残存タグの確認（ステップ 5）は、必ず source.md ではなく source.html を対象にしてください。 実際のレスポンスに .data.markdown が含まれている場合は、保存したその Markdown を確認してください。どのブランチを使うかは、記憶している CLI バージョンではなく、現在のレスポンスに基づいて選択してください。1.0.80 での HTML テストが明らかにしているのは pandoc による損失の仕組みであり、後続の各リリースがどのフィールドを返すかではありません。 --format markdown は有効な値ではありません（lark-cli は警告を出し、json にフォールバックします）。stdout と stderr は分けてください。無害な [deprecated] 行は stderr に出力されます。また、実際に 2>/dev/null と jq を同時にパイプしたところ、誤った Exit code 5 が発生しました。本文は必ず jq／pandoc 経由でディスクに保存してください。モデルが再入力したり要約したりしてはいけません。言い換えると、ソーステキストが気付かないうちに破損します。これが最も重要な忠実性ルールです。（pandoc は HTML の構造を Markdown に再レンダリングするだけで、文章を書き換えることはありません。上記のタグ除去は構造上の損失であり、文章の忠実性に関するものではありません。そのため、source.html はディスク上に保持し、リッチメディア参照の正本として扱う必要があります。）

4. コレクション／ハブの場合は、参照グラフをたどります（BFS）。 ハブの本文には、<mention-doc>（実際の生タグ：<cite doc-id="…">）、<sheet>、<image>（実際の生タグ：<img src="…">）タグ、<whiteboard token="…"> ブロック、およびテナント間の URL や Minutes／Tencent-Meeting の URL が含まれます。参照をすべて抽出し、種類ごとに処理を振り分けて取得したうえで、新たに取得したドキュメントごとに、新しい参照がなくなるまで繰り返します（末端ノードまでたどります）。ただし、whiteboard は取得も再帰処理も行いません。別のドキュメントへのリンクではなく、インラインの視覚コンテンツです（下記の専用指示を参照）。参照の見落としを防ぐため、付属の抽出ツールを使ってください（参照を見落とすとドキュメントが欠落します。これはハブのスクレイピングで最も多い失敗です）。

python3 scripts/feishu_extract_refs.py "<sanitized-title>.html"   # → JSON list of {type, ref, title, dispatch}

取得したドキュメントごとに、そのドキュメント固有の <sanitized-title>.html を使って（命名上の注意点は手順 3 を参照）、これを一度実行します。まずルートで実行し、次に新たに取得した子ドキュメントごとに実行します。抽出ツールは単純な正規表現スキャンのため、対象ドキュメントの .html と .md のどちらでも動作します。ファイルのテキストにタグが含まれているかを確認するだけだからです。ただし、両方ある場合は .html を信頼してください。そのドキュメントの .html が一度も保存されていない場合に限り、.md にフォールバックします（手順 3 の .data.markdown 分岐を参照）。再帰ループ、処理の振り分け表、テナント間／my.feishu.cn の個人スペースに関するルールは、参照資料に記載されています。

ホワイトボードブロックはたどれる参照ではありません。エクスポートして、その場で読み取ってください。 whiteboard token="…" タグは Feishu のネイティブな図表／フローチャートブロックで、現在のドキュメント内にインラインで埋め込まれています。別のドキュメントへのポインターではないため、mention-doc／sheet のように再帰処理したり取得したりしないでください。内容は視覚的に理解する必要があります。フローチャートの意味は、ノードの生座標やテキスト断片のリストだけからは確実に復元できません。プレビュー画像をエクスポートし、実際に確認してください。

lark-cli whiteboard +export --whiteboard-token <token> --output-type preview --output <path>.jpg --overwrite

続いて、Read ツールで生成された .jpg を開き、図表の実際の内容を確認します。--output-type raw も利用できます（構造化されたノード JSON であり、照合や検索可能な索引として便利ですが、レンダリング済み画像の確認の代わりにはなりません）。出力形式には svg と source もあります。出力パスには、コマンドが実際に生成する形式に一致した正しい画像拡張子を指定する必要があります。実際の形式が .jpg のときに .png を指定するとエラーになります。コマンドの報告に合わせて拡張子を指定するか、独自の --help に従って拡張子を省略してください。プレビューは、デフォルトでは 作業用キャッシュです。ホワイトボードのトークン、確認した MIME／バイト数／ハッシュ、および任意のキャッシュパスをアーティファクトマニフェストに記録してください。JPEG を Git／LFS に暗黙のうちに昇格させてはいけません。長期保存用のアーカイブに独立したバイナリコピーが必要な場合は、明示的に OSS に送ってください。これは重要です。図表には、ドキュメントのプレーンテキスト部分にない、意思決定に関わる内容が頻繁に含まれているからです。たとえば、スイムレーン／プロセス図には、役割ごとの手順や、ドキュメント内のどこにも記載されていない具体的な数値しきい値が含まれることがあります。これらのブロックを開かずにドキュメントを「完全に抽出済み」と扱うと、実際の運用ロジックを最もよく示す内容が、気付かないうちに欠落します。 5. 最終的な残存タグの確認（受け入れゲート — コレクションだけでなく、取得したすべてのドキュメントで実行してください）。 他のドキュメントを参照していない単独のドキュメントにも、この確認は必要です。インラインの whiteboard や未解決の参照タグは、他のドキュメントが一切関与していなくても現れることがあります（実際、2026-08-16 に実際の単独ドキュメント抽出で起きました。ハブも再帰処理もなく、未読のホワイトボードが3つあっただけです）。リッチメディアの参照はすべて解決し、レンダリングしておく必要があります。単一ファイルではなく、作業ディレクトリ全体を再帰的に検索してください。コレクションにはドキュメントごとに <sanitized-title>.html／.md のペアが1つずつあります（ステップ3）。pandocで変換した .md はそれ単体では「問題なし」と報告する一方、実際のタグが黙って削除されている場合があるため（ステップ3の注記を参照）、ディスク上のすべての .html を検索する必要があります。

grep -rlE '<(lark-table|lark-tr|sheet token=|mention-doc|cite doc-id=|whiteboard token=|view type=)' . \
  && echo "UNRESOLVED — keep recursing" || echo "clean"

このパターンにある lark-tr と view type= は、実際のHTMLに対する検証がまだ済んでいない既存の用語です。他の5つと異なり、feishu_extract_refs.py に対応する正規表現もディスパッチエントリーもありません。ここでヒットした場合、構造化ツールによるサポートはありません。「停止して、生のタグを手動で確認する」対象として扱ってください。抽出ツールがすでに認識しているものとして扱ってはいけません。

⚠️ 各ドキュメントの保存済み .html では、「空であること」は文字どおりの停止条件ではありません。各ヒットを、ループを続けられない理由ではなく作業リストの項目として扱ってください。 各 <sanitized-title>.html は、そのドキュメントの不変な生データのキャプチャです（取得後、そのドキュメント自身のファイルがこのスキルによってインプレースで書き換えられることはありません。ステップ3のドキュメントごとの命名に関する注意を参照してください）。そのため、実際にN件の他のドキュメントやM件の図を参照している親ドキュメントは、それらすべてを正しく処理した後も、自身のファイルにN+M件の一致がずっと残ります。ディレクトリ全体でこのgrepの結果を文字どおりゼロにしようとすると、実際のハブドキュメントではいつまでも終わりません。代わりに、一致する項目ごとに、対応する成果物がディスク上に存在することを確認してください。mention-doc／cite doc-id=／sheet の一致は、参照先の子ドキュメントが実際に取得されて保存されていれば解決済みです（ステップ3を、その子ドキュメントに適用してください）。whiteboard の一致は、プレビュー .jpg がエクスポートされ、Read（ステップ4）されていれば解決済みです。別のドキュメントを取得して解決してはいけません。追跡可能な参照ではありません。 すべての一致が、ディスク上に存在することを確認済みの成果物に対応した時点でのみ停止してください。（取得した本文自体が成果物となるMarkdownであり、不変な生データのキャプチャではない .data.markdown のフォールバック経路では、文字どおり空の結果がより簡潔な目安になります。ただし、現在のどの lark-cli ビルドでもその経路に到達できることは確認されていません。ステップ3を参照してください。）

パスB — 権限拒否 → 所有者がエクスポートした .docx

lark-cli wiki spaces get_node が code 131006 … node permission denied, user needs read permission を返す場合（または取得時に同じエラーが返る場合）、これはFeishu側の強固な境界です。lark-cli、匿名curl、ブラウザーのいずれでも失敗します。これは徹底的に検証済みです。回避を試みることに時間を費やさないでください。唯一正しい対応は、権限を持つ人にドキュメントを .docx としてエクスポートしてもらい、別経路で送ってもらってから、忠実度を保って変換することです（フォントサイズから見出しへの復元、および w:shd からハイライトへの復元を行い、その後に目視で確認してください）。手順全体については、references/docx-export-to-markdown.md を参照してください。

パスC — Feishu Minutes（妙记）の文字起こし

lark-cli minutes が返すのはメタデータのみで、音声／動画をダウンロードできますが、テキストの文字起こしはエクスポートできません。文字起こしは lark-cli api 経由で呼び出すネイティブエンドポイントから取得します。また、デバイスフローログインで追加のスコープを付与する必要があります。メディアをダウンロードしてASRを再実行するより、ネイティブのAI文字起こしのほうがはるかに優れています。後者は絶対に行わないでください。エンドポイント、スコープ名、デバイスフローのタイムアウトに関する落とし穴、テナント単位ではなく分単位の権限動作については、references/feishu-minutes-transcript.md を参照してください。

Path D — ブラウザー DOM フォールバック（最終手段）

lark-cli では実際にコンテンツにアクセスできない場合に限ります（インストールできず、ドキュメントに権限の壁もない場合）。これは、以前の仮想スクロール／目次駆動型の DOM キャプチャワークフローです。処理に時間がかかり、接続されたブラウザー画面に依存します（ブラウザー内拡張機能は接続に失敗することがよくあります）。また、匿名のデバッグ用 Chrome で確認できるのは、ページが 公開状態で アクセス可能かどうかだけです。ログインが必要なコンテンツは読み取れません。ワークフロー：references/browser-dom-fallback.md。実地で検証済みの DOM ルール（仮想スクロール、data-block-id の順序、表／箇条書きの抽出、画像ストリーム）：references/browser-failure-rules.md。

厳守事項

違反すると、気づかないうちに出力が損なわれるルールです。それぞれに理由があります。文面だけでなく、その理由も踏まえて遵守してください。

• ドキュメント本文をモデルに通さないでください。 jq／cat／スクリプトを使って直接ディスクに抽出してください。モデルがソーステキストを言い換えても後から検出できず、忠実性が損なわれます。これが、構造上 Path A がブラウザーパスより優れている理由です。
• *.feishu.cn では export LARK_CLI_NO_PROXY=1 を設定してください。 そうしないと、認証情報がローカルプロキシを経由し、DNS が乗っ取られます。
• 文字起こしにはプラットフォームのネイティブな文字起こしを使い、再度 ASR を行わないでください。 メディアをダウンロードして再度文字起こしすると、話者ラベル、タイムスタンプ、精度が失われます。
• 生成した docx の Markdown は、ソースと照らし合わせて 視覚的に 検証するまで完了ではありません（画像にレンダリングして読みます）。Feishu がエクスポートした docx では、見出しに Word の見出しスタイルではなくフォントサイズと太字が使われるため、「エラーなし、単語数一致」というチェックを通過しても、見出し階層全体が気づかないうちに平坦化されます。テキストレベルのチェックでは検出できません。
• 従来の docx 画像 CLI 手法に固執しないでください。 1.0.32 までに発生したそれらの失敗から、現在のブラウザーでの元ファイルプレビューの権限について判断することはできません。本文のキャプチャには成功していて、エクスポート／プレビューに失敗した場合は、元メディアとリーダーへの引き継ぎにある操作別の分岐を使ってください。それ以外の場合は、ソーストークンを登録し、画像の未解決部分を報告してください。
• リッチメディアタグの検証は、pandoc フォールバックパスでは各ドキュメント固有の .html に対して行ってください。.md に対しては行わず、共有の固定文字列 source.html ではなく、各ドキュメント固有のファイル名を使ってください。 pandoc -f html -t gfm は Feishu のカスタム埋め込みタグを気づかないうちに削除します。実際のドキュメントで検証したところ、.data.document.content にあった生の whiteboard token="…" タグ 3 個は、変換後の .md にまったく残りませんでした（2026-08-16）。このパスで残存タグを .md だけで確認すると、コンテンツが気づかないうちに破棄されていても、常に「問題なし」と報告されます。また、ハブ内の複数回の取得（ステップ 3）で、ハードコードされた同じファイル名を使い回すと、後続のドキュメントが先行ドキュメントの未検査の生キャプチャを気づかないうちに上書きします。
• 「ダウンロード済み」を「Git／LFS に含めるべき」と同一視しないでください。 生の動画、Office ファイル、PDF、画像は、Feishu 上のオリジナルと安定したロケーターを既定とします。ローカルファイルはキャッシュです。Git には構造化された検索可能な派生物と来歴を保存します。ソースのみの保持では不十分な場合、OSS は明示的な長期保存手段として使います。パッケージをコミットする前に、python3 scripts/check_archive_storage.py <artifact-manifest.json> を実行してください。
• 匿名 curl の HTTP 200 は、アクセス可能であることを意味しません。 Feishu のログイン画面は、accounts.feishu.cn／login／passport を含む本文、または空の <title> を伴って 200 を返します。本文を確認し、ステータスコードだけから「公開されている」と判断しないでください。
• 検索エージェントが「見つからない」と報告したファイルを、確定情報として扱わないでください。 結論を出す前に、信頼できる情報源で確認してください（これは一般的な推論規律です。取り込み済みのコンテンツがすでにどこにあるかを調べる際に関係します）。
• 生成したすべてのファイルで、最後に U+FFFD を確認してください： LC_ALL=C grep -rl $'\xef\xbf\xbd' . の結果が空である必要があります。置換文字が含まれている場合、エンコーディング処理でテキストが破損しています。

受け入れ条件

次のすべてに該当する場合にのみ終了してください。

• 取得したすべての本文が、モデルによる再入力ではなく、jq／スクリプトを経由してディスクに保存されています。
• コメントとフィードバックの受け入れルールを適用しています。
• 取得したすべてのドキュメント — 単独のドキュメントもコレクションと同様に：リッチメディアタグの残存チェック（パス A の手順 5。作業ディレクトリ全体を再帰的に実行）で検出された各項目が、処理済みアーティファクトに対応しています。すべての mention-doc／cite doc-id=／sheet／テナント間参照は、取得済みの末端ファイルまでたどられており、すべての whiteboard 参照はエクスポートして読み取り済みです（たどるのではありません。ホワイトボードはインラインのビジュアルコンテンツであり、再帰的にたどるリンクではありません）。生バイナリは、安定したプラットフォーム／OSS ロケーターと、任意の検証済みローカルキャッシュに対応しています。構造化された検索可能な派生物は、バージョン管理されたファイルに対応しています。これはコレクションだけを対象としたチェックではありません。単独のドキュメントに、ほかのドキュメントが一切関係しなくても、未解決の whiteboard が含まれている場合があります。各ドキュメント固有の .html には、タグがいつまでも残っていて問題ありません（不変の未加工キャプチャであり、手順 3 に従って各ドキュメントに個別のファイル名を付けている限り、書き換えられることはありません）。grep の結果を文字どおりゼロにするために追い続けないでください。
• アーティファクトマニフェストが python3 scripts/check_archive_storage.py <manifest> を通過しています。生バイナリが Git ストレージとして宣言されておらず、すべての外部アーティファクトに安定したロケーターがあり、すべてのローカルキャッシュが非権威的なものとして明示されています。
• ローカルの読者向け成果物が、完了ゲートに従っています。変換やストレージのチェックは、読者による受け入れではありません。ユーザーが対象外としたチェックは、引き続き対象外かつ未検証のままにしてください。タスクを拡張したり、準備完了の状態にするために受領証を捏造したりしないでください。
• LC_ALL=C grep -rl $'\xef\xbf\xbd' . の結果が空です。
• docx の場合：画像にレンダリングしてソースと視覚的に比較しており、見出しの階層とハイライトが一致しています（docx リファレンスのチェックリストを参照）。
• ブラウザーでのフォールバックのみ：目次の網羅性と倍率チェックを実施しています（browser-failure-rules.md を参照）。
• 各出力ファイルの frontmatter に source（元の URL／トークン）が記録されており、後処理を行った場合は post_process の来歴行も記録されています。**ファイルごとの仕上げ手順**に従ってください。
• まだエクスポートされていない 131006 ドキュメントやダウンロードできない画像など、権限不足の項目をユーザー向けに明示しています。黙って省略するより、未対応の項目を透明性をもって示すほうが適切です。

試みてはいけないこと

検証済みの行き止まりです。再試行してもセッションを無駄にするだけです。失敗モードと根本原因を含む一覧は、**references/permission-and-failure-boundaries.md**を参照してください。主な項目：

• lark-cli／curl／匿名ブラウザーなど、どの手段でも 131006 の権限拒否を回避しようとすること。これはサーバー側の境界です。
• 1.0.32 までにテスト済みの docx 画像 CLI メソッドを再試行すること：docs +media-download、api …/drive/v1/medias/<t>/download（extra の有無を問わず）、または schema drive.medias.download。これらのメソッドは失敗しています。ただし、現在の正規のプレビューリクエストが許可されている可能性まで否定するものではありません。
• API 仕様に対して open.feishu.cn/document/server-docs/... を WebFetch で取得すること。バックエンドが不安定です。代わりに open.feishu.cn/llms-docs/zh-CN/llms-<module>.txt を使用してください（LLM 向けで安定しています）。
• AppleScript／JXA の executeJavaScript、ポート 9222 の Chrome CDP。この環境では無効または空です（ブラウザー経由のパスのみ）。
• docx を md に変換するために minimax-docx を使用すること。これは docx の作成ツールです。代わりに doc-to-markdown スキルを使用してください。

同梱リソース

• scripts/fetch_comments.py — コメントを取得する実行可能なインターフェースです。
• scripts/feishu_extract_refs.py — 決定論的な参照トークン抽出ツールであり、再帰エンジンの中核です。取得した各ドキュメントについて、そのドキュメント固有の <sanitized-title>.html（.md より優先してください。手順 3 を参照）を使って一度実行し、<mention-doc>／<sheet>／<image>／<whiteboard>／テナント間／Minutes／Tencent-Meeting の参照を JSON として列挙します。
• scripts/restore_docx_headings.py — Path B 用です。python-docx で実際のフォントサイズを読み取り、見出しレベルに割り当て、本文を再入力せずに w:shd のハイライトを Obsidian の ==…== に復元します。
• scripts/feishu_dom_capture.js — Path D 用の、注入可能なエンドツーエンドのブラウザー DOM キャプチャです。
• scripts/download_feishu_images.py — ブラウザー自動化が利用できない場合の、SSR 画像抽出ツールです。
• scripts/build_feishu_markdown.py — キャプチャマニフェストを Markdown にレンダリングします。
• scripts/check_heading_coverage.py — 網羅性を検証します（両方のパスに対応）。
• scripts/check_archive_storage.py — ソース／Git／OSS の保存先の分離を検証する、フェイルクローズ型のバリデーターです。Git アーティファクトとして宣言された生のバイナリをブロックします。
• references/lark-cli-api-extraction.md — Path A の完全なリファレンス（コマンド、再帰、シート、テナント間）。
• references/feishu-minutes-transcript.md — Path C のネイティブ文字起こし API とスコープ認証。
• references/permission-and-failure-boundaries.md — エラーコードと、「試みてはならないこと」の完全な一覧表。
• references/docx-export-to-markdown.md — Path B の忠実な変換手順。
• references/browser-dom-fallback.md と references/browser-failure-rules.md — Path D 用です。
• references/capture-manifest.md — build_feishu_markdown.py 用のマニフェスト形式です。
• references/archive-storage-contract.md — 構造化 Git アーティファクト、プラットフォームのオリジナル、任意のキャッシュ、OSS コピー向けの永続的な保存契約です。

次のステップ

ユーザーがすでに選択した保存先を使用してください。個人のお気に入りの場合は、 ソースカタログの引き継ぎ に従って favorites-search に渡してください。その選択を PKM の推奨として再検討したり、 個人向けの素材をチームコレクションに昇格させたりしないでください。保存先が選択されていない場合は、忠実なキャプチャと明示的な不足事項を渡してください。分類と重複排除は、受け取り側が選択したアーカイブのワークフローに委ねます。