ov-session-report

OpenViking セッション Q&A 週間レポート

ユーザーから提供されたセッションデータのみを読み取ります。データを整理して正規化し、期間を適用し、指標を算出し、トピックを分類し、リスクを確認し、前の期間と比較して、自己完結した Markdown ファイルを 1 つ作成します。デフォルトのタイムゾーンは Asia/Shanghai です。

提供範囲

• 分析対象となる情報源は、sessions_root 配下のセッションファイルのみです。他のコミュニティ、メッセージストリーム、ディレクトリ、オンラインチャットデータを取得または統合しないでください。
• .md ファイルをちょうど 1 つ作成します。分析中に一時スクリプトや中間ファイルを使用してもかまいませんが、レポートはそれらがなくても理解できる必要があります。
• オンラインのドキュメント、メッセージング、連絡先、ホワイトボードの API を呼び出さないでください。XML、HTML、SVG、PNG ファイルを作成したり、何かをアップロードしたりしないでください。
• ドキュメントおよびホワイトボードのデータ要件を満たしてください。Markdown には、後続のレンダラーがセッションを再度開かずにレポート本文、サマリーダッシュボード、比較ダッシュボード全体を作成できるだけの集計値、時系列、ランキング、結論、人間のメッセージからの抜粋を含める必要があります。
• 推測で件数を見積もらないでください。すべての数値は、解析したデータまたは再現可能な計算式に基づいている必要があります。また、重要な結論はすべて、具体的なセッションメッセージにたどれる必要があります。
• セッションから主張を裏付けられない場合、全体的な事実として提示するのではなく、「データの締め切りまでに裏付けとなる証拠は見つかりませんでした」と記載してください。

デフォルトの出力ファイル名：

OpenViking_Community_QA_Weekly_Report_YYYY-MM-DD_to_YYYY-MM-DD.md

入力

• sessions_root：必須。このディレクトリから .jsonl セッションファイルを再帰的に読み取ります。
• current_start / current_end：任意。今回のレポート期間の開始境界と終了境界です。
• previous_start / previous_end：任意。比較対象となる前の期間の開始境界と終了境界です。
• previous_report：任意。このスキルで作成した Markdown レポートです。公開済みの定義と過去の数値を維持するために使用します。
• output_path：任意。省略した場合は、現在のワークスペースにある reports/qa-weekly-YYYYMMDD-YYYYMMDD/ に書き込みます。
• session_scope：任意。ユーザーから指定されたサブディレクトリ、ファイル名パターン、または明示的なセッションセットです。
• history：任意。後続のドキュメントレンダリング用に、確認済みのレポートタイトルとリンクを指定します。これらは照会せずにそのまま引き継ぎます。

可能な場合は、ディレクトリ構造、タイムスタンプ、前回のレポートから不足している値を推定します。対象となるセッションセットまたはレポート期間を特定できず、選択の違いによって結果が大きく変わる場合にのみ、ユーザーに確認してください。

レポートの順序

Markdown レポートは、次の順序にしてください。

1. タイトル：OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD
2. Executive Summary
3. Releases This Week
4. Weekly Topic Ranking
5. Open High-Priority Issues
6. Week-over-Week Comparison
7. Weekly Activity
8. Trends and Recommendations
9. Methodology and Data Notes
10. Previous Reports
11. Appendix: Structured Report Data

Releases This Week では、「リリースされた」「デプロイされた」「インストール可能」などの明示的な証拠がセッションに含まれているバージョンのみを要約できます。「予定されている」「見込みである」「次のリリースに含まれる予定である」といった記述は、リリース完了を意味しません。該当する証拠がない場合は、「今週のセッションから正式なリリースは確認できませんでした。」と記載してください。確認のためのウェブ閲覧はしないでください。

期間

半開区間を使用します。

Current:  [current_start, current_end)
Previous: [previous_start, previous_end)

締め切りは、次の優先順位で選択します。

1. ユーザーが明示した締め切り。
2. 継続中の週次レポートの場合、前回のレポートのcurrent_end + 7 days。
3. ユーザーが「現時点まで」と指定した場合、Asia/Shanghaiの現在時刻。
4. ユーザーがディレクトリを特定時点のエクスポートスナップショットだと明示した場合に限り、最新メッセージのタイムスタンプを使用します。

比較要件：

• 現在の期間と前の期間は同じ長さにし、境界で接し、重複させないでください。
• デフォルトでは連続する7日間の期間を使用します。ユーザーが最初の期間を短くするよう求めた場合は、タイトルと方法論の注記の両方に実際の範囲を記載してください。
• 現在の締め切り時刻以降のメッセージは、次のレポートに含めます。
• 最も古いエクスポート済みメッセージが指定された開始日時より後の場合は、指定された期間を維持し、データの不足を明記してください。
• 有効なメッセージの最も古い日時と最も新しい日時、および指定された境界からの差を記録してください。
• 現在のディレクトリに前期間のデータがない場合は、previous_report内の構造化された付録を優先してください。どちらもない場合は、比較セクションを残して、前期間は利用できないと記載してください。不明な値をゼロに置き換えてはいけません。

セッションファイルの検出

まず候補ファイルを一覧表示します。

rg --files "$SESSION_ROOT" -g '*.jsonl'

ディレクトリ内のすべてのファイルが対象データセットに属すると決めつけないでください。

1. ディレクトリ階層、ファイル名のプレフィックス、利用可能なメタデータごとにファイルをグループ化します。各グループのファイル数と時間範囲を特定してください。
2. 各グループの先頭、中間、末尾から人間のメッセージをサンプリングし、OpenVikingコミュニティの質疑応答セッションが含まれていることを確認してください。
3. テスト会話、内部デバッグ、ボットの自己テスト、無関係な製品、明らかに無関係なデータを除外してください。
4. ユーザーが正確なsession_scopeを指定した場合はそれに従いますが、データが含まれていることも確認してください。
5. 検出、採用、除外したファイルの数と除外理由を方法論のセクションに記録してください。内部識別子については、マスクした要約のみを開示してください。

ファイル数が最も多いという理由だけで、対象データセットを選択しないでください。

JSONLの解析と正規化

各行に実際のJSONパーサーを使用します。

• 不正な形式の行をbad_linesにカウントします。ローカルでの監査用にファイル名と行番号を保持しますが、最終レポートでは開示しないでください。
• _type=metadataなどのメッセージ以外の行はスキップします。ただし、セッション識別子とコンテキストメタデータは引き続き使用してください。
• タイムスタンプフィールドは次の順に試します：timestamp、created_at、create_time、time。秒単位とミリ秒単位の数値タイムスタンプに対応してください。
• タイムゾーン付きの値はAsia/Shanghaiに変換します。タイムゾーンのない値はAsia/Shanghaiとして扱い、その前提を明記してください。
• メッセージ本文はプレーンな文字列を優先します。構造化された本文の場合は、解析中は元のオブジェクトを保持し、脆弱な文字列の切り出しではなく、その構造化フィールドから読み取れるテキストを抽出してください。
• 元のロール、正規化後のロール、タイムスタンプ、セッションキー、メッセージキー、内部話者キー、表示名の候補、正規化済みテキストを保存してください。

ロールは次のように正規化します。

• user、human、および同等のロールは、人間のメッセージとして数えます。
• assistant、bot、および同等のロールは、アシスタントのメッセージとして数えます。
• system、tool、メタデータ、および同等のレコードは別枠にし、人間のアクティビティやトピックの開始者には含めません。
• 判定できないロールはunknown_role_messagesに含め、判断を下す前に手作業でサンプリングしてください。不明なロールをデフォルトで人間として分類してはいけません。

重複排除とディスカッション単位

一意のセッションを1つのディスカッション単位とします。

次の順序で重複を排除します。

1. 安定したメッセージ ID を優先します。
2. メッセージ ID がない場合は、session_key + timestamp + sender_key + normalized_text のハッシュを使用します。
3. 重複するセッションエクスポートは1つだけ残し、メッセージがより完全で、時間範囲がより広いファイルを優先します。
4. ファイルの一部だけが期間内に含まれる場合は、期間内のメッセージのみをカウントします。前後の期間外メッセージは文脈の把握に使用できますが、カウントしてはいけません。
5. 同じ課題のファイルは、共通のルートキー、返信チェーン、またはその他の強い重複の証拠がある場合にのみ統合します。テキストの類似性だけでは不十分です。

有効なディスカッションとは、実際の技術的な質問、障害、設計の比較、使用に関するフィードバック、または実行可能な回答を含むものです。単なる共有、状況報告、挨拶、ボットのテスト、内容のないリンクの転送は、メッセージ総数には含めても、有効なディスカッションには含めません。

ID の特定とマスキング

表示名はセッションファイルに記載されている情報のみを使用できます。

1. メッセージ上の明示的な表示名フィールド。
2. 同じ内部 ID と繰り返し関連付けられている、安定した [Name]: または [Name]： 形式のプレフィックス。
3. どちらも利用できない場合は、Name unavailable を使用します。名前を推測したり、内部 ID を表示したりしてはいけません。

1つの ID に複数の表示名候補がある場合は、出現頻度、時間的な一貫性、文脈を確認します。証拠が不十分な場合は、ID を別々に扱います。

マスキングルール：

• 1文字の場合は、* と表示します。
• 2文字の場合は、最初の文字を残します。例：张三 -> 张*
• 3文字以上の場合は、最初と最後の文字を残し、その間の文字をすべて * に置き換えます。例：秦浩杰 -> 秦*杰
• ラテン文字、数字、混在するエイリアスにも、同じ文字数に基づくルールを適用します。例：darren -> d****n、Lin101 -> L****1
• ユーザーが申告した機密性の高い名前には一般ルールを適用せず、最初の文字だけを残します。例：胡江涛 -> 胡**
• Markdown の文章中で、マスキング用のアスタリスクが強調表示の内部にある場合は、エスケープします。例：Q\*n。構造化 JSON では、生の値を Q*n のままにします。

最終的な Markdown と構造化 JSON に、完全な人名、メールアドレス、電話番号、生の ID キー、Authorization 値、API キー、ルートキー、テナントキー、または認証情報とみられる長い文字列を含めてはいけません。

指標

両方の期間で、同じコードと定義を使用します。最低限、次の項目を計算します。

• discussion_units：一意のセッション数。
• effective_discussions：有効なディスカッション単位数。
• participants：期間内の一意な人間の ID 数。
• human_messages：人間のメッセージ数。
• assistant_messages：アシスタントの返信数。
• system_messages：システムおよびツールのメッセージ数。
• unknown_role_messages：役割を特定できないメッセージ数。
• total_messages：カウント対象の全メッセージ数。

次の不変条件を満たす必要があります。

human_messages + assistant_messages + system_messages + unknown_role_messages = total_messages

参加者数、Top 10 ユーザー、キーワードには、人間のメッセージのみを使用します。アシスタントのメッセージは、Q&A の文脈の解釈や、質問に回答があったかどうかの判断に役立てることはできますが、人間のランキングを増やすために使用してはいけません。

トピックとキーワード

週をまたいで一貫したトピック分類を使用します。推奨される基本分類は次のとおりです。

• ストレージ、インデックス作成、検索
• ボット、エージェント、スキルのアプリケーション
• デプロイ、ランタイム、環境設定
• メモリ、圧縮、アーカイブ
• モデル、解析品質、コスト
• 権限、マルチテナント、コラボレーション
• SDK、API、ツール
• ドキュメント、サンプル、使用方法に関する質問
• その他

分類ルール：

• 複数のトピックを割り当てる前に、セッション全体を読みます。
• 1つの議論単位が複数のトピックに該当する場合があるため、トピックごとの件数の合計は議論単位の総数と一致する必要はありません。
• 各トピックについて、議論単位数、参加者数、人間のメッセージ数、キーワード、および簡潔なインサイトを1つ算出します。
• トピックは、議論単位数、人間のメッセージ数、参加者数、固定されたトピック順の順に並べます。
• 上位20件を算出する前に、キーワードの大文字・小文字、全角・半角、単数形・複数形、および一般的な別名を正規化します。
• トピックに関係のないストップワード、挨拶、テンプレート文、マスキングされた名前、パスの一部を除外します。
• Memory、add_resource、VLM、MCP など、識別可能な技術表記は維持します。

人気のあるトピックやキーワードに関連するセッションを手作業でサンプリングし、誤分類、ログのノイズ、アシスタントの繰り返しによる頻度の水増しがないか確認します。

優先度の高い未解決の問題

データの締め切り時点で未解決の優先度の高い問題のみを、デフォルトでは最大4件まで記載します。ここでの未解決とは、締め切りまでの利用可能なセッションに、明示的な修正、利用可能なリリース、既存インスタンスの復旧、ユーザー側での検証がすべてそろった一連の記録がないことを意味します。

候補は、次のいずれかの条件を満たす必要があります。

• 複数の独立した人間が同じ問題を報告している。
• 具体的なログ、失敗率、または再現手順があり、メンテナーによる確認もある。
• Session Commit、リソースの取り込み、セマンティックインデックス作成、権限の分離、データ整合性などの中核的な処理経路に影響する。

次の問題は除外します。

• 利用可能なデータ期間内に修正され、ユーザーによる検証も完了した問題。
• 文脈のない単発のエラー、通常の設定に関する質問、またはアシスタントの返信にのみ見られる仮説。
• セキュリティテスト、雑談、ボット同士のやり取り、または根拠のない根本原因の主張。

すべての問題に、次の6項目を含めます。

1. Priority / Category
2. Background
3. User Impact
4. Evidence
5. Current Assessment
6. Community Feedback

各問題の直後に、その問題に固有の Human Feedback Excerpt を記載します。人間のメッセージのみを含め、アシスタントの返信と内部リンクは省略します。

> **08-31 21:16 | O\*\*\*r**
> Session Commit has failed repeatedly...
>
> **08-31 21:19 | 秦\*杰**
> The current fix direction is still incorrect and needs another revision.

各引用は、その問題に関連するセッションから取得し、タイムスタンプ、マスキングされた名前、要点を維持します。長いログは短縮でき、無関係なテキストは省略できますが、会話を捏造したり、別の問題のメッセージを混在させたりしてはいけません。

今週のリリース

セッションから、完了したリリースを明示的に示す情報のみを抽出します。対象は、バージョン、確認時刻、主な変更点、修正内容、アップグレードに関する警告、および関連する議論です。

• 「リリースした」「デプロイした」「新しいバージョンが利用可能」といった記述のみを数えます。
• 「リリースの準備中」「予定」「次のバージョン」は、完了したリリースではなく計画として扱います。
• メッセージに矛盾がある場合は、後の時点の記述のうち、ユーザーによる検証で裏付けられたものを優先し、根拠の注記には不確実性を残します。
• 根拠が不十分な場合は、このセクションを残し、「今週のセッションから正式なリリースを確認できませんでした。」と記載します。
• セッションに明示されていて、基本的な形式として有効な URL のみをそのまま記載します。ブラウジングしたり、リンクを捏造したりしてはいけません。

前週比の比較

まず規模を比較し、次に内容を比較します。

1. 議論単位、有効な議論、参加者、人間のメッセージ、アシスタントのメッセージ、メッセージ総数について、前回と今回の値、絶対変化量、変化率。
2. 安定したトピック分類ごとの前回と今回の値、および変化率。
3. 上位キーワードとアクティブユーザー上位の変化。
4. 前回の焦点、今回の焦点、および意味のある変化の解釈。
5. 活動量の変化と議論内容の変化を区別した全体的な結論。

変化率の計算式：

(current - previous) / previous * 100

前回の値がゼロで、今回の値が正の場合はNewと表示します。両方がゼロの場合は0.0%と表示します。前回の値が不明の場合はNot comparableと表示し、不明な値をゼロに置き換えないでください。

焦点の変化は、両方の期間における高頻度セッションダイジェストを人間が確認して判断する必要があります。キーワードの増減だけから推測しないでください。

週間の活動状況

以下を含めます。

• 参加者、人間のメッセージ、アシスタントのメッセージ、システムメッセージ、メッセージ総数。
• 7日間の期間における、人間、アシスタント、メッセージ総数の日別件数。
• 00時から23時まで、すべての時間帯における人間のメッセージ件数。
• ピーク時間、2番目に多い時間帯、ピーク日。
• アクティブな人間上位10人。順位、マスク済み表示名、メッセージ件数、議論単位数、主要キーワードを含めます。
• 任意で回答カバー率と応答時間。メッセージの順序と返信関係が信頼できる場合にのみ計算し、ヒューリスティック指標であることを明記します。

24時間のピーク時間の時系列をMermaidで表示し、24時間分の表も残します。

xychart-beta
    title "Hourly Human Message Distribution (CST)"
    x-axis ["00","01","02","03","04","05","06","07","08","09","10","11","12","13","14","15","16","17","18","19","20","21","22","23"]
    y-axis "Messages" 0 --> MAX
    line [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

MAXと24個すべてのデータポイントを置き換えます。Mermaidを描画できない場合でも、完全なデータ表に結果を残す必要があります。

傾向と推奨事項

実行可能な推奨事項を3～6件提示します。各推奨事項には、以下を含める必要があります。

• 観察された事実または変化。
• Q&Aの効率、製品体験、または保守作業への影響。
• 修正、ドキュメント、監視、リリース、回帰テスト、またはコミュニケーションに関する具体的なアクション。

未解決のP1課題、高頻度で繰り返される質問、リリース後の互換性に関する警告、活動の変化、データ品質の不足を優先してください。「監視を続ける」「さらに最適化する」など、具体的なアクションを示さない曖昧な表現は避けてください。

ドキュメントとホワイトボードのデータ要件

このスキルはオンラインドキュメントを作成しませんが、Markdown出力は現在の週次レポートのレイアウトをそのまま支えられる必要があります。

サマリーダッシュボード

構造化データは、以下の生成に十分な内容である必要があります。

• 4つのKPI：議論単位、有効な議論、参加者、メッセージ総数。
• 週間トピック上位6件と、議論単位数の棒グラフ。
• 未解決のP1カードを最大4件。
• 24時間の人間のメッセージの折れ線グラフと、ピーク日の注釈。
• アクティブなコミュニティメンバー上位10人。
• 主要キーワード上位20件。簡易ボードには先頭の12件を表示できますが、Markdownには20件すべてを残します。

比較ダッシュボード

構造化データは、以下の生成に十分な内容である必要があります。

• 前回から今回への指標カードを3つ：議論単位、参加者、メッセージ総数。
• 安定したトピック分類上位6件の比較棒グラフ。
• 焦点の変化の一覧。
• 活動量と議論内容の両方を網羅する全体的な結論。

ドキュメント本文

• エグゼクティブサマリーは、構造化された指標と結論から作成します。
• リリースのセクションは、セッションで確認できる、完了したリリースの明確な証拠に基づいて作成します。
• すべてのP1を6つのフィールドと、独立した人間のチャットのシミュレーションブロック付きで表示します。
• 比較指標6つすべてを本文に記載し、ボードには主要な指標を3つだけ掲載します。
• 推奨事項、方法論の注記、前回のレポートへのリンクは、それぞれ独立したフィールドとして保持します。

重要な数値を、構造化データに含めず、説明文だけに記載してはいけません。

qa-report.v3 データコントラクト

Markdown は、1 つの qa-report.v3 JSON オブジェクトで終わる必要があります。文章は読み物であり、JSON が後続のドキュメントおよびホワイトボードのレンダリングにおける信頼できる唯一の情報源です。

ルール：

• JSON は有効でなければならず、コメント、末尾のカンマ、NaN、省略記号、プレースホルダーを含めてはいけません。
• と の間に配置し、ドキュメント内の最後の JSON フェンスブロックにしてください。
• +08:00 を含む ISO 8601 形式のタイムスタンプ、YYYY-MM-DD 形式の日付、0 から 23 までの整数の時刻を使用してください。
• 件数は整数、パーセンテージは数値として保存してください。不明な値には null を使用し、ゼロで代用してはいけません。
• daily は、現在のウィンドウ内のすべての日付区分を網羅する必要があります。hourly には、活動のない時間帯のゼロも含め、ちょうど 24 個のエントリーを含めてください。
• JSON を記述する前に、人間の表示名をすべてマスキングしてください。名前の対応表や内部の識別キーは保存しないでください。
• 文章中のすべての数値は、このオブジェクトから直接読み取れるか、単純な算術、並べ替え、または変化率の計算式で再現できる必要があります。

必須フィールド：

{
  "schema_version": "qa-report.v3",
  "report": {
    "title": "OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD",
    "generated_at": "YYYY-MM-DDTHH:mm:ss+08:00",
    "timezone": "Asia/Shanghai",
    "window": {
      "current": {"start": "YYYY-MM-DDTHH:mm:ss+08:00", "end": "YYYY-MM-DDTHH:mm:ss+08:00"},
      "previous": {"start": "YYYY-MM-DDTHH:mm:ss+08:00", "end": "YYYY-MM-DDTHH:mm:ss+08:00"}
    },
    "coverage": {
      "sessions_root": "user-supplied local path",
      "discovered_files": 0,
      "included_files": 0,
      "excluded_files": 0,
      "included_sessions": 0,
      "earliest_message": null,
      "latest_message": null,
      "bad_lines": 0,
      "missing_timestamps": 0,
      "complete": true,
      "notes": []
    }
  },
  "summary": {
    "headline": "One overall conclusion",
    "top_topic_names": [],
    "peak_hour": 0,
    "peak_hour_messages": 0,
    "peak_day": "YYYY-MM-DD",
    "peak_day_messages": 0,
    "open_p1_count": 0,
    "release_versions": []
  },
  "presentation": {
    "section_order": [
      "Executive Summary",
      "Releases This Week",
      "Weekly Topic Ranking",
      "Open High-Priority Issues",
      "Week-over-Week Comparison",
      "Weekly Activity",
      "Trends and Recommendations",
      "Methodology and Data Notes",
      "Previous Reports"
    ],
    "summary_dashboard": {
      "kpi_metric_order": ["discussion_units", "effective_discussions", "participants", "total_messages"],
      "topic_limit": 6,
      "anomaly_limit": 4,
      "hourly_series": "human_messages",
      "top_user_limit": 10,
      "keyword_limit": 20,
      "compact_keyword_limit": 12
    },
    "comparison_dashboard": {
      "metric_order": ["discussion_units", "participants", "total_messages"],
      "show_topic_change": true,
      "show_focus_shift": true
    }
  },
  "metrics": {
    "current": {
      "discussion_units": 0,
      "effective_discussions": 0,
      "participants": 0,
      "human_messages": 0,
      "assistant_messages": 0,
      "system_messages": 0,
      "unknown_role_messages": 0,
      "total_messages": 0
    },
    "previous": {
      "discussion_units": 0,
      "effective_discussions": 0,
      "participants": 0,
      "human_messages": 0,
      "assistant_messages": 0,
      "system_messages": 0,
      "unknown_role_messages": 0,
      "total_messages": 0
    }
  },
  "topics": [
    {
      "rank": 1,
      "name": "Topic name",
      "current": {"discussion_units": 0, "participants": 0, "human_messages": 0},
      "previous": {"discussion_units": 0, "participants": 0, "human_messages": 0},
      "delta_pct": 0.0,
      "keywords": [],
      "insight": ""
    }
  ],
  "keywords": [
    {"rank": 1, "keyword": "Memory", "current_count": 0, "previous_count": 0, "delta_pct": 0.0}
  ],
  "activity": {
    "daily": [
      {"date": "YYYY-MM-DD", "human_messages": 0, "assistant_messages": 0, "total_messages": 0}
    ],
    "hourly": [
      {"hour": 0, "human_messages": 0}
    ],
    "peaks": {
      "top_hours": [{"hour": 0, "messages": 0}],
      "top_day": {"date": "YYYY-MM-DD", "messages": 0}
    },
    "top_users": [
      {"rank": 1, "display_name": "Q*n", "messages": 0, "discussion_units": 0, "keywords": []}
    ],
    "response_metrics": {
      "available": false,
      "answered_discussions": null,
      "answer_rate_pct": null,
      "median_latency_seconds": null,
      "p90_latency_seconds": null,
      "method": ""
    }
  },
  "releases": [
    {
      "version": "vX.Y.Z",
      "published_at": "YYYY-MM-DDTHH:mm:ss+08:00",
      "type": "main|hotfix|component",
      "url": null,
      "highlights": [],
      "reliability_fixes": [],
      "breaking_changes": [],
      "related_topics": [],
      "evidence": []
    }
  ],
  "anomalies": [
    {
      "rank": 1,
      "title": "Issue title",
      "short_label": "Short label for the dashboard risk card",
      "priority": "P1",
      "category": "Category",
      "background": "",
      "user_impact": "",
      "evidence": "",
      "current_assessment": "",
      "community_feedback": "",
      "unresolved_at_cutoff": true,
      "chat": [
        {"time": "MM-DD HH:mm", "speaker": "Q*n", "message": "Masked human message"}
      ]
    }
  ],
  "comparison": {
    "available": true,
    "metric_conclusion": "",
    "topic_conclusion": "",
    "focus_shifts": [
      {"previous_focus": "", "current_focus": "", "interpretation": ""}
    ],
    "overall_conclusion": ""
  },
  "recommendations": [
    {"rank": 1, "observation": "", "impact": "", "action": ""}
  ],
  "history": [
    {"title": "Previous report title", "url_or_path": "verified link or relative path"}
  ]
}

前期間のデータがない場合は、metrics.previous を null に設定し、各トピックおよびキーワードの previous／delta_pct の値を null に設定し、comparison.available=false に設定して、その理由を文章で説明してください。捏造した前期間の全ゼロ値を残してはいけません。

Markdown テンプレート

---
report_schema: qa-report.v3
report_type: openviking_qa_weekly
timezone: Asia/Shanghai
current_start: YYYY-MM-DDTHH:mm:ss+08:00
current_end: YYYY-MM-DDTHH:mm:ss+08:00
previous_start: YYYY-MM-DDTHH:mm:ss+08:00
previous_end: YYYY-MM-DDTHH:mm:ss+08:00
generated_at: YYYY-MM-DDTHH:mm:ss+08:00
---

# OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD

## Executive Summary

- Reporting window: ...
- Weekly volume: ...
- Participation: ...
- Leading topics: ...
- Peak period: ...
- Main conclusion: ...

## Releases This Week

| Version | Time | Type | Highlights | Upgrade Notes | Session Evidence |
| --- | --- | --- | --- | --- | --- |

## Weekly Topic Ranking

| Rank | Topic | Discussion Units | Participants | Human Messages | Keywords | Insight |
| ---: | --- | ---: | ---: | ---: | --- | --- |

### Top 20 Keywords

| Rank | Keyword | Current | Previous | Change |
| ---: | --- | ---: | ---: | ---: |

## Open High-Priority Issues

### 1. Issue Title

- **Priority / Category:** P1 / ...
- **Background:** ...
- **User Impact:** ...
- **Evidence:** ...
- **Current Assessment:** ...
- **Community Feedback:** ...

#### Human Feedback Excerpt

> **Time | Masked Name**
> Message...

## Week-over-Week Comparison

### Core Metrics

| Metric | Previous | Current | Absolute Change | Percentage Change |
| --- | ---: | ---: | ---: | ---: |

### Topic Heat Changes

| Topic | Previous | Current | Change | Interpretation |
| --- | ---: | ---: | ---: | --- |

### Focus and Discussion Shifts

| Previous Focus | Current Focus | Interpretation |
| --- | --- | --- |

## Weekly Activity

### Activity Overview
### Daily Distribution
### Peak-Time Line Chart
### 24-Hour Data
### Top 10 Active Community Members

## Trends and Recommendations

1. ...

## Methodology and Data Notes

- Data directory, discovered files, and included scope.
- Both time windows, timezone, and actual data coverage.
- Deduplication, roles, discussion units, effective discussions, and multi-label topic definitions.
- Malformed lines, missing timestamps, unknown roles, and coverage gaps.
- Display-name resolution and masking rules.

## Previous Reports

- [OpenViking Community Q&A Weekly Report: YYYY-MM-DD to YYYY-MM-DD](verified link or path)

## Appendix: Structured Report Data


```json
{complete qa-report.v3 object}
```

エンドツーエンドの手順

1. sessions_root をスキャンし、ディレクトリ、ファイル名のプレフィックス、メタデータから対象のセッションセットを特定します。
2. すべての JSONL 行を解析し、不正な行、タイムスタンプの欠落、不明なロール、実際のデータ範囲を記録します。
3. 期間が連続し、同じ長さになるように現在のウィンドウと前のウィンドウを決定します。前のウィンドウの生データがない場合は、previous_report を読み込みます。
4. メッセージのフィールド、ロール、タイムスタンプを正規化してから、メッセージと重複したセッションのエクスポートを重複排除します。
5. 表示名はセッションの内容からのみ特定し、マスキングを適用して、機密情報をスキャンします。
6. 両方のウィンドウについて、ディスカッション単位、有効なディスカッション、参加者、メッセージの指標を計算します。
7. すべてのセッションのダイジェストを作成し、安定したトピック分類に基づいて分類して、件数が最も多いトピックを手作業でサンプリングします。
8. Top 20 キーワード、日次および時間別の系列、ピーク、活動が最も多い人間の Top 10 を計算します。
9. 候補となる各問題について、その後のメッセージをたどり、カットオフまでに解決した証拠がない P1 の問題だけを残します。
10. セッションから、明示されたリリース完了のシグナルを抽出します。計画段階のリリースは数えないでください。
11. 主要な指標、トピック、キーワード、注目分野を比較し、実行可能な推奨事項を作成します。
12. 完全な qa-report.v3 オブジェクトを先に組み立て、その同じオブジェクトから Markdown の文章と Mermaid の両方を生成して、数値のずれを防ぎます。
13. 最終 JSON を再解析し、表、計算式、順序、24 時間の系列、マスキング、すべてのドキュメント／ホワイトボードのフィールドを検証します。

受け入れチェックリスト

• 最終成果物は、テンポラリスクリプトやキャッシュがなくても理解できる、自己完結型の .md ファイル1つです。
• 分析データはすべて対象セッションと任意の前回の Markdown レポートから取得され、他のメッセージソースは混在していません。
• フロントマターで report_schema: qa-report.v3 が宣言され、最終的な JSON は正常に解析できます。
• タイトルの日付は現在の期間と一致しています。現在と前回の期間は同じ長さで、連続しており、重複していません。
• 検出、採用、除外したファイル数、不正な行数、データの網羅率が記録されています。
• メッセージのロールと合計数に矛盾がなく、不明なロールを暗黙に人間として扱っていません。
• 週間ランキングには、議論単位、参加者、人間のメッセージ、キーワード、インサイトが含まれています。
• 週間アクティビティには、日別の表、24時間すべてを網羅した表、折れ線グラフ、ピーク、Top 10 が含まれています。
• 比較では規模、トピック、注力分野の変化を取り上げ、比較可能な履歴がない場合はその旨を明示しています。
• リリースには、セッションで確認された完了状態のものだけを含めています。証拠が不十分な場合は、その旨を明記しています。
• 未解決の課題には、カットオフ前に解決の証拠がない P1 項目のみを含め、各項目に6つのフィールドすべてと、それぞれに対応する人間の抜粋を記載しています。
• 人間の抜粋にアシスタントの返信、創作したメッセージ、内部リンクは含まれていません。
• 人名はすべてマスキングされています。完全な氏名、内部ID、認証情報はレポートに含まれていません。
• activity.hourly は0から23の順で並び、エントリーはちょうど24件です。daily は現在の期間のすべての日付範囲を網羅しています。
• Top 10、Top 20、トピックランキング、すべての変化率は再現可能です。
• 構造化データは、サマリーダッシュボード、比較ダッシュボード、P1本文セクション、シミュレートされたチャットモジュールを直接生成するのに十分な内容を備えています。
• 前回レポートの項目は、検証済みのリンクまたはパスのみを引き継ぎ、過去のURLを捏造していません。